Hacker News Reader

Comment by YoavR7 | Hacker News Reader

Cool! You should probably add http support and not only https. Writing `curl ec2.shop` is easier than `curl https://ec2.shop`

View on HN

For HTTPS to truly be meaningful we need to stop supporting HTTP as an on-ramp, to prevent people from just hijacking that initial unencrypted connection and sending anything they want.

If you MITM and the user agent send an HTTP request for ec2.shop it does not matter whether the webserver supports HTTP or not, you can send a fake HTTP response either way.

That was the GPs point.

Anyone who likes to prevent that can submit their site to the HSTS preload list. Chrome, Firefox and Edge use a shared one, the only two relevant other agents (Safari and curl) unfortunately don't though.

This is about curl though.

(speaking only for myself, not my employer)

I truly do not care if someone goes through the effort to MITM my curl of ec2.shop to inject fake prices or something like that.

There's nothing here that's going to be executed, it'll just be printed or grepped.

In theory you could exploit a 0 day in curl or my terminal or something like that, but I think if you truly think about the risks and tradeoffs here it's really not worth worrying about.

If curl had an hsts list to make this irrelevant that'd also be cool.

> There's nothing here that's going to be executed

... yet.

Imagine someone using it to find "the biggest size available under $1" and then taking that value to execute some other script.

These days curl should probably default to https. Or at least give you an environmental variable where you can define the default protocol (libcurl does offer something similar: https://curl.haxx.se/libcurl/c/CURLOPT_DEFAULT_PROTOCOL.html)

    alias curl='curl --proto-default https'

curl -L ec2.shop works for just 2 extra chars

Reply on news.ycombinator.com