Network Security

Reading
• Chapter 11
• SSL/TLS: RFC2246
• SSH: RFC4251-4254
• IPsec: RFC4301-4309
Network Security
• The Internet is untrusted
• Have to guard against attacks
 Passive intercepts
 Man in the middle
 Denial of service
Network Security Approaches
• End-to-end
 Treat Internet as big untrusted “cloud”
• Link-level
 Implement protection between each router
• What are some advantages of each?
Network Security Protocols
• SSL/TLS
 Secure sockets layer / Transport layer security
 Used mainly to secure Web traffic
• SSH
 Secure Shell
 Remote login
• IPsec
 IP-level security suite
SSL
• Mid ‘90s introduced concerns over credit card
transactions over the Internet
• SSL designed to respond to thse concerns,
develop e-commerce
• Initially designed by Netscape, moved to
IETF standard later
SSL model
• A client and a server
• Implements a socket interface
 Any socket-based application can be made to run
on top of SSL
• Protect against:
 Eavesdroppers
 MITM attacks
• Server has X.509 certificate
 Client may have a certificate, too
SSL certificates
SSL history
• SSLv2 1994
• SSLv3 1996
 Fixed security problems
• TLS v1.0 1999
• TLS v1.1 2006
SSL key lengths
• Earlier versions used 40-bit keys for export
reasons
• Later versions switched to 128-bit keys, with
an option to use 40-bit ones with legacy
servers/clients
• Rollback attack:
 MITM
SSL sequence
• Negotiate parameters
• Key exchange
• Authentication
• Session
SSL negotiation
• Choice of cipher suites, key exchange
algorithms, protocol versions
• E.g. : choice of 40- or 128-bit keys for export
reasons
• Rollback attack: MITM chooses least secure
parameters
SSL key exchange
• Diffie-Hellman key exchange
• RSA-based key exchange
 Encrypt secret s with public key of server
 (resists attacks described in last class)
Reaction attack
• Send encrypted nonce, see if it is of the right form
 If padding decrypts incorrectly, server sends an error
 Otherwise, SSL protocol continues
• Use algebraic properties of RSA to deduce bits of
key from error
• Fixed with better padding
• Better fix: don’t send error
 Pretend key exchange was OK, continue protocol with
bogus session key
SSL authentication
• Anonymous (no authentication)
• RSA authentication (implicit)
• Sign Diffie-Hellman parameters
 Achieves perfect forward secrecy
Perfect forward secrecy
• Suppose Client sends credit card to Server
over SSL today
• Suppose tomorrow Eve breaks the Server’s
key
 Want credit card to remain secure
• What happens with RSA key exchange?
• What happens with Diffie-Hellman?
SSL session
• Use ChangeCipherSpec message to start
encrypting data
• Encryption: RC4, also DES, 3DES, AES, ...
• Authentication: HMAC, using MD5 or SHA1
SSL pitfalls
• Hard to set up
 Expensive certificates
 Resource-intensive
• Insufficient verification
 Do people notice the lock icon?
 Do people check the URL?
• Improper use
Announcements
• No regular lecture on Tuesday
• 15-minute meeting to:
 Get back HW3
 Hand in HW4 (trade for solution)
 Ask review questions
• At 4PM, lecture in B02 CSL
 "Experiences With Countering Internet Attacks”,
Vern Paxson
Secure Shell
• SSH: secure shell
• Designed in 1995 by Tatu Ylonen
• Replaced in 1996 by SSHv2
 Fixed security holes
 Eventually standardized
• Less popular than SSL
 But completely dominates the market
SSH architecture
• Similar to SSL:
 Clients, servers, socket-like interface
• Difference:
 No certificates
 Remember public key associated with host
• Intuition
 MITM attacks are difficult
 To evade detection, adversary must succeed at MITM every time
Other SSH features
• Flexible authentication architecture
 Password, public key, SecureID, Kerberos, ...
• Perfect forward secrecy
 Permanent host key + temporary key
 Host key signs temporary key
 Key exchange done with temporary key
• Port forwarding
 Used to tunnel traffic on other ports
 Esp. X11 forwarding
IPsec
• Designed as part of IPv6 suite
 One of the key features v6 was supposed to bring
• Backported to IPv4
• Two options: AH (authentication) and ESP (encapsulated
security)
• Two modes: transport and tunnel
Transport vs. Tunnel Mode
• Grand vision: eventually, all IP packets will be encrypted and
authenticated
• Transport mode: add headers to IP to do so
• Reality: Most computers don’t support IPsec (more on why
later)
• Tunnel mode: use IPsec between two gateways to relay IP
packets through “untrusted cloud”
Tunnel Mode

PP
P
P PP

H1
H2
AH - Authentication
• Simple design: add header with authentication data
 Security parameters
 Authentication data (usu. SHA1-HMAC)
AH diagram
AH in Tunnel Mode
ESP - Encapsulated Security Payload
• Encapsulate data
 Encapsulate datagram rather than add a header
 Encrypt & authenticate
ESP diagram
Key management
• ESP and AH use session keys
• Sessions are called Security Associations
 Indexed by protocol, IP address, SPI
• ISAKMP: Internet Security Association Key
Management Protocol
 Authenticates parties
 Establishes session keys
• Authentication
 Big global PKI (DNSSEC??)
 Manual configuration
IPsec redux
• Deployment of IPsec limited
• Some reasons
 Global PKI infrastructure hard to set up
 Wrong layer for security
• Session/Application-layer, rather than Network layer
 Fixes a “solved” problem
• SSL & SSH work well
• IPsec success: VPNs
 Use tunnel mode of Ipsec