- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 1 Dec 2015 09:33:47 +0100
- To: "Walter H." <Walter.H@mathemainzel.info>, Roland Zink <roland@zinks.de>
- Cc: Jim Manico <jim@manicode.com>, ietf-http-wg@w3.org
On 2015-12-01 09:22, Walter H. wrote: > On 01.12.2015 01:19, Roland Zink wrote: >> Am 01.12.2015 um 00:32 schrieb Jim Manico: >>> > TLS is also end-to-end >>> >>> No way is that true. TLS per the standard can be MITM'ed by proxies >>> in ways that subvert both certificate pinning and HSTS in ways that >>> do NOT inform the user in any browser today. I'm happy to provide >>> references to this if you like. >>> >> The browser will build a end to end TLS tunnel through known proxies. >> Intercepting proxies may do MITM and > and exact these intercepting proxies can't validate this content, if it > contains malware or not; > as I said, THIS DRAFT IS NONSENS; Are you promoting the concept of intercepting proxies that break up HTTPS? >> RFC7469 says it is allowed for clients to turn off pin validation >> based on some policy and still be compliant. Is this what you want to >> reference? >> >> However it is also compliant to not do this and do pin validation. >> > what does this help preventing clients receiving malware, that will be > raised through this draft? Privacy and the ability for third-parties to inspect the contents obviously are conflicting goals. Nothing new here. One reason for the use of encrypted content in a "blind cache" is to allow caching of HTTPS content without having to mount a MITM attack. And I believe that's a very good reason. Best regards, Julian
Received on Tuesday, 1 December 2015 08:34:19 UTC