CMSC 414 Computer and Network Security Lecture 26

1. CMSC 414Computer and Network SecurityLecture 26 Jonathan Katz

2. Administrivia • Final exam reminder + study guide • DSS students contact me

3. Network security protocols in practice

4. Network layers • Application • Transport • Network • Data link • Physical

5. 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

6. Example security protocols • Application layer: PGP, SSH • Transport layer: SSL/TLS • Network layer: IPsec • Data link layer: IEEE 802.11 (WEP, WPA)

7. 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?

8. 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

9. 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?

10. 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)

11. 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

12. 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)

13. 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

14. 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

15. SSL/TLS

16. 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

17. 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

18. SSL overview • Three phases • Handshake • Key derivation • Data transfer

19. 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

20. 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

21. 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

22. 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)