Understanding SSL vulnerability within Apple's GOTOFAIL

Question

Currently learning and reading about the fascinating SSL Key Exchange and came upon the Apple GOTOFAIL incident back in 2014. I'm going through the code during that time and came across this section.

err = sslRawVerify(ctx,
                ctx->peerPubKey,
                dataToSign,                              /* plaintext */
                dataToSignLen,                   /* plaintext length */
                signature,
                signatureLen)

I am not quite sure which portion of the SSL Key Exchange protocol this belongs to. It seems like it is trying to verify the public key, date signed, and signature, however I don't think I can recall any portion of the SSL protocol with these three components in one transmission.

As this is known to deny the certificates, it would make sense that this portion came across before(or during) the time when server sends the certificate over to the client.

What exactly is 'sslRawVerify' doing?

here is a post with more detailed code.

Thanks!

Answer 1

I am not quite sure which portion of the SSL Key Exchange protocol this belongs to.

The webpage you link to shows this call in a function named SSLVerifySignedServerKeyExchange. Given that ServerKeyExchange is a message in the SSL/TLS handshake that is normally signed (except for "anonymous" suites that don't authenticate the server which are rare), I'll go out on limb and guess that function does the verify logic for a signed ServerKeyExchange in SSL (and TLS). Especially since the full code performs exactly the logic specified in the protocol standards through TLSv1.1 for verifying a ServerKeyExchange (except for the bug).

It seems like it is trying to verify the public key, date signed, and signature, however I don't think I can recall any portion of the SSL protocol with these three components in one transmission.

It is using the public key to (try to) verify the signature on the data signed, which has nothing to do with any date. If you look at the preceding code, dataToSign and dataToSignLen are the address and length of space that at this point contains (or would without the bug) for RSA concatenated MD5 and SHA1 hashes of (apparently) clientRandom serverRandom and signedParams, or for DSA or ECDSA the SHA1 hash. This is exactly the computation specified by TLSv1.1 et pred modified by TLS-ECC. The clientRandom serverRandom and signedParams come from outside this function so we'd have to look elsewhere to be 100% certain they are correct, but it seems very unlikely the programmer(s) would have used exactly the names in the protocol standards for something different.

The server public key is part of its certificate, which was received in the prior server Certificate message. The signature is part of the current ServerKeyExchange message. The actual data to sign is the hash(es), which are computed from the signed params which are in the ServerKeyExchange message and the client random and server random where were in the prior ClientHello and ServerHello messages respectively.

As this is known to deny the certificates, it would make sense that this portion came across before(or during) the time when server sends the certificate over to the client

That's backwards. This bug causes the client to accept the server signature as valid, and thus the server as authentic, even if the signature is forged by an imposter that does not have (and use) the correct private key. Since it uses the public key from the server cert, it must come after the server cert is received (and usually validated) and ServerKeyExchange does come after server Certificate in the handshake sequence.