-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
curl: warn when --insecure is used #1821
Conversation
As noted on That is, While this causes an 'extra' connection attempt in the case where the server certificate can not be verified, it prevents warning fatigue -- issuing a warning when in fact nothing is wrong. I don't mind penalizing connections to an untrusted server to avoid further habituating users to ignore warnings. See the full discussion on |
Changes Unknown when pulling d82708e on bagder/insecure-warning into ** on master**. |
Disagree. If someone uses |
I'm with @jay here. |
The question is what they asked for. And what this PR is actually trying to accomplish. Previously, what they got was a connection to a site, even if the certificate could not be verified. No warning, no error - just connect. So that's what anyone who has used -k up to now is asking for. This PR changes that. Now you get a warning whether or not the certificate can be verified. So any current user is NOT asking for a warning that (s)he is doing something dangerous. The PR is adding a warning - whether or not the user is in fact doing something dangerous. Substituting your judgement for theirs, based on the stated belief that many users don't know what they are doing. The motivation is good - educate users and try to improve security by having --insecure used judiciously. But the implementation causes a new problem: you still assume that the user is uneducated/following random instructions when the site certificate may in fact be verifiable, yet you provide a warning that the connection IS insecure without even trying to see if the certificate can be verified. The result is that you do not attain your goal, which is that --insecure is employed only when necessary. Instead, your PR:
An alternative to only warning when the certificate fails to verify is to also warn when --insecure is used but the certificate DOES verify. This would address the last point. I didn't suggest this initially because it seemed better to meet the current user expectation of silent success when things are OK. I believe that either of my suggestions would advance your goals more effectively than the current PR. |
That's what they asked for. (Cue Abbott and Costello). I think the warning is unnecessary. |
I'm not pushing forward on this idea, as I fear it won't help much and add to our general warning-fatigue. I'm instead trying out a larger take, see Trust On First Use. |
The warning can easily be avoided by just using With
Having seen the confusion over this flag (also in (To ease on "warning-fatigue", the warning may be omitted when used with HTTP protocol. I've seen projects where the flag is used with HTTP - yet another sign of getting the meaning of this flag wrong.) |
No. There many sites that do not respond to http, or if they do, simply redirect to https. This is increasingly common with the push for TLS everywhere. If the certificate is self-signed/not locally trusted, the site is inaccessible without some means of adding trust (or ignoring the error.) TOFU seems like the best path forward. |
If a site unconditionally redirects HTTP to HTTPS and have a broken (self-signed/untrusted/etc) certificate, it's a site that should be fixed. Such scenario also don't seem to be very widespread, at least not on the public internet and such site is already broken when used from a browser. So, if the |
As for TOFU: To me this seems to address a different problem and won't help with the hundreds of thousands of cases where -k/--insecure is already added and silently nilling the (positive) effect of HTTPS. It also inherits the issues of (It'd be nice to add a few words about what problem TOFU is exactly designed to solve though. Maybe I'm misunderstanding it completely. It'd be also nice to verify how its functionality may or may not overlap with HSTS.) |
The TOFU concept could help people avoid HSTS support would be lovely but seems to be somewhat orthogonal as that automatically upgrades HTTP to HTTPS for us - but doesn't really address the trust part. |
Not sure what the common case may be for I think inherently TOFU encourages to create manual "custom trusts" (by accepting whatever cert the server is offering), instead of fixing the underlying TLS/server configuration or tapping on existing |
Agree. I don't think it will make educated users any safer, they have already established a secure method and if they choose to use --insecure so be it. They could also use pubkey pinning. Just because there are a lot of people using --insecure does not mean they don't know what they're doing. Maybe they need a public resource and don't care to deal with some server's shenanigans. Uneducated though I can see it now, |
I'd only add that I'd guesstimate that a significant portion of If someone has chosen this road intentionally: fine. The issue starts to become a bigger problem when downstream/end users are lead to believe they are using security when seeing/specifying an HTTPS:// address, while in reality security is invisibly disabled. This is even more hidden with direct libcurl usage - and turning off security is even more widespread there (at least according to GitHub code search numbers.) Speaking of the curl command-line, another possible cure might be to show the certification verification error even with the |
In my view, the discussion around tofu is a discussion on how to make curl enable users to do the right thing easier. Not necessarily make people automatically become perfect netizens without knowing a thing about it. Like "Sure, --insecure is bad, but what's the easy step to make the connection secure?"
True, but I'm firmly against deliberately breaking an unimaginable large number of scripts and programs "out there" for this reason alone. It also goes orthogonality against our efforts to maintain backwards compatibility. |
The idea of TOFU is based on the assumption that the majority reason for I'm still in favour of a warning, at least by showing the cert problems at all times, and possibly toning it down by omitting it for IP addresses and I also think that giving new tools for curl users to shoot themselves (and their end-users) in the foot is perhaps not the best solution and |
I am forwarding a reply on this from Nikos Mavrogiannopoulos (sorry for the delay):
|
Good points. I've updated the wiki page slightly to make it more clearly prefer pinning. |
As mentioned in #1810, the
--insecure
(and its short version-k
) command line option is used very widely by programs and scripts all over the world (hundreds of thousands of times in github hosted code alone).Presumably, not all users of this option fully aware of the implications. One way to try to make more people aware, is to add a warning message in the output when this option is used.
This PR adds such a warning and I figured it could be used as a sort of discussion-starter of what we can do to raise people's awareness and encourage that users rather make secure SSL connections.