- From: Anil Sharma <asharma@sandvine.com>
- Date: Thu, 19 Jul 2012 09:55:54 +0000
- To: Willy Tarreau <w@1wt.eu>, Roberto Peon <grmocg@gmail.com>
- CC: Paul Hoffman <paul.hoffman@gmail.com>, Phillip Hallam-Baker <hallam@gmail.com>, "grahame@healthintersections.com.au" <grahame@healthintersections.com.au>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Mike Belshe <mike@belshe.com>
" in HTTP they always force safesearch to on in outgoing requests so that they rely on google's ability to filter out unsuitable contents. In HTTPS they obviously can't do this so google images then becomes a single-handed browsing tool." Didn't understand this point? From compute server point of view (which is providing you search results) it shouldn't matter whether transport used was secure or not? Did I miss something? Best, Anil -----Original Message----- From: Willy Tarreau [mailto:w@1wt.eu] Sent: Thursday, July 19, 2012 3:09 PM To: Roberto Peon Cc: Paul Hoffman; Phillip Hallam-Baker; grahame@healthintersections.com.au; ietf-http-wg@w3.org; Mike Belshe Subject: Re: Mandatory encryption Hi Roberto, On Wed, Jul 18, 2012 at 10:31:30AM -0700, Roberto Peon wrote: > There are number of technical issues here. > 1) speed of experience > 2) deployability of protocol > 3) privacy against wireless sniffers (I call this point-to-point privacy) > 4) authentication of the server to the client. > 5) runtime cost > (...) > #2: Experience has shown, unfortunately, that deploying something new from > browser to server is either extremely difficult or unreliable. That is the > only case where mandating anything like TLS makes sense to me. > > #1 isn't obvious one way or another. For the first request TLS potentially > harms latency as compared to http/1.1. For subsequent requests it comes out > as better (given application protocol changes). More interestingly, > negotiating http/2 over port 80 will require a round trip, which is the > same latency penalty one will pay for using TLS at a site that you have > recently visited assuming we use false-start. For the two points above, I get your point but partially disagree. As we discussed in another thread on HyBi a few years ago, I have experience of a number of places where proxies don't allow TLS to pass through for filtering reasons. For instance, one of my customers doesn't allow HTTPS to google.com for a simple reason : in HTTP they always force safesearch to on in outgoing requests so that they rely on google's ability to filter out unsuitable contents. In HTTPS they obviously can't do this so google images then becomes a single-handed browsing tool. So they don't allow HTTPS on this domain. The effect is that connections from the browser to google cannot use SPDY over port 443 right now and this is not going to change for a long time due to internal filtering policy reasons. So outgoing connection attempts to use port 443 will have to fall back to use port 80 instead (second round trip) while the Upgrade would pass on the same connection. TLS is a valid transport to join many directly connected users but is not very practical for people in enterprises unfortunately. What I'm opposed to is to force such users to choose between HTTP/2.0 and HTTP/1.1 instead of choosing between clear and encrypted as they're doing right now. Because whatever the transport we choose, we're designing HTTP/2.0 to provide much better end-user experience to users and we should not condition this to the ability to pass over port 443. Regards, Willy
Received on Thursday, 19 July 2012 09:57:27 UTC