Hacker News Reader

Comment by frik | Hacker News Reader

You are right. More and more propaganda these days to steer the crowd to things were only the top players benefit. HTTP 0.9/1.x with or without TLS (aka HTTPS) is still relevant. And making TLS mandatory is a very bad decisions, it will hurt every dev who had to touch lower level APIs or do performance optimization or debugging a lot. Sometimes it would help to think a bit father then ones nose is long.

View on HN

>it will hurt every dev who had to touch lower level APIs or do performance optimization or debugging a lot

Cry me a river. Devs want to pump out as much code as possible without thinking about the security considerations. Who cares about the end user that's going to get pwned, right?

HTTP is being phased out. HTTPS certs are available for free. Companies can use self generated certs if needed. The days of exchanging unencrypted text over the internet and blindly expecting some evil or ignorant 3rd party not to tamper with it is long gone.

There's no need to get aggressive.

It will suck to have to resort to essentially MITM tactics on my developer workstation in order to decrypt local traffic. Yes, there are tools like Fiddler that can do this, but eventually it may be impossible to MITM traffic the way Fiddler does. That will make it more difficult to debug applications. There are also platforms like Pivotal Cloud Foundry that rely on being able to inject headers into HTTP messages as the messages traverse the platform (e.g., to support throttling); this will become more difficult if that traffic has to be encrypted.

HTTP/2 with forced TLS is, in effect, a binary protocol. Right now, developers all over the world enjoy the plain-text and hackable nature of HTTP 1.x.

I'm not sure why it would become impossible to do what Fiddler does. It's not like any major platform is going to stop letting you add root certificates.

I don't agree with the parent post (I think all traffic should be encrypted now that let's encrypt exists) but this is an interesting point.

For example, Google is making it as difficult as possible to install certificate authorities in Android. Root certificates are encrypted as if they are client certificates, requiring the user to set up PIN or password protection on their lock screens. Removing this protection immediately disables the installed user certificates.

Google has changed the Android 7 API so that by default the user certificate store is not used to validate the validity of certificates (only the system store is used). Apps need to opt in to still support user certificates.

Of course this is all done to prevent malicious actors from performing MitM attacks on users. Still, I would not be surprised if Android P removes the user certificate store all together.

Cloud Foundry doesn't have a problem injecting headers, as HTTP traffic is plaintext inside the system itself. It's once it starts traveling across the public internet that encryption is needed. This does make it harder for network edge caches and for middleboxes, but that's not totally a bad thing either.

It's a common argument that HTTP/2 being binary makes it harder to debug. Sure, it might be tougher if I'm using Wireshark to look at raw TCP packets. But Chrome/Safari/Firefox/IE Web Inspectors (what most web devs use to debug HTTP requests) already parse the HTTP the same way as before.

So I've noticed exactly 0 difference in my workflow between HTTP 1 and HTTP 2.

What's the support for HTTP/2 in tools like curl and socat?

Answering myself: curl has supported HTTP/2 since 2013.

<strike>None for netcat (it's a bare-wire tool, and doesn't support HTTP/1.1 either)</strike>

sorry, I must have misread "socat" as "netcat". Since socat's HTTP integration is an HTTP proxy on port 8080 it should be transparent due to using "CONNECT" for https.

curl offers --http2 and uses ALPN where available as explained here: https://curl.haxx.se/docs/http2.html

Try h2i too: https://github.com/bradfitz/http2/tree/master/h2i

Reply on news.ycombinator.com