6.824 2005 Lecture 9: SSL Wagner and Schneier's "Analysis of the SSL 3.0 Protocol" What's SSL? https://... Browser is anonymous But you're connecting to a particular web site What is SSL trying to achieve? Privacy What does this mean for the browser? What does this mean for the server? Private from whom? Authenticity Server must prove its identity to the browser Browser is anonymous See l10-handout.txt The basics: Why can't a passive observer decrypt data? Because pre_master is random and encrypted with server's public key, and server private key is secret. How does the client know where a data record came from? Need a provable path back to server certificate. Server proves it owns certificate, client can think about it. How does the server know where a data record came from? Server doesn't know client's "identity" in this mode of operation. What can server deduce about authenticity of data records? Should server even bother checking the data MAC? Perhaps the client included a username/password early in data stream... Replay key exchange. Why can't attacker replay client's entire session? And e.g. order a second identical item from a web catalog? Each side needs to contribute a nonce to master key. Replay encrypted data record from earlier point in the session. Caught by MAC, sequence #. Details? Fake server, providing real server's certificate and public key? Since server's public key and certificate are public. Can't read pre_master_secret... Totally fake server. Provide attacker's certificate as ServerCertificate? Suppose client sends a username/password in the data. And the server verifies them, and they really are correct. Does SSL guarantee to the server that subsequent data is from same source? (This is the integrity that SSL gives the server.) Why does data MAC cover length? Forward secrecy? I.e., record a conversation, then later steal server's private key. SSL 3.0 does not appear to have it. How could we fix this? Could generate a session public/private key pair? Cipher roll-back. Attacker deletes strong algorithms from cipher_suites. Then must modify the MAC in the finished message? But it includes the master_secret! Why allow choice of key lengths? Why allow choice/selection of ciphers? (separate issue...) Is there a "no-cipher" option? Why can't attacker force it? Or a 40-bit option? Or a no-authentication option? Version roll-back? Attacker modifies client_version in ClientHello message. SSL 2.0 did *not* protect cipher_suite list in Finished message. Protected by 8 non-random bytes in padding of SSL 2.0 ClientKeyExchange equivalent message. Only if client supported 3.0 but is using 2.0. Insert my own data if weak export cipher used. Attacker cracks cipher in real time, and finds the key. Then can create its own fake encrypted messages! MAC is always strong. And it includes a large MAC_write_secret. Why doesn't RC4 suffer from an attack if plaintext known? Explain that RC4 xor's random stream with plain text. I.e. xor msg with known plain text, then xor with bogus text? Because that's an authenticity attack! And SSL3 has a separate plan for authenticity. What is it? Each record's MAC includes (implicit) sequence #.