TLS in HTTP/2 - Hackdot

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.

[ Parent | on HN ]

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 :]

[ Parent | on HN ]

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

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 :)

[ Parent | on HN ]