CMSC 414 Computer and Network Security Lecture 26 Jonathan Katz.

CMSC 414Computer 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)