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, 24 Jul 2013 00:43:19 GMT
I don't think it's very often that a phone will connect only through an
enterprise network.

I guess my thinking is that if the feature is used in any way (whitelist,
JS callbacks, window.open attribute), then the app will be vulnerable to
man-in-the-middle attacks. Still, disabling verification can be convenient
when doing local development. I'd hate for someone to forget to flip the
switch back on though...

Maybe the right answer is to implement our own warning interstitial? That
way it *is* recoverable, but still warns the user.




On Tue, Jul 23, 2013 at 5:29 PM, Josh Soref <jsoref@blackberry.com> wrote:

> I should have included a citation:
> https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
>
> > -----Original Message-----
> > From: Ken Wallis [mailto:kwallis@blackberry.com]
> > Sent: Tuesday, July 23, 2013 5:20 PM
> > To: dev@cordova.apache.org
> > Subject: RE: Ignoring SSL Errors for InAppBrowser
> >
> > It came up this morning that Enterprise could use something like this.
> An app
> > that is deployed into the Enterprise secure container, already being
> > enforced/controlled by corporate firewall etc., and approved for use
> internally
> > might want "blanket" access to any internal domain.
> > --
> >
> > Ken Wallis
> >
> > Senior Product Manager - WebWorks
> >
> > BlackBerry
> >
> > 289-261-4369
> >
> > ________________________________________
> > From: Josh Soref [jsoref@blackberry.com]
> > Sent: Tuesday, July 23, 2013 1:20 PM
> > To: dev@cordova.apache.org
> > Cc: ramandeep.singh@barco.com
> > 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 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 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.
>

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