Secure Sockets Layer (SSL) : INFS 766 Internet Security Protocols

SECURE SOCKETS LAYER
INFS 766 (SSL)

Internet Security Protocols
layered on top of TCP
Lecture 5 SSL versions 1.0, 2.0, 3.0, 3.1
SSL Netscape protocol
later refitted as IETF standard TLS
(Transport Layer Security)
Prof. Ravi Sandhu TLS 1.0 very close to SSL 3.1
© Ravi Sandhu 2000-2004 2
SECURE SOCKETS LAYER

(SSL) SSL ARCHITECTURE
application protocol independent

does not specify how application SSL SSL Change SSL Other
Handshake Cipher Spec Alert HTTP Application
protocols add security with SSL Protocol Protocol Protocol Protocols
¾ how to initiate SSL handshaking
¾ how to interpret certificates SSL Record Protocol
left to designers of upper layer TCP
protocols to figure out IP
© Ravi Sandhu 2000-2004 3 © Ravi Sandhu 2000-2004 4
SSL ARCHITECTURE SSL/TLS DIFFERENCES

Handshake protocol: complicated
TLS uses HMAC, SSL uses a precursor
¾ embodies key exchange & authentication
¾ 10 message types TLS MAC covers compression version
Record protocol: straightforward field in addition to what SSL MAC covers
¾ fragment, compress, MAC, encrypt
TLS defines additional alert codes
Change Cipher Spec protocol: straightforward
¾ single 1 byte message with value 1 other minor differences
¾ could be considered part of handshake protocol
TLS has a mode to fall back to SSL
Alert protocol: straightforward
¾ 2 byte messages
• 1 byte alert level- fatal or warning; 1 byte alert code

SSL SESSIONS AND
SSL SERVICES CONNECTIONS
peer entity authentication Every connection is associated with
data confidentiality one session
data authentication and integrity Session can be reused across
multiple secure connections
compression/decompression
Handshake protocol
generation/distribution of session keys
¾ establishes new session and connection
¾ integrated into protocol together
security parameter negotiation ¾ uses existing session for new connection
SSL SESSION SSL CONNECTION STATE

SSL session negotiated by handshake protocol connection end: client or server
¾ session ID client and server random: 32 bytes each
• chosen by server
¾ X.509 public-key certificate of peer
keys generated from master secret, client/server random
• possibly null ¾ client_write_MAC_secret server_write_MAC_secret
¾ compression algorithm ¾ client_write_key server_write_key
¾ cipher spec ¾ client_write_IV server_write_IV
• encryption algorithm compression state
• message digest algorithm
¾ master secret
cipher state: initially IV, subsequently next feedback block
• 48 byte shared secret sequence number: starts at 0, max 264-1
¾ is resumable flag
• can be used to initiate new connections
SSL CONNECTION STATE SSL RECORD PROTOCOL
4 parts to state 4 steps by sender (reversed by receiver)

¾ current read state ¾ Fragmentation
¾ current write state ¾ Compression
¾ pending read state
¾ MAC
¾ pending write state
¾ Encryption
handshake protocol
¾ initially current state is empty
¾ either pending state can be made current and
reinitialized to empty

SSL HANDSHAKE
SSL RECORD PROTOCOL PROTOCOL
each SSL record contains initially
SSL session has null
¾ content type: 8 bits, only 4 defined
compression and cipher algorithms
• change_cipher_spec
• alert both are set by the handshake
handshake
•
protocol at beginning of session
• application_data
¾ protocol version number: 8 bits major, 8 bits minor handshake protocol may be repeated
¾ length: max 16K bytes (actually 214+2048) during the session
¾ data payload: optionally compressed and encrypted
¾ message authentication code (MAC)
SSL HANDSHAKE SSL HANDSHAKE

PROTOCOL PROTOCOL
Client Server
Type: 1 byte ClientHello -------->

ServerHello
Certificate*
¾ 10 message types defined ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
length: 3 bytes Certificate*
ClientKeyExchange
CertificateVerify*
content [ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Fig. 1 - Message flow for a full handshake
* Indicates optional or situation-dependent messages that are not

always sent.

PROTOCOL PROTOCOL
Client Server
Phase 1
ClientHello --------> Phase 1:
ServerHello
Certificate*
ServerKeyExchange* ¾ Establish security capabilities
Phase 2 CertificateRequest*
Certificate*
<-------- ServerHelloDone Phase 2:
Phase 3 ClientKeyExchange
CertificateVerify* ¾ Server authentication and key exchange
[ChangeCipherSpec]
Phase 4
Finished -------->
[ChangeCipherSpec] Phase 3:
<-------- Finished
Application Data <-------> Application Data ¾ Client authentication and key exchange
Record
Protocol
Phase 4:
always sent. ¾ Finish

SSL 1-WAY HANDSHAKE SSL 2-WAY HANDSHAKE
WITH RSA WITH RSA
Client Server Client Server
Phase 1 Phase 1
ClientHello --------> ClientHello -------->
ServerHello ServerHello
Certificate* Certificate*
ServerKeyExchange* ServerKeyExchange*
Phase 2 CertificateRequest* Phase 2 CertificateRequest*
<-------- ServerHelloDone <-------- ServerHelloDone
Certificate* Certificate*
Phase 3 ClientKeyExchange Phase 3 ClientKeyExchange
CertificateVerify* CertificateVerify*
[ChangeCipherSpec] [ChangeCipherSpec]
Finished --------> Finished -------->
Phase 4 [ChangeCipherSpec] Phase 4 [ChangeCipherSpec]
<-------- Finished <-------- Finished
Application Data <-------> Application Data Application Data <-------> Application Data
Record Fig. 1 - Message flow for a full handshake Record Fig. 1 - Message flow for a full handshake
Protocol Protocol
* Indicates optional or situation-dependent messages that are not * Indicates optional or situation-dependent messages that are not
always sent. always sent.

PROTOCOL PROTOCOL
these 9 handshake messages must occur Client Server
in order shown ClientHello -------->

ServerHello
optional messages can be eliminated [ChangeCipherSpec]
<-------- Finished
10th message explained later [ChangeCipherSpec]
Finished -------->
¾ hello_request message Application Data <-------> Application Data
change_cipher_spec is a separate 1 Fig. 2 - Message flow for an abbreviated handshake
message protocol
¾ functionally it is just like a message in the
handshake protocol

PROTOCOL PROTOCOL
Client Server
Phase 1
hello_request (not shown) can be sent ClientHello -------->
ServerHello
anytime from server to client to request Certificate*
ServerKeyExchange*
Phase 2
client to start handshake protocol to <--------
CertificateRequest*
ServerHelloDone
renegotiate session when convenient Phase 3
Certificate*
ClientKeyExchange
CertificateVerify*
can be ignored by client [ChangeCipherSpec]
Finished -------->
Phase 4 [ChangeCipherSpec]
¾ if already negotiating a session <-------- Finished
¾ don’t want to renegotiate a session Record Fig. 1 - Message flow for a full handshake
• client may respond with a no_renegotiation alert Protocol
always sent.

SSL HANDSHAKE: PHASE 1 SSL HANDSHAKE: PHASE 1
ESTABLISH SECURITY CAPABILITIES ESTABLISH SECURITY CAPABILITIES
client hello server hello

¾ 4 byte timestamp, 28 byte random value ¾ 32 byte random value
¾ session ID: ¾ session ID:
• non-zero for new connection on existing session • new or reuse
•zero for new connection on new session ¾ version
¾ client version: highest version • lower of client suggested and highest supported
¾ cipher_suite list: ordered list ¾ cipher_suite list: single choice
¾ compression list: ordered list ¾ compression list: single choice

ESTABLISH SECURITY CAPABILITIES ESTABLISH SECURITY CAPABILITIES
cipher suite cipher suite

¾ key exchange method ¾ cipher spec
• RSA: requires receiver’s public-key certificates • CipherAlgorithm: RC4, RC2, DES, 3DES, DES40,
• Fixed DH: requires both sides to have public-key IDEA, Fortezza
certificates
• MACAlgorithm: MD5 or SHA-1
• Ephemeral DH: signed ephemeral keys are
exchanged, need signature keys and public-key • CipherType: stream or block
certificates on both sides • IsExportable: true or false
• Anonymous DH: no authentication of DH keys, • HashSize: 0, 16 or 20 bytes
susceptible to man-in-the-middle attack
• Key Material: used to generate write keys
• Fortezza: Fortezza key exchange
• IV Size: size of IV for CBC
we will ignore Fortezza from here on
SSL HANDSHAKE
SSL HANDSHAKE: PHASE 2
PROTOCOL SERVER AUTHENTICATION & KEY EXCHANGE
Client Server
Phase 1
ClientHello --------> Certificate message
ServerHello
Certificate* ¾ server’s X.509v3 certificate followed by optional chain of
ServerKeyExchange* certificates
<-------- ServerHelloDone ¾ required for RSA, Fixed DH, Ephemeral DH but not for
Certificate*
Phase 3 ClientKeyExchange Anonymous DH
CertificateVerify*
[ChangeCipherSpec] Server Key Exchange message
Finished -------->
Phase 4 [ChangeCipherSpec] ¾ not needed for RSA, Fixed DH
<-------- Finished
Application Data <-------> Application Data ¾ needed for Anonymous DH, Ephemeral DH
Record Fig. 1 - Message flow for a full handshake ¾ needed for RSA where server has signature-only key
Protocol • server sends temporary RSA public encryption key to client
always sent.

SSL HANDSHAKE
SSL HANDSHAKE: PHASE 2
SERVER AUTHENTICATION & KEY EXCHANGE PROTOCOL
Client Server
Server Key Exchange message Phase 1
ClientHello -------->
ServerHello
¾ signed by the server Certificate*
¾ signature is on hash of Phase 2 ServerKeyExchange*
CertificateRequest*
• ClientHello.random, ServerHello.random <-------- ServerHelloDone
• Server Key Exchange parameters Certificate*
Phase 3 ClientKeyExchange
Certificate Request message CertificateVerify*
[ChangeCipherSpec]
¾ request a certificate from client Finished -------->
Phase 4 [ChangeCipherSpec]
¾ specifies Certificate Type and Certificate Authorities <-------- Finished
• certificate type specifies public-key algorithm and use
Record
Server Done message Protocol
¾ ends phase 2, always required * Indicates optional or situation-dependent messages that are not
always sent.

CLIENT AUTHENTICATION & KEY EXCHANGE CLIENT AUTHENTICATION & KEY EXCHANGE
Certificate message Client Key Exchange message

¾ send if server has requested certificate and client has
appropriate certificate ¾ RSA
• otherwise send no_certificate alert
•client generates 48-byte pre-master secret, encrypts
Client Key Exchange message with server’s RSA public key (from server certificate
¾ content depends on type of key exchange (see next slide) or temporary key from Server Key Exchange
Certificate Verify message message)
¾ can be optionally sent following a client certificate with signing
capability
¾ Ephemeral or Anonymous DH
¾ signs hash of master secret (established by key exchange) and • client’s public DH value
all handshake messages so far
¾ Fixed DH
¾ provides evidence of possessing private key corresponding to
certificate • null, public key previously sent in Certificate Message
SSL HANDSHAKE: POST PHASE 3 SSL HANDSHAKE: POST PHASE 3

CRYPTOGRAPHIC COMPUTATION CRYPTOGRAPHIC COMPUTATION
48 byte pre master secret

master_secret = PRF(pre_master_secret, "master secret",
¾ RSA ClientHello.random + ServerHello.random)
[0..47];
• generated by client
pre_master_secret: 48 bytes
• sent encrypted to server
¾ DH
• both sides compute the same value
PRF is composed of a sequence and nesting of HMACs
• each side uses its own private value and the
other sides public value

SSL HANDSHAKE SSL HANDSHAKE: PHASE 4
PROTOCOL FINISH
Client Server
Phase 1
ClientHello -------->
ServerHello
Change Cipher Spec message
Certificate*
ServerKeyExchange* ¾ not considered part of handshake
<-------- ServerHelloDone protocol but in some sense is part of it
Certificate*
Phase 3
Finished message
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Phase 4
Finished -------->
[ChangeCipherSpec] ¾ sentunder new algorithms and keys
<-------- Finished
Application Data <-------> Application Data ¾ content is hash of all previous messages
Record
Protocol
and master secret
always sent.

FINISH FINISH
Change Cipher Spec message Finished message

verify_data
¾ 1 byte message protected by current state PRF(master_secret, finished_label, MD5(handshake_messages)+
¾ copies pending state to current state SHA-1(handshake_messages)) [0..11];
• sender copies write pending state to write current finished_label

state For Finished messages sent by the client, the string "client
finished". For Finished messages sent by the server, the
• receiver copies read pending state to read current string "server finished".
state
handshake_messages
¾ immediately send finished message under new All of the data from all handshake messages up to but not
current state including this message. This is only data visible at the
handshake layer and does not include record layer headers.
SSL ALERT PROTOCOL SSL ALERT MESSAGES

Warning or fatal
close_notify(0),
2 byte alert messages unexpected_message(10),
bad_record_mac(20),
¾ 1 byte level
decryption_failed(21),
record_overflow(22),
decompression_failure(30),
• fatal or warning handshake_failure(40),
bad_certificate(42),
¾1 byte unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
• alert code certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
SSL ALERT MESSAGES APPLICATIONS AND SSL
always fatal use dedicated port numbers for

¾ unexpected_message every application that uses SSL
¾ bad_record_mac ¾ de facto what is happening
¾ decompression_failure use normal application port and
¾ handshake_failure
negotiate security options as part of
application protocol
¾ illegal_parameter
negotiate use of SSL during normal
TCP/IP connection establishment
APPLICATION PORTS
OFFICIAL AND UNOFFICIAL
https 443 ftp-data 889

ssmtp 465 ftps 990
snntp 563 imaps 991
sldap 636 telnets 992
spop3 995 ircs 993
© Ravi Sandhu 2000-2004 45

Secure Sockets Layer (SSL) : INFS 766 Internet Security Protocols

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Secure Sockets Layer (SSL) : INFS 766 Internet Security Protocols

Încărcat de

Drepturi de autor:

Formate disponibile

SECURE SOCKETS LAYER

INFS 766 (SSL)

© Ravi Sandhu 2000-2004 2

SECURE SOCKETS LAYER

 application protocol independent

© Ravi Sandhu 2000-2004 3 © Ravi Sandhu 2000-2004 4

SSL ARCHITECTURE SSL/TLS DIFFERENCES

© Ravi Sandhu 2000-2004 5 © Ravi Sandhu 2000-2004 6

© Ravi Sandhu 2000-2004 7 © Ravi Sandhu 2000-2004 8

SSL SESSION SSL CONNECTION STATE

© Ravi Sandhu 2000-2004 9 © Ravi Sandhu 2000-2004 10

SSL CONNECTION STATE SSL RECORD PROTOCOL

 4 parts to state 4 steps by sender (reversed by receiver)

© Ravi Sandhu 2000-2004 11 © Ravi Sandhu 2000-2004 12

© Ravi Sandhu 2000-2004 13 © Ravi Sandhu 2000-2004 14

SSL HANDSHAKE SSL HANDSHAKE

 Type: 1 byte ClientHello -------->

Fig. 1 - Message flow for a full handshake

* Indicates optional or situation-dependent messages that are not

© Ravi Sandhu 2000-2004 15 © Ravi Sandhu 2000-2004 16

SSL HANDSHAKE SSL HANDSHAKE

© Ravi Sandhu 2000-2004 17 © Ravi Sandhu 2000-2004 18

© Ravi Sandhu 2000-2004 19 © Ravi Sandhu 2000-2004 20

SSL HANDSHAKE SSL HANDSHAKE

 these 9 handshake messages must occur Client Server

in order shown ClientHello -------->

© Ravi Sandhu 2000-2004 21 © Ravi Sandhu 2000-2004 22

SSL HANDSHAKE SSL HANDSHAKE

© Ravi Sandhu 2000-2004 23 © Ravi Sandhu 2000-2004 24

 client hello  server hello

© Ravi Sandhu 2000-2004 25 © Ravi Sandhu 2000-2004 26

SSL HANDSHAKE: PHASE 1 SSL HANDSHAKE: PHASE 1

 cipher suite  cipher suite

© Ravi Sandhu 2000-2004 27 © Ravi Sandhu 2000-2004 28

© Ravi Sandhu 2000-2004 29 © Ravi Sandhu 2000-2004 30

© Ravi Sandhu 2000-2004 31 © Ravi Sandhu 2000-2004 32

SSL HANDSHAKE: PHASE 3 SSL HANDSHAKE: PHASE 3

 Certificate message  Client Key Exchange message

© Ravi Sandhu 2000-2004 33 © Ravi Sandhu 2000-2004 34

SSL HANDSHAKE: POST PHASE 3 SSL HANDSHAKE: POST PHASE 3

 48 byte pre master secret

© Ravi Sandhu 2000-2004 35 © Ravi Sandhu 2000-2004 36

© Ravi Sandhu 2000-2004 37 © Ravi Sandhu 2000-2004 38

SSL HANDSHAKE: PHASE 4 SSL HANDSHAKE: PHASE 4

 Change Cipher Spec message Finished message

• sender copies write pending state to write current finished_label

© Ravi Sandhu 2000-2004 39 © Ravi Sandhu 2000-2004 40

SSL ALERT PROTOCOL SSL ALERT MESSAGES

 always fatal  use dedicated port numbers for

© Ravi Sandhu 2000-2004 43 © Ravi Sandhu 2000-2004 44

 https 443  ftp-data 889

© Ravi Sandhu 2000-2004 45

S-ar putea să vă placă și

application protocol independent

4 parts to state 4 steps by sender (reversed by receiver)

Type: 1 byte ClientHello -------->

these 9 handshake messages must occur Client Server

client hello server hello

cipher suite cipher suite

Certificate message Client Key Exchange message

48 byte pre master secret

Change Cipher Spec message Finished message

always fatal use dedicated port numbers for

https 443 ftp-data 889