14 ms·

StartCom will log all issued SSL certificates to public CT log servers

74 points by pfg 11y ago

ran290 11y ago
Context: https://news.ycombinator.com/item?id=11330877 https://news.ycombinator.com/item?id=11330877
- pfg 11y 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 11y 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 11y 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 11y 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 11y 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 11y ago
        That's interesting. If you don't mind, what rules are you violating?
        creshal 11y 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 11y ago
        Oh right, yeah. I'm pretty sure every company violates that particular rule :P
        chris_wot 11y ago
        Every company that does this loses all their auditing capabilities on the systems that use these accounts. Not good.
- nailer 11y 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...
BillinghamJ 11y ago
As a Class 4 StartCom subscriber, this is quite irritating. We use StartCom to issue a lot of certificates for sensitive internal hostnames. While we don't rely on security by obscurity, we'd really prefer it if our internal hostnames weren't published all over the internet... :\ Given Lets Encrypt does this too, I'm not sure what other options we have with regards to certificates without paying on a per-certificate basis. :( I like StartCom's model of only paying for verifications (i.e. the only thing which really directly costs money). We definitely want our EV certs going to CT logs, but not any of our wildcard or Class 2/3 certificates.
- DoubleMalt 11y ago
  If they are internal hostnames, don't you control both client and server? Why not create a PKI? In my opinion the only advantage certificates from official CAs bring is that clients you have no control over are not MitMed.
  - BillinghamJ 11y ago
    Well yeah, that is a fair point actually. There would be a couple of issues to sort out, but nothing major or anything we couldn't deal with.
    - creshal 11y ago
      Setting up your own CA is rather easy, for internal hostnames I'd definitely not bother with going to an external CA (nor want an external CA to have control over internal certificates).
      - ryan-c 11y ago
        Having set up and run an internal CA for a > 1000 person org that needed to issue a couple certificates a week, I would refute the "easy" claim.
        creshal 11y ago
tptacek 11y ago
They pretty much have to, right? The alternative is for Google to make the announcement for them.
- pfg 11y ago
  Not sure about that, based on this[1]. The turnaround time for this is a bit too fast for it to be just a reaction to that incident, I think. (Not saying that it's a coincidence either.) [1]: https://www.startssl.com/NewsDetails?date=20160322 https://www.startssl.com/NewsDetails?date=20160322
cat-dev-null 11y ago
SSL CA's are broken in some sense in that it's currently relatively easy to acquire rogue certs because it's a Tragedy of the Commons of the unaddressed issue of a single-source of truth, trust and cert issue authorization for cert management for a given domain. Perhaps all CAs for should be married to internet-facing domains with an encrypted, authoritative, non-repudiable cert discovery protocol... perhaps something like DNSSEC+DANE or something else. Likely the only way to fix the situation is make some nonrepudiable proof-of-domain-ownership mandatory before any CA can issue any cert... although that doesn't solve the other issue of clients figuring out which certs to trust, although there have been some web-of-trust efforts to improve it (un-authoritatively).
- iancarroll 11y ago
  If you believe it is relatively easy to issue a certificate for a domain you do not own, I am sure many people would like to hear about it.
Animats 11y ago
The next step is to have browsers check the CT database for any page that requires a login. Pages you just look at aren't really security-critical; it's user input that matters.
- IgorPartola 11y ago
  Oh sure. Can I have your session key? Not your password, just the thing that lets me reset it, drain your bank account, etc.

74 points by pfg 11y ago

ran290 11y ago

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

pfg 11y 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 11y 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 11y 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 11y 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 11y 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 11y ago
        That's interesting. If you don't mind, what rules are you violating?
        creshal 11y 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 11y ago
        Oh right, yeah. I'm pretty sure every company violates that particular rule :P
        chris_wot 11y ago
        Every company that does this loses all their auditing capabilities on the systems that use these accounts. Not good.
nailer 11y 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...

BillinghamJ 11y ago

As a Class 4 StartCom subscriber, this is quite irritating. We use StartCom to issue a lot of certificates for sensitive internal hostnames. While we don't rely on security by obscurity, we'd really prefer it if our internal hostnames weren't published all over the internet... :\ Given Lets Encrypt does this too, I'm not sure what other options we have with regards to certificates without paying on a per-certificate basis. :( I like StartCom's model of only paying for verifications (i.e. the only thing which really directly costs money). We definitely want our EV certs going to CT logs, but not any of our wildcard or Class 2/3 certificates.

DoubleMalt 11y ago
If they are internal hostnames, don't you control both client and server? Why not create a PKI? In my opinion the only advantage certificates from official CAs bring is that clients you have no control over are not MitMed.
- BillinghamJ 11y ago
  Well yeah, that is a fair point actually. There would be a couple of issues to sort out, but nothing major or anything we couldn't deal with.
  - creshal 11y ago
    Setting up your own CA is rather easy, for internal hostnames I'd definitely not bother with going to an external CA (nor want an external CA to have control over internal certificates).
    - ryan-c 11y ago
      Having set up and run an internal CA for a > 1000 person org that needed to issue a couple certificates a week, I would refute the "easy" claim.
      - creshal 11y ago

tptacek 11y ago

They pretty much have to, right? The alternative is for Google to make the announcement for them.

pfg 11y ago
Not sure about that, based on this[1]. The turnaround time for this is a bit too fast for it to be just a reaction to that incident, I think. (Not saying that it's a coincidence either.) [1]: https://www.startssl.com/NewsDetails?date=20160322 https://www.startssl.com/NewsDetails?date=20160322

cat-dev-null 11y ago

SSL CA's are broken in some sense in that it's currently relatively easy to acquire rogue certs because it's a Tragedy of the Commons of the unaddressed issue of a single-source of truth, trust and cert issue authorization for cert management for a given domain. Perhaps all CAs for should be married to internet-facing domains with an encrypted, authoritative, non-repudiable cert discovery protocol... perhaps something like DNSSEC+DANE or something else. Likely the only way to fix the situation is make some nonrepudiable proof-of-domain-ownership mandatory before any CA can issue any cert... although that doesn't solve the other issue of clients figuring out which certs to trust, although there have been some web-of-trust efforts to improve it (un-authoritatively).

iancarroll 11y ago
If you believe it is relatively easy to issue a certificate for a domain you do not own, I am sure many people would like to hear about it.

Animats 11y ago

The next step is to have browsers check the CT database for any page that requires a login. Pages you just look at aren't really security-critical; it's user input that matters.

IgorPartola 11y ago
Oh sure. Can I have your session key? Not your password, just the thing that lets me reset it, drain your bank account, etc.