Android Webapps stop authenticating with client cert after phone/chrome restart
Reported by
xani...@gmail.com,
Apr 26 2018
|
|||||
Issue descriptionSteps to reproduce the problem: 1. Set up a webapp (or whatever is that thing that installs webpage as an icon on home screen) to be behind server that uses client CA for auth - I've used HAProxy + letsencrypt + client cert generated via cfssl 2. Load client CA into Android 3. Go to URL with webapp then install it on home screen (not necessary, just easier to test that way - bug happens even when going to the page directly) - in my case it was HomeAssistant's webapp 4. At that point app works flawlessly 5. Restart phone 6. App complains it can't connect. HAProxy complaints about bad SSL 7. Going either incognito, or going to settings and removing site data "fixes" it till next restart. I assume because webapp is removed. Client certs work fine if I use it on site that does not use web apps. As in, if I clean data and just put a dummy static site then that works no matter how many times I restart, that behaviour starts when I put webapp in What is the expected behavior? After restart it should either remember cert that I've picked the first time I visited site (per webapp, not per site) OR ask which one it should use. It does neither What went wrong? It seems like after installing webapp chrome forgets it is supposed to use client certs. It doesn't even *ask* for one after restart (as opposed to "normal" websites that do) Did this work before? N/A Chrome version: 66.0.3359.126 Channel: stable OS Version: 8.0.0 Flash Version: Tried on 61 (factory chrome install) and it has similar problems
,
Apr 26 2018
A network export will probably be helpful here. Can you capture and attach one? https://www.chromium.org/for-testers/providing-network-details
,
Apr 26 2018
Looks like the problem is that Service Workers in Chrome do not correctly handle client certificates. Service Worker folks, a while ago we discussed this with you and how Service Worker will need a lot of extra work to avoid this kind of lock-up with client certificates, HTTP auth, and proxy auth. I believe the end result was that the Fetch API got a window parameter that, in SW fetch event, fed back to the originating page for network auth purposes. Was this ever implemented?
,
May 11 2018
horo: do you know the status of the certificate thing? Could you triage it?
,
May 25 2018
,
Jun 10 2018
I don't understand what this is, but I suspect the nature of this issue will change a lot after NetworkService, possibly going away entirely.
,
Jun 11 2018
I don't think the NetworkService will change this particular behaviour. This is about whether or not an SW has a Window to attach to to provide the prompt to. If not, it's expected not to work.
,
Jun 11 2018
What's the basic flow we're looking for? The browser can certainly know the tab/window that made the fetch request that the service worker intercepted.
,
Jun 11 2018
Network requests can trigger browser UI (client certs, HTTP server auth, HTTP proxy auth), which depends on the window. That needs to go through the request's window: https://fetch.spec.whatwg.org/#concept-request-window https://fetch.spec.whatwg.org/#dom-requestinit-window https://fetch.spec.whatwg.org/#ref-for-dom-requestinit-window https://fetch.spec.whatwg.org/#http-network-fetch (note this refers to the request's window throghout) So if do the default thing with a SW, UI should still work. If you fetch of your own accord and disassociate the request from the window, that should not work and we'll decline to let you do auth. Without implementing this, sites that use SW alongside these auth methods (along with normal sites where the user happens to be behind a proxy) may find themselves blackholed themselves once the SW is installed after the previously cached auth info clears. (If I remember my history right, the window parameter of request was added to address exactly this problem. We brought it up when SW was first being implemented.)
,
Nov 28
This should be fixed via issue 894484 which is slated to be fixed in M71 stable. Please reopen if that's not case. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by elawrence@chromium.org
, Apr 26 2018Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug
Summary: Android Webapps stop authenticating with client cert after phone/chrome restart (was: Android Webapps stops authenticating with client CA after phone/chrome restart)