SSL stripping easier than some seem to realise

[sh1boot]

SSL stripping involves intercepting the initial HTTP connection which is supposed to redirect to the HTTPS site, and returning something which does not redirect to the expected HTTPS site, so subsequent transactions carry on in cleartext or carry on to the wrong server. It's a gaping hole that's supposed to be mitigated by HSTS preload, or by always specifying HTTPS in the URL.

I recently came across a site which had apparently golfed their curl-to-bash install command by removing https:// and replacing it with -L , seemingly leaving the operation wide open to MITM attacks.

When curl sees an URI with no scheme it ends up using the CURLU_GUESS_SCHEME flag which will guess http and not https. It then attempts to get the file using that scheme and if the HTTP site is working correctly it'll get a redirect meaning that you need the -L option to follow the redirect to the corresponding HTTPS site. If that initial HTTP request is intercepted then hilarity ensues.

You can configure curl otherwise, but by default it makes insecure guesses.

Should there be an alternative to CURLU_GUESS_SCHEME which guesses only secure protocols? Should there be some means for site administrators to make that the default for the machines that they manage, at the cost of making people mad at them when scripts break?

It might be reasonable to make it the default for .dev domains. Google established this as an HTTPS-only domain by putting all sites under it in the HSTS preload implicitly (although this says nothing about non-HTTP traffic).

But HSTS isn't enabled by default. And even if you enable it .dev isn't preloaded by default.

Should .dev TLDs be hard-coded with the HSTS upgrade by default? Even without enabling HSTS? If so, how would you use curl to test the redirect that should be present on port 80?

[bagder]

I insist that this problem is not curl's. curl does the transfer you ask it to do. If you want to do a secure transfer, use a secure and authenticated transfer mechanism such as HTTPS. Don't ask curl to do insecure transfers if you want secure. It is easy to always just use https:// URLs to stay safe. Guessing is never the safe bet.

curl provides options to disable the use of a specific protocols, such as HTTP:// and you can set which protocol it should default to when "guessing".

curl will not auto-enable HSTS for specific domain names.

[sh1boot]

I don't question curl doing what is asked of it. I question whether or not an URI with no scheme is asking for HTTP.

Maybe there's some RFC somewhere that says it is. Or maybe it's just some outdated convention. I don't know.

However, I believe the intent of preloading .dev into HSTS is that it should be HTTPS by default.

But I guess even modifying the guess to prefer HTTPS when it sees a .dev TLD is objectionable, on the basis that it's just one entry in a vast database, and it's irregular and unpredictable to give it special handling.

Certainly changing the default arbitrarily is bound to break stuff, and that's why we still have an insecure-by-default internet. Maybe it's worth enabling incremental changes to the default until maybe one day the internet is no longer that way, but I'm not going to push for it.

I saw something, I said something. I did my part.

[sh1boot]

That is why http:// is obsolete and should no longer be considered the default assumption if somebody doesn't specify what they meant.

You can tell from the curl-to-bash arguments out there that people believe they're using TLS when they're doing this. They're wrong, but it shows their intent.

[swhiteman]

A URI cannot be specified without a scheme, so by definition anything without a scheme is not a spec-compliant URI.

Just catching up on this thread.

The final URI (target URI) must have a scheme. When resolving relative URIs, RFC 3986 specifies the Default Base URI is application-dependent (5.1.4).

So curl is explicitly compliant in choosing a Default Base URI of http, i.e. Base.scheme of http in the Reference Resolution algorithm. Nothing even out-of-spec about it.

[bagder]

@swhiteman section 5 has the following text in the intro "This section defines the process of resolving a URI reference within a context that allows relative references"

A scheme-less URL as curl supports is not a relative reference. You cannot and never could use a relative reference like "localhost" as a URL. It can however be specified as //localhost if you do a redirect to a host and want to stick to the same scheme.

The URL curl accepts is an absolute URL.

[swhiteman]

Not sure what you mean by 'never could'?

localhost is a relative URI with only an authority (and only host part of the authority). curl localhost retrieves http://localhost. The outcome is the same as it would be with RFC 3986 Reference Resolution of localhost + base URI http:.

[swhiteman]

Oh I see now, you're saying localhost is a non-compliant relative reference.

(EDIT: More accurately, localhost is an RFC 3986-compliant relative reference. But it specifies a path, not a host: transformed using RFC 3986 semantics and a known Base URI, it wouldn't replace the authority but the path. On the contrary, curl prepends the implicit http:// rather than treating it as relative, so the RFC 3986 algorithm is irrelevant. Gotcha.)

[sh1boot]

So here's a fun search to run on GitHub:
/\bcurl -[^ ]*L[^:${%]*\|[ a-z]*sh\b/
Eleven thousand people who didn't read the manual.

But these ones get the gold star:
/\bcurl -[^ ]*L[^:${%]*\| *sudo\b/

[bagder]

Eleven thousand people who didn't read the manual.

That's just your (peculiar) conclusion. Not a fact. I believe lots of them know exactly what's going on.

[sh1boot]

You mean they want their users' shells to execute code sent over an insecure channel?