- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Fri, 17 Feb 2017 06:52:45 +0200 (EET)
- To: HTTP working group mailing list <ietf-http-wg@w3.org>
- CC: Adrien de Croy <adrien@qbik.com>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Ryan Hamilton <rch@google.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
> But if the proxy can mint certs that are trusted by the browser, the > question is how is that. The proxy would need to be using a signing > cert that is trusted by the browser, and how did it get installed in the > browser? If proxy CA certificate can be installed to browser, then it is also possible to install browser plugin to browser. That browser plugin can implement some kind sidechannel. But different browsers and OSes, cpus need all diffrent plugin. Proxy CA certificate format does not change here. I see why that direction is selected. And network border (or proxy) need some way to verify plugin is active and sidechannel is in use on many use scenario. Otherwise may be even disabled accidentally on browser update. Hmm. One radical sidechannel is what tells symmectric encryption key of TLS connection. I guess that this is not acceible for browser plugin either. In that case proxy can verify that it have symmectric encryption key for TLS connection. Internet Content Adaptation Protocol (ICAP, RFC 3507) can perhaps act as standardised sidechannel protocol, but that does not look like practical and is is not implemneted by browsers. Basically that means that content is moved several times. And also network border (or proxy) can not verify that sidechannel is on use. / Kari Hurtta
Received on Friday, 17 February 2017 04:53:25 UTC