3 ms·

wait how? CA workflows should still work and be able to break this?

by trooop 5y ago

midasuni 5y ago
If you can hijack the traffic you can respond to http challenges from CAs and they will give you a valid certificate. In theory the certificate owner should spot this via CT, but it’s not automatic.
- obert 5y ago
  aren't root CAs installed inside browsers and OSes so that they can't be hijacked without physical access to the target victim device?
  - mindwok 5y ago
    The attack (I think) would work like this: - You own the domain trust.org pointing to IP address 2.3.4.5. - Someone performs a BGP hijack on 2.3.4.5 and now hosts their own server on 2.3.4.5. - They then ask Letsencrypt for a certificate to prove they are trust.org. Letsencrypt provides them a token to host on their website to prove they control it. - Letsencrypt does a DNS lookup, sees trust.org resolves to 2.3.4.5, and performs a http request to that website to check for a token which the hijacker has duly placed on their server at 2.3.4.5. - Letsencrypt issues a certificate for trust.org, which is now valid and controlled by the hijacker. None of this requires access to CAs installed on anyones machine, because Letsencrypt is widely trusted and they are the ones issuing the cert.
  - kadoban 5y ago
    When the CA is giving you, supposedly the owner of someguy.example, a new certificate, how do they verify that you're you first? One common way is they tell you a magic, unique string and you serve it under someguy.example/.well-known/whatever and they connect to you and verify it's there and matches. But if BGP is being hijacked, when they connect to you, they could really be connecting to some scammer. How would they know? So now some scammer has proved they're you and they'll be given a valid cert for someguy.example. The other common verification methods have similar holes.
aaomidi 5y ago
CAs currently run on the assumption that the underlying internet is....somewhat fine. FWIW let's encrypt does multi perspective validation, but it is not a requirement currently. The best thing to do as a site owner is to regularly check CT logs or use a service that does that for you.
- throwaway984393 5y ago
  I'm not sure CT logs would help in practice. Assuming a site owner religiously monitors CT logs (who actually does that?), notices a cert they didn't mean to issue, and then issues a CRL or OCSP change (do most people even know how to do that?), the client application has to download the lists and respect it, and many (most?) clients do not. The site owner may know about the compromised cert, but the users/clients will be blissfully ignorant and unable to do anything about it.
  - aaomidi 5y ago
    There are initiatives to make certificate revocation better. As of now, the world's most popular browser does not support OCSP. So revoking a cert kinda has no impact on chrome. As we go forward, crlite is going to be required by Apple around October of this year. It's probably our current best option for browsers to use. But yeah, you're not wrong. At the very least it would give you an idea that you were targeted and give you an idea that you need to plan for DR.
bawolff 5y ago
CA's verify the person that the domain is pointing to. If the domain is pointing to a malicious server (due to bgp making IP addresses belong to an evil person), then the CA will verify the malicious server instead.

wait how? CA workflows should still work and be able to break this?

by trooop 5y ago

wait how? CA workflows should still work and be able to break this?

If you can hijack the traffic you can respond to http challenges from CAs and they will give you a valid certificate. In theory the certificate owner should spot this via CT, but it’s not automatic.

obert 5y ago
aren't root CAs installed inside browsers and OSes so that they can't be hijacked without physical access to the target victim device?
- mindwok 5y ago
  The attack (I think) would work like this: - You own the domain trust.org pointing to IP address 2.3.4.5. - Someone performs a BGP hijack on 2.3.4.5 and now hosts their own server on 2.3.4.5. - They then ask Letsencrypt for a certificate to prove they are trust.org. Letsencrypt provides them a token to host on their website to prove they control it. - Letsencrypt does a DNS lookup, sees trust.org resolves to 2.3.4.5, and performs a http request to that website to check for a token which the hijacker has duly placed on their server at 2.3.4.5. - Letsencrypt issues a certificate for trust.org, which is now valid and controlled by the hijacker. None of this requires access to CAs installed on anyones machine, because Letsencrypt is widely trusted and they are the ones issuing the cert.
- kadoban 5y ago
  When the CA is giving you, supposedly the owner of someguy.example, a new certificate, how do they verify that you're you first? One common way is they tell you a magic, unique string and you serve it under someguy.example/.well-known/whatever and they connect to you and verify it's there and matches. But if BGP is being hijacked, when they connect to you, they could really be connecting to some scammer. How would they know? So now some scammer has proved they're you and they'll be given a valid cert for someguy.example. The other common verification methods have similar holes.

aaomidi 5y ago

CAs currently run on the assumption that the underlying internet is....somewhat fine. FWIW let's encrypt does multi perspective validation, but it is not a requirement currently. The best thing to do as a site owner is to regularly check CT logs or use a service that does that for you.

throwaway984393 5y ago
I'm not sure CT logs would help in practice. Assuming a site owner religiously monitors CT logs (who actually does that?), notices a cert they didn't mean to issue, and then issues a CRL or OCSP change (do most people even know how to do that?), the client application has to download the lists and respect it, and many (most?) clients do not. The site owner may know about the compromised cert, but the users/clients will be blissfully ignorant and unable to do anything about it.
- aaomidi 5y ago
  There are initiatives to make certificate revocation better. As of now, the world's most popular browser does not support OCSP. So revoking a cert kinda has no impact on chrome. As we go forward, crlite is going to be required by Apple around October of this year. It's probably our current best option for browsers to use. But yeah, you're not wrong. At the very least it would give you an idea that you were targeted and give you an idea that you need to plan for DR.

bawolff 5y ago

CA's verify the person that the domain is pointing to. If the domain is pointing to a malicious server (due to bgp making IP addresses belong to an evil person), then the CA will verify the malicious server instead.