4 ms·

SSL/info sec/whatever noob here. Why can they produce certificates for, say, google.com without the permission of Google? Or am I reading the article wrong?

by mrkgnao 10y ago

pfg 10y ago
Slightly simplified: Each and every CA that's trusted by your browser is capable of issuing a certificate for every single domain on the internet. A certificate is basically nothing more than a document saying "StartSSL has verified that the certificate you're seeing right now belongs to the owner of google.com", with some crypto sprinkled on top. The only thing that's preventing you from getting a certificate for any domain are software checks implemented on their end. If one of these checks fail (i.e. because the methodology is broken, or there's a bug, or they can be bypassed), you can get a certificate for any domain.
geofft 10y ago
The CA determines "permission of Google" by "can put something on a web page at google.com". This is well-accepted, and as long as the CA's own connection to the internets is hard to MITM, it's pretty reasonable for what domain-validated SSL does. (If you want more security than that, try EV, or something other than SSL.) Usually, "a web page at google.com" means to put a specific, CA-picked string at a specific, CA-picked URL. The ACME protocol has you put it under /.well-known/, which is reserved for this sort of thing. Other CAs will give you a randomly-generated filename. The intention is that you shouldn't be able to, say, upload a file to GitHub or some forum and claim control of it; you actually have to operate the site. StartEncrypt neglected to enforce that check. For google.com in particular, when you click "Sign in with Google" to a third-party service, it sends you to a URL on google.com, and google.com will redirect you back to the third-party site when it's done. What the attacker does is they set up their own website and enable Google sign-in on it (which anyone can do without Google's permission). Then they sign in, and save the URL that's redirecting them back, and send that URL to StartEncrypt. StartEncrypt dutifully follows the redirect when fetching content from google.com, and tricks itself into thinking the file was actually at google.com.
antif 10y ago
In short: they are granted that capacity by your browser or operating system. Hundreds of other companies also have the same ability, with new grants and revocations of trust occurring over time.

SSL/info sec/whatever noob here. Why can they produce certificates for, say, google.com without the permission of Google? Or am I reading the article wrong?

by mrkgnao 10y ago

SSL/info sec/whatever noob here. Why can they produce certificates for, say, google.com without the permission of Google? Or am I reading the article wrong?

pfg 10y ago

Slightly simplified: Each and every CA that's trusted by your browser is capable of issuing a certificate for every single domain on the internet. A certificate is basically nothing more than a document saying "StartSSL has verified that the certificate you're seeing right now belongs to the owner of google.com", with some crypto sprinkled on top. The only thing that's preventing you from getting a certificate for any domain are software checks implemented on their end. If one of these checks fail (i.e. because the methodology is broken, or there's a bug, or they can be bypassed), you can get a certificate for any domain.

geofft 10y ago

The CA determines "permission of Google" by "can put something on a web page at google.com". This is well-accepted, and as long as the CA's own connection to the internets is hard to MITM, it's pretty reasonable for what domain-validated SSL does. (If you want more security than that, try EV, or something other than SSL.) Usually, "a web page at google.com" means to put a specific, CA-picked string at a specific, CA-picked URL. The ACME protocol has you put it under /.well-known/, which is reserved for this sort of thing. Other CAs will give you a randomly-generated filename. The intention is that you shouldn't be able to, say, upload a file to GitHub or some forum and claim control of it; you actually have to operate the site. StartEncrypt neglected to enforce that check. For google.com in particular, when you click "Sign in with Google" to a third-party service, it sends you to a URL on google.com, and google.com will redirect you back to the third-party site when it's done. What the attacker does is they set up their own website and enable Google sign-in on it (which anyone can do without Google's permission). Then they sign in, and save the URL that's redirecting them back, and send that URL to StartEncrypt. StartEncrypt dutifully follows the redirect when fetching content from google.com, and tricks itself into thinking the file was actually at google.com.

antif 10y ago

In short: they are granted that capacity by your browser or operating system. Hundreds of other companies also have the same ability, with new grants and revocations of trust occurring over time.