Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TLS in HTTP/2

daniel.haxx.se

Post reply on HN
Print view View original

11–20 of 34 posts

Re: TLS in HTTP/2

#11

Post by m_eiman »

stephen_g wrote: post #9
m_eiman wrote: post #7

How could certificates ever work in embedded applications connected to consumer LANs that provide interfaces over HTTP? Aren't certificates tied to IP addresses, which wouldn't work with e.g. DHCP? Not to mention certificate expiration and updates…

Certificates are generally based on hostnames. You can put an IP as the common name but it's problematic (and you can't get one signed by most authorities for an IP address as far as I know). Generally the devices just generate a self-signed certificate and you have to click through the warning.

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

Re: TLS in HTTP/2

#12

Post by higherpurpose »

EtherealMind wrote: post #4
sanxiyn wrote: post #3

Earlier quoted context omitted.

> Which is interesting, because I remember quite clearly the "Snowden discussion" at the IETF, and there were consensus for an "encrypt everything Internet". I think this is still the official IETF position. RFC 7258 "Pervasive Monitoring Is an Attack" is published as Best Current Practice and has not been retracted.

Certain corporate companies formed a consortium to prevent encryption to ensure that monetisation of personal information would continue. At the very last stage, the IETF appeared to be hijacked by very large telcos (e.g. ATT, Verizon, Ericsson, Comcast) to remove the mandatory requirement for TLS As an outsider, this look likes a careful co-ordinated attack on the IETF standards process by a small number of "serial…

Not just corporations, NSA, too:

http://arstechnica.com/security/2014/01/nsa-employee-will-co...

Re: TLS in HTTP/2

#13

Post by calibwam »

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

Re: TLS in HTTP/2

#14

Post by TazeTSchnitzel »

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.

Re: TLS in HTTP/2

#15

Post by calibwam »

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.

So basically, while HTTP/2.0 could force TLS, the world could still be like it is today, with some pages running web servers with HTTP/1.1 without TLS?

Re: TLS in HTTP/2

#16

Post by bodyfour »

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.

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. Likewise, embedded devices can speak 1.0 only without any problem.

Re: TLS in HTTP/2

#17

Post by forgottenpass »

m_eiman wrote: post #7

How could certificates ever work in embedded applications connected to consumer LANs that provide interfaces over HTTP? Aren't certificates tied to IP addresses, which wouldn't work with e.g. DHCP? Not to mention certificate expiration and updates…

Tied to domains, but you still have a good point. Try getting a cert for "foo.myhouse.lan" (and that ignores complications of coordinating hostnames of embedded device ahead of time).

On a manged corporate intranet, Active Directory can push out a new CA and your computer trust whatever certs the local IT department wants to cook up, but it breaks down with a BYOD office or SOHO lan.

I manage a few intranet websites, this encryption requirement basically kills any interest I had in experimenting with HTTP/2 which was already miniscule. I'm not seeing the use case for HTTP/2 unless you're already all-https or in the Top N websites and want to slim down bandwidth use.

Re: TLS in HTTP/2

#18

Post by bodyfour »

m_eiman wrote: post #11
stephen_g wrote: post #9

Earlier quoted context omitted.

Certificates are generally based on hostnames. You can put an IP as the common name but it's problematic (and you can't get one signed by most authorities for an IP address as far as I know). Generally the devices just generate a self-signed certificate and you have to click through the warning.

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, since only they know the hostname it will be exposed as. That's a poor initial-install experience.

Re: TLS in HTTP/2

#19

Post by Siecje »

higherpurpose wrote: post #2

> Internet Explorer people have expressed that they intend to also support the new protocol without TLS, but when they shipped their first test version as part of the Windows 10 tech preview, that browser also only supported HTTP/2 over TLS. As of this writing, there has been no browser released to the public that speaks clear text HTTP/2. Most existing servers only speak HTTP/2 over TLS. I'm hoping it will stay this…

Why wouldn't you want to see HTTP/2 used without TLS?

If you are not logged in or sending sensitive information you don't need TLS but could still benefit from HTTP/2.

Re: TLS in HTTP/2

#20

Post by michaelbuckbee »

m_eiman wrote: post #7

How could certificates ever work in embedded applications connected to consumer LANs that provide interfaces over HTTP? Aren't certificates tied to IP addresses, which wouldn't work with e.g. DHCP? Not to mention certificate expiration and updates…

Typing IP addresses to certs is a certificate vendor addition to standard SSL issuance policies. Some of the high end (as denoted by more insurance) certs from say Symantec will be "locked" to an IP address, but again this is mostly handwaving.
Post reply on HN