7 ms·

Context: https://news.ycombinator.com/item?id=11330877 https://news.ycombinator.com/item?id=11330877

by ran290 10y ago

pfg 10y ago
It's worth pointing out that StartCom claims the verification email address in the article in question was only accepted because it matched the WHOIS record of said domain[1], which is permitted according to CA/B Baseline Requirements and their CPS. Definitely not a good choice by the researcher either way. [1]: https://www.startssl.com/NewsDetails?date=20160322 https://www.startssl.com/NewsDetails?date=20160322
- cypherpunks01 10y ago
  That is real confusing, wouldn't that imply one party is outright lying? Blog claims: In the last step of the validation process is where you can modify the email address and replace it with any regular email address StartSSL claims: The email address used to verify the domain name is listed in the WHOIS records..
  - pfg 10y ago
    It could be that, or the researcher really didn't think to try it with an address that's completely unrelated to the domain. Personally, I find it hard to believe that an audited CA has a system where the web frontend can make a decision as to what would be an allowed verification email address. I'm leaning towards believing their story, and would assume they have a backend system which is responsible for checking that input (and which happened to be out of sync with the options offered by the frontend). That's a reasonable explanation for the complete lack of validation in their frontend code. Then again, some CAs have had a terrible track record, so I guess we'll never know for sure now that they fixed the issue (whatever the issue actually was).
    - BillinghamJ 10y ago
      Honestly, while StartSSL's front-end is awful, their practices always seem to far exceed other CAs - especially around verification. I don't enjoy the website, or the verification procedure, but ultimately I generally trust them pretty highly - they operate in a way which shows me they care about security.
      - creshal 10y ago
        We've been generating certificates in direct violation of their TOS for over six years. Every few years they pretend to find out, we do another blatantly non-compliant verification, fork over 120 dollars, and they let us keep printing certificates.
        BillinghamJ 10y ago
        That's interesting. If you don't mind, what rules are you violating?
        creshal 10y ago
        You're only ever allowed to use your account with the person you validated with. You cannot share an account, e.g. between employees of the same company; if you want to transfer an account to another person over your vacation, you have to create a new account, re-validate, and recreate all certificates on the new account. Obviously, we said f*k that and just registered everything on the CEO's name and have him do the phone verification.
        BillinghamJ 10y ago
        Oh right, yeah. I'm pretty sure every company violates that particular rule :P
        chris_wot 10y ago
        Every company that does this loses all their auditing capabilities on the systems that use these accounts. Not good.
    - ikeboy 10y ago
      >the vulnerability was reported and fixed If this was not really a vuln, then they wouldn't have told the researcher it was fixed. OTOH maybe it wasn't exploitable because the backend checks it, but they still considered it a vulnerability and fixed the ability to put a bad email in at all.
      - pfg 10y ago
        Sure, it's a vulnerability in the sense that they didn't want to allow WHOIS-based verification from their web frontend (for whatever reason. Maybe it wasn't even a conscious decision and they just forgot to include it during some rewrite.) It's not a vulnerability in the sense that it's not allowed in their CPS or by CA/B.
nailer 10y ago
Reminds me of Symantec's "we really like CT too, and have spontaneously decided to use it for all our certs" after Google ripped them a new one and demanded they do it: https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html https://security.googleblog.com/2015/10/sustaining-digital-c...

Context: https://news.ycombinator.com/item?id=11330877 https://news.ycombinator.com/item?id=11330877

by ran290 10y ago

Context: https://news.ycombinator.com/item?id=11330877 https://news.ycombinator.com/item?id=11330877

pfg 10y ago

It's worth pointing out that StartCom claims the verification email address in the article in question was only accepted because it matched the WHOIS record of said domain[1], which is permitted according to CA/B Baseline Requirements and their CPS. Definitely not a good choice by the researcher either way. [1]: https://www.startssl.com/NewsDetails?date=20160322 https://www.startssl.com/NewsDetails?date=20160322

cypherpunks01 10y ago
That is real confusing, wouldn't that imply one party is outright lying? Blog claims: In the last step of the validation process is where you can modify the email address and replace it with any regular email address StartSSL claims: The email address used to verify the domain name is listed in the WHOIS records..
- pfg 10y ago
  It could be that, or the researcher really didn't think to try it with an address that's completely unrelated to the domain. Personally, I find it hard to believe that an audited CA has a system where the web frontend can make a decision as to what would be an allowed verification email address. I'm leaning towards believing their story, and would assume they have a backend system which is responsible for checking that input (and which happened to be out of sync with the options offered by the frontend). That's a reasonable explanation for the complete lack of validation in their frontend code. Then again, some CAs have had a terrible track record, so I guess we'll never know for sure now that they fixed the issue (whatever the issue actually was).
  - BillinghamJ 10y ago
    Honestly, while StartSSL's front-end is awful, their practices always seem to far exceed other CAs - especially around verification. I don't enjoy the website, or the verification procedure, but ultimately I generally trust them pretty highly - they operate in a way which shows me they care about security.
    - creshal 10y ago
      We've been generating certificates in direct violation of their TOS for over six years. Every few years they pretend to find out, we do another blatantly non-compliant verification, fork over 120 dollars, and they let us keep printing certificates.
      - BillinghamJ 10y ago
        That's interesting. If you don't mind, what rules are you violating?
        creshal 10y ago
        You're only ever allowed to use your account with the person you validated with. You cannot share an account, e.g. between employees of the same company; if you want to transfer an account to another person over your vacation, you have to create a new account, re-validate, and recreate all certificates on the new account. Obviously, we said f*k that and just registered everything on the CEO's name and have him do the phone verification.
        BillinghamJ 10y ago
        Oh right, yeah. I'm pretty sure every company violates that particular rule :P
        chris_wot 10y ago
        Every company that does this loses all their auditing capabilities on the systems that use these accounts. Not good.
  - ikeboy 10y ago
    >the vulnerability was reported and fixed If this was not really a vuln, then they wouldn't have told the researcher it was fixed. OTOH maybe it wasn't exploitable because the backend checks it, but they still considered it a vulnerability and fixed the ability to put a bad email in at all.
    - pfg 10y ago
      Sure, it's a vulnerability in the sense that they didn't want to allow WHOIS-based verification from their web frontend (for whatever reason. Maybe it wasn't even a conscious decision and they just forgot to include it during some rewrite.) It's not a vulnerability in the sense that it's not allowed in their CPS or by CA/B.

nailer 10y ago

Reminds me of Symantec's "we really like CT too, and have spontaneously decided to use it for all our certs" after Google ripped them a new one and demanded they do it: https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html https://security.googleblog.com/2015/10/sustaining-digital-c...