TLS in HTTP/2 • Hacker News Board

Re: TLS in HTTP/2

#21

Post by Karunamon » Fri, Mar 06, 2015, 4:50 PM UTC

bodyfour wrote: post #18

m_eiman wrote: post #11

Earlier quoted context omitted.

Ok, so it's just a horrible user experience then :]

Exactly. Worse, it trains users to ignore cert warnings. I don't have any problems with the campaigns to make the public internet HTTPS-only. However, for software inside an intranet, or software that just wants to expose an interface on http://127.0.0.1:*someport* non-SSL is the better default. If people want to protect their intranet that's great, but it means that they have to go through the work of buying a cert,…

My view is starting to change on this.. can you really trust a LAN beyond a certain size? (That size being what one person can comfortably architect and maintain.)

Nowadays, I'm a firm believer in "encrypt all the things", but that's because I'm a geek and can deal with the PITA. There needs to be either an encryption mechanism that's completely separate from authentication, or the use case of LAN encryption for regular people needs to be addressed in some other way.

Re: TLS in HTTP/2

#22

Post by comex » Fri, Mar 06, 2015, 5:08 PM UTC

The only one of the counterarguments that interests me is that it defeats caching. I mean, if 100 users in a large network want to access the same video or other large resource from the Internet, it seems pretty ridiculous that the connection must use 100 times as much bandwidth as it would if they could just install a simple caching proxy, especially if it's just some cat video or online game, which is probably the common case. True, not all large resources are as innocent, and there is no real way around encrypting and not caching everything if you don't want devices on the network to tell the difference... but the result is just so pathological. The price of freedom?

[For the record, YouTube seems to use HTTPS by default for video content, so this is already the case for some large percentage of the types of large resources typically accessed from shared networks.]

Re: TLS in HTTP/2

#23

Post by nly » Fri, Mar 06, 2015, 5:22 PM UTC

comex wrote: post #22

The only one of the counterarguments that interests me is that it defeats caching. I mean, if 100 users in a large network want to access the same video or other large resource from the Internet, it seems pretty ridiculous that the connection must use 100 times as much bandwidth as it would if they could just install a simple caching proxy, especially if it's just some cat video or online game, which is probably the…

The answer is probably to have a way to sign and/or encrypt headers separately so that clients can request authentication and/or encryption on a per-resource basis. Perhaps a public and a private header section.

Checksumming and cryptographic signing of responses as an alternative to full-blown encryption might be useful as well (since response signatures could still be cached).

Re: TLS in HTTP/2

#24

Post by Nimi » Fri, Mar 06, 2015, 5:27 PM UTC

I'm surprised to see Certificate Transparency presented as a band-aid. My understanding is that assuming it will be deployed successfully, forged certificates will require very significant resources to use successfully for an attack, typically limiting such attacks to nation states.

But I would love to know where I'm wrong about this.

Re: TLS in HTTP/2

#25

Post by charonn0 » Fri, Mar 06, 2015, 5:57 PM UTC

TazeTSchnitzel wrote: post #14

calibwam wrote: post #13

For how long will HTTP 1.1/1.0 live alongside HTTP/2? It's all nice if every web page has TLS, but if I can just not upgrade to 2.0, it will not matter at all...

HTTP/1.1 and HTTP/2.0 will coexist forever. HTTP/2 is mostly just a higher-performance, binary version of HTTP/1.1. HTTP/1.0 is basically dead and has been for years, because it lacks Host: and so cannot be used for vhosts.

> HTTP/1.0 is basically dead and has been for years

There are probably a lot more active HTTP/1.0 clients than you think. Just slap a `Host: foo.com` and `Connection: close` header onto the request and your HTTP/1.0 client can talk to just about any HTTP/1.1 server.

Re: TLS in HTTP/2

#26

Post by cbhl » Fri, Mar 06, 2015, 6:10 PM UTC

comex wrote: post #22

The only one of the counterarguments that interests me is that it defeats caching. I mean, if 100 users in a large network want to access the same video or other large resource from the Internet, it seems pretty ridiculous that the connection must use 100 times as much bandwidth as it would if they could just install a simple caching proxy, especially if it's just some cat video or online game, which is probably the…

Caching already happens through CDNs at the ISP level, such as through the Google Global Cache (YouTube), Netflix Open Connect. That roughly covers about half of network traffic.

Plus, running a squid proxy on 100 users isn't nearly as effective as it once was; pages contain far more dynamically generated content than they used to. Think about a Facebook News Feed or Twitter Stream.

Re: TLS in HTTP/2

#27

Post by jerf » Fri, Mar 06, 2015, 6:14 PM UTC

comex wrote: post #22

The only one of the counterarguments that interests me is that it defeats caching. I mean, if 100 users in a large network want to access the same video or other large resource from the Internet, it seems pretty ridiculous that the connection must use 100 times as much bandwidth as it would if they could just install a simple caching proxy, especially if it's just some cat video or online game, which is probably the…

As the article mentions, for better or worse, TLS-piercing proxies aren't exactly unusual anymore. An ISP may not be able to just jam one in front of their customers, but use cases involving a corporate entity owning computers such that they can push a root cert update and wanting such a cache are still unaffected.

Re: TLS in HTTP/2

#28

Post by cbr » Fri, Mar 06, 2015, 6:24 PM UTC

bodyfour wrote: post #16

TazeTSchnitzel wrote: post #14

Earlier quoted context omitted.

HTTP/1.1 and HTTP/2.0 will coexist forever. HTTP/2 is mostly just a higher-performance, binary version of HTTP/1.1. HTTP/1.0 is basically dead and has been for years, because it lacks Host: and so cannot be used for vhosts.

That's not completely accurate about HTTP/1.0. It's true that HTTP/1.1 requires "Host:" (a compliant server MUST reject any request from a 1.1 client that lacks that header). However, HTTP/1.0 clients had been sending "Host:" headers for years before the 1.1 standard came out. It's still possible to use a 1.0 client today if you don't want to handle other client-side requirements of 1.1 like chunked transfer-encoding…

Have you ever tried to browse the web without chunked transfer encoding? It's everywhere now.

Re: TLS in HTTP/2

#29

Post by r1ch » Fri, Mar 06, 2015, 6:33 PM UTC

I still don't see many arguments about advertising when it comes to TLS. I can't deploy TLS across my sites without losing a huge amount of ad inventory due to cross-site request policies (no HTTP content from HTTPS domains).

AFAIK, Google is the only network actively working on having HTTPS-supported ads. The value of the ads drops significantly as the auction pressure from all the HTTP ads is gone, meaning any sites that rely on ad revenue can not afford to use TLS.

Re: TLS in HTTP/2

#30

Post by bodyfour » Sat, Mar 07, 2015, 12:33 AM UTC

cbr wrote: post #28

bodyfour wrote: post #16

Earlier quoted context omitted.

That's not completely accurate about HTTP/1.0. It's true that HTTP/1.1 requires "Host:" (a compliant server MUST reject any request from a 1.1 client that lacks that header). However, HTTP/1.0 clients had been sending "Host:" headers for years before the 1.1 standard came out. It's still possible to use a 1.0 client today if you don't want to handle other client-side requirements of 1.1 like chunked transfer-encoding…

Have you ever tried to browse the web without chunked transfer encoding? It's everywhere now.

Most well-behaved servers will only send chunked-encoding if the client claimed to be HTTP/1.1. If the client is HTTP/1.0 it will fall back to doing "Connection: close"

The only big thing chunked-encoding gives you is the ability to do a keep-alive connection when the server doesn't know the Content-Length in advance. (Technically it also added "trailers" for sending headers after the reply body, but that's little-used)