News for hackers. Stuff that matters.
Re:TLS in HTTP/2 by m_eiman on Friday March 06, 2015 @05:39AM (#9156454)
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…
Re:TLS in HTTP/2 by forgottenpass on Friday March 06, 2015 @08:55AM (#9156973)
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 by stephen_g on Friday March 06, 2015 @05:49AM (#9156476)
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.

Re:TLS in HTTP/2 by m_eiman on Friday March 06, 2015 @06:05AM (#9156507)
Ok, so it's just a horrible user experience then :]
Re:TLS in HTTP/2 by bodyfour on Friday March 06, 2015 @08:57AM (#9156978)
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 by Karunamon on Friday March 06, 2015 @11:50AM (#9158006)
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 by jeremie on Friday March 06, 2015 @11:36PM (#9161005)
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 by michaelbuckbee on Friday March 06, 2015 @10:34AM (#9157483)
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.
Re:TLS in HTTP/2 by icebraining on Friday March 06, 2015 @05:46AM (#9156471)
Aren't certificates tied to IP addresses

No, just to domains.