1 / 35

Cryptographic Strength of SSL/TLS Servers: Current and Recent Practices

Cryptographic Strength of SSL/TLS Servers: Current and Recent Practices. Homin K. Lee, Tal Malkin, Erich Nahum Columbia University and IBM Research. Motivation. Many Web services ( e.g. e-commerce, online banking) require secure servers

kareem
Download Presentation

Cryptographic Strength of SSL/TLS Servers: Current and Recent Practices

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Cryptographic Strength of SSL/TLS Servers: Current and Recent Practices Homin K. Lee, Tal Malkin,Erich Nahum Columbia Universityand IBM Research

  2. Motivation • Many Web services (e.g. e-commerce, online banking) require secure servers • Web security is handled by the Secure Socket Layer (SSL) protocol • SSL relies on cryptographic algorithms • A Web service is only truly secure if it uses current best practices in cryptography • A weak SSL configuration may indicate a poorly maintained site What crypto is actually used by SSL servers?

  3. Talk Outline • Motivation • Brief review of SSL • Methodology • Results • Summary and Conclusions • Future Work

  4. https ssl/tls tcp ip ethernet What is SSL/TLS? • SSL/TLS is a network protocol • SSL: Secure Socket Layer • TLS: Transport Layer Security • Provides end-to-end security: • Authentication of server & client • Encryption/integrity of data • History: • Netscape developed versions 1,2 • SSL v3  TLS 1.0 (IETF RFC 2246) • TLS 1.1 RFC out; 1.2 in draft

  5. What Security Does SSL Provide? • Secrecy/Privacy/Confidentiality • Only 2 relevant parties understand messages, prevent eavesdropping • Encrypt using symmetric key ciphers • E.g., RC2, RC4, DES, 3-DES, AES, NULL(!) • Integrity: • Message you get/send is the same one they/you sent, detect tampering • Use one-way hash functions: MD5, SHA-1 • Authentication: • Person you’re speaking with is who they say they are, prevent masquerading • RSA, Digital Signature Standard (DSS) • Key Exchange: • Two parties who have never met mutually agree on a shared secret • RSA, Diffie-Hellman

  6. ClientHello ServerHello Certificate verify certificate generate nonce & choose options generate nonce & ciphers time SSL Option Negotiation client server • Key Part of the SSL/TLS Handshake • Client HELLO message: • Nonce (random + time) • Cipher suites • Server HELLO response: • Nonce • Chosen cipher suite • Server Certificate • Client verifies certificate TLS1-RSA-EDH-AES256-SHA1; TLS1-DSS-EDH-3DES-MD5; SSL3-RSA-RSA-RC4128-MD5; SSL2-RSA-RSA-DES56-MD5; etc. TLS1-RSA-EDH-AES256-SHA1

  7. Talk Outline • Motivation • Brief review of SSL • Methodology • Results • Summary and Conclusions • Future Work

  8. ClientHello ServerHello Certificate verify certificate generate nonce & choose options generate nonce & ciphers time How to Discover Support client server • For each cyphersuite j • Make connection to server • Advertise only one cyphersuite j • Log success of first part of handshake • Terminate connection SSL2-RSA-RSA-DES56-MD5; SSL2-RSA-RSA-DES56-MD5

  9. What is PSST? • PSST: The Probing SSL Scanning Tool • Leverages code from openssl & httperf • Modifications to use algorithm • Uses a list of over 19,000 SSL servers • Culled from TBIT site, Web100, NLANR, etc. • Run algorithm over each server • Takes roughly 3 days • Runs in 11/2006, 6/2006, 08/2005, 02/2005 • Wait for angry phone calls/email But none come!

  10. Talk Outline • Motivation • Brief review of SSL • Methodology • Results • Summary and Conclusions • Future Work

  11. Questions We’re Asking • What versions of SSL/TLS are out there? • What kinds of key exchange and site authentication? • How strong are the public keys? • What types of bulk transfer authentication? • What kinds of symmetric key encryption? • How strong are the symmetric keys? • Do sites choose the best crypto possible? • How has behavior changed over time?

  12. SSL/TLS Protocol Version • SSL 2.0 has many flaws: • Vulnerable to man-in-the-middle attacks • Uses MD5 exclusively • Uses a weak MAC • Uses same key for authentication and encryption

  13. SSL/TLS Protocol Breakdown

  14. Key Exchange & Authentication • EDH, DSS, and RSA give comparable levels of security for equal key sizes.

  15. 512 bits factored in 1999 NIST, RSA, NESSIE: Public key sizes should be at least 1024 bits for the recommended 80-bit level of security. Old export laws used to forbid sizes greater than 512 bits. Public Key Sizes

  16. Hash Functions • MD5 has a family of collisions • Only option for SSL 2.0, but 79 servers use SSL 3.0 or TLS and only support MD5 • SHA-1 is also recently in trouble • SHA-256, SHA-512 are also available

  17. Nearly all servers support DES, RC2, and RC4 Over 50% of the servers support the new AES standard Symmetric Key Encryption

  18. DES DES support Maximum DES strength

  19. RC2 RC2 Support Maximum RC2 Strength

  20. RC4 RC4 Support Maximum RC4 strength

  21. AES AES support

  22. Default Choice of Full Cipher Suite

  23. Really Bad Choices

  24. Changes in SSL Version Support over Time SSL Version Support (Percentage) Situation is improving, but not quickly enough

  25. Changes in Cipher Support over Time Cipher Support (Percentage)

  26. Changes in Public Key Size over Time Key Size Support (Percentage)

  27. Summary and Conclusions • Most servers support reasonable cryptography • 57% support the new AES standard • 95% have strong public keys • Most servers also support weak cryptography • E.g., SSL2, 40-bit & 64 bit RC2/RC4/DES • Clients should not be allowed to use them • e.g., Firefox changing to disable SSL2 • Some servers have serious weaknesses • 5% of servers support breakable public keys • 24 servers only support SSL2 • 8% support only weak RC2 • 87 support only weak RC4 • 225 support only weak DES

  28. Summary and Conclusions (cont) • We see some sites that make bad choices • Choose RC4 or DES over AES • Choose weaker symmetric keys than are supported • Choose SSL2 over SSL3 • We also see some strange birds • A few that do not support RSA • Some bizarre public key sizes (1048,1568,2560) • A few sites that support AES-128 or 256 but not both • Sites with inconsistent choices (behind a L4/L7 switch)

  29. Future Work • Shorter term: • Categorize servers by industry • Categorize server strengths • Check certificates (expired, self-signed, revoked) • Longer Term: • Scan random (or routable) IPs rather than list • Measure SSH server crypto strength • Measure crypto used by clients

  30. Security Is Limited By The Weakest Link

  31. Q&A Thank you!

  32. Backup

  33. Related Work • Murray 2001 Study (USENIX Security 2001) • Tested 8081 servers • Found many more weak SSL sites (using 2001 defs) • Didn’t study choice of cipher, AES, etc. • NetCraft, SecuritySpace • Both sell subscription service testing SSL sites • Look at coarser-grain information (“strong”, “weak”) • SecuritySpace checks self-signed certificates (~9%) • Other Scanning Tools • E.g., IBM’s NSA, NMAP, ssh-scan (Michigan) • Look at different class of vulnerabilities (open ports, SSH version, etc.)

  34. Default Choice of Symmetric Encryption • Most sites choose wisely

  35. Key Strengths • NIST suggests that the 80-bit level will be appropriate until 2015, and the 112- bit level until 2035.

More Related