Short Take – CAA Records and Site Security

In this Short Take, Russ discusses what DNS CAA records are and theorizes how their more pervasive use could nearly mitigate MITM HTTPS interception in the wild.

Russ White

One Comment

  1. Jon S.
    March 1, 2019
    Reply

    Russ, I’m confused by a few things. I’ve noted them as timestamps.

    00:45 – You mention “private key” is exchanged. By that I assume you mean the “secret” symmetric key that is used to secure the TLS session. Since the public/private keypair is such that the private key is never sent. I’m assuming that’s what you mean for the rest of the video.

    0:52 – I assume you mean symmetric key operations are faster than asymmetric key operations.

    1:10 – Hopefully the private key is never exchange server to client, since it has to remain private on the server. I’m assuming you are referring to the “secret” symmetric key used for that session.

    1:57 – Not sure if you are referring to the Subject Alternate Name (SAN) field in the server’s certificate. Which simply lets that certificate (pub/priv keypair) be used to secure multiple addresses (websites).

    2:17 – To modify the SAN the attacker would have to issue a new certificate that the client would trust. I’m assuming in this context the “interception” you are talking about would be a MITM attack wherein the attacker issues a new cert (with the appropriate domains in the SAN) that would come from a Certificate Authority (CA) trusted by the client. This may be a corporate installed CA, or even a compromised commercial CA.

    2:55 – Assuming the attacker issues the rogue certificate, then they haven’t really read the private (read: symmetric) key, they’ve just established two encrypted sessions. Server-to-attacker and attack-to-client. Effectively they are re-encrypting in such a way as the client never knows he’s not talking to the server directly.

    3:10 – I’m following this, if by “authorized sources” you mean “authorized CAs” that are allowed to issue certificates for that server. This means the CA “used” by the attacker would not have been authorized to issue a certificate for that server. Unless of course the actually authorized CA was also compromised, but that’s a different issue.

    3:35 – Couldn’t agree more. The attacker’s job would be much harder.

    I don’t mean to be nitpicky, but I’ve always found PKI to be hard enough even without the complexity of making sure I had the right term.

    Love the short takes!

Leave a Reply

Your email address will not be published. Required fields are marked *