Very Short Answer: - Big No: do not put this on Apache Core - Check other inAppBrowers in Apps that you use everyday (Try opening this link https://www.cacert.org/images/cacert4.png inside your facebook, twitter, or mobile safari)
Short Answer: - Allowing Dev to put a skip a invalid ssl certificate is very bad. - Bad UX : User needs to be inform about the problem with invalid certificate - Puts the App Dev in a potential liability problem - Bad reputation for Apache Cordova Project (i.e. Allowing developers to shoot them self on the foot, it will be the dev faults but their will be other that will blame Cordova framework as having a security hole) - Bad Security Practice Medium Answer: - I spent or waisted several weeks (how ever you want to see it) in this area on an App ( http://ibm.com/systems/flex/fsm/mobile ) we developed - Version 1.0 (Dec 2012) forced users to have the end https service that they were connecting with the App with a valid SSL - Version 1.1 (April 2013) if invalid https certificate (self sign, expired, not matching domain, etc..) it will prompt the same way Android and iOS stock browsers prompts to cancel, continue or cancel. - You need to give a user a prompt with either an error message like twitter app on iOS, or give options to continue after user have a chance to inspect SHA sum to make sure it matches the trusted https server Long Answer: - I can provide sample code for cordova-ios and sample App on how we implemented this prompt for Android, and iOS. For BB7 the OS takes care of the prompting (which I think all mobile OSs should handle this) - For iOS it was more work, I worked with Apple Dev Support and they helped me out with invalid https connection using webview and I open a few bugs against Apple to improve their API that is available in OSX but not iOS - I can also setup a "meeting" google hangout if people have more question about ssl certificates and validation - I can also provide a blog post or article about this since I found it difficult to find good resources on this topic including creating your own CA for self sign or internal CA, dual ssl trusting client certificate, etc.. Fine print: I'm not a certified securoty/ssl specialist but I had a lot nightmares trying to solve this for our App :-) Resources: More Info here on installing trust cert on mobile OS, and how we changed our statement from your must have a valid https vs. you will get prompt up to you if you want to continue https://www.ibm.com/developerworks/community/forums/html/topic?id=47c1f1de-61da-4b31-8168-9db50452d4d7 Apple AdvancedURLConnections Sample dealing with invalid HTTPS certificates http://developer.apple.com/library/ios/#samplecode/AdvancedURLConnections/Introduction/Intro.html --Carlos On Wed, Jul 24, 2013 at 9:01 AM, Andrew Grieve <agri...@chromium.org> wrote: > Raman, > > Do you know why this is the case for enterprise apps? Are they just > insecure, or are they providing security in some other fashion? Perhaps we > should be adding the ability to install known valid certificates at build > time for their use-case? > > > On Wed, Jul 24, 2013 at 1:29 AM, Singh, Ramandeep < > ramandeep.si...@barco.com > > wrote: > > > Hi > > > > Many enterprise apps require functionality to access self-signed URLs so > > this option is really missing in the InAppBrowser. In the main PhoneGap > web > > view, one can overwrite a public function (onReceivedSslError()) to allow > > self-signed URLs so something similar should be possible in the > > InAppBrowser too. You can check the following app which has been made > using > > PhoneGap: > > > > Regards, > > Raman > > > > -----Original Message----- > > From: Josh Soref [mailto:jso...@blackberry.com] > > Sent: 24 July 2013 01:51 > > To: dev@cordova.apache.org > > Cc: Singh, Ramandeep > > Subject: RE: Ignoring SSL Errors for InAppBrowser > > > > A simple flag is definitely wrong... a static whitelist could be > > interesting. > > > > Are there real use cases beyond `localhost`? > > > > If someone whitelists any site that isn't on the local device, then when > > I'm in an Internet Café, the wrong thing can happen (and in certain > cases, > > the wrong thing probably will happen). > > > > Making it easy for people to write broken applications doesn't seem to be > > a good "value-add". Unfortunately, people will do the wrong thing and not > > care about their customers.... > > > > But, this is just my personal opinion.... > > > > > -----Original Message----- > > > From: Shazron [mailto:shaz...@gmail.com] > > > Sent: Tuesday, July 23, 2013 3:40 PM > > > To: dev@cordova.apache.org > > > Cc: ramandeep.si...@barco.com > > > Subject: Re: Ignoring SSL Errors for InAppBrowser > > > > > > Why the js callback and not just the static white-list? > > > the js callback allows someone to change the security rules at runtime > > > which could be a hole I suppose. > > > > > > > > > On Tue, Jul 23, 2013 at 12:26 PM, Andrew Grieve > > > <agri...@chromium.org>wrote: > > > > > > > https://issues.apache.org/jira/browse/CB-3576 > > > > > > > > There are pulls request for adding to iOS & Android that add: > > > > > > > > window.open(url, '_blank', 'location=yes,validatessl=no'); > > > > > > > > > > > > Given that this is security-related though, I wanted to get more > > > > eyes on it. Other proposals are to have each questionable cert go > > > > through a JS > > > > callback: > > > > > > > > var iab = window.open(...); > > > > iab.onSSLError = function(url) { > > > > return !!/^https://myalloweddomain.com\//.exec(url); > > > > }; > > > > > > > > Or to add a white-list to your config.xml for allowed self-signed > > https: > > > > addresses. > > > > > > > > If your app is not going to validate ssl certs, then perhaps > > > > restricting the scope of it isn't really increasing security > > > > anyways. It's certainly useful for development to be able to turn it > > > > off, but maybe for that reason we should turn it off globally with a > > <preference> tag? > > > > > > > > Thoughts? Willingness from other platforms? > > > > > > > > --------------------------------------------------------------------- > > This transmission (including any attachments) may contain confidential > > information, privileged material (including material protected by the > > solicitor-client or other applicable privileges), or constitute > non-public > > information. Any use of this information by anyone other than the > intended > > recipient is prohibited. If you have received this transmission in error, > > please immediately reply to the sender and delete this information from > > your system. Use, dissemination, distribution, or reproduction of this > > transmission by unintended recipients is not authorized and may be > unlawful. > > This message is subject to the following terms and conditions: > > http://www.barco.com/en/maildisclaimer > > > -- Carlos Santana <csantan...@gmail.com>
