StartCom will log all issued SSL certificates to public CT log servers(startssl.com)
startssl.com
StartCom will log all issued SSL certificates to public CT log servers
https://www.startssl.com/NewsDetails?date=20160323
5 comments
Context: https://news.ycombinator.com/item?id=11330877
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
[1]: https://www.startssl.com/NewsDetails?date=20160322
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..
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..
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).
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).
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.
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.
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.
Went through the same headaches for a few years. Their atrociously unfriendly and unintuitive interface finally just pushed me over to using a cheap alternative that is much less painful (RapidSSL in our case).
Until Let's Encrypt came around we've heavily depended on wildcard certificates (several domains with 100+ customer facing subdomains), so any other alternative would have been massively more expensive.
But with LE allowing scripted certificate generation, we're just moving to that instead.
But with LE allowing scripted certificate generation, we're just moving to that instead.
How do you plan to get around LE's 5 subdomains per 7 day period limit? You can only get about 60 subdomains in theory, and that only if you stagger the registrations out carefully over three months and never make any mistakes.
If appropriate for your use case, you can get your domain added to the public suffix list [1]. Then the restrictions no longer apply.
This has side-effects with browsers and cookies so you wouldn't want to do it on a domain without understanding the impact.
[1]: https://github.com/publicsuffix/list/blob/master/public_suff...
P.S. In the unlikely event that someone involved is reading this, PLEASE make this a DNS attribute that is set on the top-level domain instead, in a TXT record perhaps. It's silly that we have to have a globally coordinated and distributed list for this data.
This has side-effects with browsers and cookies so you wouldn't want to do it on a domain without understanding the impact.
[1]: https://github.com/publicsuffix/list/blob/master/public_suff...
P.S. In the unlikely event that someone involved is reading this, PLEASE make this a DNS attribute that is set on the top-level domain instead, in a TXT record perhaps. It's silly that we have to have a globally coordinated and distributed list for this data.
> P.S. In the unlikely event that someone involved is reading this, PLEASE make this a DNS attribute that is set on the top-level domain instead, in a TXT record perhaps. It's silly that we have to have a globally coordinated and distributed list for this data.
The Dbound WG[1] was working on this, but sadly didn't seem to get anywhere.
[1]: https://tools.ietf.org/wg/dbound/
The Dbound WG[1] was working on this, but sadly didn't seem to get anywhere.
[1]: https://tools.ietf.org/wg/dbound/
You can get up to 100 SANs on one certificate, which will only increase your rate limit counter by one.
Works nicely if you have a (mostly) fixed list of subdomains, but becomes hard or impossible to manage if subdomains are dynamic.
Works nicely if you have a (mostly) fixed list of subdomains, but becomes hard or impossible to manage if subdomains are dynamic.
You can get 100 subdomains per certificate, you're only limited to 5 certificates per domain per week.
That's largely sufficient for our use case, but we're still staggering renewal for certificates on our main domains. So far it's no problem because renewal is fully automated and we're leaving buffers.
That's largely sufficient for our use case, but we're still staggering renewal for certificates on our main domains. So far it's no problem because renewal is fully automated and we're leaving buffers.
That's interesting. If you don't mind, what rules are you violating?
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.
Obviously, we said f*k that and just registered everything on the CEO's name and have him do the phone verification.
Oh right, yeah. I'm pretty sure every company violates that particular rule :P
Every company that does this loses all their auditing capabilities on the systems that use these accounts. Not good.
>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.
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.
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.
It's not a vulnerability in the sense that it's not allowed in their CPS or by CA/B.
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-c...
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.
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.
The plan for CT was always to be once extended to all certs. And I think this is right. This whole system has suffered from security failures kept under the rug for too long, more transparency is good.
If you don't want transparency of your certificates don't participate in the public CA system. You still have the option of using wildcards for internal names.
If you don't want transparency of your certificates don't participate in the public CA system. You still have the option of using wildcards for internal names.
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.
In my opinion the only advantage certificates from official CAs bring is that clients you have no control over are not MitMed.
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.
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).
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.
Still easier than StartSSL's horrible, occasionally unreachable, web interface I'd bet.
I hope you don't often place bets. :P
Honestly, it's not that easy. The StartSSL process is much, much, much easier.
There are a myriad of problems you need to solve when running an internal CA for your organization. Who has access to generate new certs? Is it automated, and what security controls are around that system? What audits are there around certs being cut? Who can revoke certificates? Then you get down to the details of CRL/OSCP...
While running your own PKI is great and definitely recommended, it's much easier to say "just set up PKI" than to actually do it and maintain it.
Honestly, it's not that easy. The StartSSL process is much, much, much easier.
There are a myriad of problems you need to solve when running an internal CA for your organization. Who has access to generate new certs? Is it automated, and what security controls are around that system? What audits are there around certs being cut? Who can revoke certificates? Then you get down to the details of CRL/OSCP...
While running your own PKI is great and definitely recommended, it's much easier to say "just set up PKI" than to actually do it and maintain it.
I've always enforced a strict policy of every certificate request be asked for in person by someone with authority to ask us for one, and then a second person actually issues the certs after an hour, just in case. Nobody likes being responsible for data breaches, and I for one am a sadist and a masochist when it comes to keeping control of my systems.
I think the end-game for CT is that all certificates will have to be submitted to log servers, so this is going to happen anyway.
The current CT draft spec permits the CA to generate a precertificate containing "?.example.com" instead of "secretproject.example.com", for exactly this reason:
https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-13#...
https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-13#...
I don't think that was really an option in this case as his CA just went and published the logs without asking the users first?
I'm pretty sure they're not publishing any existing certificates, so that's okay, but they definitely need to treat the fact that they are doing from now on as a "breaking change" and be very clear about it to existing users.
Yeah, I don't know what StartCom is actually doing. All I'm saying is that StartCom has the option of redacting the labels, and as a paying customer, they should be asking StartCom to do so.
RFC6962bis is still a draft and there are no implementations of it yet, so actually they don't have the option to redact labels.
Did all of those internal hostnames need to be accessed over the internet in the first place?
I don't envy you though, that's quite a few subdomains you have there. Although I think that quite a few/almost all of those would have been found anyway if someone were to throw their dictionary at it.
I don't envy you though, that's quite a few subdomains you have there. Although I think that quite a few/almost all of those would have been found anyway if someone were to throw their dictionary at it.
Most of these hostnames are on 10.x IPs, so not internet addressable anyway, but we don't really want to advertise how our internal services are structured.
If they're on private IP addresses, per RFC, they shouldn't be listed in a public DNS zone. If they aren't listed in a public DNS zone, it's not really an issue, is it?
Still a bit of an issue. Primarily the reasoning here is that if you compromise one of our systems, we'd prefer to make it as difficult as possible to traverse across our internal network.
Obviously that is mostly handled by access controls, but every little helps.
Obviously that is mostly handled by access controls, but every little helps.
Which RFC is that? I've never noticed this restriction in any of the DNS RFCs (and I do DNS for a living ;))
(Honestly curious, not trying to say you're wrong !)
(Honestly curious, not trying to say you're wrong !)
RFC1918.
If memory serves, it does say "should not" and not "MUST NOT" (cf. RFC2119). Thus, it's not technically a "violation" to do so but it certainly goes against the recommendations, IMO.
I also "do DNS for a living" (and have been for ~20 years) but I'm sure there's still things that I don't know. This is one of those often overlooked things simply because it isn't that common and one doesn't often see any major issues because of it.
If memory serves, it does say "should not" and not "MUST NOT" (cf. RFC2119). Thus, it's not technically a "violation" to do so but it certainly goes against the recommendations, IMO.
I also "do DNS for a living" (and have been for ~20 years) but I'm sure there's still things that I don't know. This is one of those often overlooked things simply because it isn't that common and one doesn't often see any major issues because of it.
So it does, I've never noticed this section before:
Indirect references to such addresses should be contained within the
enterprise. Prominent examples of such references are DNS Resource
Records and other information referring to internal private
addresses. In particular, Internet service providers should take
measures to prevent such leakage.I'm not aware of any RFCs on the matter either. Some DNS servers do this to protect against DNS rebinding attacks, though.
Ah, the use of public ca implied a more general use scenario in my head.
As someone else mentioned, creating a PKI is probably the way to go at this point.
And I suppose double check that none of them are binding interfaces they're not supposed to, if any of those have interfaces with public IPs.
As someone else mentioned, creating a PKI is probably the way to go at this point.
And I suppose double check that none of them are binding interfaces they're not supposed to, if any of those have interfaces with public IPs.
Yeah, agreed. We had used it so far simply because it was convenient. I do still think it's important for StartSSL to be very clear about this to their existing customers though - it's a breaking change of sorts.
And they are definitely not, but thanks. :) They're in an AWS VPC which is only internet addressable via explicitly defined servers. The default is to not provide a public IP.
And they are definitely not, but thanks. :) They're in an AWS VPC which is only internet addressable via explicitly defined servers. The default is to not provide a public IP.
not any of our wildcard
Not really true. Wildcard certs only work for one level of labels. As such, we still have to include quite a large proportion of a set of our internal hostnames in the cert
[deleted]
They pretty much have to, right? The alternative is for Google to make the announcement for them.
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
[1]: https://www.startssl.com/NewsDetails?date=20160322
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).
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).
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.
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.
Oh sure. Can I have your session key? Not your password, just the thing that lets me reset it, drain your bank account, etc.