4 ms·

> it also wouldn't have been a big deal for them to show something attacker controlled for a little while This is understating the risk. If an attacker obtain

by agwa 5y ago

> it also wouldn't have been a big deal for them to show something attacker controlled for a little while This is understating the risk. If an attacker obtains control over a website for even a brief period of time, they can go to a certificate authority and obtain a domain validation for the domain (including all subdomains) that's valid for one year. At the end of that year, they can use the domain validation to obtain an SSL certificate that's valid for up to one year, even if they no longer control the website. This means that following a brief takeover, the domain continues to be vulnerable to attack for two years, which would be a problem if a parked domain is transitioned to active use during that time.

detaro 5y ago
Nowadays a bit lessened by CT logs, so you (or MM) can at least notice and cause the cert to be revoked.
- agwa 5y ago
  Yes, although the attacker can defer logging the certificate to CT until the moment before the certificate is used in an attack, so you would not have much time to respond.
  - detaro 5y ago
    How? The CA submits records (precertificates) to the logs before it signs the cert.
    - agwa 5y ago
      Precertificates are optional. Alternatively, the CA can skip creating a precertificate. The certificate would not contain any embedded SCTs. Instead, the certificate is logged using the add-chain endpoint[1], and the returned SCTs are delivered via an extension to the TLS handshake or an extension in a stapled OCSP response[2] [1] https://datatracker.ietf.org/doc/html/rfc6962#section-4.1 https://datatracker.ietf.org/doc/html/rfc6962#section-4.1 [2] https://datatracker.ietf.org/doc/html/rfc6962#section-3.3 https://datatracker.ietf.org/doc/html/rfc6962#section-3.3
      - deleted 5y ago
        [deleted]
      - detaro 5y ago
        thanks, I didn't know both steps (pre-cert and actual cert submission into logs) were optional.
    - tialaramex 5y ago
      Logging is not a policy requirement of the trust stores. It's a condition for your certificates to work in some popular browsers (notably Chrome and Safari) but not a policy requirement. This is on purpose. Google themselves for example will get a certificate issued, say, today, for shiny-new-google-product.example and then only at the last moment do they log that certificate when spinning up the web site https://shiny-new-google-product.example/ https://shiny-new-google-product.example/ to launch shiny-new-google-product -- you can't find out about it in the CT logs because it wasn't in there earlier. Now, the readily available and especially free certificates most people use are logged before issuance as you describe using the poisoned "pre-certificate" feature from RFC 6962 (in theory this will one day be replaced by a 6962bis actual pre-certificate document rather than poisoned X.509 certs) but that is not at all mandatory, it's just convenient because it requires no workflow changes. You get a certificate, it's a bit bigger (it has SCTs baked inside it) and it just works. If you do things the hard way, you must ensure your server application software understands what SCTs are and can send them to clients as necessary. You save some bytes talking to clients that don't want the SCTs, and you get to have this just-in-time logging behaviour if you want that. The other reason it isn't against policy to issue without logging is that some archaic systems that are subject the Web PKI rules but aren't actually talking to the public Internet, and especially to web browsers, do not have logging, it's not a thing for them. This will probably go away in the next few years, these systems age out, but they still existed when I last looked.
      - detaro 5y ago
        thanks for the context, that pretty much answered all my follow-up questions. :) The "weird old systems" case sounds like something were maybe it could be required for DV-certs?
        tialaramex 5y ago
        Logging is only valuable if it's enforced. A mandate ("You must log everything") with no enforcement ("... but we won't check") is futile. At the very most maybe it adds one more to what is likely a long list of problems with a CA during a distrust discussion. In effect there is already a requirement on CAs to internally track everything they issue, because there are numerous circumstances where the question, "What was issued with these criteria?" is pertinent and being unable to answer honestly is unacceptable. So, it doesn't make much sense to introduce logging as a policy requirement. I can't say it won't happen but I don't think it's useful. In contrast improvements to client software to actually examine SCTs in more clients and eventually to gossip about what SCTs they've seen are valuable because they improve the practical enforcement of logging. What we see today is that most incidents are logged. A CA will issue something that shouldn't exist, and independent researchers will see that in the logs, but the CA's own tools didn't discover this, not only before logging but often afterwards. Under existing policy the pre-certificate is a misissuance, even if the "real" certificate never existed we can't prove that, so the CA violated policy, but it's a problem that some of them will only realise this after it's reported by somebody else rather than flagging it immediately and self-reporting the violation. So this is reassuring because it matches my assumption that the CA operators are like most of us, they are lazy and incompetent but they aren't malevolent. They can't be bothered to do it properly, they don't remember how to do it properly, but they aren't intentionally doing a bad job, which means that they can improve if given better tools and procedures to avoid trouble.
jstanley 5y ago
> At the end of that year, they can use the domain validation to obtain an SSL certificate that's valid for up to one year, even if they no longer control the website. Can you explain this further? I don't understand. Are you saying they could MITM the request that the CA makes to the website when it tries to do domain valudation? If that's the case, why is it limited to 2 years? Why couldn't they continue to do this indefinitely?
- agwa 5y ago
  No, they don't have to MitM the CA's domain validation request. While they have brief control over the website, they use domain validation method 3.2.2.4.18 (Agreed-Upon Change to Website v2)[1] or 3.2.2.4.19 (Agreed-Upon Change to Website - ACME)[2] to legitimately complete domain validation by making a change to the website. Due to domain validation reuse[3], the certificate doesn't have to be issued right away. The attacker can wait and request the certificate up to 398 days later, without having to do domain validation again. [1] https://github.com/cabforum/servercert/blob/cda0f92ee70121fd5d692685b97ebb6669c74fb7/docs/BR.md#322418-agreed-upon-change-to-website-v2 https://github.com/cabforum/servercert/blob/cda0f92ee70121fd... [2] https://github.com/cabforum/servercert/blob/cda0f92ee70121fd5d692685b97ebb6669c74fb7/docs/BR.md#322419-agreed-upon-change-to-website---acme https://github.com/cabforum/servercert/blob/cda0f92ee70121fd... [3] https://github.com/cabforum/servercert/blob/cda0f92ee70121fd5d692685b97ebb6669c74fb7/docs/BR.md#421-performing-identification-and-authentication-functions https://github.com/cabforum/servercert/blob/cda0f92ee70121fd...

by agwa 5y ago

detaro 5y ago

Nowadays a bit lessened by CT logs, so you (or MM) can at least notice and cause the cert to be revoked.

agwa 5y ago
Yes, although the attacker can defer logging the certificate to CT until the moment before the certificate is used in an attack, so you would not have much time to respond.
- detaro 5y ago
  How? The CA submits records (precertificates) to the logs before it signs the cert.
  - agwa 5y ago
    Precertificates are optional. Alternatively, the CA can skip creating a precertificate. The certificate would not contain any embedded SCTs. Instead, the certificate is logged using the add-chain endpoint[1], and the returned SCTs are delivered via an extension to the TLS handshake or an extension in a stapled OCSP response[2] [1] https://datatracker.ietf.org/doc/html/rfc6962#section-4.1 https://datatracker.ietf.org/doc/html/rfc6962#section-4.1 [2] https://datatracker.ietf.org/doc/html/rfc6962#section-3.3 https://datatracker.ietf.org/doc/html/rfc6962#section-3.3
    - deleted 5y ago
      [deleted]
    - detaro 5y ago
      thanks, I didn't know both steps (pre-cert and actual cert submission into logs) were optional.
  - tialaramex 5y ago
    Logging is not a policy requirement of the trust stores. It's a condition for your certificates to work in some popular browsers (notably Chrome and Safari) but not a policy requirement. This is on purpose. Google themselves for example will get a certificate issued, say, today, for shiny-new-google-product.example and then only at the last moment do they log that certificate when spinning up the web site https://shiny-new-google-product.example/ https://shiny-new-google-product.example/ to launch shiny-new-google-product -- you can't find out about it in the CT logs because it wasn't in there earlier. Now, the readily available and especially free certificates most people use are logged before issuance as you describe using the poisoned "pre-certificate" feature from RFC 6962 (in theory this will one day be replaced by a 6962bis actual pre-certificate document rather than poisoned X.509 certs) but that is not at all mandatory, it's just convenient because it requires no workflow changes. You get a certificate, it's a bit bigger (it has SCTs baked inside it) and it just works. If you do things the hard way, you must ensure your server application software understands what SCTs are and can send them to clients as necessary. You save some bytes talking to clients that don't want the SCTs, and you get to have this just-in-time logging behaviour if you want that. The other reason it isn't against policy to issue without logging is that some archaic systems that are subject the Web PKI rules but aren't actually talking to the public Internet, and especially to web browsers, do not have logging, it's not a thing for them. This will probably go away in the next few years, these systems age out, but they still existed when I last looked.
    - detaro 5y ago
      thanks for the context, that pretty much answered all my follow-up questions. :) The "weird old systems" case sounds like something were maybe it could be required for DV-certs?
      - tialaramex 5y ago
        Logging is only valuable if it's enforced. A mandate ("You must log everything") with no enforcement ("... but we won't check") is futile. At the very most maybe it adds one more to what is likely a long list of problems with a CA during a distrust discussion. In effect there is already a requirement on CAs to internally track everything they issue, because there are numerous circumstances where the question, "What was issued with these criteria?" is pertinent and being unable to answer honestly is unacceptable. So, it doesn't make much sense to introduce logging as a policy requirement. I can't say it won't happen but I don't think it's useful. In contrast improvements to client software to actually examine SCTs in more clients and eventually to gossip about what SCTs they've seen are valuable because they improve the practical enforcement of logging. What we see today is that most incidents are logged. A CA will issue something that shouldn't exist, and independent researchers will see that in the logs, but the CA's own tools didn't discover this, not only before logging but often afterwards. Under existing policy the pre-certificate is a misissuance, even if the "real" certificate never existed we can't prove that, so the CA violated policy, but it's a problem that some of them will only realise this after it's reported by somebody else rather than flagging it immediately and self-reporting the violation. So this is reassuring because it matches my assumption that the CA operators are like most of us, they are lazy and incompetent but they aren't malevolent. They can't be bothered to do it properly, they don't remember how to do it properly, but they aren't intentionally doing a bad job, which means that they can improve if given better tools and procedures to avoid trouble.

jstanley 5y ago

> At the end of that year, they can use the domain validation to obtain an SSL certificate that's valid for up to one year, even if they no longer control the website. Can you explain this further? I don't understand. Are you saying they could MITM the request that the CA makes to the website when it tries to do domain valudation? If that's the case, why is it limited to 2 years? Why couldn't they continue to do this indefinitely?

agwa 5y ago
No, they don't have to MitM the CA's domain validation request. While they have brief control over the website, they use domain validation method 3.2.2.4.18 (Agreed-Upon Change to Website v2)[1] or 3.2.2.4.19 (Agreed-Upon Change to Website - ACME)[2] to legitimately complete domain validation by making a change to the website. Due to domain validation reuse[3], the certificate doesn't have to be issued right away. The attacker can wait and request the certificate up to 398 days later, without having to do domain validation again. [1] https://github.com/cabforum/servercert/blob/cda0f92ee70121fd5d692685b97ebb6669c74fb7/docs/BR.md#322418-agreed-upon-change-to-website-v2 https://github.com/cabforum/servercert/blob/cda0f92ee70121fd... [2] https://github.com/cabforum/servercert/blob/cda0f92ee70121fd5d692685b97ebb6669c74fb7/docs/BR.md#322419-agreed-upon-change-to-website---acme https://github.com/cabforum/servercert/blob/cda0f92ee70121fd... [3] https://github.com/cabforum/servercert/blob/cda0f92ee70121fd5d692685b97ebb6669c74fb7/docs/BR.md#421-performing-identification-and-authentication-functions https://github.com/cabforum/servercert/blob/cda0f92ee70121fd...