Er, actually reading the specification, it's about proxying http resources, not https ones. This proposal is strictly better than the transparent proxying that's common on the internet today.
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.
...
4.3. Secure Forward Proxy and https URIs
The Proxy intercepts the TLS ClientHello analyses the application
layer protocol negotiation extension field and if it contains "h2"
value it does not do anything and let the TLS handshake continue and
the TLS session be established between the User-Agent and the Server
(see Figure 8).
HTTP/2 changes the meaning of the http:// scheme. All connections will now be TLS-encrypted. (Edit: Maybe not. See hobohacker below.) http:// means that the endpoint has not been verified using the CA system and is using a self-signed certificate (and is thus trivially vulnerable to a MITM should certificate keys not be checked out-of-band).
The purpose is to provide confidentiality to the vast majority of traffic, even if the authentication part of the CIA triangle isn't achieved. This proposal's purpose is to undo that and expose all traffic using the http:// scheme to your ISP, exactly as it is today. (I would also note that this draft is proposed by AT&T, which is now rolling out new plans in Austin that charge an extra $30/month if you do NOT agree to them inspecting and data-mining all of your internet activity and selling it to advertisers.)
This proposal's purpose is to ... expose all traffic using the http:// scheme to your ISP, exactly as it is today.
Isn't that a semantic requirement of HTTP, though? Half of the "tech" in the HTTP/1.X spec is to allow for caching of resources and responses by proxies, allowing anyone between the client and server (e.g. your ISP) to act as a CDN.
HTTPS/1.X effectively throws that away by doing end-to-end encryption. It's a trade-off: we gain the surety that all the responses are coming directly from the peer, rather than anyone else... but the web becomes 90% less cacheable, because the only places things can end up cached are between the client and the HTTPS pipe (i.e. the browser cache), or between the HTTPS pipe and the server (i.e. "reverse proxies" like Nginx.)
The current workaround for this, when you need caching for your Big Traffic on either ingress or egress, is to do what amounts to purposeful self-MITMing of your HTTPS session: to terminate HTTPS on a caching proxy, that holds the certificate of your client/server, and acts as if it were you, while itself doing another HTTPS session for "the last mile" to connect to you. This is what companies do when they deploy their own CA-cert to their networks, so everyone's access can be proxied through their own system; and this is what services like Cloudflare do when they sit "in front of" your server while not being a part of your company's VPN at all.
Basically, HTTP2 codifies this workaround, and calls it HTTP.
I don't see why you think this is a semantic requirement of HTTP. Perhaps there's some confusion over what HTTP semantics are. Let me refer you to http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-2.... It doesn't discuss exposing all HTTP traffic to network intermediaries. Perhaps you're thinking of the HTTP messaging layer http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-2.... Also, I think your statement about allowing an in-path intermediary to act as a CDN is weird, since a CDN is defined as "a large distributed system of servers deployed in multiple data centers across the Internet. The goal of a CDN is to serve content to end-users with high availability and high performance." [1].
It's true, HTTPS is full of tradeoffs. You've identified some of them.
What do you see in HTTP/2 that "codifies this workaround"? That wasn't immediately obvious to me. Recall that HTTP/2 is basically just multiplexing with prioritized streams. There's no requirement on TLS in the spec, although all current browser deployments (of SPDY) require TLS.
I find it difficult to imagine a world where Applications agnostic caching for encrypted sessions is possible.
I fully expect a world where application developers have services at their disposal for positioning assets closer to the end user with VM instance level isolation and security guarantees.
Transport level security is not likely to be enough for high value/sensitivity data in the long run but adding a bunch of new trusted parties to the system is going to be huge enabler for end user surveillance.
Why application-agnostic? HTTP's own caching isn't application-agnostic; it relies on the server to specify Cache-Control headers.
I would imagine an ideal HTTP2 caching protocol to basically specify that some resources can come from anywhere, as long as the retrieved result conforms to an attached content hash—while also specifying a primary source to get the resource from, if you don't have a DHT handy. (Oddly enough, this is basically a suggestion that web browsers try to resolve magnet: URNs.)
Thanks for this correction; I was under the impression that opportunistic encryption had already been chosen based on HTTP/2 descending from SPDY, but I clearly am not following the WG all that closely.
Is a fair reading of your blog post that it has a high likelihood of succeeding?
Only time will tell. It's all still in progress. Of all the major browser vendors (Firefox, Chromium, IE) present at the Zurich HTTP/2 interim meeting, only Patrick McManus (Firefox) has expressed interest. Notably, he's a co-editor of that Alternate-Services internet-draft.
http:// means that the endpoint has not been verified using the CA system and is using a self-signed certificate (and is thus trivially vulnerable to a MITM should certificate keys not be independently checked).
Right. I understand that. The lack of certificate verification for the http scheme means that ISPs can MITM HTTP traffic with or without this proposal, just like they can with HTTP/1.1.
So how does this proposal make things worse?
new plans in Austin that charge an extra $30/month if you do NOT agree to them inspecting and data-mining all of your web browsing and selling it to advertisers
Really? That's a special kind of evil and should be illegal.
Really? That's a special kind of evil and should be illegal.
Nah, no need to make it illegal. He's referring to AT&T's "GigaPower" gigabit service in Austin... the same service that's available from 2 other providers for the same, or cheaper, as what AT&T's charging for their data-mined bullshit.
AT&T will have a fun time getting customers when Google and Grande point that out in their attack ads. :D
Frankly, I would be surprised if this was not in Google's ToS from the start, considering that Google's core business model is mining of big data. I suspect there wouldn't be an option to turn it off, not even by paying extra.
One other provider. Neither Google (1 Gbps, "by mid 2014") nor Time Warner (300 Mbps, "by the fall of 2014") is yet offering comparable service. Only AT&T and Grande have any actual ultra-high-speed customers at this time.
The lack of certificate verification for the http scheme means that ISPs can MITM HTTP traffic with or without this proposal, just like they can with HTTP/1.1.
Can they really? At least some of those connections should have the certificates verified out of band, so I'd imagine they would get caught fairly quickly. And then loudly accused of conspiring with the CAs (to stifle competition) or the NSA (to steal your data), or the competitors of whatever site/product was being used, or someone I haven't thought of.
It's part of GigaPower (their 300Mbps, soon-to-be 1Gbps FTTH service they rolled out quickly after the Google Fiber announcement). AT&T does a good job of obscuring it on their website[0], but if you click "See offer details", you'll find that the $70/month price is a "special" that requires you opting in to "AT&T Internet Preferences", which is their euphemism for DPI. It's not explained there, but if you opt out, you lose the "special" and your price goes to $99/month.
From just a random googling, here's the first news article I found detailing the plan.[1] (See the last three paragraphs.)
which makes it clear that the point is to be able to say "I trust this proxy sufficiently that I'm ok with it acting as an intermediary, but I still don't want my stuff in the clear between me and the proxy or between the proxy and the far end server."
So it's about enabling the user to trust -only- the proxy, whereas currently in order to get utility out of a proxy you need to send the traffic as plain HTTP which then trusts both the proxy and the networks over which the data will travel.
That seems to me to absolutely meet the requirements for "strictly better".
If your definition of "better" is simply "faster", then yes, it is better. If you care about security of your data, end-to-end, this is worse (as others have pointed out because of your ISP being a MitM). In addition, now we are introducing another vector of attack for bad guys to exploit - how enticing does it sound that every ISP becomes a root certificate authority, essentially?
Your ISP could be MitM-ing your plaintext HTTP already, and it's the use cases that we currently use plaintext HTTP for that this is addressing.
If you care about security of your data, end-to-end, then you should probably only use this feature, if at all, with the proxy running on a machine you control - but presumably in that case you currently aren't using plaintext HTTP for anything anyway, so I don't see how it relates.
indeed - but I think its even worse than that, because even "faster" is rather contextual.
proxies can inject dog leg routes, single points of failure, computational and i/o bottlenecks and they make lovely centralized dos and data theft targets. They also often downgrade you out of performance enhancements that the client and server would have negotiated if they had been speaking directly (e.g. some actually block compression negotiation so they can observe the content of more flows with less cpu).
Sometimes they do make things faster though - its just not clear to me why we want to continue to centralize that approach rather than distributing it across the network given all the baggage proxying carries.
When the user has given consent to the use of a proxy, the User-Agent SHOULD store this consent so that the user does not have to give consent for each new TLS connection involving the proxy. The consent SHOULD be limited to the specific access and MAY be limited to a single connection to that access or limited in time. How the consent information is stored is implementation specific, but as a network may have several proxies (for network resilience) it is RECOMMENDED that the consent is only tied to the Subject field of the proxy certificate so that the consent applies to all proxy certificates with the same name.
If the user has previously given consent to use the specific proxy and the user-agent has stored that, the user-agent may conclude that the user has given consent without asking the user again.
If the user provides consent, the User-Agent continues the TLS handshake with the proxy.
-----------
Right in the next section, it's again implied:
The proxy will then notice that the TLS connection is to be used for a https resource or for a http resource for which the user wants to opt out from the proxy. The proxy will then forward the ClientHello message to the Server and the TLS connection will be end-to-end between the user-agent and the Server.
-----------
Then in 3.2, again implied:
When the User-Agent arrives to the portal page it becomes aware of the existence of a Proxy in the access network and receives a consent request for the proxy to stay in the path for HTTP URI resources. The user-agent then SHOULD secure user consent.
When the user has given consent to the use of a proxy, both the User-Agent and the Proxy SHOULD store this consent so that the user does not have to give consent for each new TLS connection involving the proxy.
The way I'm reading the sections you've quoted, the spec merely allows proxying of https ciphertext. Every router in the internet does that already. Bear in mind that in HTTP 2.0, all connections are TLS connections. The spec sections you've quoted just say that users should only have to consent once to their "http"-resource connections being proxied; they're not talking about "https" resources.
Comments
Er, actually reading the specification, it's about proxying http resources, not https ones. This proposal is strictly better than the transparent proxying that's common on the internet today.
...HTTP/2 changes the meaning of the http:// scheme. All connections will now be TLS-encrypted. (Edit: Maybe not. See hobohacker below.) http:// means that the endpoint has not been verified using the CA system and is using a self-signed certificate (and is thus trivially vulnerable to a MITM should certificate keys not be checked out-of-band).
The purpose is to provide confidentiality to the vast majority of traffic, even if the authentication part of the CIA triangle isn't achieved. This proposal's purpose is to undo that and expose all traffic using the http:// scheme to your ISP, exactly as it is today. (I would also note that this draft is proposed by AT&T, which is now rolling out new plans in Austin that charge an extra $30/month if you do NOT agree to them inspecting and data-mining all of your internet activity and selling it to advertisers.)
Isn't that a semantic requirement of HTTP, though? Half of the "tech" in the HTTP/1.X spec is to allow for caching of resources and responses by proxies, allowing anyone between the client and server (e.g. your ISP) to act as a CDN.
HTTPS/1.X effectively throws that away by doing end-to-end encryption. It's a trade-off: we gain the surety that all the responses are coming directly from the peer, rather than anyone else... but the web becomes 90% less cacheable, because the only places things can end up cached are between the client and the HTTPS pipe (i.e. the browser cache), or between the HTTPS pipe and the server (i.e. "reverse proxies" like Nginx.)
The current workaround for this, when you need caching for your Big Traffic on either ingress or egress, is to do what amounts to purposeful self-MITMing of your HTTPS session: to terminate HTTPS on a caching proxy, that holds the certificate of your client/server, and acts as if it were you, while itself doing another HTTPS session for "the last mile" to connect to you. This is what companies do when they deploy their own CA-cert to their networks, so everyone's access can be proxied through their own system; and this is what services like Cloudflare do when they sit "in front of" your server while not being a part of your company's VPN at all.
Basically, HTTP2 codifies this workaround, and calls it HTTP.
I don't see why you think this is a semantic requirement of HTTP. Perhaps there's some confusion over what HTTP semantics are. Let me refer you to http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-2.... It doesn't discuss exposing all HTTP traffic to network intermediaries. Perhaps you're thinking of the HTTP messaging layer http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-2.... Also, I think your statement about allowing an in-path intermediary to act as a CDN is weird, since a CDN is defined as "a large distributed system of servers deployed in multiple data centers across the Internet. The goal of a CDN is to serve content to end-users with high availability and high performance." [1].
It's true, HTTPS is full of tradeoffs. You've identified some of them.
What do you see in HTTP/2 that "codifies this workaround"? That wasn't immediately obvious to me. Recall that HTTP/2 is basically just multiplexing with prioritized streams. There's no requirement on TLS in the spec, although all current browser deployments (of SPDY) require TLS.
[1]: http://en.wikipedia.org/wiki/Content_delivery_network
I find it difficult to imagine a world where Applications agnostic caching for encrypted sessions is possible.
I fully expect a world where application developers have services at their disposal for positioning assets closer to the end user with VM instance level isolation and security guarantees.
Transport level security is not likely to be enough for high value/sensitivity data in the long run but adding a bunch of new trusted parties to the system is going to be huge enabler for end user surveillance.
Why application-agnostic? HTTP's own caching isn't application-agnostic; it relies on the server to specify Cache-Control headers.
I would imagine an ideal HTTP2 caching protocol to basically specify that some resources can come from anywhere, as long as the retrieved result conforms to an attached content hash—while also specifying a primary source to get the resource from, if you don't have a DHT handy. (Oddly enough, this is basically a suggestion that web browsers try to resolve magnet: URNs.)
HTTP/2 does not change the meaning of http://. That's the opportunistic encryption proposal: http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-.... For more information, you can see https://insouciant.org/tech/http-slash-2-considerations-and-....
Thanks for this correction; I was under the impression that opportunistic encryption had already been chosen based on HTTP/2 descending from SPDY, but I clearly am not following the WG all that closely.
Is a fair reading of your blog post that it has a high likelihood of succeeding?
Only time will tell. It's all still in progress. Of all the major browser vendors (Firefox, Chromium, IE) present at the Zurich HTTP/2 interim meeting, only Patrick McManus (Firefox) has expressed interest. Notably, he's a co-editor of that Alternate-Services internet-draft.
Right. I understand that. The lack of certificate verification for the http scheme means that ISPs can MITM HTTP traffic with or without this proposal, just like they can with HTTP/1.1.
So how does this proposal make things worse?
Really? That's a special kind of evil and should be illegal.
Nah, no need to make it illegal. He's referring to AT&T's "GigaPower" gigabit service in Austin... the same service that's available from 2 other providers for the same, or cheaper, as what AT&T's charging for their data-mined bullshit.
AT&T will have a fun time getting customers when Google and Grande point that out in their attack ads. :D
Unless Grande and Google eventually decide to do the same thing. Why not, from their perspective?
Frankly, I would be surprised if this was not in Google's ToS from the start, considering that Google's core business model is mining of big data. I suspect there wouldn't be an option to turn it off, not even by paying extra.
Google doesn't need to, your encrypted traffic is to their servers.
One other provider. Neither Google (1 Gbps, "by mid 2014") nor Time Warner (300 Mbps, "by the fall of 2014") is yet offering comparable service. Only AT&T and Grande have any actual ultra-high-speed customers at this time.
The lack of certificate verification for the http scheme means that ISPs can MITM HTTP traffic with or without this proposal, just like they can with HTTP/1.1.
Can they really? At least some of those connections should have the certificates verified out of band, so I'd imagine they would get caught fairly quickly. And then loudly accused of conspiring with the CAs (to stifle competition) or the NSA (to steal your data), or the competitors of whatever site/product was being used, or someone I haven't thought of.
Can you elaborate on those AT&T plans?
It's part of GigaPower (their 300Mbps, soon-to-be 1Gbps FTTH service they rolled out quickly after the Google Fiber announcement). AT&T does a good job of obscuring it on their website[0], but if you click "See offer details", you'll find that the $70/month price is a "special" that requires you opting in to "AT&T Internet Preferences", which is their euphemism for DPI. It's not explained there, but if you opt out, you lose the "special" and your price goes to $99/month.
From just a random googling, here's the first news article I found detailing the plan.[1] (See the last three paragraphs.)
[0]: http://att.com/gigapower
[1]: http://news.cnet.com/8301-1035_3-57615246-94/at-t-delivers-g...
I pay AT&T about half that no-DPI price for 12mbit. I wouldn't sweat paying the extra to avoid DPI if I wanted the service.
The point isn't whether one can afford it, but whether it's right.
I agree. But that sad situation looks good from where I'm standing.
I think the crucial thing to understanding this is this diagram -
which makes it clear that the point is to be able to say "I trust this proxy sufficiently that I'm ok with it acting as an intermediary, but I still don't want my stuff in the clear between me and the proxy or between the proxy and the far end server."So it's about enabling the user to trust -only- the proxy, whereas currently in order to get utility out of a proxy you need to send the traffic as plain HTTP which then trusts both the proxy and the networks over which the data will travel.
That seems to me to absolutely meet the requirements for "strictly better".
If your definition of "better" is simply "faster", then yes, it is better. If you care about security of your data, end-to-end, this is worse (as others have pointed out because of your ISP being a MitM). In addition, now we are introducing another vector of attack for bad guys to exploit - how enticing does it sound that every ISP becomes a root certificate authority, essentially?
Your ISP could be MitM-ing your plaintext HTTP already, and it's the use cases that we currently use plaintext HTTP for that this is addressing.
If you care about security of your data, end-to-end, then you should probably only use this feature, if at all, with the proxy running on a machine you control - but presumably in that case you currently aren't using plaintext HTTP for anything anyway, so I don't see how it relates.
indeed - but I think its even worse than that, because even "faster" is rather contextual.
proxies can inject dog leg routes, single points of failure, computational and i/o bottlenecks and they make lovely centralized dos and data theft targets. They also often downgrade you out of performance enhancements that the client and server would have negotiated if they had been speaking directly (e.g. some actually block compression negotiation so they can observe the content of more flows with less cpu).
Sometimes they do make things faster though - its just not clear to me why we want to continue to centralize that approach rather than distributing it across the network given all the baggage proxying carries.
Read the rest. You'll see that these proxies also serve as handlers for all TLS sessions.
Where does it say that?
3.1.1 TLS Handshake with Proxy certificate
When the user has given consent to the use of a proxy, the User-Agent SHOULD store this consent so that the user does not have to give consent for each new TLS connection involving the proxy. The consent SHOULD be limited to the specific access and MAY be limited to a single connection to that access or limited in time. How the consent information is stored is implementation specific, but as a network may have several proxies (for network resilience) it is RECOMMENDED that the consent is only tied to the Subject field of the proxy certificate so that the consent applies to all proxy certificates with the same name.
If the user has previously given consent to use the specific proxy and the user-agent has stored that, the user-agent may conclude that the user has given consent without asking the user again.
If the user provides consent, the User-Agent continues the TLS handshake with the proxy.
-----------
Right in the next section, it's again implied:
The proxy will then notice that the TLS connection is to be used for a https resource or for a http resource for which the user wants to opt out from the proxy. The proxy will then forward the ClientHello message to the Server and the TLS connection will be end-to-end between the user-agent and the Server.
-----------
Then in 3.2, again implied:
When the User-Agent arrives to the portal page it becomes aware of the existence of a Proxy in the access network and receives a consent request for the proxy to stay in the path for HTTP URI resources. The user-agent then SHOULD secure user consent.
When the user has given consent to the use of a proxy, both the User-Agent and the Proxy SHOULD store this consent so that the user does not have to give consent for each new TLS connection involving the proxy.
The way I'm reading the sections you've quoted, the spec merely allows proxying of https ciphertext. Every router in the internet does that already. Bear in mind that in HTTP 2.0, all connections are TLS connections. The spec sections you've quoted just say that users should only have to consent once to their "http"-resource connections being proxied; they're not talking about "https" resources.