Singh, my 2 cents
When you have app that need to access privale signed URLs, my recommendation is to add to the mobile device the certificate of the CA that was used to signed the private URL. Most mobile operating systems support installing certificates for private/internal CA (Certificate Authorities) via different methods. If you absolutely need to access an URL that can't be validated at least present a popup message to the user so he can verify the fingerprint and decide if its a real attack or not. This is the behavior on desktop and mobile browsers, there is no reason why Apps hybrid or native would skip this security measure. --Carlos On Wed, Aug 7, 2013 at 12:54 AM, Singh, Ramandeep <ramandeep.si...@barco.com > wrote: > Andrew > > Some enterprise apps allow access to their own intranet sites with > privately signed certificates. Such apps can't connect to internet usually > so there's no way to verify the certificates. > As I mentioned earlier, it's pretty easy to access privately signed URLs > within the main Cordova web view by overwriting onReceivedSslError() > function but there's no way to do it in InAppBrowser currently. > I had to develop an enterprise app which allowed privately signed URLs and > I had to face this issue in InAppBrowser and I am sure many other people > would be facing the same issue. > > 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>
