ilab
play

ilab Lab 8 - SSL/TLS and IPSec Outlook: On Layer 4: Goal: Provide - PowerPoint PPT Presentation

Lehrstuhl fr Netzarchitekturen und Netzdienste Fakultt fr Informatik Technische Universitt Mnchen ilab Lab 8 - SSL/TLS and IPSec Outlook: On Layer 4: Goal: Provide security for one specific port SSL (Secure Socket Layer) /


  1. Lehrstuhl für Netzarchitekturen und Netzdienste Fakultät für Informatik Technische Universität München ilab Lab 8 - SSL/TLS and IPSec

  2. Outlook:  On Layer 4:  Goal: Provide security for one specific port  SSL (Secure Socket Layer) / TLS (Transport Layer Security) • ~1990 - 1996 SSL Version 1, 2, 3 developed by Netscape • 1999: TLS 1.0, 2006: TLS 1.1, 2008: TLS 1.2 developed / standardized by IETF  Uses TCP as transport protocol  On Layer 3:  Goal: Provide security for IP traffic  IPSec (IP Security) • ~ 1998  Alternative: OpenVPN  Often used for Virtual Private Networks (VPN) / Tunnel Internetpraktikum 2

  3. SSL/TLS Internetpraktikum 3

  4. TLS - Properties  Used for : Encryption and integrity protection for data sent over a socket TCP/IP-Modell  Transparent for the application layer protocol  E.g.: Protection of HTTP, IMAP  HTTPS, IMAPS Applikation TLS  Application flow : 1. Key exchange , e.g. with RSA, Diffie-Hellman TCP 2. optional server and/or client authentication (server/client certificates and digital signatures used) IP 3. finally: encryption + authentication for all packets Host to Network  SSL/TLS uses the reliable transport protocol TCP  DTLS is an adaptation that uses the more lightweight protocol UDP Internetpraktikum 4

  5. TLS Architecture  TLS can be split into two protocol layers: Applikation SSL Handshake SSL Change SSL Alert SSL Application Protocol Cipherspec Protocol Protocol Data Protocol SSL Record Protocol TCP  Handshake : Authentication of peers and negotiation of security parameters  Change Cipherspec : Signalization of encryption method to be used  Alert : Signalization of errors (e.g. certificate could not be validated)  Application Data : Transparent transport of application payload  All protocols described above communicate via the Record Protocol Internetpraktikum 5

  6. SSL Record Protocol 0 7 15 23 31 Type Ver. (maj.) Ver. (min.) Length Length Data  Type:  Change Cipherspec: 0x14 (20)  Alert: 0x15 (21)  Handshake: 0x16 (22)  Application Data: 0x17 (23)  Version: SSL-Version (major = 3, minor = 3  TLS 1.2)  Length: Length of payload  Data: Payload to transmit (e.g. for Application Data Protocol: encrypted data, MAC, padding) Internetpraktikum 6

  7. SSL Record Protocol  Is directly built on top of TCP  Processing chain (sending):  Fragmentation • Parts/records are max 2 14 Bit long  Compression • optional  Calculation of authentication data • MAC = H(MAC_write_secret + pad_2 + H(MAC_write_secret + pad_1 + seq_num + length + data)) • Remark: the sequence number will not be sent inside the SSL header, as the TCP header contains the sequence number  Encryption of data and MAC • Using the algorithms which were selected and signalized with the current “Change Cipherspec” Internetpraktikum 7

  8. SSL Handshake Protocol (RSA, Server auth.)  Overview: 1. random number, Client Server set of cryptographic suites 1. random number, 1 chosen cryptographic suite, 2 certificate 3 1. Key exchange (Pre-master secret) Key Generation Key Generation  Generation of the master-secret 4 1. MAC on all previous messages 5 2. MAC on all previous messages  Note: 3 and 4 are actually sent together to reduce latency  the TLS handshake requires two round trips Internetpraktikum 8

  9. SSL Handshake Protocol (Bsp.: RSA, Server auth) Client Server ClientHello(Ver,Random, 1 CipherSuite,Compr) ServerHello(Ver,Random, SessionID,CipherSuite,Compr) 2 ServerCertificate ServerHelloDone 3 ClientKeyExchange ChangeCipherSpec Finished 4 ChangeCipherSpec 5 Finished Internetpraktikum 9

  10. SSL Handshake Protocol Client Server ClientHello(Ver,Random, 1 CipherSuite,Compr) ServerHello(Ver,Random, SessionID,CipherSuite,Compr) [ServerCertificate] 2 [CertificateRequest] [ServerKeyExchange] ServerHelloDone [ClientCertificate] 3 ClientKeyExchange [CertificateVerify] ChangeCipherSpec 4 Finished ChangeCipherSpec 5 Finished [...] denotes optional message Internetpraktikum 10

  11. IPSec Internetpraktikum 11

  12. Application of IPSec: Virtual Private Networks 3 typical configurations:  End-to-End (both devices have VPN Software)  Site-to-Site (security gateways apply IPSec to traffic, often used to connect branches of a company)  End-to-Site (road warriors connect to the company) End-to-End Site-to-Site 10.3.2.11 10.3.2.34 Branch A Branch B End-to-Site Internetpraktikum 12

  13. IP Security (IPSec)  Shortcomings of IP:  IP neither protects authenticity of communication entities or data, or protects data integrity , nor provides confidentiality  Services of IPSec:  Authentication of client/server  Data integrity protection  Confidentiality  IPSec defines two packet formats…  AH (RFC 2402)  Authentication  ESP (RFC 2406)  Confidentiality (+ Authentication)  A combination of ESP and AH is possible  … and a key exchange protocol  IKE (Internet Key Exchange) provides a safe key exchange mechanism via an insecure channel Internetpraktikum 13

  14. Terms  Security Policy (SP) / Security Policy Database (SPD)  SP is a rule that specify how to protect a specific communication session • E.g.: protect confidentiality and authenticity of all packets sent between Host a and Host b using encryption mechanism x and authentication mechanism y  Security Policies are quite static and stateless • E.g.: A SP does not contain a session key used for encryption  Security Association (SA) / Security Association Database (SAD)  SAs are the concrete settings that enforce the more abstract policies specified in the SPD  SAs are bindings of IPs, encryption / authentication methods, the currently used key, duration, …  SAs are negotiated by IKE • SAs are quite dynamic and stateful  Each SA is identified by a SPI (Security Parameter Index) Internetpraktikum 14

  15. Authentication Header vs. Encapsulating Security Payload  The authentication header (AH):  Provides data origin authentication and replay protection  Is realized as a header which is inserted between the IP header and the data to be protected protected IP AH data header header authenticated  The encapsulating security payload (ESP):  Provides data origin authentication , confidentiality , replay protection  Is realized with a header and a trailer encapsulating the data to be protected encrypted IP ESP protected ESP header header data trailer authenticated Internetpraktikum 15

  16. ESP + AH Combined encrypted IP AH ESP protected ESP header header header data trailer authenticated  ESP and AH can be combined for maximum security:  Payload is encrypted by ESP  Payload and nearly all header fields of the IP header are authenticated by AH  Uses two SAs  For ESP  For AH Internetpraktikum 16

  17. Transport Mode vs. Tunnel Mode  IPSec works in two modes:  Transport mode can be used between end-points of a communication: • host ↔ host  Tunnel mode can be used between arbitrary peers • security gateway ↔ security gateway • host ↔ security gateway  The difference between the two modes is, that:  Transport mode just adds a security specific header (+ possibly a trailer): IP IPSec protected header header data  Tunnel mode encapsulates IP packets: New IP IPSec Old IP protected header header header data Encapsulation of IP packets allows for a gateway protecting traffic on behalf of other entities (e.g. hosts of a subnetwork, etc.) Internetpraktikum 17

  18. Example: IPSec-Tunnel between two networks Site-to-Site 10.3.2.11 10.3.2.34 Branch A Branch B Internetpraktikum 18

  19. AH-Header  AH authenticates all invariant fields of the IP Header  Protocol (IPv4) / Next 0 7 15 23 31 Header Feld (IPv6): 51 = AH IP Header Next Payload Reserved Header Length Security Parameter Index (SPI) authenticated AH Used to identify the currently used SA Sequence Number Authentication Data Payload Internetpraktikum 19

  20. ESP-Header 0 7 15 23 31 Security Parameter Index (SPI) Used to identify the Sequence Number currently used SA Initialization Vector authenticated encrypted Protected Data Pad Pad Length Next Header Authentication Data  The ESP-Header directly follows the IP header or the AH header  Protocol (IPv4) or Next-Header (IPv6) field: 50 = ESP  The next header field refers to protected data Internetpraktikum 20

  21. Example: IPSec-Tunnel between two networks – Outbound Processing Site-to-Site 10.3.2.11 10.3.2.34 Branch A Branch B Internetpraktikum 21

  22. Basic Scheme: Processing of Outgoing Packets IPSec outbound processing new incoming packet Lookup appropriate policy yes deliver packet No policy? no yes Policy is discard packet discard? no Lookup SAs yes IKE No SA? no perform outbound processing according to the order given in the SPD Internetpraktikum 22

  23. Example: IPSec-Tunnel between two networks – Inbound Processing Site-to-Site 10.3.2.11 10.3.2.34 Branch A Branch B Internetpraktikum 23

  24. Basic Scheme: Processing of Incoming Packets IP Inbound processing (1) Wait for Fragments no All Fragments Available? yes no IPSec header found yes get SPI from the IPSec header no Does SA for Discard Packet SPI Exist? yes perform ESP/AH inbound processing Internetpraktikum 24

Recommend


More recommend