Mailing-List: contact issues-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 4 Dec 2017 21:30:00 +0000 (UTC)
From: "jakub-g (JIRA)" <jira@apache.org>
To: issues@cordova.apache.org
Message-ID: <JIRA.13027222.1481411431000.382490.1512423000963@Atlassian.JIRA>
In-Reply-To: <JIRA.13027222.1481411431000@Atlassian.JIRA>
References: <JIRA.13027222.1481411431000@Atlassian.JIRA> <JIRA.13027222.1481411431051@jira-lw-us.apache.org>
Subject: [jira] [Comment Edited] (CB-12232) [cordova-android] Skipping HTTPS
 certificate validation should be hidden behind a flag, and not a default in
 debug builds
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Mon, 04 Dec 2017 21:30:10 -0000


    [ https://issues.apache.org/jira/browse/CB-12232?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D162775=
43#comment-16277543 ]=20

jakub-g edited comment on CB-12232 at 12/4/17 9:29 PM:
-------------------------------------------------------

Hmm to fix the problem of people only checking Chrome DevTools and not logc=
at, maybe what could be done is calling the following inside of `onReceived=
SslError`:

{code}
        webView.evaluateJavascript("console.warn('SSL error for $domain....=
.......')");
{code}

so basically double logging (on Java and JavaScript side). That would be di=
fficult to miss to anyone doing any serious work.


was (Author: jakub-g):
Hmm to fix the problem of people only checking Chrome DevTools and not logc=
at, maybe what could be done is calling the following inside of `onReceived=
SslError`:

    webView.evaluateJavascript("console.warn('SSL error for $domain........=
...')");

so basically double logging (on Java and JavaScript side). That would be di=
fficult to miss to anyone doing any serious work.

> [cordova-android] Skipping HTTPS certificate validation should be hidden =
behind a flag, and not a default in debug builds
> -------------------------------------------------------------------------=
------------------------------------------------
>
>                 Key: CB-12232
>                 URL: https://issues.apache.org/jira/browse/CB-12232
>             Project: Apache Cordova
>          Issue Type: Improvement
>          Components: cordova-android
>    Affects Versions: 6.2.0
>            Reporter: jakub-g
>            Priority: Critical
>              Labels: android
>
> Right now, when you create a debuggable Cordova build (default behavior f=
or commands like `cordova run android` etc.), it by default ignores all HTT=
PS certificate errors, as you can see in the code below:
> https://github.com/apache/cordova-android/blob/23fd0982b0faa6b7e169c2946e=
ab07930f1f4d16/framework/src/org/apache/cordova/engine/SystemWebViewClient.=
java#L232-L239
> HTTPS certs are only validated when you create a release build, explicitl=
y passing a flag, e.g.=20
> {{cordova run android --release}}
> This behavior is IMO harmful, and let me tell you why (see below for two =
real-life stories)
> *TL;DR I believe it would be better to not bind the lax HTTPS behavior to=
 {{\-\-debug}} vs {{\-\-release}} build type, but hide it behind a special =
flag (to follow Chrome's naming convention, that would be {{\-\-ignore-cert=
ificate-errors}}, but we can name it whatever we like). This would expose d=
evelopers to HTTPS errors much earlier in the dev process, which IMO is ben=
eficial; it will also make it easier to understand and debug the problems, =
and avoid last-minute surprises.*
> _Question: do we have a portion of code already that makes runtime behavi=
or depend on build-time flag? i.e. would it be easy to add a new flag in a =
similar way, without herculean effort?_
> So, the promised real-life stories:
> 1) Consider, that you have an HTTPS website and your HTTPS certificate is=
 somehow invalid (but you don't know about that). You develop your stuff _f=
or weeks and weeks_ in debug builds and everything is great. You prepare fo=
r grand APK upload to Play Store, do a {{\-\-release}} build, and... stuff =
doesn't work! You want to debug it, but you can't - because {{\-\-release}}=
 build is non-debuggable! This looks super mysterious and you're totally ba=
ffled.
> Doing black-box debugging on --release build ain't easy, but you give it =
a try.
> You're thinking about all possible things that could go wrong (code minif=
ication? some issue with signing keys? Cordova/Chrome/Android are broken?),=
 finally after a while you reach to google and you figure out the issue is =
due to cordova only checking HTTPS certs in {{\-\-release}} mode.
> People tell about self-signed certs, but your cert looks legit, after all=
, it works on all desktop client. But at least you know where to look.
> Luckily for you, the staging platform has a publicly accessible domain na=
me. You test your cert with SSLLabs and it tells you that your server doesn=
't send all intermediary certs. It's still not sure if this is the issue, b=
ut you ask the ops team to update the server.
> They get a better cert and update server config to send the intermediary =
cert. You're saved! This was the missing piece to make the app work.
> 2) Suppose you never had the issue 1), you built an app, it works in prod=
uction, all is well. One day, you change the HTTPS cert in production (beca=
use an old one expired etc.), you do quick tests, all is well (or, even wor=
se: when in big corporation, ops guys change the HTTPS cert without telling=
 you). You forget about it, and continue developing your app. You're a dev =
and you're constantly in the Chrome DevTools, so naturally you always build=
 debuggable builds. You keep adding features for weeks, all works great in =
your debuggable builds. Your QAs do tests and most often stuff works great,=
 but sometimes they're getting weird connection issues. First they think it=
's some weird connectivity issue (poor WiFi etc.), but the issues happen mo=
re often. Turns out the issue happens _only with --release builds_ and _onl=
y on production server_. There's a fire in production, but no one noticed f=
or quite a while since the QA test features mostly on staging servers, and =
devs work with staging servers too, and use debuggable builds most of the t=
ime - and the --release sanity targeting production happens only every N we=
eks before loading to production.
> But finally someone connects the dots that only --release builds targetin=
g production server do not work. You want to investigate the issue, and obv=
iously, in debug mode it doesn't happen, whereas in --release mode, you can=
't connect to DevTools to see what's going on and test some hypotheses.
> Finally you dig hard into the topic and learn about {{onReceivedSslError}=
} and change it to never ignore the errors, and redo the build. Issue is re=
producible in debuggable build now, so now that you know it's HTTPS, you lo=
ok again at your cert (and here the dragons just start: turns our your cert=
 was issued by Symantec, and there's a webview bug in versions 53, 54 and e=
arly 55 which rejects Symantec-issued certs: http://android.stackexchange.c=
om/q/164066/165570 !)
> As you can see, quite a lot of those hassles would have been avoided if s=
trict HTTPS was the default rule.
> Ok, to be honest, if the default is strict HTTPS, the developer will stil=
l be baffled if stuff doesn't work when connecting to his platform in debug=
 build (particularly if the issue is with missing intermediary certs), and =
we should think about how to make this more discoverable, but, being at lea=
st able to observe request failure in devtools is already a major step forw=
ard!


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@cordova.apache.org
For additional commands, e-mail: issues-help@cordova.apache.org