CMSC 414
Computer and Network Security
Lecture 26
Jonathan Katz
Administrivia
 Final exam reminder + study guide
– DSS students contact me
Network security protocols
in practice
Network layers
 Application
 Transport
 Network
 Data link
 Physical
Roughly…
 Application layer: the communicating processes
themselves and the actual ‘content’ transmitted
 Transport layer (TCP/UDP): “end-to-end”
communication; reliability; flow control
 Network layer (IP): “host-to-host” communication;
routing
 Data link layer (Ethernet/WiFi): transmission of
frames over a single hop
Example security protocols
 Application layer: PGP, SSH
 Transport layer: SSL/TLS
 Network layer: IPsec
 Data link layer: IEEE 802.11 (WEP, WPA)
Security in what layer?
 Depends on the purpose…
– How are keys provisioned/shared?
– Should the (human) user be involved?
– Semantics: authenticate user-to-user, or host-to-host?
Security in what layer?
 Depends on what’s available
– E.g., consider a user connecting to a website from a
café (over a wireless network)
– End-to-end encryption might be unavailable (e.g., if
website does not support encryption)
– Eavesdropping on Internet backbone less likely than
eavesdropping on wireless link in café
– Encrypt link from user to wireless router
– Link-layer encryption more appropriate
• Link-layer authentication also possible
Security in what layer?
 Depends on the threat model/what threats are
being addressed
– What information needs to be protected? (Ports, IP
addresses?)
– E.g., network-layer authentication will not prevent DoS
attacks at link level (e.g., ARP spoofing, replay
disconnect messages, overloading access point)
– E.g., an application-layer protocol cannot protect IP
header information
– End-to-end, or hop-by-hop?
Security in what layer?
 Security interactions with various layers
– E.g., if TCP accepts a packet which is rejected by the
application above it, then TCP will reject the “correct”
packet (detecting a replay) when it arrives!
– E.g., if higher-layer header data is used by a firewall to
make decisions, this is incompatible with network-layer
encryption (if it encrypts headers)
Generally…
 When security is placed at lower levels, it can
provide automatic, “blanket” coverage…
– …but it can take a long time before it is widely adopted
– Can be inefficient to encrypt everything
 When security is placed at higher levels,
individual users can choose when to use it…
– …but users who are not security-conscious may not
take advantage of it
– Can encrypt only what is necessary
Example: PGP vs. SSL vs. IPsec
 PGP is an application-level protocol for “secure
email”
– Can provide security over insecure networks
– Users choose when to use PGP; user must be involved
– Alice’s signature on an email proves that Alice actually
generated the message, and it was received unaltered;
also non-repudiation
• In contrast, SSL secures “the connection” from Alice’s
computer; would need additional mechanisms to authenticate
the user
– Communication with off-line party (i.e., email)
Example: PGP vs. SSL vs. IPsec
 SSL sits at the transport layer, “above” TCP
– Packet stream authenticated/encrypted
– End-to-end security, best for connection-oriented
sessions (e.g., http traffic)
– User does not need to be involved
– The OS does not have to change, but applications do if
they want to communicate securely
Example: PGP vs. SSL vs. IPsec
 IPsec sits at the network layer
– Individual packets authenticated/encrypted
– End-to-end or hop-by-hop security
– Need to modify OS
– All applications “protected” by default, without
requiring any change to applications or actions on
behalf of users
– Only authenticates hosts, not users
– User can be completely unaware that IPsec is running
SSL/TLS
Brief history…
 SSLv2 deployed in Netscape 1.1 (1995)
 Modified version of SSLv3 standardized as TLS
 This overview will not focus on the differences;
I just say “SSL” for convenience
 SSL is a major success story!
– Used extensively and (almost) exclusively to secure
web traffic
Broad overview
 SSL runs on top of TCP
– Advantage: does not require changes to TCP
 From the programmer’s point of view, it sits at the
transport layer
– Same API as for TCP
– Runs only with TCP, not UDP
 Primarily used for HTTP traffic
SSL overview
 Three phases
– Handshake
– Key derivation
– Data transfer
Handshake + key derivation
 Client sends list of supported crypto algorithms
and nonce RC
 Server sends a certificate, selects a crypto
algorithm, and sends nonce RS
– Nonce protects against client impersonation
 Client encrypts random K with server’s public key
 Client/server derive session keys from RC, RS, K
– Prevents replay attacks
 Client sends a MAC of the handshake; server
responds with the same
Sessions and connections
 One session may have multiple simultaneous
connections
 Can derive per-connections keys by exchanging
fresh RC, RS, and using session (master) key K
Data transfer
 Client and server use K to establish four keys:
encryption and authentication, for each direction
 SSL breaks data stream into records; appends a
MAC to each record; and then encrypts the result
– Mac-then-encrypt…
– What would have been a better choice?
 The MAC is computed over the record plus a
sequence number
– Prevents replay, re-ordering, or dropping packets
SSL security
 Provides confidentiality, integrity, and
unidirectional authentication
– Client wants to make sure they are talking to the right
merchant; merchant does not care who client is
 Mutual authentication supported
– If server requests it, and client has a certificate
– Note that mutual authentication may be done at
application level (e.g., password-based login)