6 ms·

So I guess you couldn't get certificates for any random (MX) domain, only for those where you can obtain an inbox / user account. Still really bad, especially f

by 0x0 1y ago

So I guess you couldn't get certificates for any random (MX) domain, only for those where you can obtain an inbox / user account. Still really bad, especially for things like gmail.com, but also larger enterprises. Intense.

tptacek 1y ago
It is unlikely that SSL.com would issue a certificate for any major mail host; it would be malpractice for them not to have some kind of exclusion list. Issuing a Google certificate is a good way to get your whole CA killed.
- AdamJacobMuller 1y ago
  Sure, gmail.com might be excluded, but its still a massive hole for a few reasons. This would affect ANY email provider who offers public email addresses. While I agree gmail.com is probably excluded (and maybe this doesn't bypass CAA -- maybe it does) there's a whole additional surface of anyone who has an email at any big enterprise getting a certificate for their domain. Even if I work at google.com, therefore have a google.com email, I should absolutely not be able to get a certificate for google.com just by getting an email at that company. I doubt it's even /that hard/ to buy an email account at a big company like that in the underground world, it seems like they are valuable generally and any company with 200k employees is going to have some leaks. This massively increases the attack surface of a simple leaked email account (which might otherwise have very little or no access). Crazy crazy oversight that has huge implications and is so easy to carry out that I would not be surprised if this was actually exploited by bad actors.
  - londons_explore 1y ago
    plenty of companies have mailing lists which are listname@companydomain.com Getting on those lists is often easy. Same with support ticketing systems, etc.
    - thayne 1y ago
      Someone else on the list might figure out something was fishy when the verification email came through though.
- bawolff 1y ago
  > Issuing a Google certificate is a good way to get your whole CA killed. Surely what happened here is a good way to get your CA killed? The linked bug seems pretty bad.
  - tptacek 1y ago
    Less clear on that. Bugs happen. I'm not an expert on browser root policies.
    - thayne 1y ago
      From what I understand one of the factors is how often things like this happen, and how well they handle it when it does.
  - agwa 1y ago
    Historically, singular domain validation bugs have not killed CAs.
- unit149 1y ago
  [dead]
mukesh610 1y ago
Even then, use of a DNS CAA record should mitigate this, right?
- jsheard 1y ago
  Yeah - unless you're an actual SSL.com customer, in which case your CAA records would allow it. That's a much smaller blast radius at least.
- AdamJacobMuller 1y ago
  Maybe? I wouldn't assume that the bug doesn't bypass CAA checking. Very important question to answer.
cperciva 1y ago
Or potentially one where you could subscribe to a mailing list. Which includes a lot of very important open source software projects.
remram 1y ago
Or any domain for which you can read an email sent to an inbox. I remember a few years ago an attack where the attacker would read email because a ticket would be created for incoming emails, and he could guess the next ticket ID to read it. A lot of platform that aren't email providers still allow emails in (e.g. GitHub, GitLab). This looks like a rather widely-applicable attack. edit: I was thinking about this: https://news.ycombinator.com/item?id=41818459 https://news.ycombinator.com/item?id=41818459
mcpherrinm 1y ago
I couldn’t reproduce the attack with a pair of my own domains, so I think it might be even narrower in scope than the initial post suggests. But I suppose we will just have to wait to see what the CA says.
- thayne 1y ago
  > Out of an abundance of caution, we have disabled domain validation method 3.2.2.4.14 that was used in the bug report for all SSL/TLS certificates while we investigate. I think they have already addressed the bug.
  - mcpherrinm 1y ago
    I tested before they acknowledged or disabled the method (I was able to use a 3.2.2.4.14 validation the “normal” way)

by 0x0 1y ago

tptacek 1y ago

It is unlikely that SSL.com would issue a certificate for any major mail host; it would be malpractice for them not to have some kind of exclusion list. Issuing a Google certificate is a good way to get your whole CA killed.

AdamJacobMuller 1y ago
Sure, gmail.com might be excluded, but its still a massive hole for a few reasons. This would affect ANY email provider who offers public email addresses. While I agree gmail.com is probably excluded (and maybe this doesn't bypass CAA -- maybe it does) there's a whole additional surface of anyone who has an email at any big enterprise getting a certificate for their domain. Even if I work at google.com, therefore have a google.com email, I should absolutely not be able to get a certificate for google.com just by getting an email at that company. I doubt it's even /that hard/ to buy an email account at a big company like that in the underground world, it seems like they are valuable generally and any company with 200k employees is going to have some leaks. This massively increases the attack surface of a simple leaked email account (which might otherwise have very little or no access). Crazy crazy oversight that has huge implications and is so easy to carry out that I would not be surprised if this was actually exploited by bad actors.
- londons_explore 1y ago
  plenty of companies have mailing lists which are listname@companydomain.com Getting on those lists is often easy. Same with support ticketing systems, etc.
  - thayne 1y ago
    Someone else on the list might figure out something was fishy when the verification email came through though.
bawolff 1y ago
> Issuing a Google certificate is a good way to get your whole CA killed. Surely what happened here is a good way to get your CA killed? The linked bug seems pretty bad.
- tptacek 1y ago
  Less clear on that. Bugs happen. I'm not an expert on browser root policies.
  - thayne 1y ago
    From what I understand one of the factors is how often things like this happen, and how well they handle it when it does.
- agwa 1y ago
  Historically, singular domain validation bugs have not killed CAs.
unit149 1y ago
[dead]

mukesh610 1y ago

Even then, use of a DNS CAA record should mitigate this, right?

jsheard 1y ago
Yeah - unless you're an actual SSL.com customer, in which case your CAA records would allow it. That's a much smaller blast radius at least.
AdamJacobMuller 1y ago
Maybe? I wouldn't assume that the bug doesn't bypass CAA checking. Very important question to answer.

cperciva 1y ago

Or potentially one where you could subscribe to a mailing list. Which includes a lot of very important open source software projects.

remram 1y ago

Or any domain for which you can read an email sent to an inbox. I remember a few years ago an attack where the attacker would read email because a ticket would be created for incoming emails, and he could guess the next ticket ID to read it. A lot of platform that aren't email providers still allow emails in (e.g. GitHub, GitLab). This looks like a rather widely-applicable attack. edit: I was thinking about this: https://news.ycombinator.com/item?id=41818459 https://news.ycombinator.com/item?id=41818459

mcpherrinm 1y ago

I couldn’t reproduce the attack with a pair of my own domains, so I think it might be even narrower in scope than the initial post suggests. But I suppose we will just have to wait to see what the CA says.

thayne 1y ago
> Out of an abundance of caution, we have disabled domain validation method 3.2.2.4.14 that was used in the bug report for all SSL/TLS certificates while we investigate. I think they have already addressed the bug.
- mcpherrinm 1y ago
  I tested before they acknowledged or disabled the method (I was able to use a 3.2.2.4.14 validation the “normal” way)