-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
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
HTTP/SASL/SOCKS: Implement CURLOPT_SAFE_AUTH #8295
base: master
Are you sure you want to change the base?
Conversation
Test 452 needs to be disabled for rustls for now:
(there's a list of disabled tests in |
Thanks for the hint. |
.SH DESCRIPTION | ||
Pass a long as parameter, 0 or 1 where 1 is for enable and 0 for disable. | ||
When set, This option rejects authentication mechanisms that would | ||
transfer clear passwords on a non-encrypted connection. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It feels reasonable to expect a user to mostly want to set this for both host+proxy at the same time, or not at all. Therefore I think it could make sense to be able to set both using the same libcurl option using a bitmask instead of adding two separate options.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if this option is set true and CURLOPT_HTTPAUTH
sets Basic? It would probably help if this spells that out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the review.
What happens if this option is set true and CURLOPT_HTTPAUTH sets Basic?
Sure, these are contradictory options.
In case it occurs, the CURLOPT_SAFE_AUTH
takes the precedence. This is also true for SASL mechanisms. I'll add a doc paragraph for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... set both using the same libcurl option using a bitmask instead of adding two separate options.
I did it that way because we don't have a curl_easy_getopt()
(BTW: possible future feature?). But I'll change it if you prefer.
What about flag names? I suggest CURLSAFE_AUTH
and CURLSAFE_PROXYAUTH
.
lib/http.c
Outdated
#define SAFE_AUTH_MECHS (CURLAUTH_NEGOTIATE | CURLAUTH_BEARER | \ | ||
CURLAUTH_DIGEST | CURLAUTH_NTLM | \ | ||
CURLAUTH_NTLM_WB | CURLAUTH_AWS_SIGV4) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be the same bitmask as CURLAUTH_ANYSAFE
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I missed it. Will change.
.SH DEFAULT | ||
0, disabled | ||
.SH PROTOCOLS | ||
FTP, HTTP, IMAP, LDAP, POP3 and SMTP |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm don't SCP and SFTP then basically always have this option implied? I don't think they can send any auth in clear text.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ssh protocol always login on a secure channel. See https://www.ssh.com/academy/ssh/protocol#how-does-the-ssh-protocol-work.
Thus there's no need to handle these options there.
e5e8e19
to
57a8658
Compare
f2b697a
to
a44c3b8
Compare
263d559
to
e39ced2
Compare
5d9bc89
to
0b34465
Compare
a7bcf80
to
348eec1
Compare
Ping ? |
@bagder: I was not aware you were reluctant about this PR: your review did not comment in this sense. Alternatives to this PR are:
Additional question: without this PR, how to block clear text non-SASL logins (FTP, IMAP, POP3, LDAP, SOCKS5) ? I'm open to develop an alternative solution if I have some hints in which direction to go, in order not to get a needs-votes label on it and have a quick commit. |
0b062f0
to
0ae77ec
Compare
bcd6b82
to
6219fb5
Compare
b8b5fe6
to
f42f8b3
Compare
ed291f7
to
43761f3
Compare
78382be
to
f3d46fb
Compare
db03ad8
to
1118c7e
Compare
9de2f7e
to
13a9acd
Compare
This option disables clear text password authentication mechanisms over a non-encrypted connection. In particular: - HTTP Basic authentication is disabled - PLAIN and LOGIN mechanisms are disabled for all SASL protocols - IMAP LOGIN is disabled - POP3 USER/PASS authentication is disabled - FTP authentication is disabled unless the user name is "anonymous" - LDAP simple bind is disabled if not anonymous. - SOCKS5 proxy basic authentication is disabled. TLS-encrypted connections (either implicit or explicit) are not affected as they won't transport clear text passwords. This option is triggered by the new curl tool options --safe-auth and --proxy-safe-auth. New tests 750-766 check this option in various contexts.
|
What are you calling an *authenticated channel"?
This is what will finally happen if no safe auth method can be selected. |
An authenticated channel would be using TLS, SSH or QUIC (without Your test 750 does a Basic auth for |
These options disable clear text password authentication mechanisms over
a non-encrypted connection. In particular:
TLS-encrypted connections (either implicit or explicit) are not affected
as they wont transport clear text passwords.
These options are triggered by the new curl tool options --safe-auth and
--proxy-safe-auth respectively.
New tests 730-746 check these options in various contexts.