cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: Ignoring SSL Errors for InAppBrowser
Date Wed, 21 Aug 2013 13:56:32 GMT
+1 on Joe Bower "Breaking SSL for
InAppBrowser or Cordova itself would be really foolish"

+1 on Raman "a normal browser gives an option to the user in case of a
unverifiable https link, so i suppose this should be the case for Cordova
WebView as well as InAppBrowser, after all you are treating InAppBrowser as
a normal browser window."
I think is the right answer

--Carlos



On Wed, Aug 21, 2013 at 3:53 AM, Joe Bowser <bowserj@gmail.com> wrote:

> It's an open source plugin, which means you can implement your own
> plugin and add this feature.  I'm personally against adding this
> feature.  If you're using Android for the Enterprise, you can install
> your own cert on all the devices you support so that this works and
> have your network even more locked down.  Breaking SSL for
> InAppBrowser or Cordova itself would be really foolish,
>
> On Tue, Aug 20, 2013 at 10:50 PM, Singh, Ramandeep
> <Ramandeep.Singh@barco.com> wrote:
> > Wow, this is really a sad sad decision to not fix this issue (or add
> this functionality in InAppBrowser). Please check these enterprise apps:
> >
> > https://itunes.apple.com/us/app/cinemate/id674386455?mt=8
> > https://play.google.com/store/apps/details?id=com.barco.cinemate
> >
> > These apps do require privately signed URL access and i had to hack my
> way to make it work in InAppBrowser. Lot of people have commented in this
> thread itself that they do need this functionality. As i mentioned earlier,
> it's possible to make it work in the main Cordova WebView by overwriting
> onReceivedSslError(), then why there is no such option in the InAppBrowser?
> In that case, you should remove this option from the main Cordova WebView
> too.
> >
> >>> Joe Bowser wrote:
> >>> After reading the mailing list, it looks like this will NOT be added
> to InAppBrowser, since there is very little reason to add it for a corp >>
> VPN setup. (If your network is so secure, why do you need broken SSL?)
> >
> > Corporate networks or VPNs are secure that's why we usually can't verify
> the https identity through an external certification authority. You can't
> expect them to change https to http for all internal sites just because
> InAppBrowser doesn't handle it or give an option to the user if he wants to
> continue with the link or block it.
> >
> > If you compare InAppBrowser to a normal browser, a normal browser gives
> an option to the user in case of a unverifiable https link, so i suppose
> this should be the case for Cordova WebView as well as InAppBrowser, after
> all you are treating InAppBrowser as a normal browser window.
> >
> > Regards,
> > Raman
> >
> > -----Original Message-----
> > From: Singh, Ramandeep
> > Sent: 24 July 2013 10:59
> > To: 'Josh Soref'; dev@cordova.apache.org
> > Subject: RE: Ignoring SSL Errors for InAppBrowser
> >
> > 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: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