8

Excuse me in advance since I'm new to this. From what I understand, when the client receive the server certificate, client would verify the cert/ cert chain against its trust list. It would follow the chain to verify if any of the intermediate or root is in the trust list.

What would happen if all the intermediates never point to a root but keep looping back to itself?

For example, what would happen if A -> B -> C -> D -> A? How would your normal windows user system handle this if it doesn't have A, B, C, and D in the trust store? Would it timeout? Would it keep running in the background?

Improve this question

2 Answers 2

Reset to default
13

What would happen if all the intermediates never point to a root but keep looping back to itself?

at some point chain validation will fail. This loop will never run infinitely, see explanation below.

For example, what would happen if A -> B -> C -> D -> A? How would your normal windows user system handle this if it doesn't have A, B, C, and D in the trust store?

the chain validation will fail. Microsoft CryptoAPI implements a CertGetCertificateChain function that has explicit loop detection and if any certificate in the chain appears more than once, chain validation function immediately fails with CERT_TRUST_IS_CYCLIC.

In addition, if the chain is too long, there is a total chain building/validation timeout which is 20 seconds by default.

p.s. I disagree with Tatyana Zakharova that cyclic chains are hard to generate. Modern cryptography tools allow you to craft any certificate configurations.

Improve this answer
2
  • Thanks. I had been wonder about this for awhile but couldn't Google information specific enough for this.
    – 8-bit-potato
    Commented Jul 6, 2022 at 16:52
  • You might be able to create a chain A -> B -> C -> D -> A' -> B' -> C' -> D' -> A'' -> ... where A, A', A'' are practically identical, but that would be just a very long chain, not a cyclic chain. Clients should / will limit the length of the chain or the size of a chain in bytes or both.
    – gnasher729
    Commented Jul 7, 2022 at 8:05
2

Cryptographically, this would be quite difficult to set up. After all, in order to generate certificate A, certificate B must already exist. And for B to be generated, C must already exist. For C to be generated, D must already exist, and for D to be generated, A must already exist. Such a "loop" would thus be very difficult to generate.

I wouldn't necessarily say impossible to make, simply because I am not qualified to make such an absolute statement, but I feel confident enough saying it would be very difficult to do so.

As for how any given system would react when encountering such a system...that is difficult to say, since I cannot find a way to produce and thus test it myself. I would assume that the system will throw an error, either recognizing that it has encountered a certificate twice, or via a maximum length limit. For example, the maximum certificate chain length limit in OpenSSL is 10 by default, according to the manual:

The default value for the maximum certificate chain size is 100kB (30kB on the 16-bit DOS platform). This should be sufficient for usual certificate chains (OpenSSL's default maximum chain length is 10, see SSL_CTX_set_verify(3), and certificates without special extensions have a typical size of 1-2kB).

Even if loops would not be recognized specifically, OpenSSL at least would throw an error after 10 iterations, as no root certificate would be found by then. Even if no specific check would be done, the application would keep allocating memory and would eventually crash, due to being unable to allocate more memory. Thus, the case that the application would keep running in the background, forever trying to check the validity of a certificate is not possible.

I hope this helps. Best regards, Tatyana

Improve this answer
4
  • 1
    The question is about Windows which doesn't use OpenSSL.
    – Crypt32
    Commented Jul 6, 2022 at 7:07
  • 14
    Setting it up is far from difficult, it's actually pretty trivial. No special tools are needed, plain command-line openssl will do. The key is that while the signing (private) key of X needs to exist before it can be used to sign the certificate of Y, this doesn't say anything about the existence of the certificate of X at that point. Even if you don't want to delve into more obscure signing options, it's trivial to first issue D as self-signed, create the whole chain, and then re-issue the certificate for D reusing the key pair (public key/CSR) but signing it with A this time.
    – TooTea
    Commented Jul 6, 2022 at 10:14
  • 1
    If the verification process didn't check for cycles, that would be a trivial DoS attack - setup a site with a cyclic certificate, direct a user to the site, and watch their machine breaking done, trying to follow these cycles forever. You can be 100% sure that such a simple DoS attack will not succeed and the cycle will be detected.
    – gnasher729
    Commented Jul 7, 2022 at 7:59
  • 2
    @gnasher729: Creating a circular certificate would require producing a signature that verifies a certain hash value, and then creating a certificate that contains that signature and whose hash value matches the one that is verified by the signature. If the hash function used for certificates would make it possible to deliverately engineer such a certificate, it would be broken in many other ways as well.
    – supercat
    Commented Jul 7, 2022 at 17:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .