Hacker News Reader

Comment by danielweber | Hacker News Reader

What about embedded devices.

Not everything on the web is sitting on a well-known server.

Right - embedded devices, one off toy apps, a lot of internal organization pages, and a lot of hobbiest projects make up a huge part of the "web space". These will all suffer for more reasons than cost of certs - it adds a new hurdle and a barrier for entry.

Think about printers for a moment: now all the printers providing http interfaces need to include a way to install an organizational cert on them (at least for a lot of organizations). That means that there needs to be an out of band step in setup (and maintenance) to add the cert, or a way to do so from an http interface. The later just screams "giant security risk" for a dozen reasons.

I am sure it happens but you should not be exposing your printer to the Internet. That is just asking for trouble. You would not need HTTPS on an internal network.

But HTTP 2 requires it, no matter if you need it or not.

No, it doesn't. From the article: “To be clear - we will still define how to use HTTP/2.0 with http:// URIs, because in some use cases, an implementer may make an informed choice to use the protocol without encryption.”

The reason for your parent comment (and my initial misunderstanding) was because this post title was submitted as "HTTP 2.0 to be HTTPS only". By the time I refreshed the title was changed, but this is why we need to stop modifying original article titles in order to bait more views.

So you require a cert for personal projects. That doesn't mean a cert that chains to a public trust. You could easily cut your own cert and trust it on whatever device you wish to access the site on

And for e.g. intranet usage the organisation could set up their own internal CA to validate TLS certificates. The root certificate could be distributed in a manner suitable to the organisation. E.g. via Group Policy for Windows clients, or by simply including it in the disk image used for setting up new machines.

> You would not need HTTPS on an internal network.

This is false. Good security is layered security.

> You would not need HTTPS on an internal network.

Oh, really?

http://www.washingtonpost.com/world/national-security/nsa-in...

Sure, but there are many new (and not-so-new) "internet of things" devices that explicitly _do_ want to be able to connect to the internet - and a great deal of additional value derives from that ability.

I've spent a lot of time recently working out how to securely allow a set of christmas tree lights with an embedded linux controller[1] with wifi connect via OAuth to your Twitter or Facebook account while being controlled from your phone. The lack of workable/affordable ways to have SSL keys on the device that your phone will trust makes life _very_ interesting - and getting the password-equivalent OAuth tokens into the device has been a fun challenge.

[1] Gratuitous self promotion - http://moorescloud.com/ go pre-order one now to justify getting UL certification so we can sell 'em in North America! _Please!_ ;-)

sounds like devices that wouldnt make the switch to http 2 anyway

So your argument is lets create a new version of a protocol, but make it less capable than the version which proceeds it, so that there are very valid use-cases which cannot be solved using the new protocol-version, forcing us to rely on multiple protocol-versions for what should be the same thing?

How on earth do you make such an argument make sense?

Did you mean to send that reply to me?

Reply on news.ycombinator.com