- From: Håvard Molland <haavardm@opera.com>
- Date: Wed, 17 Dec 2014 15:02:31 +0100
- To: Chris Palmer <palmer@google.com>, Sigbjørn Vik <sigbjorn@opera.com>
- CC: "public-webappsec@w3.org" <public-webappsec@w3.org>, blink-dev <blink-dev@chromium.org>, security-dev <security-dev@chromium.org>, "dev-security@lists.mozilla.org" <dev-security@lists.mozilla.org>
On 16. des. 2014 21:10, 'Chris Palmer' via Security-dev wrote: > Well, we do have to make sure that the browser does not send cookies > to an impostor origin. That's (1 reason) why Chrome uses interstitial > warnings today. I've been experimenting with a Chromium patch where the url context is given two cookie stores, "standard" and "insecure https" (this being adapted to the current scheme where we don't warn about http). After the connection has been established but before the request is sent, the appropriate cookies are picked from the stores based on the security state of the connection. Secure cookies going over a good tls connection and all http cookies are picked from the "normal" store, while secure cookies going over a bad tls connection is picked from the "insecure https" store. This stops secure cookies received on a good connection from being sent to an imposter origin. However, to remove the interstitial warning, most offline storages would have to be separated into two caches, to avoid cache poisoning. Examples are appcache, service workers, fileapi, dom storage, indexed db and the standard disk cache. This would be a huge undertaking to get right and maintain. Separating the cookie store still has some value even without removing the interstitial warning though. >> BTW, have you explicitly contacted other browser teams? > This mass mailing is that. Hopefully all the relevant Browser UI teams read these lists. -- --- Opera Software
Received on Wednesday, 17 December 2014 14:04:47 UTC