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

ilab
SMART_READER_LITE
LIVE PREVIEW

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) /


slide-1
SLIDE 1

Lehrstuhl für Netzarchitekturen und Netzdienste

Fakultät für Informatik Technische Universität München

ilab

Lab 8 - SSL/TLS and IPSec

slide-2
SLIDE 2

Internetpraktikum 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

slide-3
SLIDE 3

Internetpraktikum 3

SSL/TLS

slide-4
SLIDE 4

Internetpraktikum 4

TLS - Properties

Used for: Encryption and integrity protection for data sent over a socket

  • Transparent for the application layer protocol
  • E.g.: Protection of HTTP, IMAP  HTTPS, IMAPS

Application flow:

  • 1. Key exchange, e.g. with RSA, Diffie-Hellman
  • 2. optional server and/or client authentication

(server/client certificates and digital signatures used)

  • 3. finally: encryption + authentication for all packets

SSL/TLS uses the reliable transport protocol TCP

  • DTLS is an adaptation that uses the more lightweight protocol UDP

Applikation TLS TCP IP Host to Network TCP/IP-Modell

slide-5
SLIDE 5

Internetpraktikum 5

TLS Architecture

 TLS can be split into two protocol layers:

  • 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

SSL Handshake Protocol SSL Change Cipherspec Protocol SSL Application Data Protocol SSL Alert Protocol SSL Record Protocol TCP Applikation

slide-6
SLIDE 6

Internetpraktikum 6

SSL Record Protocol

 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)

Type

  • Ver. (maj.)
  • Ver. (min.)

Length Length Data 23 15 7 31

slide-7
SLIDE 7

Internetpraktikum 7

SSL Record Protocol

 Is directly built on top of TCP  Processing chain (sending):

  • Fragmentation
  • Parts/records are max 214 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”

slide-8
SLIDE 8

Internetpraktikum 8

SSL Handshake Protocol (RSA, Server auth.)

Overview:

  • 1. random number,

set of cryptographic suites

  • 1. random number,

chosen cryptographic suite, certificate

  • 1. Key exchange (Pre-master secret)
  • Generation of the master-secret
  • 1. MAC on all previous messages
  • 2. MAC on all previous messages
  • Note: 3 and 4 are actually sent together to reduce latency

 the TLS handshake requires two round trips Client Server 1 2 3

Key Generation Key Generation

4 5

slide-9
SLIDE 9

Internetpraktikum 9

ClientHello(Ver,Random, CipherSuite,Compr)

SSL Handshake Protocol (Bsp.: RSA, Server auth)

Client Server

ServerHello(Ver,Random, SessionID,CipherSuite,Compr) ServerCertificate ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished

1 2 3 4 5

slide-10
SLIDE 10

Internetpraktikum 10

ClientHello(Ver,Random, CipherSuite,Compr)

SSL Handshake Protocol

Client Server

ServerHello(Ver,Random, SessionID,CipherSuite,Compr) [ServerCertificate] [CertificateRequest] [ServerKeyExchange] ServerHelloDone [ClientCertificate] ClientKeyExchange [CertificateVerify] ChangeCipherSpec Finished ChangeCipherSpec Finished

[...] denotes optional message

1 2 3 4 5

slide-11
SLIDE 11

Internetpraktikum 11

IPSec

slide-12
SLIDE 12

Internetpraktikum 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 End-to-Site Branch A Branch B

10.3.2.11 10.3.2.34

slide-13
SLIDE 13

Internetpraktikum 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

slide-14
SLIDE 14

Internetpraktikum 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)
slide-15
SLIDE 15

Internetpraktikum 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

 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

IP header AH header protected data authenticated IP header ESP header protected data ESP trailer authenticated encrypted

slide-16
SLIDE 16

Internetpraktikum 16

ESP + AH Combined

 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

IP header ESP header protected data ESP trailer authenticated encrypted AH header

slide-17
SLIDE 17

Internetpraktikum 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):
  • Tunnel mode encapsulates IP packets:

Encapsulation of IP packets allows for a gateway protecting traffic

  • n behalf of other entities (e.g. hosts of a subnetwork, etc.)

IP header IPSec header protected data New IP header IPSec header protected data Old IP header

slide-18
SLIDE 18

Internetpraktikum 18

Example: IPSec-Tunnel between two networks

Site-to-Site Branch A Branch B

10.3.2.11 10.3.2.34

slide-19
SLIDE 19

Internetpraktikum 19

AH-Header

Security Parameter Index (SPI) Sequence Number Authentication Data Payload Length 23 15 7 31 Next Header Reserved IP Header Payload authenticated AH

 AH authenticates all invariant fields of the IP Header  Protocol (IPv4) / Next

Header Feld (IPv6): 51 = AH

Used to identify the currently used SA

slide-20
SLIDE 20

Internetpraktikum 20

ESP-Header

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

Security Parameter Index (SPI) Sequence Number Initialization Vector Protected Data Pad Pad Length Next Header Authentication Data 23 15 7 31 encrypted authenticated Used to identify the currently used SA

slide-21
SLIDE 21

Internetpraktikum 21

Example: IPSec-Tunnel between two networks – Outbound Processing Site-to-Site Branch A Branch B

10.3.2.11 10.3.2.34

slide-22
SLIDE 22

Internetpraktikum 22

Basic Scheme: Processing of Outgoing Packets

IPSec outbound processing Lookup appropriate policy No policy? yes no perform outbound processing according to the order given in the SPD no new incoming packet deliver packet Policy is discard? discard packet yes Lookup SAs No SA? IKE yes no

slide-23
SLIDE 23

Internetpraktikum 23

Example: IPSec-Tunnel between two networks – Inbound Processing Site-to-Site Branch A Branch B

10.3.2.11 10.3.2.34

slide-24
SLIDE 24

Internetpraktikum 24

Basic Scheme: Processing of Incoming Packets

IP Inbound processing (1) All Fragments Available? no Wait for Fragments Does SA for SPI Exist? no Discard Packet yes yes get SPI from the IPSec header perform ESP/AH inbound processing IPSec header found yes no

slide-25
SLIDE 25

Internetpraktikum 25

Security of IPSec

 Currently no working attacks are known  Design got criticized by various persons, e.g. Schneier/Ferguson

  • Some concepts are redundant

 most operational modes are not used/not needed – AH+ESP fits all

  • Highly complexity, mainly due to IKE

 Complex things are prone to errors, i.e. implementation is very difficult

 Currently the best working security mechanism for securing IP

communication (on layer 3)