SoylentNews is people
SoylentNews
mrbluze writes:
"A modified HTTP protocol is being proposed (the proposal is funded by AT&T) which would allow ISP's to decrypt and re-encrypt traffic as part of day to day functioning in order to save money on bandwidth through caching. The draft document states:
To distinguish between an HTTP2 connection meant to transport "https" URIs resources and an HTTP2 connection meant to transport "http" URIs resource, the draft proposes to 'register a new value in the Application Layer Protocol negotiation (ALPN) Protocol IDs registry specific to signal the usage of HTTP2 to transport "http" URIs resources: h2clr.
The proposal is being criticized by Lauren Weinstein in that it provides a false sense of security to end users who might believe that their communications are actually secure. Can this provide an ISP with an excuse to block or throttle HTTPS traffic?"
(Score: 4, Informative) by mattyk on Monday February 24 2014, @08:55PM
If anyone else here takes part in the httpbis-wg, please step in and help clarify. This proposal doesn't affect https: URIs in any way. Resources served "securely" will continue to be served the same way they currently are. The "trusted proxy" proposal goes hand-in-hand with another proposal -- "opportunistic encryption" -- whereby cleartext http: URIs can be siphoned through TLS if both ends are happy to do so (e.g. using self-signed certificates, or a null cypher), without making any indication to the end user that their data is any more "secure" than it would be using a HTTP/1.1 browser/server (because it isn't). The "trusted proxy" proposal adds some extra utility to that proposal.
IIRC part of the problem with HTTP/2 was cramming a binary data stream down lines that, in many cases, are hard-coded to expect HTTP/1.[01] ASCII text, without those hard-coded middleware devices barfing. Since HTTPS is an existing, functional binary data stream (in the eyes of those devices) there was a lot of talk about forcing HTTP/2 to travel as HTTPS/TLS.
See more here: http://hillbrad.typepad.com/blog/2014/02/trusted-p roxies-and-privacy-wolves.html [typepad.com]
_MattyK_
(Score: 3, Insightful) by mindriot on Monday February 24 2014, @09:22PM
This makes a bit more sense. But then, IMHO interrupted encryption is no better than no encryption at all. "Trusted proxy" is just an oxymoron akin to "benevolent man-in-the-middle" -- I will, out of principle, not trust any third party to decrypt and re-encrypt traffic. In other words, why bother with opportunistic encryption at all when it can be interrupted in the middle? What good does it serve then? The interruption makes it null and void, so any CPU cycles spent on encrypting the data stream are nothing but a waste of heat.
Could anyone point out a good use case where such "half-decent" encryption has any sort of advantage? To me encryption is all (end-to-end) or nothing (might as well send plaintext).
soylent_uid=$(echo $slash_uid|cut -c1,3,5)
(Score: 2, Interesting) by mattyk on Monday February 24 2014, @11:26PM
> Could anyone point out a good use case where such "half-decent"
> encryption has any sort of advantage?
My second paragraph: using TLS as a channel to tunnel through middleware devices that expect any and all http: traffic (including HTTP/2) to be readable HTTP/1.x-looking ASCII. Wrapping the traffic up in a TLS stream, even with a NULL cypher, will allow it to travel past those devices the way https: traffic already does.
Incidentally, current discussion on the working group list seems to indicate that the "trusted proxy" proposal is about *advertising* proxies, and that the user still has final say in whether or not to allow the proxy to terminate/decrypt/cache.
_MattyK_