Secure Communica-on Protocols Today SSL/TLS Protec-on for web - - PowerPoint PPT Presentation

Secure Communica-on Protocols

Today

• SSL/TLS

– Protec-on for web browsing / transac-ons

• SSH

– Secure shell (remote login)

• IPSec

– IP Security suite, originally for use with IPv6

SSL/TLS

• Secure Sockets Layer / Transport Layer

Security

• History

– Developed by Netscape – 1.0 internal – 2.0 Feb 1995 – 3.0, 1996, fixed many bugs – TLS1.0 – Internet standard, 1999 – TLS1.1 in 2004, TLS1.2 in 2008

SSL usage

• Protect web transac-ons

– HTTPS (lock icon)

• Main mo-va-on: send credit card #’s over the

web

– Aside: bank designed SET protocol was not accepted – Neither was digital cash

SSL modes

• Mutual authen-ca-on

– Both client and server know each other’s public key

• Anonymous client

– Server’s public key is known

• Anonymous server

– No public keys are known – Why use this mode?

SSL Key Distribu-on

• Public keys are enclosed

in a cer-ficate:

– Sign(K_verisign, “the public key for Amazon.com is 0x12345”)

• One of ~40 authori-es

can cer-fy

– Authori-es’ keys are hard‐ coded in browser

• What about user

cer-ficates?

Protocol

ClientHello includes version, cipher suites Cer*ficate ClientKeyExchange include PMK encrypted under server’s key ChangeCipherSpec Finished ServerHello chooses cipher suite Cer*ficate Cer*ficateRequest ServerHelloDone ChangeCipherSpec Finished

Algorithms

• Authen-ca-on

– RSA, DSA, Ellip-c curve DSA

• Encryp-on

– RC4, 3DES, AES, IDEA, DES, Camellia

• HMAC

– HMAC‐MD5 or HMAC‐SHA1

• Key exchanges

– RSA, DH, Ellip-c curve DH, SRP, pre‐shared key

Version Nego-a-on

• Cipher subs-tu-on agack

– Client ‐> “I support AES, 3DES, DES” – Middleman ‐> Server “I support DES” – Server ‐> Client “Let’s use DES”

• Problem in SSLv2. SSLv3 uses a MAC on all of

exchange messages to protect against this

• Cute trick to deal with SSLv2 fallback

– Non‐random data in RSA‐PSS

Timing Agacks

• Mod‐exp algorithm for RSA

cur = M for i in 1..log d if bitisset(d,i) cur = cur * M cur = cur * cur

• Timing depends on which bits set in d
• More on this & other side channel agacks

later

SSH

• Secure Shell
• Secure replacement for insecure rlogin
• Op-mis-c key exchange:

– Each host sends its public key (w/o cer-ficate) in message – First -me talking to host a, record its key – Warn if key changed in between instances

SSH Protocols

• V1: basic protocol (“my first crypto protocol”)

– Many problems

• V2: fixes problems, adds func-onality

– Uses encrypt‐and‐MAC approach – Supports port forwarding, file transfers, …

SSH plaintext recovery

[diagram]

SSH Debian Vulnerability

• A maintainer “helpfully” removed these lines

MD_Update(&m,buf,j); [ .. ] MD_Update(&m,buf,j); /* purify complains */

• As a result, only 32,767 keys would ever be

generated

• 18 months to discover bug!

IPSec

• IP security suite
• Intended for IPv6

– Backported to IPv4 – Now used in most VPN installa-ons

• Two extra headers:

– AH – authen-ca-on header – ESP – encapsulated payload (encryp-on)

• IPSec PKI?

IPSec analysis

• AH and ESP considered separate func-onality
• Many agacks possible if AH is not used

– E.g., CBC cut‐and‐paste

Today

• Three widely used protocols

– SSL/TLS, SSH, IPSec

• Different design choices

– Many historical vulnerabili-es

• Take away points:

– Encryp-on without authen-ca-on “all but useless” [Bellovin 96] – Protocol design is hard, try to avoid it – PKI can be a significant barrier to deployment

Further Reading

• Analysis of the SSL 3.0 protocol David Wagner and Bruce
• Schneier. 2nd USENIX Workshop on Electronic Commerce,

November 1996

– Systema*c analysis of the SSL protocol; finds it mostly good

• Problem Areas for the IP Security Protocols, Steven M.

Bellovin, NDSS 1996

– Most problems due to using encryp*on without authen*ca*on

• Plaintext Recovery ANacks against SSH, Mar-n R. Albrecht,

Kenneth G. Paterson, Gaven J. Watson, IEEE S&P 2009