7 ms·

I figured interesting words would probably start to trickle out about HPKP after the last month or so of talks. Opinions are split on how much damage RansomPKP

by eganist 10y ago

I figured interesting words would probably start to trickle out about HPKP after the last month or so of talks. Opinions are split on how much damage RansomPKP and other hostile pinning attacks can do. I'm inclined to believe that it's a big enough risk to warrant some action (such as more diligence by free certificate authorities -- the crux of the talk was rekeying at up to 20x per week enabling the attack). Others, notably Mozilla, are taking the wait-and-see approach. Google and Let's Encrypt were the most resistant to changing anything at all. Anyway, Scott Helme's writeup did a quick and solid job of summarizing a lot of it. It's linked from the Qualys piece, but here it is if you'd rather get to it directly: https://scotthelme.co.uk/using-security-features-to-do-bad-things/ https://scotthelme.co.uk/using-security-features-to-do-bad-t... Full Disclosure: I and buu700 (https://news.ycombinator.com/user?id=buu700 https://news.ycombinator.com/user?id=buu700) did the AppSec Glory talk at Black Hat / DEF CON and developed the RansomPKP attack pattern. Edit for Fuller Disclosure plus added thoughts: I'd rather not see HPKP die because we've done some cool stuff with it over at Cyph. I'd rather see HPKP be refined with extra requirements, possibly some sort of tie-in with CAA (that little-known standard for enforcing which CAs can issue certs for your domain). Speaking of CAA, we did a show of hands in both the BlackHat and DEF CON versions of the AppSec Glory talk. Five hands across thousands of attendees. That's it.

pfg 10y ago
I don't think blocking rapid re-keying on the CA side is going to do much good to prevent this kind of thing. It would help with the pattern described in RansomPKP, but that's not the only option available to attackers. The web server does not need direct access to the (maliciously added) private key - a separate service under the attacker's control that holds the private key and signs stuff for the web server would be sufficient (this is basically what CloudFlare does with Keyless SSL[1]). I see some potential for CAA to help prevent these attacks. Limiting issuance to a small number of CAs would help, especially if those CAs are ones you have a business relationship with and have agreed to some sort of out-of-band confirmation process for all certificate requests (I believe this is fairly common for high-risk domains). There's been some discussion about account key pinning via CAA in the ACME WG. Account keys could be kept separate from the web server (possibly even in a HSM), so this could also help mitigate this problem. That being said, none of that is going to do any good while checking CAA records is optional for CAs, not to mention that just about no one knows it even exists (even in the infosec community, as you have demonstrated). Hopefully we'll see some movement on that front in light of recent mis-issuance reports. [1]: https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/ https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tec...
nathanaldensr 10y ago
Just curious: What did you mean by you "did a show of hands?" Do you mean that's the number of people that had heard of or understood CAA?
- eganist 10y ago
  Literally: 1) raise your hand if you've heard of CSP (more than half the room at both talks) 2) raise your hand if you've heard of HPKP (half at def con. Probably a third at black hat) 3) raise your hand if you've heard of CAA (I gave this one something like 15 seconds for people to think. The number of hands v. attendees was a rounding error.)
  - JoshTriplett 10y ago
    Next time you're testing that, you might also include Certificate Transparency. Mandatory CT seems like it solves the same problems HPKP does, without the risk. Now if we can just finish getting to mandatory CT...
    - pfg 10y ago
      Certificate Transparency (especially if mandatory) guarantees detection after the fact (if we assume the domain owner is properly monitoring known logs). It also adds a certain chilling effect that will probably cause attackers to look for other methods of compromising the target rather than risk sacrificing one of the CAs under the attacker's control (which, arguably, is what intelligence agencies are already doing as many high-profile sites have deployed HPKP). It's not a real-time protection mechanism for targeted attacks and such - the mis-issuance event won't be noticed immediately, and revocation is both slow and, well, broken in general. The existence of HPKP is still a good thing for the Gmail's of this world, but I agree that mandatory CT is probably good enough for 99 out of 100 sites out there.
      - JoshTriplett 10y ago
        I can imagine extensions to CT that would make it better at combating real-time attacks before they can affect anyone. For instance, suppose a new certificate didn't become valid for a certain amount of time after the publication of the corresponding CT log, to give the domain owner (or rather, automated processing working on their behalf) time to shoot it down somehow? You could choose how much of a delay you wanted, trading off between security and potential downtime (if you lose all access to your existing certificates, can't revoke them, and have to issue entirely new ones). If you use any non-automated CA, you should know when renewing your certificates, so you could open up a window to renew; in the absence of that, a fully automated process could notice a new certificate for your domain and automatically shoot it down. If you use an automated CA, you (or the automated process) should similarly know the window of time you will renew in, though in that case someone could learn that and take advantage of that window. On the other hand, given sufficient confidence in the automated CA you could use CAA with it.
Strilanc 10y ago
Server software might be able to help with some of the foot-gunning mentioned in Scott Helme's writeup. For example, web servers that were just configured to do cert pinning for the first time could default to giving a 5-hour grace period where the max-age was clamped below a day, followed by a 2-day grace period where the max-age was clamped below a week. Problems are likely to show up immediately, so starting with a low max-age makes sense. This wouldn't help with malicious scenarios though; attackers would just disable the grace period.
- zrm 10y ago
  You could do that on the client side too though. Have the clients refuse to long-term pin anything until they've seen it multiple times over multiple days.
  - Strilanc 10y ago
    Doing it client-side defeats the purpose of certificate pinning. Three years after you rolled out pinning, new users would still be using max ages that were clamped too low.
agwa 10y ago
> such as more diligence by free certificate authorities -- the crux of the talk was rekeying at up to 20x per week enabling the attack You are wrong if you think this is the crux of the attack. Let's Encrypt is unique in rate limiting issuance to 20 a week. Other CAs will happily give you unlimited reissues once you pay a small amount for the initial cert (e.g. $15), and they have an API for it too!
- eganist 10y ago
  Well aware, but not having to pay for it makes it more widely accessible. Any nation-state attacker or attacker with the will to also compromise an identity or two will have no problems either compromising a CA or swiping an owned credit card respectively, but will either of these actors really go out of their way to ransom a site for up to a five figure sum? The former has no incentive to make money, and the latter makes money through identity theft as-is. For what it's worth, we're aware of rapid rekeying with other CAs because Cyph uses rapid key rotation with DigiCert right now and has since before Let's Encrypt entered open beta.
  - agwa 10y ago
    > Well aware, but not having to pay for it makes it more widely accessible. Any nation-state attacker or attacker with the will to also compromise an identity or two will have no problems either compromising a CA or swiping an owned credit card respectively, but will either of these actors really go out of their way to ransom a site for up to a five figure sum? The former has no incentive to make money, and the latter makes money through identity theft as-is. These CAs have resellers that sell certs anonymously, accepting Bitcoin as payment. If the upside is a five-figure sum, $15 is nothing. > For what it's worth, we're aware of rapid rekeying with other CAs because Cyph uses rapid key rotation with DigiCert right now and has since before Let's Encrypt entered open beta. Odd then that you mentioned Let's Encrypt 5 times in your Chrome security report (and reported this to the Let's Encrypt security team, as if it's their problem), but didn't mention DigiCert once: https://bugs.chromium.org/p/chromium/issues/detail?id=620776 https://bugs.chromium.org/p/chromium/issues/detail?id=620776
jb613 10y ago
> CAA (that little-known standard for enforcing which CAs can issue certs for your domain) I'm sure the CA's absolutely LOVE this - customers are signaling that they will stay with CA 'X'. Given 'vendor lockin' or 'guaranteed recurring revenue', cert prices would drop thru the floor for 1st year only for renewals to increase.
- pfg 10y ago
  CAA is just a DNS record that can be changed at any time, so there's no vendor lock-in. CAs that implement CAA request that record and check whether they're permitted to issue the certificate; if they're not, they should refuse issuance.
  - jb613 10y ago
    1) CAA tries to address the threat of attacker getting a cert issued for your domain - to carry out such an attack inherently requires taking over your DNS record or your domain account - if they can do this then they can also reconfigure your CAA record. 2) CAA requires the CA to perform additional operation (retrieve and check that DNS record) - not all of the 300-600+ CA's will do this - all it takes is 1 CA and the attacker will get his fraudulent cert from that CA.
    - ivanr 10y ago
      For what it's worth, my impression is that CAA will be mandated by the CA/Browser forum at some point. But, indeed, that's the main weakness of CAA—it requires that substantially all CAs support it.
      - jb613 10y ago
        There's too many paying entities to appease - not just hundreds of CA's but various browser vendors as well. Either MUSTs will be changed to SHOULDs - or fragmentation of the CA/Browser body itself. Look no further than at some of the past transgressions browsers let CA's get away with.
    - 10y ago

by eganist 10y ago

pfg 10y ago

I don't think blocking rapid re-keying on the CA side is going to do much good to prevent this kind of thing. It would help with the pattern described in RansomPKP, but that's not the only option available to attackers. The web server does not need direct access to the (maliciously added) private key - a separate service under the attacker's control that holds the private key and signs stuff for the web server would be sufficient (this is basically what CloudFlare does with Keyless SSL[1]). I see some potential for CAA to help prevent these attacks. Limiting issuance to a small number of CAs would help, especially if those CAs are ones you have a business relationship with and have agreed to some sort of out-of-band confirmation process for all certificate requests (I believe this is fairly common for high-risk domains). There's been some discussion about account key pinning via CAA in the ACME WG. Account keys could be kept separate from the web server (possibly even in a HSM), so this could also help mitigate this problem. That being said, none of that is going to do any good while checking CAA records is optional for CAs, not to mention that just about no one knows it even exists (even in the infosec community, as you have demonstrated). Hopefully we'll see some movement on that front in light of recent mis-issuance reports. [1]: https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/ https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tec...

nathanaldensr 10y ago

Just curious: What did you mean by you "did a show of hands?" Do you mean that's the number of people that had heard of or understood CAA?

eganist 10y ago
Literally: 1) raise your hand if you've heard of CSP (more than half the room at both talks) 2) raise your hand if you've heard of HPKP (half at def con. Probably a third at black hat) 3) raise your hand if you've heard of CAA (I gave this one something like 15 seconds for people to think. The number of hands v. attendees was a rounding error.)
- JoshTriplett 10y ago
  Next time you're testing that, you might also include Certificate Transparency. Mandatory CT seems like it solves the same problems HPKP does, without the risk. Now if we can just finish getting to mandatory CT...
  - pfg 10y ago
    Certificate Transparency (especially if mandatory) guarantees detection after the fact (if we assume the domain owner is properly monitoring known logs). It also adds a certain chilling effect that will probably cause attackers to look for other methods of compromising the target rather than risk sacrificing one of the CAs under the attacker's control (which, arguably, is what intelligence agencies are already doing as many high-profile sites have deployed HPKP). It's not a real-time protection mechanism for targeted attacks and such - the mis-issuance event won't be noticed immediately, and revocation is both slow and, well, broken in general. The existence of HPKP is still a good thing for the Gmail's of this world, but I agree that mandatory CT is probably good enough for 99 out of 100 sites out there.
    - JoshTriplett 10y ago
      I can imagine extensions to CT that would make it better at combating real-time attacks before they can affect anyone. For instance, suppose a new certificate didn't become valid for a certain amount of time after the publication of the corresponding CT log, to give the domain owner (or rather, automated processing working on their behalf) time to shoot it down somehow? You could choose how much of a delay you wanted, trading off between security and potential downtime (if you lose all access to your existing certificates, can't revoke them, and have to issue entirely new ones). If you use any non-automated CA, you should know when renewing your certificates, so you could open up a window to renew; in the absence of that, a fully automated process could notice a new certificate for your domain and automatically shoot it down. If you use an automated CA, you (or the automated process) should similarly know the window of time you will renew in, though in that case someone could learn that and take advantage of that window. On the other hand, given sufficient confidence in the automated CA you could use CAA with it.

Strilanc 10y ago

Server software might be able to help with some of the foot-gunning mentioned in Scott Helme's writeup. For example, web servers that were just configured to do cert pinning for the first time could default to giving a 5-hour grace period where the max-age was clamped below a day, followed by a 2-day grace period where the max-age was clamped below a week. Problems are likely to show up immediately, so starting with a low max-age makes sense. This wouldn't help with malicious scenarios though; attackers would just disable the grace period.

zrm 10y ago
You could do that on the client side too though. Have the clients refuse to long-term pin anything until they've seen it multiple times over multiple days.
- Strilanc 10y ago
  Doing it client-side defeats the purpose of certificate pinning. Three years after you rolled out pinning, new users would still be using max ages that were clamped too low.

agwa 10y ago

> such as more diligence by free certificate authorities -- the crux of the talk was rekeying at up to 20x per week enabling the attack You are wrong if you think this is the crux of the attack. Let's Encrypt is unique in rate limiting issuance to 20 a week. Other CAs will happily give you unlimited reissues once you pay a small amount for the initial cert (e.g. $15), and they have an API for it too!

eganist 10y ago
Well aware, but not having to pay for it makes it more widely accessible. Any nation-state attacker or attacker with the will to also compromise an identity or two will have no problems either compromising a CA or swiping an owned credit card respectively, but will either of these actors really go out of their way to ransom a site for up to a five figure sum? The former has no incentive to make money, and the latter makes money through identity theft as-is. For what it's worth, we're aware of rapid rekeying with other CAs because Cyph uses rapid key rotation with DigiCert right now and has since before Let's Encrypt entered open beta.
- agwa 10y ago
  > Well aware, but not having to pay for it makes it more widely accessible. Any nation-state attacker or attacker with the will to also compromise an identity or two will have no problems either compromising a CA or swiping an owned credit card respectively, but will either of these actors really go out of their way to ransom a site for up to a five figure sum? The former has no incentive to make money, and the latter makes money through identity theft as-is. These CAs have resellers that sell certs anonymously, accepting Bitcoin as payment. If the upside is a five-figure sum, $15 is nothing. > For what it's worth, we're aware of rapid rekeying with other CAs because Cyph uses rapid key rotation with DigiCert right now and has since before Let's Encrypt entered open beta. Odd then that you mentioned Let's Encrypt 5 times in your Chrome security report (and reported this to the Let's Encrypt security team, as if it's their problem), but didn't mention DigiCert once: https://bugs.chromium.org/p/chromium/issues/detail?id=620776 https://bugs.chromium.org/p/chromium/issues/detail?id=620776

jb613 10y ago

> CAA (that little-known standard for enforcing which CAs can issue certs for your domain) I'm sure the CA's absolutely LOVE this - customers are signaling that they will stay with CA 'X'. Given 'vendor lockin' or 'guaranteed recurring revenue', cert prices would drop thru the floor for 1st year only for renewals to increase.

pfg 10y ago
CAA is just a DNS record that can be changed at any time, so there's no vendor lock-in. CAs that implement CAA request that record and check whether they're permitted to issue the certificate; if they're not, they should refuse issuance.
- jb613 10y ago
  1) CAA tries to address the threat of attacker getting a cert issued for your domain - to carry out such an attack inherently requires taking over your DNS record or your domain account - if they can do this then they can also reconfigure your CAA record. 2) CAA requires the CA to perform additional operation (retrieve and check that DNS record) - not all of the 300-600+ CA's will do this - all it takes is 1 CA and the attacker will get his fraudulent cert from that CA.
  - ivanr 10y ago
    For what it's worth, my impression is that CAA will be mandated by the CA/Browser forum at some point. But, indeed, that's the main weakness of CAA—it requires that substantially all CAs support it.
    - jb613 10y ago
      There's too many paying entities to appease - not just hundreds of CA's but various browser vendors as well. Either MUSTs will be changed to SHOULDs - or fragmentation of the CA/Browser body itself. Look no further than at some of the past transgressions browsers let CA's get away with.
  - 10y ago