Yeah, I think I agree Carlos - if you're environment is a locked down intranet, why bother using SSL?
On Wed, Aug 7, 2013 at 11:09 AM, Carlos Santana <csantan...@gmail.com>wrote: > 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> >
