Live data from Hacker News

Strengthening HTTP: A Personal View

mnot.net

31–40 of 51 posts

Re: Strengthening HTTP: A Personal View

#32

Earlier quoted context omitted.

Don't shift the burden of proof-It is up to HTTP/2 proponents to demonstrate that the benefits are greater than the costs and from everything I've seen the benefits are meager and the costs are large.

I'm not trying to shift the burden here, but the point made was along the lines of "HTTP2 is rubbish" - I've seen this a lot, with little to back it up. But I'd say some of the benefits were: - Server push support - Multiplexed requests/header compression/other performance improvements - Mandatory encryption support Downsides are (from what I understand): - Not a plaintext protocol There may be more downsides, which…

Mandatory encryption support sounds like a good idea, but isn't that what the article was saying they aren't going to do? I would say the other things you mentioned are features, but not necessarily benefits. Server push is not something I want, and if I did, web sockets are probably a better solution. And those alleged performance improvements have yet to show a significant performance increase on real-world web sites.

Re: Strengthening HTTP: A Personal View

#33

Forget the hand-waving and excuses, TLS needs to be mandatory, period. This alone would make me forgive just about any other problem with HTTP/2.

I disagree for a number of simple reasons.

- Cost. You now require every domain owner to also pay for certificates (or get a free one, but the process is roughly the same).

- Limited choices. The keys to the kingdom are owned by a few corporate interests.

- Encrypted browsing is simply unnecessary for certain classes of sites (non-logon, informational sites).

- It increases the barrier for entry to put a basic website up. As well as knowing some html and css, you also need to know about certificates and keys, how to deploy them, and how to keep them safe.

- Internal network communication becomes a lot harder with self-signed certificates. You've now got to generate certs and add them to trust stores.

Leave the choice to the site operators and the users. Fix the CA system before forcing it upon everyone.

I have HAProxy set up as the SSL termination point. It fronts about 15 different applications. But there's no easy way to decrypt at the proxy and then re-encrypt to the backend servers.

We're not ready for mandatory SSL.

Re: Strengthening HTTP: A Personal View

#34
post #31

Forget the hand-waving and excuses, TLS needs to be mandatory, period. This alone would make me forgive just about any other problem with HTTP/2.

Disagree, purely informational websites have no need for TLS.

The need for TLS is less in purely information websites, but there are a number of problems with this attitude. For one thing, the content of the pages you visit still leaks information about a user, even if the page isn't customized per user.

Second, authenticated, trustworthy SSL connections provide MITM protection and prevents modification of the content you receive - the transition from HTTP to HTTPS is generally going to be vulnerable to an sslstrip-like attack, homoglyph attacks, etc, plus content could be modified maliciously in transit directly over an HTTP connection (a less drastic form of this sort of thing has happened many times with ISPs adding in tracking cookies in transit, or comcast adding some javascript to pages when you get close to your bandwidth limit).

In any case, the cost of all-TLS is really not so high that you can't enable it just for edge cases who want or need to use secure connections for all internet communication.

Re: Strengthening HTTP: A Personal View

#35

Forget the hand-waving and excuses, TLS needs to be mandatory, period. This alone would make me forgive just about any other problem with HTTP/2.

That would be totally valid if the CA industry wasn't so terrible. But given that encryption without authentication and trust is more or less theatre, we need a solid replacement for the current CA scene before mandating TLS is sane.

Re: Strengthening HTTP: A Personal View

#36
post #31

Forget the hand-waving and excuses, TLS needs to be mandatory, period. This alone would make me forgive just about any other problem with HTTP/2.

Disagree, purely informational websites have no need for TLS.

1) There are regimes that would lock you up (or worse) for looking at some "purely informational" sites.

2) Defaults matter and developers make mistakes. Without required TLS many sites that should be encrypted won't be (they forgot, the site grew into something it didn't used to be, they had no idea what TLS was, etc)

Re: Strengthening HTTP: A Personal View

#37

Myself, I like the idea of opportunistic encryption. Why not require TLS for HTTP/2 but don't require authentication for http:// URLs?

It's hard to see what benefit that would offer. Non-authenticated TLS is trivially vulnerable to MITM attacks. This is especially the case because I can't foresee a situation in which a website would put the effort in to implement opportunistic TLS, but not implement straightforward authenticated HTTPS…

This article has a great response to that argument: https://www.tbray.org/ongoing/When/201x/2014/07/28/Privacy-E...

Re: Strengthening HTTP: A Personal View

#38

Forget the hand-waving and excuses, TLS needs to be mandatory, period. This alone would make me forgive just about any other problem with HTTP/2.

I disagree for a number of simple reasons. - Cost. You now require every domain owner to also pay for certificates (or get a free one, but the process is roughly the same). - Limited choices. The keys to the kingdom are owned by a few corporate interests. - Encrypted browsing is simply unnecessary for certain classes of sites (non-logon, informational sites). - It increases the barrier for entry to put a basic websit…

> Cost

The certificate issue is a browser problem. Self-issued certificates are trivial to produce, and in the era of mandatory TLS they probably should not produce the huge scary browser warnings we see today. I'm not a UI expert, but I could envision a "medium severity" browser warning that states the connection is encrypted but the certificate can't be verified. I don't see the logic behind abandoning encryption entirely rather than tolerate some level of self-signed certificates.

> Limited choices.

Arguably the whole CA system is in need of serious reform. This is orthogonal to HTTP/2 and TLS.

> Encrypted browsing is simply unnecessary for certain classes of sites (non-logon, informational sites).

I could not disagree more. Encryption is--from an efficiency standpoint--literally just some bit-twiddling (after key exchange). The efficiency cost is trivial, the social benefits are enormous. It's very much worth it.

> It increases the barrier for entry to put a basic website up.

This is one advantage of baking it into the protocol. If the HTTP/2 implementation takes care of the details of encryption (including certificate generation if necessary), website authors don't need to be concerned with it. Everything will just work.

> Internal network communication becomes a lot harder with self-signed certificates.

As stated above, certificates are not barriers. If your network is "trusted", then why would you care if the certificates are self-signed? You are arguing instead to not use encryption at all! Do you see how backward this is?

Re: Strengthening HTTP: A Personal View

#39
post #8

It's disappointing to hear that the idea of requiring TLS with HTTP/2 has lost traction. For me, TLS-everywhere was the carrot on the stick. I recognize that getting consensus is hard work, but I don't think creating another encryption-optional protocol and letting vendors duke it over security is going to end well for the users. HTTP is a deployed protocol with lots of existing stakeholders, like proxy vendors, netw…

I'd like to hear why maintaining status quo for stakeholders should ever be a valid argument for a technology standard.

Because for a standard to actually become standard, you have to make it desirable for the people who you're trying to talk into switching to it.

Re: Strengthening HTTP: A Personal View

#40
post #27

For example, in the current design of HTTP the decision as to whether to use encryption is completely up to the server; the only thing the user can do is observe whether a URL is “HTTP” or “HTTPS” (or maybe watch a lock icon) and decide whether they can continue surfing. This seems a strange characterization. As in any other network protocol, if the client and server don't agree then nothing happens. If either insist…

I think he's saying that clients could decide beforehand whether they want to go into HTTPS-only mode, for example. But this is something clients can actually do today, without the need for a new protocol or any awareness on the server side. URL isn't HTTPS? Don't load it. I actually did a Firefox plugin that implements this, called http-nowhere.

But this is something clients can actually do today, without the need for a new protocol or any awareness on the server side. URL isn't HTTPS? Don't load it. I actually did a Firefox plugin that implements this, called http-nowhere.

Yes - and my understanding is that the browser developers are going to require all HTTP2 connections to be over TLS anyway.

Post reply on HN