| ▲ | 0x0 3 days 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. |
|
| ▲ | remram 3 days ago | parent | next [-] |
| 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 |
|
| ▲ | tptacek 3 days ago | parent | prev | next [-] |
| 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 3 days ago | parent | next [-] | | 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 3 days ago | parent [-] | | 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 3 days ago | parent [-] | | Someone else on the list might figure out something was fishy when the verification email came through though. |
|
| |
| ▲ | bawolff 3 days ago | parent | prev | next [-] | | > 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 3 days ago | parent | next [-] | | Less clear on that. Bugs happen. I'm not an expert on browser root policies. | | |
| ▲ | thayne 3 days ago | parent [-] | | 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 3 days ago | parent | prev [-] | | Historically, singular domain validation bugs have not killed CAs. |
| |
| ▲ | unit149 3 days ago | parent | prev [-] | | [dead] |
|
|
| ▲ | cperciva 3 days ago | parent | prev | next [-] |
| Or potentially one where you could subscribe to a mailing list. Which includes a lot of very important open source software projects. |
|
| ▲ | mukesh610 3 days ago | parent | prev | next [-] |
| Even then, use of a DNS CAA record should mitigate this, right? |
| |
| ▲ | AdamJacobMuller 3 days ago | parent | next [-] | | Maybe? I wouldn't assume that the bug doesn't bypass CAA checking. Very important question to answer. | |
| ▲ | jsheard 3 days ago | parent | prev [-] | | 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. |
|
|
| ▲ | mcpherrinm 3 days ago | parent | prev [-] |
| 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 3 days ago | parent [-] | | > 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 3 days ago | parent [-] | | I tested before they acknowledged or disabled the method (I was able to use a 3.2.2.4.14 validation the “normal” way) |
|
|
