Transport Layer Security TLS Mario agalj mcagaljfesb hr
Transport Layer Security (TLS) Mario Čagalj mcagalj@fesb. hr FESB
Transport Layer Security (TLS) o o o Najvažniji sigurnosni protokol modernog Interneta Dizajnirao ga je Netscape pod nazivom Secure Socket Layer o SSL v 3. 0 objavljen je kao Internet Draft prije 20 godina o Evoluirao je u TLS (Transport Layer Security) o TLS 1. 0 inicijalno definiran u RFC 2246 (1999) TLS je najpoznatiji i najkorišteniji protokol za sigurnu komunikaciju putem Interneta o HTTP o SSL-based VPN o E-mail o Wi. Fi o . . . : : 2: :
Transport Layer Security (TLS) o o Status: o TLS 1. 0 definiran u RFC 2246 (1999) o TLS 1. 1 definiran u RFC 4346 (2006) o TLS 1. 2 definiran u RFC 5246 (2008) o TLS 1. 3 (https: //tools. ietf. org/html/draft-ietf-tls 13 -28, 2018) Preporuke: o TLS 1. 0 x o TLS 1. 1 x o TLS 1. 2 ✔ o TLS 1. 3 ✔ : : 3: :
Osnovne sigurnosne usluge TLS-a o TLS omogućava zaštitu mrežnog prometa na transportnoj razini (transport layer security), te koristi TCP protokol za pouzdan prijenos podataka o TLS pruža sljedeće sigurnosne usluge o o Confidentiality (privacy of data and identities) o Data integrity, anti-replay protection o Server authentication o Client authentication (optionally) Example: HTTPS HTTP Klijent TLS tunnel HTTPS = HTTP over TLS Server : : 4: :
Arhitektura TLS protokola (TLS 1. 2) o Protokol se sastoji od dvije razine o TLS Handshake Protocol o TLS Record Protocol Handshake Protocol Change Cipher Spec Protocol Alert Protocol applications (e. g. , HTTP) Record Protocol TCP IP : : 5: :
Arhitektura TLS protokola Client Server Handshake protocol Record protocol : : 6: :
Arhitektura TLS protokola o o TLS Handshake Protocol o Autentikacija servera i opcionalno klijenta o Uskladjivanje kriptografskih algoritama, modova i parametara o Uspostava simetričnih kljuceva za TLS Record protokol TLS Record Protocol o Enkripcija poruka o Autentikacija poruka (zaštita integriteta, anti-replay zaštita) o Fragmentacija poruka viših razina o Sažimanje (kompresija) fragmenata – opcionalno : : 7: :
TLS 1. 2 Handshake Protocol
TLS 1. 2 Handshake Protocol Overview o Involves the following steps (between a client and a server): 1. Exchange hello messages to agree on algorithms, exchange random values, and check for session resumption 2. Exchange the necessary cryptographic parameters to allow the client and server to agree on a premaster secret 3. Exchange certificates and cryptographic information to allow the client and server to authenticate themselves 4. Generate a master secret from the premaster secret and exchanged random values 5. Provide security parameters to the record layer 6. Allow the client and server to verify that their peer has calculated the same security parameters and that the handshake occurred without tampering by an attacker (using HMAC) Source: https: //www. ietf. org/rfc 5246. txt : : 9: :
Simplified RSA handshake (TLS 1. 2) Client Generates a PREMASTER KEY Derives a Server Client. Hello [Random] Server. Hello [Random], Certificate [Pu. S] MASTER KEY from the E(Pu. S, PREMASTER KEY), Finished = MAC(MASTER KEY, „client”, Handshake) PREMASTER KEY Derives a MASTER KEY Finished = MAC(MASTER KEY, „server”, Handshake) from the PREMASTER KEY E(SESSION KEY, Application data) : : 10: :
TLS 1. 2 Handshake Protocol client server client_hello server_hello certificate server_key_exchange certificate_request server_hello_done certificate client_key_exchange certificate_verify Phase 1: Negotiation of the session ID, key exchange algorithm, MAC algorithm, encryption algorithm, and exchange of initial random numbers Phase 2: Server may send its certificate and key exchange message, and it may request the client to send a certificate. Server signals end of hello phase. Phase 3: Client sends certificate if requested and may send an explicit certificate verification message. Client always sends its key exchange message. change_cipher_spec finished Phase 4: Change cipher spec and finish handshake optional messages : : 11: :
TLS 1. 2 Handshake: Client Hello o Klijent i server pregovaraju/usklađuju algoritme i ključeve o Klijent predlaže listu algoritama i protokola a server bira iz liste struct { Protocol. Version client_version; Random random; Session. ID session_id; Cipher. Suite cipher_suites<2. . 2^16 -2>; Compression. Method compression_methods<1. . 2^8 -1>; select (extensions_present) { case false: struct {}; case true: Extension extensions<0. . 2^16 -1>; }; } Client. Hello; : : 12: :
TLS 1. 2 Handshake: Client Hello o client_random o o session_id o o o current time (4 bytes) + pseudo random bytes (28 bytes) empty if the client wants to create a new session, or the session ID of an old session the client wishes to use for this connection cipher_suites o o list of cryptographic options supported by the client ordered by preference a cipher suite contains the specification of the key exchange method, the encryption and the MAC algorithm ( + sizes of keys, IVs) o exmaples: TLS_RSA_WITH_3 DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA 256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA 256 TLS_DHE_DSS_WITH_AES_256_GCM_SHA 384. . . : : 13: :
TLS 1. 2 Handshake: Cipher Suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 256 o Key exchange (RSA, DHE, ECDHE, PSK, . . . ) o Server/client authentication (RSA, ECDSA, . . . ) o Encryption (AES, Camellia, 3 DES, RC 4, . . . ) o MAC (CBC, HMAC, . . . ) o KDF (key derivation function) or Pseudo Random Function (PRF) (MD 5, SHA 1, SHA 256, SHA 384, . . . ) : : 14: :
TLS 1. 2 Handshake: Server Hello o Klijent i server pregovaraju/usklađuju algoritme i ključeve o Klijent predlaže listu algoritama i protokola a server bira iz liste struct { Protocol. Version server_version; Random random; Session. ID session_id; Cipher. Suite cipher_suite; Compression. Method compression_method; select (extensions_present) { case false: struct {}; case true: Extension extensions<0. . 2^16 -1>; }; } Server. Hello; : : 15: :
TLS 1. 2 Handshake: Server Hello o server_random o o current time (4 bytes) + pseudo random bytes (28 bytes) independent of the client random session_id o o session ID chosen by the server if the client wanted to resume an old session: o if the client wanted a new session server generates a new session ID o o server checks if the session is resumable if so, it responds with the session ID and the parties proceed to the finished messages cipher_suites o o single cipher suite selected by the server from the list given by the client the server rejects the client’s request if there is no suitable chipher suite : : 16: :
TLS 1. 2 Handshake Protocol client server client_hello server_hello certificate server_key_exchange certificate_request server_hello_done certificate client_key_exchange certificate_verify Phase 1: Negotiation of the session ID, key exchange algorithm, MAC algorithm, encryption algorithm, and exchange of initial random numbers Phase 2: Server may send its certificate and key exchange message, and it may request the client to send a certificate. Server signals end of hello phase. Phase 3: Client sends certificate if requested and may send an explicit certificate verification message. Client always sends its key exchange message. change_cipher_spec finished Phase 4: Change cipher spec and finish handshake optional messages : : 17: :
TLS 1. 2 Handshake: key exchange o U 2. i 3. fazi handshake protokola klijent i server izvršavaju odgovarajući protokol za uspostavu dijeljenog sesijskog tajnog ključa – (authenticated) key exchange protocol o Primjer podržanih key exchange protokola u TLS 1. 2: o RSA (no forward secrecy) o DH (static Diffie-Hellman, no forward secrecy) o DHE (ephemeral Diffie-Hellman, forward secrecy) o ECDHE (ephemeral Diffie-Hellman based on elliptic curves, forward secrey) o . . . : : 18: :
Simplified RSA key exchange (TLS 1. 2) Client Generates a PREMASTER KEY Authenticates Server (with public RSA key Pu. S) Client. Hello [. . . , TLS_RSA_WITH_AES_256_CBC_SHA 256, . . . ] Server. Hello [TLS_RSA_WITH_AES_256_CBC_SHA 256], Certificate [Pu. S] the server Derives a E(Pu. S, PREMASTER KEY), Finished = MAC(MASTER KEY, „client”, Handshake) MASTER KEY from the PREMASTER KEY Finished = MAC(MASTER KEY, „server”, Handshake) random values) from the PREMASTER KEY (and the client’s and server’s Derives a E(SESSION KEY, Application data) (and the client’s and server’s random values) : : 19: :
Simplified DHE key exchange (TLS 1. 2) Client Server Client. Hello [. . . , TLS_DHE_RSA_WITH_AES_256_CBC_SHA 256, . . . ] Server. Hello [TLS_DHE_. . . ], Cert [Pu. S], Server. Key. Exchange [p, g, g. Xs] Client. Key. Exchange [g. Xc], Finished = MAC(MASTER KEY, „client”, Handshake) Finished = MAC(MASTER KEY, „server”, Handshake) Derives a PREMASTER KEY : : 20: :
TLS 1. 2 Handshake Protocol client server client_hello server_hello certificate server_key_exchange certificate_request server_hello_done certificate client_key_exchange certificate_verify Phase 1: Negotiation of the session ID, key exchange algorithm, MAC algorithm, encryption algorithm, and exchange of initial random numbers Phase 2: Server may send its certificate and key exchange message, and it may request the client to send a certificate. Server signals end of hello phase. Phase 3: Client sends certificate if requested and may send an explicit certificate verification message. Client always sends its key exchange message. change_cipher_spec finished Phase 4: Change cipher spec and finish handshake optional messages : : 21: :
Server certificate and key exchange o certificate o o server_key_exchange o o o carries a server’s key exchange public key (and public key parameters) carries the digital signature of the above public key and parameters certificate_request o o o contains one or a chain of X. 509 certificates (up to a known root CA) authenticates the server authenticates the key exchange protocol (i. e. , the server public keys) the server can ask the client to authenticate itself via a certificate specifies which type of certificate is requested server_hello_done o sent to indicate that the server is finished its part of the key exchange : : 22: :
TLS 1. 2 Handshake Protocol client server client_hello server_hello certificate server_key_exchange certificate_request server_hello_done certificate client_key_exchange certificate_verify Phase 1: Negotiation of the session ID, key exchange algorithm, MAC algorithm, encryption algorithm, and exchange of initial random numbers Phase 2: Server may send its certificate and key exchange message, and it may request the client to send a certificate. Server signals end of hello phase. Phase 3: Client sends certificate if requested and may send an explicit certificate verification message. Client always sends its key exchange message. change_cipher_spec finished Phase 4: Change cipher spec and finish handshake optional messages : : 23: :
Client authentication and key exchange o certificate o o client_key_exchange o o o sent only if requested by the server always sent carries a client’s key exchange public key or RSA encrypted pre-master secret certificate_verify o o o sent only if the client sent a certificate provides client authentication contains signed hash of all the previous handshake messages : : 24: :
TLS 1. 2 Handshake Protocol client server client_hello server_hello certificate server_key_exchange certificate_request server_hello_done certificate client_key_exchange certificate_verify Phase 1: Negotiation of the session ID, key exchange algorithm, MAC algorithm, encryption algorithm, and exchange of initial random numbers Phase 2: Server may send its certificate and key exchange message, and it may request the client to send a certificate. Server signals end of hello phase. Phase 3: Client sends certificate if requested and may send an explicit certificate verification message. Client always sends its key exchange message. change_cipher_spec finished Phase 4: Change cipher spec and finish handshake optional messages : : 25: :
Finished messages o change_cipher_spec o o sent by the client and the server to notify the receiving party that subsequent records will be protected under the negotiated algorithms and keys finished o o sent immediately after the change_cipher_spec message used to authenticate all previous handshake messages, i. e. , use to verify that the key exchange and authentication processes were successful the first message protected with the just negotiated algorithms, keys, and secrets esentially, it carries the HMAC calculated over all of the data from all messages in this handshake Finished = HMAC(master_secret, „server_finished”, HASH(handshake_messages)) Finished = HMAC(master_secret, „client_finished”, HASH(handshake_messages)) : : 26: :
Cryptographic key computations o pre_master_secret o o if key exchange is RSA based o generated randomly by the client o sent to the server encrypted with the server’s public RSA key if key exchange is Diffie-Hellman based o pre_master_secret = DH shared key o example: pre_master_sercret = g. Xs. Xc mod p : : 27: :
Cryptographic key computations o master_secret (48 bytes) – a session key o master_secret = PRF(pre_master_secret, "master secret", Client. Hello. random + Server. Hello. random) o PRF - Pseudo Random Function o TLS 1. 2 PRF is esentially a HMAC function PRF(secret, label, seed) = HMAC_hash(secret, A(1) || seed) || HMAC_hash(secret, A(2) || seed) || HMAC_hash(secret, A(3) || seed) ||. . . , with A(0) = seed A(i) = HMAC_hash(secret, A(i-1)) o PRF can be iterated as many times as necessary to produce the requred quantity od data : : 28: :
Cryptographic key computations o TLS Record. Protocol needs encryption keys, MAC keys, initializations vectors (IV) to be able to protect messages o Required crypto material is generated from the master_secret key_block = PRF(master_secret, "key expansion", server_random || client_random) key_block : … client write MAC key server write MAC key client write key server write key client write IV server write IV … : : 29: :
Cryptographic key computations random pre_master_secret TLS 1. 2 PRF random master_secret TLS 1. 2 PRF key_block : client write MAC key server write MAC key client write key server write key … : : 30: :
TLS 1. 2 Record Protocol
Arhitektura TLS protokola Client Server Handshake protocol Record protocol : : 32: :
Arhitektura TLS protokola o o TLS Handshake Protocol o Autentikacija servera i opcionalno klijenta o Uskladjivanje kriptografskih algoritama, modova i parametara o Uspostava simetričnih kljuceva za TLS Record protokol TLS Record Protocol o Enkripcija poruka o Autentikacija poruka (zaštita integriteta, anti-replay zaštita) o Fragmentacija poruka viših razina o Sažimanje (kompresija) fragmenata – opcionalno : : 33: :
Arhitektura TLS protokola (TLS 1. 2) o Protokol se sastoji od dvije razine o TLS Handshake Protocol o TLS Record Protocol Handshake Protocol Change Cipher Spec Protocol Alert Protocol applications (e. g. , HTTP) Record Protocol TCP IP : : 34: :
TLS Record Protocol (for CBC mode) Application data Fragment Compress Add header Add MAC Encrypt (MAC protects: header + data fragment)
TLS Record Protocol (CBC mode) o Example: the Record’s format when CBC mode is used to protect data type version length Authenticated application data (compressed fragment) Encrypted MAC Not encrypted padding o p. len Encrypted Please note that TLS uses CBC and HMAC in the insecure Authenticate-then-Encrypt composition (attacks possible) o CBC mode discarded in TLS 1. 3 : : 36: :
TLS Record Protocol (GCM mode) o Example: the Record’s format when GCM mode is used to protect data; recall, GCM is an authenticated encryption (AE) mode type version length explicit nonce Authenticated application data (compressed fragment) Encrypted Not encrypted Encrypted : : 37: :
Anti-replay protection in TLS o o TLS Record Protocol maintains a sequence number (seq_num) for each TLS connection o Separate seq_num for incoming and outgoing data records/fragments o seq_num starts at 0 and may not exceed 264 – 1 o seq_num incremented after each data record Record Protocol includes the seq_num when authenticating the given data record/fragment o Example: CBC mode MAC calculation: MAC(write_MAC_key, seq_num || type || version || length || fragment) o seq_num is not explicitly sent with the data fragment o Each end point maintains separate seq_nums for each connection o This is possible because TLS sits on the reliable TCP protocol that guarantees in-order delivery of packets o In case of authentication failures, connection is terminated : : 38: :
TLS 1. 2 Alert Protocol
TLS Alert Protocol (TLS 1. 2) Handshake Protocol Change Cipher Spec Protocol Alert Protocol applications (e. g. , HTTP) Record Protocol TCP IP : : 40: :
TLS Alert Protocol (TLS 1. 2) o Each alert message consists of 2 fields (bytes) o First field (byte): warning or fatal o Second field (byte): o o o o unexpected_message bad_record_MAC decompression_failure handshake_failure illegal_parameter close_notify no_certificate bad_certificate unsupported_certificate_revoked certificate_expired. . . In case of a fatal alert o Both parties immediately close the connection o Servers and clients MUST forget any session-identifiers, keys, and secrets associated with a failed connection : : 41: :
TLS 1. 2 vs TLS 1. 3
Examples: TLS in Enterprise Wi. Fi
Autentikacijski model IEEE 802. 1 X Kontrolirani port AP LAN (Internet) Autentikacijski server Mobilni klijent Slobodni port o o o Mobilni klijent želi se spojiti na mrežu AP kontrolira pristup uslugama (kontrolirani port) Autentikacijski server (AS) o Mobilni klijent i AS se međusobno autenticiraju o Ako je autentikacija uspješna, AS informira AP da može otvoriti kontrolirani port mobilnom klijentu : : 44: :
Operacijske faze u IEEE 802. 11 i Mobilni klijent (M) Pristupna točka (AP) Autentikacijski server (AS) Otkrivanje sigurnosnih funkcionalnosti Rezultat: M i AS - generiraju Master Key (MK) - izvedu Pairwise MK (PMK) 802. 1 X autentikacija Rezultat: M i AP 802. 1 X key management - provjere PMK - izvedu Paiwise Transient Key (PTK) - PTK vezan uz ovaj M i ovu AP Distribucija PMK ključa (u WPA putem RADIUS-a) Zaštita podataka (TKIP, CCM-AES) : : 45: :
Wi. Fi Security: EAP-TTLS o Tunneled TLS over Extensible Authentication Protocol (EAP-TTLS) o Provides protection for mobile client initial authentication messages (e. g. , plaintext passwords as in PAP, or hash-based MS-CHAPv 2 - used by FESB) transmitted over public wireless channel o Initial authentication messages are exchanged through a TLS tunnel <------certificate-----> <--no trust--> Mobile client (M) <--trust--> Access Point (AP) <--trust--> TTLS server Establishing a TLS tunnel TLS protected authentication Authentication WLAN master session key Data traffic on secured link : : 46: :
Security Issues in Practice o EAP-TTLS (+ PAP: Password Authentication Protocol) Their are many forms of authentication in an 802. 1 X/EAP network and one of the more secure forms is EAP-TTLS is know as a tunneled authentication method. It's security lies in the fact that before the user credentials are sent to the authenticating server a TLS tunnel is setup between the users client and the authenticating server in which the credentials are transmitted. Benefits of using such a tunnel is that not only are the credentials of the user protected, but this also allows the verification of the authenticating server based on it's TLS certificate. o Quoting: „Uputa za spajanje na FESB WLAN mrežu”: o “Certificate, slika 6 (isključeno Verify server certificate)” o Impersonation attack (stealing your passwords) : : 47: :
- Slides: 47