Mailing-List: contact issues-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 10 Dec 2016 23:13:58 +0000 (UTC)
From: "jakub-g (JIRA)" <jira@apache.org>
To: issues@cordova.apache.org
Message-ID: <JIRA.13027222.1481411431000.491909.1481411638443@Atlassian.JIRA>
In-Reply-To: <JIRA.13027222.1481411431000@Atlassian.JIRA>
References: <JIRA.13027222.1481411431000@Atlassian.JIRA> <JIRA.13027222.1481411431051@arcas>
Subject: [jira] [Updated] (CB-12232) [cordova-android] Skipping HTTPS
 certificate validation should be hidden behind a flag
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Sat, 10 Dec 2016 23:14:00 -0000


     [ https://issues.apache.org/jira/browse/CB-12232?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:all-tabpanel ]

jakub-g updated CB-12232:
-------------------------
    Description:=20
Right now, when you create a debuggable Cordova build (default behavior for=
 commands like `cordova run android` etc.), it by default ignores all HTTPS=
 certificate errors, as you can see in the code below:

https://github.com/apache/cordova-android/blob/23fd0982b0faa6b7e169c2946eab=
07930f1f4d16/framework/src/org/apache/cordova/engine/SystemWebViewClient.ja=
va#L232-L239

HTTPS certs are only validated when you create a release build, explicitly =
passing a flag, e.g. `cordova run android --release`

This behavior is IMO harmful, and let me tell you why (see below for two re=
al-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-certificate=
-errors`, but we can name it whatever we like). This would expose developer=
s to HTTPS errors much earlier in the dev process, which IMO is beneficial;=
 it will also make it easier to understand and debug the problems, and avoi=
d last-minute surprises.**

*Question: do we have a portion of code already that makes runtime behavior=
 depend on build-time flag? i.e. would it be easy to add a new flag in a si=
milar way, without herculean effort?*

So, the promised real-life stories:

1) Consider, that you have an HTTPS website and your HTTPS certificate is s=
omehow invalid (but you don't know about that). You develop your stuff *for=
 weeks and weeks* in debug builds and everything is great. You prepare for =
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 baffled.

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 minific=
ation? some issue with signing keys? Cordova/Chrome/Android are broken?), f=
inally after a while you reach to google and you figure out the issue is du=
e 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 name=
. 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, but=
 you ask the ops team to update the server.

They get a better cert and update server config to send the intermediary ce=
rt. 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 produc=
tion, all is well. One day, you change the HTTPS cert in production (becaus=
e an old one expired etc.), you do quick tests, all is well (or, even worse=
: when in big corporation, ops guys change the HTTPS cert without telling y=
ou). You forget about it, and continue developing your app. You're a dev an=
d you're constantly in the Chrome DevTools, so naturally you always build d=
ebuggable builds. You keep adding features for weeks, all works great in yo=
ur debuggable builds. Your QAs do tests and most often stuff works great, b=
ut sometimes they're getting weird connection issues. First they think it's=
 some weird connectivity issue, but the issues happen more often. After a w=
hile you investigate, and issue happens *only with --release builds* and *o=
nly on production server*. There's a fire in production, but no one noticed=
 for quite a while since the QA test features mostly on staging servers, an=
d devs work with staging servers too, and use debuggable builds most of the=
 time - and the --release sanity targeting production happens only at the e=
nd of the sprint.

But finally someone connects the dots that --release builds targeting produ=
ction server do not work. You want to investigate the issue, and obviously,=
 in debug mode it doesn't happen, whereas in --release mode, you can't conn=
ect to DevTools to see what's going on and test some hypotheses.

Finally you dig hard into the topic and learn about `onReceivedSslError` an=
d change it to never ignore the errors, and redo the build. Issue is reprod=
ucible in debuggable build now, so now that you know it's HTTPS, you look a=
gain 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 early=
 55 which rejects Symantec-issued certs: http://android.stackexchange.com/q=
/164066/165570)

  was:
Right now, when you create a debuggable Cordova build (default behavior for=
 commands like `cordova run android` etc.), it by default ignores all HTTPS=
 certificate errors, as you can see in the code below:

https://github.com/apache/cordova-android/blob/23fd0982b0faa6b7e169c2946eab=
07930f1f4d16/framework/src/org/apache/cordova/engine/SystemWebViewClient.ja=
va#L232-L239

HTTPS certs are only validated when you create a release build, explicitly =
passing a flag, e.g. `cordova run android --release`

This behavior is IMO harmful, and let me tell you why (see below for two re=
al-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 (t=
o follow Chrome's naming convention, that would be  `--ignore-certificate-e=
rrors`, but we can name it whatever we like). This would expose developers =
to HTTPS errors much earlier in the dev process, which IMO is beneficial; i=
t 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 behavior=
 depend on build-time flag? i.e. would it be easy to add a new flag in a si=
milar way, without herculean effort?*

So, the promised real-life stories:

1) Consider, that you have an HTTPS website and your HTTPS certificate is s=
omehow invalid (but you don't know about that). You develop your stuff *for=
 weeks and weeks* in debug builds and everything is great. You prepare for =
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 baffled.

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 minific=
ation? some issue with signing keys? Cordova/Chrome/Android are broken?), f=
inally after a while you reach to google and you figure out the issue is du=
e 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 name=
. 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, but=
 you ask the ops team to update the server.

They get a better cert and update server config to send the intermediary ce=
rt. 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 produc=
tion, all is well. One day, you change the HTTPS cert in production (becaus=
e an old one expired etc.), you do quick tests, all is well (or, even worse=
: when in big corporation, ops guys change the HTTPS cert without telling y=
ou). You forget about it, and continue developing your app. You're a dev an=
d you're constantly in the Chrome DevTools, so naturally you always build d=
ebuggable builds. You keep adding features for weeks, all works great in yo=
ur debuggable builds. Your QAs do tests and most often stuff works great, b=
ut sometimes they're getting weird connection issues. First they think it's=
 some weird connectivity issue, but the issues happen more often. After a w=
hile you investigate, and issue happens *only with --release builds* and *o=
nly on production server*. There's a fire in production, but no one noticed=
 for quite a while since the QA test features mostly on staging servers, an=
d devs work with staging servers too, and use debuggable builds most of the=
 time - and the --release sanity targeting production happens only at the e=
nd of the sprint.

But finally someone connects the dots that --release builds targeting produ=
ction server do not work. You want to investigate the issue, and obviously,=
 in debug mode it doesn't happen, whereas in --release mode, you can't conn=
ect to DevTools to see what's going on and test some hypotheses.

Finally you dig hard into the topic and learn about `onReceivedSslError` an=
d change it to never ignore the errors, and redo the build. Issue is reprod=
ucible in debuggable build now, so now that you know it's HTTPS, you look a=
gain 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 early=
 55 which rejects Symantec-issued certs: http://android.stackexchange.com/q=
/164066/165570)


> [cordova-android] Skipping HTTPS certificate validation should be hidden =
behind a flag
> -------------------------------------------------------------------------=
-------------
>
>                 Key: CB-12232
>                 URL: https://issues.apache.org/jira/browse/CB-12232
>             Project: Apache Cordova
>          Issue Type: Improvement
>          Components: Android
>    Affects Versions: 6.2.0
>            Reporter: jakub-g
>              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. `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 t=
o {{--debug}} vs {{--release}} build type, but hide it behind a special fla=
g (to follow Chrome's naming convention, that would be  `--ignore-certifica=
te-errors`, but we can name it whatever we like). This would expose develop=
ers to HTTPS errors much earlier in the dev process, which IMO is beneficia=
l; it will also make it easier to understand and debug the problems, and av=
oid 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 does=
n't work! You want to debug it, but you can't - because `--release` build i=
s non-debuggable! This looks super mysterious and you're totally baffled.
> 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, but the issues happen more often. After a=
 while you investigate, and issue happens *only with --release builds* and =
*only on production server*. There's a fire in production, but no one notic=
ed for 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 t=
he time - and the --release sanity targeting production happens only at the=
 end of the sprint.
> But finally someone connects the dots that --release builds targeting pro=
duction server do not work. You want to investigate the issue, and obviousl=
y, in debug mode it doesn't happen, whereas in --release mode, you can't co=
nnect 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 repr=
oducible in debuggable build now, so now that you know it's HTTPS, you look=
 again at your cert (and here the dragons just start: turns our your cert w=
as issued by Symantec, and there's a webview bug in versions 53, 54 and ear=
ly 55 which rejects Symantec-issued certs: http://android.stackexchange.com=
/q/164066/165570)


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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