SSL/TLS Pehr Söderman Pehrs@kth.se Natsak08/DD2495 1
Historical problems No general purpose security wrapper Kerberos doesn't cut it! Each protocol has it's own security layer SNMP, Ktelnet Or none at all Telnet, ftp, gopher... Good cryptography is hard Broken protocols Is even secure communication practical? 2
Enter the web Explosive growth of the Internet from 1990 and forward Security is critical to continue the growth A general purpose security layer is needed 3
Secure Network Programing Effort to create a security wrapper Place the security on the transport layer Why? Identified the requirements Security infrastructure Simple API Transparency SNP: An Interface for Secure Network Programming (Woo, Bindignavle, Su and Lam) 4
Important parts Strong authentication Session keys Integrity protection Perfect forward secrecy DoS resilience Replay protection Session reuse 5
Strong authentication PKI Obvious answer Drawbacks? Self signed Certificates Other solutions? Mutual authentication? Common algorithms: DH, RSA, DSS 6
Session keys We do not use PK for transport Additional cipher and keys are needed Fast, secure symmetric ciphers Common algorithms. DES, 3DES, RC4, AES 7
Integrity protection We need to protect the integrity of the data Even if it's encrypted. Why? Integrity protection have to be done on everything Note that we can't protect TCP! Common algorithms: MD5, SHA-1 8
Perfect forward secrecy Commonly done with a DH exchange Disconnects the session from the authentication material Protects us against later breaches of the authentication keys. The session is still safe Be very very afraid when somebody wants to take away PFS! 9
DoS resilience Secure services are frequently critical services We need protection against DoS attacks PKI is very expensive Avoid doing PK operations when you can Have the attacker do the PK operations also Save reusable values (for example: g^a for DH) 10
Replay protection Very common problem, but not too hard to do Make sure some kind of unique nonce is used in every connection Make sure the nonce is critical for the exchange (for example by basing the keys on it) 11
Session reuse Critical for good performance in some cases HTTP We need to be able to reuse the authentication Create new session keys and start a new session... 12
SSL/TLS History SSLv1 (Netscape, 1993) Badly broken, never published SSLv2 (Netscape, 1994) Some broken parts Dominant for several years SSLv3 (Netscape, 1996) Modern version of SSL TLS (IETF,, 1999) Adds better cryptography Frequently used 13
SSL protocols Handshake Protocol Chooses Cryptographic parameters ChangeChiperSpecs protocol Switches to a new cipher Application data Protocol Secures and transfers data Alert protocol Signaling of errors 14
Basic protocol (ClientHello) First message from the client. Client cipher suits TLS_DHE_DSS_WITH_DES_CBC_SHA Random number 15
Basic protocol (ServerHello) Cipher suit to be used Random number Certificate (Optional) Certificate request (Optional) ServerKeyExchange (Optional) ServerHelloDone Why is the security material optional? 16
Basic protocol (Client tasks) Check server certificate Send own certificate Generate PMS (Pre-Master Secret) Send PMS (Secured according to cipher suit) Calculate MS (Master Secret) ChangeCipherSpecs Finished message Verify Finished message 17
Basic protocol (Server Tasks) Check client certificate Calculate MS from PMS ChangeCipherSpecs Finished message Verify finished message 18
Session resumption Server tells client session ID during initial exchange Client may present session ID when starting a new session Server implementations may choose not to serve clients that forget their session ID's to prevent DoS attacks 19
Encrypted data stream From this point and forward the data stream is encrypted and authenticated Each data package (which must not be a network package) has integrity protection. TCP is still vulnerable TCP sniping 20
Exportability issues SSL still have export ciphers These are NOT computationally secure Typical 512 bit RSA and 40 bit DES Blame America 21
Important SSLv2 Security issues Lack of integrity protection for the handshake Force a weak cipher suit Truncation Attacks Cut data stream short Down grade attacks From v3/tls 22
How secure is SSLv3/TLS? Very secure actually Still there are a few known issues and attacks... 23
Change cipher spec drop attack Change cipher spec is unprotected MitM drops the CCS message in both directions Send the Finished messages. No protection! Easy if no encryption (just strip the authenticity data) Possible if short encryption keys (crack them before the timeout) Impossible if hard encryption is used Read: Analysis of the SSL 3.0 protocol (Wagner and Schneier) 24
Timing attacks Common RSA vulnerability Several implementations have been vulnerable to timing attacks Make sure to use RSA blinding Read: Remote Timing Attacks are Practical (Brumley and Boneh) 25
Attacks on SSL over Tor Tor is based on onion routing Supposed to make traffic analysis harder Sends data through untrusted hosts Makes it easy to get in the middle Chose a server with a self signed certificate Connect to the server through Tor Check if you got the right certificate Repeat Do you think anybody will sit in the middle? 26
Other SSL issues Are the endpoints secure? Is the one we are talking to trustworthy? Information leaks GET string length 27
Various recent attacks Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS# (Bleichenbacher) Rosa T,: Attacking RSA-based Sessions in SSL/TLS (Klima, Pokorny) Security Flaws Induced by CBC Padding - Applications to SSL, IPSEC, WTLS... (Vaudenay) The vulnerability of ssl to chosen-plaintext attack (Bard) Visual Spoofing of SSL Protected Web Sites and Effective Countermeasures (Adelsbach, Gajek, Schwenk) 28
Deploying SSL Get a real certificate No cheap-certs No self signed Consider server capacity Consider SSL-offloading Clear text data on LAN can be bad Dedicated solutions offers plenty of performance Limit the suits and use SSLv3/TLS only Prevent usage of TLS_RSA_WITH_NULL_MD5 Remember that SSL is not a silver bullet! 29
Lets have a look at SSL 30
On the subject of integrity Personal integrity is a critical part when working in the security field You have to be untouchable You will be working with critical data You will be working with important secrets You will be in the position to bypass security Trust is easier to lose than to build Don't burn your bridges! 31
Common traps Ask first, poke later. Never, ever, assume it's alright to go into a system Make sure you have a written permission Never talk about confidential information Much harder than you think Don't lie, don't worm, don't guess Tell people when you don't know Stick to your principles and gut feelings Give credit were credit is due 32
About Lab 2 Most of the solution was on the net The source of the material was the HoneyNet project The lab explicitly stated that sources should be properly referenced I know the sample solutions well and can easily see when students used information from them How many students do you think used the sample solutions without referencing? 33
Basic research You give credit when you use somebody else's work, even if you replicate it. Giving credit does not diminish the value of your research Giving credit makes it easier for people to confirm the value of your work 34
Integrity Discuss (Any student who wishes to resubmit their Lab 2 may do so until midnight Thursday-Friday. Just mail it to me. I will toss away the first submission) 35