5 ms·
> and that VERIFYHOST=1 exists primarily to give people the feeling of having configured SSL/TLS well without making them actually do that. API doc: "When the
by jpdoctor 14y ago
> and that VERIFYHOST=1 exists primarily to give people the feeling of having configured SSL/TLS well without making them actually do that.
API doc: "When the value is 1, the certificate must contain a Common Name field, but it doesn't matter what name it says. (This is not ordinarily a useful setting)."
[emphasis mine] It's hard to get clearer than that.
http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTSSLVERIFYHOST http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTS...
- tptacek 14y agoI think we are all clear that if library users carefully read the documentation, this is an avoidable flaw. I'm not sure what that has to do with my point. If even the Curl author thinks VERIFYHOST=true isn't useful, why does it work that way? The answer is: it shouldn't. "Here's an option that you could reasonably expect to be boolean. And lo! the code appears to work if you treat it as a boolean. But, just to mess with you, I introduced an apparently useless option to handle the 'true' case in that boolean, and introduced an 'even truer' value that does what you expected". This is simply a terrible, dangerous design. It is, like I said on Twitter today, a vulnerability in Curl, and one that should be fixed. The option expressed today by VERIFYHOST=1 should instead be the case when VERIFYHOST=-1 or VERIFYHOST=666. Meanwhile, VERIFYHOST=1 should, tomorrow if possible, do exactly what VERIFYHOST=2 does today.
- drivebyacct2 14y agoI don't think this shouldn't be changed, but surely it's not one that can be made without thought or concern either. Changing the behavior overnight will undoubtedly break servers and scripts.
- moe 14y agoChanging the behavior overnight will undoubtedly break servers and scripts. It will only break servers and scripts that currently operate under a false sense of security. The maintainer should file a CVE, push the fixed version and let the distros sort out the rest. And he should do it ASAP.
- jpdoctor 14y ago> I'm not sure what that has to do with my point. The point of yours that I addressed was: "that VERIFYHOST=1 exists primarily to give people the feeling of having configured SSL/TLS well without making them actually do that." Put simply: It does not exist primarily for that purpose. I can't make it any clearer than that.
- tptacek 14y agoOh yeah? Interesting. Tell me, what is the point of checking to see if a certificate has a common name field in it but then not checking to see if that common name is related to the connection bearing the certificate? Make it clear for me, will you?
- Natsu 14y agoThat option exists to punish those evil people who don't read the documentation. I'm kidding... I think.
- brazzy 14y ago> Put simply: It does not exist primarily for that purpose. You fail to provide any proof for that statement. The API doc merely states what the setting does, it says absolutely nothing about about its purpose, and neither do you.
- kyberias 14y agoThis is definitely NOT a vulnerability in curl. I hate it when security people treat everything black and white. There ARE other things to consider.
- tptacek 14y agoSuch as what? When VERIFYHOST=1, curl has basically turned the security part of SSL/TLS off. That seems like kind of a big deal for an HTTPS/SSL API.
- wisty 14y ago> I hate it when security people treat everything black and white. That's because experience shows if things are "grey" then someone can almost certainly break in.
- deleted 14y ago[deleted]
- zorbo 14y agoYou do realize that the curl API says this: > The default value for this option is 2. In other words, there is absolutely no issue here. It does the right thing out of the box.
- mikeash 14y agoIt's easy to get much clearer than that. Instead of "1", use a constant with a name like "VERIFY_HOST_SETTING_INSECURE_IGNORE_COMMON_NAME".