Re: HTTPS-everywhere vs. proxy caching

[Leslie]

On Fri, May 3, 2013 at 12: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?  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-behind-corporate-firewall
) 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   
> j...@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
>

Re: HTTPS-everywhere vs. proxy caching

[Richard Barnes]

On Fri, May 3, 2013 at 3:33 PM, Wes Felter  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:



Cheers,
--Richard

Re: HTTPS-everywhere vs. proxy caching

[Wes Felter]

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

Re: HTTPS-everywhere vs. proxy caching

[Andrew Latham]

On Fri, May 3, 2013 at 3: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?  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   
> j...@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 lath...@gmail.com http://lathama.net ~

HTTPS-everywhere vs. proxy caching

[Jay Ashworth]

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   j...@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