TLS in HTTP/2 • Hacker News Board

Re: TLS in HTTP/2

#31

Post by e12e » Sat, Mar 07, 2015, 12:42 AM 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…

Lets say one uses http/2 across microservices in a datacenter (or "cloud") with (possibly) ipv6 (or ip4) over secure (vpn or physically secure) links. Would you reallly want to complicate the stack by having to choose between using both 1.1 and 2 or do double encryption?

I get that browsers demand tls as there's no sane ui/ux to show that the link is secure because of vpn etc to the user. Not so for other clients.

Re: TLS in HTTP/2

#32

Post by TazeTSchnitzel » Sat, Mar 07, 2015, 3:28 AM 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…

Host: isn't part of HTTP/1.0, though, and if you try to send it, some servers will respond to you with HTTP/1.1!

Re: TLS in HTTP/2

#33

Post by jeremie » Sat, Mar 07, 2015, 4:36 AM UTC

Karunamon wrote: post #21

bodyfour wrote: post #18

Earlier quoted context omitted.

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 regu…

I'm a big believer in a (local/p2p) transport encryption mechanism /in addition to/ one for auth, and for it to be transparent to any UX... that's very much our goals for telehash v3 :)

Re: TLS in HTTP/2

#34

Post by bodyfour » Sat, Mar 07, 2015, 7:00 PM UTC

TazeTSchnitzel wrote: post #32

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…

Host: isn't part of HTTP/1.0, though, and if you try to send it, some servers will respond to you with HTTP/1.1!

It's perfectly normal (and allowed) for servers to send back a version string of "HTTP/1.1" even if the client sent the request as "HTTP/1.0". As long as they don't do anything in their response that assumes that the client has 1.1 features, all is fine. This basically just means: * Don't use chunked encoding in the response. (Technically a 1.0 client could specifically indicate support for that by sending a "TE: chunked" header, but since chunked encoding arrived at the same time as 1.1 I think most servers just assume that HTTP/1.0 clients never support it) * Don't assume that the client supports keep-alive connections. However, prior to HTTP/1.0 clients often did indicate that they could do keep-alive by sending "Connection: keep-alive". The only real difference in 1.1 is that now the client must support it unless they specifically indicate that they don't by sending "Connection: close". In the absence of a "Connection:" header, a 1.1 client supports keep-alive and a 1.0 does not.