5 ms·

Perhaps this is a dumb question, but when would VERIFYHOST=1 be useful?

tptacek 14y ago
On Twitter today, Daniel Stenberg, Curl's maintainer, said: @pmjordan @tqbf for test, and also for the same reason browser-users just click yes yes yes on cert dialogues He seems like a nice guy and being the sole maintainer of Curl seems like a tough and probably unrewarding job. But that said, it's hard to shake the impression that VERIFYHOST=1 exists because people want to believe they're doing SSL/TLS securely, but have trouble getting it configured properly, and that VERIFYHOST=1 exists primarily to give people the feeling of having configured SSL/TLS well without making them actually do that.
- rolux 14y ago
  When it comes to API design, a good rule of thumb is that parameters that can be either 0, 1 or 2 will cause bugs.
  - jrockway 14y ago
    More generally: "when it comes to API design, a good rule of thumb is that parameters will cause bugs."
    - adgar2 14y ago
      Your more general adage is useless. The one you responded to is useful. A more useful, also general adage would be "the more choice in selecting parameters to an API, the more likely there will be bugs consuming that API."
    - rolux 14y ago
      No, I was actually trying to be specific. There's usually nothing wrong with 0/1 or 1-9. Empirically, 0/1/2 either means no/yes/yes-and-something-obscure-on-top-of-that, or, worse, as in this case, no/kind-of-but-not-really/yes.
      - prodigal_erik 14y ago
        It's akin to http://c2.com/cgi/wiki?ZeroOneInfinityRule http://c2.com/cgi/wiki?ZeroOneInfinityRule. If you started out thinking it was just a switch, you should be very reluctant to add a third state without rethinking what you really need to express, or you end up with my favorite from TheDailyWTF: enum Bool { True, False, FileNotFound }; This would have been much safer as separate AUTHENTICATE_CERT (which checks the CA sig and expiry and revocation) and VERIFY_CERT_COMMON_NAME options, both of which default to true.
  - Genmutant 14y ago
    In this case I think it wouldn't cause bugs if the effect of 1 and 2 would be switched. Then everybody would use it like a boolean and that would be fine, only the few people who really want the name-check disabled would use that option.
- 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 ago
    I 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 ago
      I 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 ago
        Changing 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.
GauntletWizard 14y ago
Networks where users have failed to set up proper SSL CAs for internal use; Lots of customers I've seen with failed CA setups, self-signed certs everywhere, etc.
- tptacek 14y ago
  Yes, but VERIFYHOST=0 handles that case, and does what users expect.

On Twitter today, Daniel Stenberg, Curl's maintainer, said: @pmjordan @tqbf for test, and also for the same reason browser-users just click yes yes yes on cert dialogues He seems like a nice guy and being the sole maintainer of Curl seems like a tough and probably unrewarding job. But that said, it's hard to shake the impression that VERIFYHOST=1 exists because people want to believe they're doing SSL/TLS securely, but have trouble getting it configured properly, and that VERIFYHOST=1 exists primarily to give people the feeling of having configured SSL/TLS well without making them actually do that.

rolux 14y ago
When it comes to API design, a good rule of thumb is that parameters that can be either 0, 1 or 2 will cause bugs.
- jrockway 14y ago
  More generally: "when it comes to API design, a good rule of thumb is that parameters will cause bugs."
  - adgar2 14y ago
    Your more general adage is useless. The one you responded to is useful. A more useful, also general adage would be "the more choice in selecting parameters to an API, the more likely there will be bugs consuming that API."
  - rolux 14y ago
    No, I was actually trying to be specific. There's usually nothing wrong with 0/1 or 1-9. Empirically, 0/1/2 either means no/yes/yes-and-something-obscure-on-top-of-that, or, worse, as in this case, no/kind-of-but-not-really/yes.
    - prodigal_erik 14y ago
      It's akin to http://c2.com/cgi/wiki?ZeroOneInfinityRule http://c2.com/cgi/wiki?ZeroOneInfinityRule. If you started out thinking it was just a switch, you should be very reluctant to add a third state without rethinking what you really need to express, or you end up with my favorite from TheDailyWTF: enum Bool { True, False, FileNotFound }; This would have been much safer as separate AUTHENTICATE_CERT (which checks the CA sig and expiry and revocation) and VERIFY_CERT_COMMON_NAME options, both of which default to true.
- Genmutant 14y ago
  In this case I think it wouldn't cause bugs if the effect of 1 and 2 would be switched. Then everybody would use it like a boolean and that would be fine, only the few people who really want the name-check disabled would use that option.
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 ago
  I 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 ago
    I 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 ago
      Changing 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.

GauntletWizard 14y ago

Networks where users have failed to set up proper SSL CAs for internal use; Lots of customers I've seen with failed CA setups, self-signed certs everywhere, etc.

tptacek 14y ago
Yes, but VERIFYHOST=0 handles that case, and does what users expect.