Hacker News Reader

Comment by rita3ko | Hacker News Reader

It's not Eleven-Lab's present, seeing as they don't support HTTPS, and HTTP2 doesn't work without it.

The standard [1] doesn't require the use of TLS/HTTPS. However, all of the major implementations only support HTTP/2 over TLS.

[1] RFC7540 - https://tools.ietf.org/html/rfc7540

Correct, "all of the major implementations" :)

Which I'd quite bad. I don't understand why/who lobbied to implement it that way in Firefox. Can someone disclose the decision-making behind this? It would help devs a lot if HTTP/2 works without TLS too.

All the main browsers want to encourage HTTPS everywhere. They're taking a number of initiatives to encourage it, some are carrots, some are sticks.

Mostly it's ending up as the stick, eg "You can only get these major performance advantages over HTTPS". Soon there is an intent to specifically call out non-HTTPS content very prominently in the browser, even more so that HTTPS content was ever called out back when that was introduced.

Yes, exactly. But why? What's the agenda? Why now? It's not like Amazon.com was broken between 1996 and 2016. There is a push to HTTPS at all costs, even if things (ad networks, devs, software) is not ready and is there even a need for 100% TLS? That an open source browser is engaged in such initiative is not good. With HTTP you can be anonymous, and most website visits aren't mission critical things. With HTTPS your traffic is quite unique and the players with big money have the resources anyway, there TLS is no big thing as we learned in the last few years. So which Think-tank or what ever is behind this initiative?

Even if it's not a mission critical web request, isp's injecting content into your http pages is unacceptable.

Even if the government could brute force or fingerprint one of your TLS sessions, they can't do it for everyone for every site.

Just because Amazon wasn't broken doesn't mean we can't improve it.

Also your comment about a think tank coming up with this idea is an odd insult, given how broadly you can empirically see people support this.

Hmmm but i am pretty sure ISP and Ad Agents(Google etc..) will figure a way to inject content.

Well... They won't be able to. If they can figure out a way it means they have broken the underlying encryption, so that gets fixed.

You believe TLS makes it easier to track you?

Is this based on some odd notion of ClientAuth?

This is a great opportunity to get people to use TLS across the board. The carrot is HTTP/2.

> With HTTPS your traffic is quite unique

What's more unique about HTTPS traffic than HTTP traffic?

Your supported ciphers contribute to your browser fingerprint maybe?

I cannot imagine that the supported ciphers could be more identifying than your user agent, all cookies, all headers, query string, and request body.

>there TLS is no big thing as we learned in the last few years

Citation? We've learned what has always thought to have been true: Encryption works very well and intel collectors need to resort to attacking other aspects. TLS has had its share of flaws but it's still very much a "big thing" to defeat.

In addition to browsers wanting to push https adoption, there was concern over how middleboxes would deal with it. Http2 is very different on the wire than http1 and middleboxes are known to be extraordinarily horrible at handling new protocols gracefully.

I think the more interesting question is why consensus couldn't be reached on requiring TLS as part of the standard.

IIRC, the ask for cleartext HTTP/2 was about IoT devices. Which IMO is short-sighted.

https://mobiforge.com/news-comment/no-https-then-bye-bye-geo...

https://www.wordfence.com/blog/2017/01/chrome-56-ssl-https-w...

https://blog.mozilla.org/security/2015/04/30/deprecating-non...

http://stackoverflow.com/questions/32106849/getcurrentpositi...

https://konklone.com/post/were-deprecating-http-and-its-goin...

http://forums.whirlpool.net.au/archive/2598616

Just some random places to start to see why the major web browsers are not going to spend any time on non-encrypted protocols. A lot of devs need to help themselves and move to encrypted to connections before they are forced at browser-point.

The problem is, basically, middleboxes. It's unfortunately still common to intercept HTTP connections and redirect them to some sort of caching proxy, and some of these proxies will misbehave when seeing HTTP/2 on the wire, causing hard-to-diagnose connection issues. It's even worse when firewalls are involved, since they can get confused easily and will drop the connection (manifesting as a hang in the browser) in that case.

With TLS, not only is it less common for the connection to be intercepted, but also a MITM proxy which doesn't understand HTTP/2 won't negotiate it with either end, transparently falling back to HTTP/1.1. And firewalls will only see the outer TLS protocol.

I think you should usually practice what you preach. I did a HTTP/2 test on their server and it doesn't support it.

Reply on news.ycombinator.com