- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Wed, 2 Dec 2015 04:21:34 +1300
- To: ietf-http-wg@w3.org
On 2/12/2015 3:56 a.m., Roland Zink wrote: > Am 01.12.2015 um 15:02 schrieb Amos Jeffries: >> On 1/12/2015 12:15 p.m., Roland Zink wrote: >>> Am 30.11.2015 um 21:10 schrieb Walter H.: >>>> On 30.11.2015 13:22, Amos Jeffries wrote: >>>>> The point of this draft is the same. When anything is encrypted with >>>>> intentio that the recipient acts on the decrypted content in ways >>>>> other than saving it to a file - the sender emits the appropriate C-E >>>>> header that says its crypted (and how). Such that the recipient can >>>>> decrypt if/when it has the ability. >>>> in comparison to encrypted end-to-end encrypted E-mails, there is the >>>> same problem; this draft is the same bad idea than the >>>> publishing the public keys to the wide ... >>>> >>> TLS is also end-to-end >>> >> That is a false statement. >> >> TLS is point-to-point. There is no requirement in TLS that point-B on >> the conection be the origin server. > >> Very often in CDN network HTTPS it is actually not the origin server but >> a TLS offloader / load balancer at least one hops in front of a whole >> LAN or farm of origins. >> >> One CDN I recently helped diagnose traffic bugs within had 8 distinct >> connection hops from the frontend HTTPS terminating device to the origin >> server. Over three separate TLS connections and a VPN (non-TLS) >> connection across two continents. >> > It is possible to see it this way. However the TLS endpoint pretends to > be the origin server and proofs this with a certificate. Not sure if the > things behind it should be name origin server. A TLS interception proxy / MITM pretends the same and also proofs using a certificate the client trusts (through a different CA). So by your interpretation it should be "the origin"? Amos
Received on Tuesday, 1 December 2015 15:22:12 UTC