CS338 Computer Security
Wednesday, 9 October 2024

+ Exam-prep questions
- What's on your mind?
- What topics worry or puzzle you?
- ...


+ Alice's perspective when using TLS

- Alice wants to talk to the real Bob, encrypted
    [e.g., Alice = my browser; Bob = web server at irs.gov]

- Alice will accept that she is talking to the real Bob if
    - a well-regarded certificate authority CA...
    - ...signs an X.509 certificate that...
    - ...says "bob.com" goes with a specific public key P_B...
    - ...and whoever Alice is talking to demonstrates that they have S_B

- How this goes, very briefly
    - Alice obtains the real Bob's public key P_B
    - Alice connects to MaybeBob
    - Alice asks MaybeBob to prove that he has S_B
        - Checks out? Then Alice accepts that MaybeBob == Bob
    - Alice & Bob do Diffie Hellman to create a shared symmetric key K
        (suitable for whatever symmetric encryption alg they want to use,
         like AES, TwoFish, ChaCha20, TripleDES,...)
    - Everything after that gets encrypted using K

+ More detailed
- Before the story begins
    - There's a certificate authority CA
    - Alice acquires CA's public key P_CA
    - Real Bob (the owner/controller of bob.com) generates a key pair P_B/S_B
    - CA does some kind of due diligence to be convinced that CA is talking to Bob
    - Real Bob gets a certificate signed by CA
        saying that "bob.com" goes with P_B

- When Alice wants to talk to Bob
    - Alice makes a connection to MaybeBob
    - Diffie Hellman to create shared symmetric encryption key K
        Everything after that gets encrypted with K
    - MaybeBob sends or points Alice to an X.509 certificate saying
        "P_MB is bob.com's public key", signed by CA
    - Alice validates the signature to make sure CA really signed it
    - Alice sends MaybeBob a random "challenge string" R
    - MaybeBob, assuming he has S_B, computes Response = E(S_B, H(R))
        and sends it back to Alice
    - Alice computes E(P_B, Response) and H(R) and compares the two.
        If they're equal, Alice believes MaybeBob == Bob and thus P_MB == P_B
    - So from now on, Alice and Bob are safely talking, encrypted using K

+ Compare to RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3

- Chapter 4: Handshake Protocol
    - list of messages in a handshake
    - 4.1.1 Cryptographic Negotiation
        - Great example of how the many, many variations cloud up the exposition (notably PSK stuff here)
        - ...even though the basic idea is simple
        - (EC)DHE
            digression to https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.7
            and https://www.rfc-editor.org/rfc/rfc7919.html#appendix-A.1

- ClientHello message (4.1.1, 4.1.2)
    - scroll down to struct ClientHello
    - note that almost all the text in 4.1.2 before that is about
        HelloRetryRequest or Renegotiation
    - the actual goods
        - **a random number
        - **a list of cipher suites
        - extensions -- especially including a ***"key share"
        - weird legacy crap (read the nutty description of legacy_compression_methods, e.g.)
    - let's look in Wireshark

- ServerHello message (4.1.3)
    - random number
    - **just one cipher suite
    - extensions including a **key share
    - let's look in Wireshark

- Authentication Messages (4.4):
    CertificateRequest (we don't care; this is Bob asking Alice for a certificate)
    Certificate: here's Bob's certificate
    CertificateVerify (4.4.3): "This message is used to provide
        explicit proof that an endpoint possesses the private key corresponding
        to its certificate." Look a little more at 4.4.3, and how wacky it gets.

        But the essential fact: Bob signs a blob that includes the ClientHello,
        which **includes a random number generated by Alice**
    - let's look in Wireshark

+ Step Back
- Imagine implementing a TLS-compliant browser or server!