cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Ignoring SSL Errors for InAppBrowser
Date Wed, 07 Aug 2013 19:21:58 GMT
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 <csantana23@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.Singh@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:jsoref@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:shazron@gmail.com]
> > > Sent: Tuesday, July 23, 2013 3:40 PM
> > > To: dev@cordova.apache.org
> > > Cc: ramandeep.singh@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
> > > <agrieve@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
> <csantana23@gmail.com>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message