It occurs to me that I don't believe I've seen any discussion of the Unexpected Consequence of pervasive HTTPS replacing HTTP for unauthenticated sessions, like non-logged-in users browsing sites like Wikipedia. That traffic's not cacheable, is it? Proxy caches on services like mobile 3/4G, or smaller ISPs, or larger corporations can't cache it, I wouldn't think, which means both that they will see traffic increases, and that the end sites will as well. Has this been discussed and I missed it? Do I improperly understand transparent caching? Or is this just a bomb waiting to go off? I assume that Wikipedia themselves are on top of the idea that their in-house reverse-proxies won't be carrying that traffic (though I don't actually know what their architecture looks like anymore), but.. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Fri, May 3, 2013 at 3:06 PM, Jay Ashworth <jra@baylink.com> wrote:
It occurs to me that I don't believe I've seen any discussion of the Unexpected Consequence of pervasive HTTPS replacing HTTP for unauthenticated sessions, like non-logged-in users browsing sites like Wikipedia.
That traffic's not cacheable, is it? Proxy caches on services like mobile 3/4G, or smaller ISPs, or larger corporations can't cache it, I wouldn't think, which means both that they will see traffic increases, and that the end sites will as well.
Has this been discussed and I missed it? Do I improperly understand transparent caching? Or is this just a bomb waiting to go off?
I assume that Wikipedia themselves are on top of the idea that their in-house reverse-proxies won't be carrying that traffic (though I don't actually know what their architecture looks like anymore), but..
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
TLS/SSL can be applied at the loadbalancer/caching proxy for service providers like Wikipedia. As you may already know products like Apple's IPhone include CA that can allow groups like the DOD to do chain-loading to allow their proxies to be MITM systems(super scary, in more systems than the one mentioned.). Yes it is a bomb but only from the ISP caching point of view, not the provider caching point of view. -- ~ Andrew "lathama" Latham lathama@gmail.com http://lathama.net ~
On 5/3/13 2:06 PM, Jay Ashworth wrote:
It occurs to me that I don't believe I've seen any discussion of the Unexpected Consequence of pervasive HTTPS replacing HTTP for unauthenticated sessions, like non-logged-in users browsing sites like Wikipedia.
That traffic's not cacheable, is it?
This has been discussed over the last year in the IETF HTTP WG in the context of SPDY and HTTP 2.0. Today this traffic is not cacheable. Some people are proposing to have a mode that is end-to-end secure and shows the lock icon in the browser and a different mode that uses SSL to the cache and SSL from the cache to the origin and doesn't show a lock. For networks that have traffic inspection "requirements" (e.g. education/enterprise) there has also been discussion about a signaling protocol for the network to indicate to browsers that all non-proxied traffic will be dropped. Transparent proxies are evil and one of the goals of HTTP 2.0 is to make proxies visible to the browser/user so they can choose whether to consent to having their traffic proxied. -- Wes Felter
On Fri, May 3, 2013 at 3:33 PM, Wes Felter <wmf@felter.org> wrote:
On 5/3/13 2:06 PM, Jay Ashworth wrote:
It occurs to me that I don't believe I've seen any discussion of the Unexpected Consequence of pervasive HTTPS replacing HTTP for unauthenticated sessions, like non-logged-in users browsing sites like Wikipedia.
That traffic's not cacheable, is it?
This has been discussed over the last year in the IETF HTTP WG in the context of SPDY and HTTP 2.0. Today this traffic is not cacheable. Some people are proposing to have a mode that is end-to-end secure and shows the lock icon in the browser and a different mode that uses SSL to the cache and SSL from the cache to the origin and doesn't show a lock. For networks that have traffic inspection "requirements" (e.g. education/enterprise) there has also been discussion about a signaling protocol for the network to indicate to browsers that all non-proxied traffic will be dropped. Transparent proxies are evil and one of the goals of HTTP 2.0 is to make proxies visible to the browser/user so they can choose whether to consent to having their traffic proxied.
-- Wes Felter
Thanks for the summary, Wes. If operators have thoughts on this issue, there is still discussion going on about HTTP/2.0. As Wes notes, HTTP/2.0 is going to have a strong emphasis on TLS, as with SPDY. Please send comments to the WG mailing list: <http://tools.ietf.org/wg/httpbis> <http://lists.w3.org/Archives/Public/ietf-http-wg/> Cheers, --Richard
On Fri, May 3, 2013 at 12:06 PM, Jay Ashworth <jra@baylink.com> wrote:
It occurs to me that I don't believe I've seen any discussion of the Unexpected Consequence of pervasive HTTPS replacing HTTP for unauthenticated sessions, like non-logged-in users browsing sites like Wikipedia.
That traffic's not cacheable, is it? Proxy caches on services like mobile 3/4G, or smaller ISPs, or larger corporations can't cache it, I wouldn't think, which means both that they will see traffic increases, and that the end sites will as well.
Has this been discussed and I missed it? Do I improperly understand transparent caching? Or is this just a bomb waiting to go off?
I assume that Wikipedia themselves are on top of the idea that their in-house reverse-proxies won't be carrying that traffic (though I don't actually know what their architecture looks like anymore), but..
If anyone's curious about Wikipedia (we're open with our architecture) - we aren't really effected by using https instead of http for non logged in sessions. I'm assuming all of the other major sites use similar methods. The path goes user <--> LVS load balancer <--> nginx ssl termination <--> varnish (caching layer) <--> (if cache miss) application layer The only extra "hop" for https is the ssl termination, and while if all of a sudden 100% of our traffic switched from http to https, we'd be underprovisioned and have to scramble, the incremental effect of a single user (or all the https everywhere users!) using https is incredibly tiny. It's not as cpu-intensive as many people think. Unless a corporation is breaking ssl ( like in this case - http://superuser.com/questions/115349/firefox-this-connection-is-untrusted-b... ) their proxies would be unable to cache SSL content. If you're curious about wikimedia's architecture, you can check it out on our wiki -- https://wikitech.wikimedia.org/wiki/Main_Page Leslie
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
participants (5)
-
Andrew Latham -
Jay Ashworth -
Leslie -
Richard Barnes -
Wes Felter