Lecture: Transport Layer Security (secure Socket Layer)
Recommended reading:
Stephen Thomas, “SSS and TLS essentials”, Wiley, 2000 Very old and in some parts obsolete, but very well written Giuseppe Bianchi
Lecture’s twofold goal Full dissection of a well known and widely employed security protocol Rasonable in-depth analysis of TSL details Devil is in details ☺ Although many more details had to be skipped (this is not a full course on TLS…)
Understand how a long-to-live security protocol should be designed Show good design choices vs bad ones TLS shows several examples for both! Giuseppe Bianchi
1
Introduction to TLS
Giuseppe Bianchi
History of SSL/TLS SSL v1 by Netscape never released 1994
…
SSL v2 Integrated in netscape 1.1 Badly broken! 1995
TLS v1.0 First IETF design (versus Netscape) 1996-1999 RFC 2246, jan 1999
SSL v3 Redesigned from scratch by Netscape 1996
…
TLS v 1.1 RFC 4346 Apr 2006
DTLS TLS v 1.2 RFC 4347 Still in progress Apr 2006 Internet draft v07-bis UDP support (nov 07) Get rid of now weak MD5/SHA-1hash TLS = SSL with minor modification (negotiated PRF, TLS1.0=SSLv3.1 default SHA-256) However NOT backward compatible with SSL 3.0 Public Domain implementation available @ www.openssl.org
Giuseppe Bianchi
2
SSL/TLS: layered view TCP/UDP/ANY
SMTP smtps SST/TLS
IPsec
TCP (if UDP, then DTLS)
IP
IP
HTTP
SMTP
……
Network layer security
HTTP https
……
Transport layer security
SSL/TLS: operates on top of TCP, but below application layer (can be considered as top sublayer for L4 or bottom for L7) SSL/TLS: NOT a security enhancement of TCP! Not necessarily limited to Internet transport (L4)! Devised for point-to-point relationships in general E.g. EAP-TLS (RFC 2716) TLS mechanisms employed for authentication and integrity protection over L2 EAP
Giuseppe Bianchi
Application support HTTP
SMTP
http 80
smtp 25
TLS
TLS
https 443
smtps 587
HTTP
Typical approach: reserve special port number for SSL/TLS mediated application Example: port 80 = HTTP over TCP Port 443 = HTTP over SSL/TLS (HTTPS)
SSL/TLS common application port numbers
http 80
smtps 465 (MS) or 587 (others) spop3 995 imaps 991 telnets 992 …
Pros works well; de facto standard Straightforward application support!!
Cons:
TCP/IP
2 reserved port numbers for same service deprecated by IETF (but still here…)
Alternative approach: slightly adapt application’s internals App reuses same port number Example: HTTPv1.1: upgrade: TLS/1.0 new http command (see RFC 2817)
Giuseppe Bianchi
3
TLS Goals Establish a session Agree on algorithms Share secrets Perform authentication Transfer application data Communication privacy Symmetric encryption
Data integrity Keyed Message Authentication Code (HMAC)
TLS approach: two-in-one Most other security protocols clearly distinguish the protocol for establishing a session (e.g., IPsec IKE) from the protocol that delivers data and enforces security services (e.g., IPsec ESP/AH) Giuseppe Bianchi
Session vs Connection Connection: Transport service TLS provides encryption and integrity TLS Record Protocol Session: Association between Client and Server Authentication and exchange of security parameters
May include several connections Heavy work: done once at the beginning Designed for HTTPv1.0;
TLS Handshake Protocol Giuseppe Bianchi
4
TLS protocol stack HTTP, etc Trivial protocols! Error Handling Establishes session & Initializes communicaton
start cipher
Handshake Alert Protocol Protocol
Change Cipher Spec
Application on TLS
TLS Record Protocol
Data transfer
Possibly special app port#
Minor modification of apps may be necessary (e.g. see RFC 2817/2818 for - HTTPS #443 - HTTPv1.1 ext
TCP Giuseppe Bianchi
TLS Record Protocol
Giuseppe Bianchi
5
Record Protocol operation
Record Protocol: - takes messages to be transmitted from apps - fragments the data into manageable blocks - optionally compresses the data - applies a MAC - encrypts - and transmits the result. - Reverse operation at reception (decryption, verification, decompression, reassembly, delivery to apps) Giuseppe Bianchi
Fragmentation At application TLS interface DON’T get confused with TCP segmentation!! Input: block message of arbitrary size possibly multiple aggregated messages of SAME protocol Fragment size: 214=16384 bytes
Giuseppe Bianchi
6
Compression Based on compression state negotiated… Lossless compression, if size increases (may happen in special cases) increase must NOT exceed 1024 bytes … but no compression by default Until recently, no compression was employed in TLS & SSLv3! Feature formerly used only in SSLv2
But some specifications recently emerged » RFC 3749 – support for DEFLATE (RFC 1951) » RFC 3943 – support for Lempel-Ziv-Stac
Reason: widespread diffusion of “verbose” languages – e.g. XML
Giuseppe Bianchi
Message Authentication Code MAC computation Secret (symmetric) key derived from security parameters negotiated during handshake Hash function: negotiated during handshake Computation: uses HMAC construction keyed-hashing Message Authentication, RFC 2104
Giuseppe Bianchi
7
Why HMAC? /1 Pay 100 dollars
Pay 100 dollars
Pay 1000 dollars
H(M,S)
Pay 1000 dollars
H(M,S)
Modified!
Simplest way to authenticate a message: Share secret S Share Hash function H Compute H(message, secret) and verify upon reception Good hash (anticollision properties) good protection Weaker than digital signature, but practical
Giuseppe Bianchi
Why HMAC? /2 Practical question: how to insert a secret in the hash??? Secret prefix H(S | M) may lead to extension attacks – H(S|M|X) may be computed from H(S|M) without knowing S – If H(M)=H(M’) then H(M|X)=H(M’|X)
Secret suffix H(M | S) much better; » but pre-computation can be exploited in attacks » and no formal proof of security
Envelope H(S1 | M | S2) two secrets needed » Again, no formal security proof Giuseppe Bianchi
8
HMAC RFC 2104, february 2007
HMACK(M) = H(K+ XOR opad || H(K+ XOR ipad || M)) K+ = shared key padded to hash basic block » When H=MD5, padding to 512 bits
size
opad = 0x36 = 00110110 repeated as needed ipad = 0x5C = 01011100 repeated as needed HMAC design goals: quantitatively proven robustness: as secure as its underlying hash is » see Bellare, Canetti, Krawcxykz, Keying Hash Functions for Message Authentication, 1996
Practical and flexible (you may change the underlying hash with more robust one) Efficient computation Padding: two key effect! Giuseppe Bianchi
Encryption Fragment Encryption Applies to both (compressed) fragment and MAC No encryption possible If no encryption negotiated Or in early handshake phases
Symmetric encryption algorithm Block or stream cipher Algorithm (RC4, DES, 3DES, etc) negotiated during handshake, too If block cipher, padding necessary to achieve block size Secret key derived from security parameters negotiated during handshake Differs from key used in MAC
Encryption algorithm CANNOT increase size of more than 1024 bytes Giuseppe Bianchi
9
Record Protocol Data Unit Application data OR Alert OR Handshake OR Change_cipher_spec
3.1 for TLS
5 bytes header Content type = 1 Version = 1+1 Length = 2 Content Type higher layer protocol
20 = 0x14 = Change Cipher Spec 21 = 0x15 = Alert 22 = 0x16 = Handshake 23 = 0x17 = Application Data
Sequence number Not transmitted, but kept at both connection extremes Remember: reliable transport, hence no “holes” NO WAY TO AVOID TCP ☺ Explicit 2 (epoch = cipher state change) + 6 bytes sequence number were added in DTLS
Giuseppe Bianchi
MAC generation details Computed through HMAC HMAC(seq.num | ctype | version | len | data) Minor differences with SSLv3 » No version in SSLv3 » Slightly different HMAC construction – (RFC 2104 final specification not yet finalized at the time ☺)
Hash used in HMAC: MD5 16 bytes hash SHA-1 20 bytes hash
Negotiation may decide not to use MAC In practice, always present Sequence number: Not transmitted but included in the MAC to detect missing/extra data and to prevent replay/reordering attacks Giuseppe Bianchi
10
TLS Handshake Protocol
Giuseppe Bianchi
Handshake: when Initial negotiation and exchange of parameters (mutually) authenticate agree on algorithms exchange random values Exchange secrets or information to compute secrets session resumption Re-keying (“refresh” secrets)
Initial handshake Includes auth & cert verification TCP conn
Abbreviated handshake TCP conn
Abbreviated handshake TCP conn time
TLS SESSION Giuseppe Bianchi
11
Handshake: goals Secure negotiation of shared secrets Never transmitted in clear text; derived from crypto parameters exchanged Robust to MITM attacks if connection authenticated Optional authentication for both client and/or server in practice always required for server
Through asymmetric, or public key, cryptography Exchange certificates and/or crypto information
Reliable Negotiation: Attacker cannot tamper communication and affect/alter the negotiation outcome without being detected by the involved C&S parties Fundamental: negotiation amenable to downgrade attacks!! Giuseppe Bianchi
Handshake Messages SERVER
CLIENT Client Hello Server Hello Certificate Server Key Exchange
Mandatory
Certificate Request Server Hello Done Certificate
Optional and/or only at session start-up
Client Key Exchange Certificate Verify Change Ciper Spec Finished Change Cipher Spec
Start encryption
Finished Application Data Giuseppe Bianchi
12
TCP segmentation (example) Handshake Layer
TLS Record Layer
TCP Layer
Server Hello
Server Hello
Server Hello
Server Hello Done
Certificate
Server Hello Done
Certificate
Certificate (continued)
Certificate
Server Hello Done
Simplified example: server responds to client hello with certificate only Arbitrary correspondence between TLS Records and TCP segments (TLS records fragmented into TCP segments) Obvious! Do you remember TCP? ☺ Giuseppe Bianchi
Handshake message format Incapsulated in TLS Record Handshake types: hello_request(0), client_hello(1), server_hello(2), certificate(11), server_key_exchange (12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange(16), finished(20)
Handshake Length of remaining message type 3 bytes
Content Major type=0x16 version
Minor version
Depends on handshake msg
Length of fragment 2 bytes
payload
Giuseppe Bianchi
13
Handshake phase 1 SERVER
CLIENT Client Hello Server Hello
General goal: Create TLS/SSL connection between client and server Detailed goals Agree on TLS/SSL version Define session ID Exchange nonces timestamp + random values used to, e.g., generate keys
Agree on cipher algorithms Agree on compression algorithm Giuseppe Bianchi
Client Hello First message, sent in plain text Incapsulated in 5 bytes TLS Record Content: Handshake Type (1 byte), Length (3 bytes), Version (2 bytes) Type 01 for Client Hello Version: 0300 for SSLv3, 0301 for TLS
32 bytes Random (4 bytes Timestamp + 28 bytes random) First 4 bytes in standard UNIX 32-bit format » Seconds since the midnight starting Jan 1, 1970, GMT
(Session ID length, session ID) 1+32 bytes – either empty or previous session ID » Previous session ID = resumed session state
(Cipher Suites length, Cipher suites) 2+Nx2 bytes, in order of client preference
(Compression length, compression algorithm) 1+1 byte (in all cases, today: compression algo = 00 = null) Giuseppe Bianchi
14
Cipher suites PUBLIC-KEY ALGORITHM
SYMMETRIC ALGORITHM
HASH ALGORITHM
TLS_AAAAAAA_WITH_BBBBBBBB_CCCCCCCC TLS_NULL_WITH_NULL_NULL
INITIAL (NULL) CIPHER SUITE
TLS_RSA_WITH_NULL_MD5 TLS_RSA_WITH_NULL_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_WITH_3DES_EDE_CBC_SHA JUST A FEW EXAMPLES (FULL LIST IN RFC)
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA TLS_DH_RSA_WITH_DES_CBC_SHA TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DH_anon_WITH_RC4_128_MD5
Note: arbitrary combination not possible: must choose from a (small) list of combinations Giuseppe Bianchi
The two basic approaches to key management Key transport (e.g., RSA) One party generates a random secret
Public Key Pk
» Client in TLS
Public Key Pk
Which is transported to the other party through a cryptographically secured channel
CLIENT draw secret
EPk (secret)
SERVER
» To Server » Using public key encryption
Key agreement (e.g., DH) Shared secred generated at both party sides through suitable exchange of crypto parameters
CLIENT Y, gY Compute mod p secret = (gX)Y = gXY
g, p, gX mod p gY mod
p
SERVER Y, gY Compute mod p secret = (gY)X = gXY
Giuseppe Bianchi
15
Server Hello In reply to Client Hello, sent in plain text Content: Handshake Type (1 byte), Length (3 bytes) Type = 02 for Server Hello)
Version Highest supported by both Client and Server
32 bytes Random (4 bytes Timestamp + 28 bytes random) Different random value than Client Hello
(Session ID length, session ID) If Client session ID=0, then generate session ID Otherwise, if resumed session ID OK also for Server, use it; Otherwise generate new one
Cipher Suite, 2 bytes Selected from client list (usually best one, but no obligation)
Compression algo, 1 byte Selected from Client list Giuseppe Bianchi
Downgrade attack MITM – doesn’t break SSL3.x, but knows very well how to break SSL2.0 (40 bit encryption only) CLIENT SSLv3.1
Client Hello, SSLv3.1 Server Hello, SSLv2.0
Client assumes that Server supports only SSL 2.0!!
Client Hello, SSLv2.0 Server Hello, SSLv2.0
SERVER SSL v3.1
Server assumes that client supports only SSL 2.0!!
Downgrade attacks on cipher suites, too MITM: remove “strong” cipher suites, and leave in Client Hello only the ones he knows he can break! Since hello message authentication not viable at the moment (not yet a shared secret available), verification must be necessarily delayed to a subsequent phase… Giuseppe Bianchi
16
Handshake phase 2 & 3 (schematic, RSA case) CLIENT
Signed_ca(server, PublicKey)
SERVER
(SSLVersion | SharedSecret)PublicKey
Phase 2: Server sends authentication information (certificate) Along with Public Key (in certificate or in extra msg) Phase 3: Client generates a Shared Secret Length depends on agreed cipher suite (RSA = 46 bytes)
And transmits it to Server, encrypted with Public Key Native SSL version included to early combat downgrade attacks Giuseppe Bianchi
Against downgrade attack CLIENT SSLv3.1
Client Hello, SSLv3.1 Server Hello, SSLv2.0
Client Hello, SSLv2.0 Server Hello, v2.0
SERVER SSL v3.1
Signed_ca(server, PublicKey) (SSLv3.1 |
SharedSecret)PublicKey
STOP!!
Since (signed) certificate cannot be tampered… … and since MITM cannot decrypt SharedSecret and must act as pass-through Downgrade attack on SSL version easily discovered! Encrypted SSL version is the one initially proposed, NOT the one negotiated in server hello, of course Giuseppe Bianchi
17
Handshake Phase 2 details Certificate (single or certificate chain)
CLIENT
SERVER
Server Key Exchange Certificate Request (certificate type & certificate authorities) Server Hello Done Certificate typically a certificate chain Server Key exchange When certificate not issued (no server authentication required – UNSAFE!!) When certificate key is for signature only (not for encryption) When certificate key cannot be used for legal reasons E.g. RSA key larger than 512 bits may not be used for encryption outside US, but only for signature Larger RSA key encoded in certificates may be used to sign shorter, temporary, RSA key
When Ephemeral Diffie-Hellman used Certificate request Requires client authentication (asks for an acceptable certificate) Server Hello Done empty message
Giuseppe Bianchi
Example: Diffie-Hellman /1 Review of DH Server transmits public value gX mod p Client replies with public value gY mod p Both compute shared key as K = (gY)X mod p = (gX)Y mod p
Three basic approaches (see next slide): Anonymous Fixed Ephemeral
Depends on whether X and Y values are pre-assigned or dynamically generated and/or signed Anon & Ephemeral DH transmitted in ServerKeyExchange
Giuseppe Bianchi
18
Example: Diffie-Hellman /2 DH variants “Anonymous” (basic) Diffie-Hellman X, Y generated on the fly and NOT authenticated Trivial MITM attack g, gZ
C Y, gY secret = gXY
g, gX
MITM Z, gZ Secret with C = gYZ Secret with S = gXZ
gY
S X, gX secret = gXZ
gZ
(Fixed) Diffie-Hellman DH “public” parameters gX and gY are static and signed by a certification authority No MITM anymore But they are long-lived brute-force attacks Ephemeral Diffie-Hellman DH parameters can vary But unlike anonymous DH, they are SIGNED by the party Hence parties mush have an RSA or DSS secret key for signature purposes Hence, why don’t just use RSA key transport? (we are here neglecting IPR/legal issues, of course ☺)
Giuseppe Bianchi
Example: Diffie-Hellman /3 ServerKeyExchange message format: Content Major Minor Length of fragment type=0x14 version=3 version=1 2 bytes = nn Handshake type=0x0c
Length 3 bytes = nn-4
DH p length 2 bytes
TLS Record Header (5 bytes) 0x14 = Handshake protocol
Handshake Header (4 bytes); 0x0c=ServerKeyEx DH p value ***
DH g length 2 bytes
DH g value ***
DH Ys length 2 bytes
DH Ys value ***
Signature RSA 16 MD5 + 20 SHA-1 DSA 20 SHA-1 only
DH parameters (variable length)
Signature size and hash used depends on signature type (RSA or DSA). Note: RSA uses BOTH MD5 and SHA-1
Client replies with DH public value Ys only (p and g are already known by the Server ☺) Giuseppe Bianchi
19
Handshake Phase 3 details CLIENT Certificate
SERVER
Client Key Exchange Certificate Verify
Certificate: Client certificate if requested Client Key exchange Transmit encrypted symmetric (premaster) key or information to generate secret key at server side (e.g. Diffie-Hellman Ys) Certificate Verify Signature of “something” known at both client and server ALL the messages exchanged up to now » Which is not only known, but also useful! Allows to detect at an early stage (more later on this) tampering attacks (e.g. cipher suite downgrade)
To prove Client KNOWS the private key behind the certificate Otherwise I could authenticate by simply copying a certificate ☺ Giuseppe Bianchi
A (smart) detail on certificate verify Q: Why Certificate Verify does not immediately follows certificate? A: to include connection specific crypto parameters into signature! client & server random values Explicit inclusion of master secret in SSLv3.0 » Since master secret can be computed only after the ClientKeyExchange message, Certificate Verify follows ClientKeyExchange » Although this was abandoned in TLS1.x, but certificate verify still left as late as possible and hence after ClientKeyExchange
Giuseppe Bianchi
20
Phase 4 CLIENT Change Ciper Spec Finished
SERVER Change Cipher Spec Finished
Phase 4 has two fundamental goals Switch to the new security connection state Hence authentication and encryption based on keys computed with the exchanged security parameters Immediately applied to finished message » First check that everything went OK! If Client and(orserver cannot decrypt finished message, something has gone wrong!
Authenticate all the previous handshake messages Finished = digital signature of all the previous handshake messages as transmitted and received by the peer up to now To avoid MITM tampering Giuseppe Bianchi
Change Cipher Spec Defined as a separate protocol (!) Only one message: 1 single byte Fixed content: constant value = 01 (!!!) 01
Change cipher spec protocol
Content Major type=0x14 version
Minor version
Length of fragment payload 0x0001
TLS Record Header Why a separate protocol, and not part of the Handshake? Wise choice! TLS specification allows aggregation of multiple messages of a SAME upper layer protocol into single TLS Record. How this possible with a Change Cipher Spec? (TLS Record is either ALL encrypted, or NOT encrypted) Giuseppe Bianchi
21
TLS Key Computation
Giuseppe Bianchi
Secret hierarchy Pre Master Secret
Exchanged (RSA) or computed (DH) during handshake - could be always the same value for same C-S pair (e.g., in the case fo fixed DH)
Master Secret
Nonce C Nonce S
Connection State Keys
Master Secret computed from: - Pre master - random values from C & S - timestamps from C & S Recomputed at session resumption
Up to 6 keys: - encription keys (write/read = C/S) - authentication keys (write/read = C/S) - initialization vector if needed (write/read) Recomputed at session resumption
Giuseppe Bianchi
22
Abbreviated handshake (3-way) (session resumption) Used to re-generate key material For new connection Avoids to reauthenticate peers Done at start of session only Avoid to re-exchange pre-master-secret Exchange new TS+random values Client Hello CLIENT
Server Hello
SERVER
Change Cipher Spec Finished Change Ciper Spec Finished Application Data Giuseppe Bianchi
Initial keying, re-keying: todo 1) Add randomness in key generation Pre master nounces
?
Master key
2) “Expand” initially limited secret to the needed amount of crypto material A3547B6AF2 ???
154892FFA100F4579D5F3AB….
Encryption key
Blablabla key
Giuseppe Bianchi
23
Basic building block: PRF Input (seed, other)
Pseudo Random Function
Output (“random”), unlimited
secret Fundamental “brick”: GOOD PRF Criteria and extensive literature available... Not only GOOD, but also fast/lightweight
PRFs in TLS SSL 3.0: not fully satisfactory PRF TLS 1.0 and 1.1: good PRF but… hard-coded! Construction used MD5 and SHA-1 (now weak) (unlike IPsec) TLS forgot that “good” in crypto is not forever….
TLS 1.2:negotiable PRF (at last ☺), and strong default based on SHA-256 Giuseppe Bianchi
PRF from a 1-way hash: Expansion function Phash A0 A1 A2 A3 … Phash =
= = = =
seed HMAChash(A0) HMAChash(A1) HMAChash(A2)
HMAChash(A1 | seed)
Same secret used in all HMACs Hash = chosen hash function
HMAChash(A2 | seed)
HMAChash(A3 | seed)
……
Phash function of: Chosen hash function Secret seed Phash size: any (unlike HMAC size) Giuseppe Bianchi
24
TLS 1.2 PRF from Phash PRF(secret, label, seed) = Phash(label|seed) TLS1.2: Default: this construction with SHA-256 32 bytes hash
But also negotiable PRF Hence possibly very different and not based on HMAC
Example: Master secret generation Inputs: Secret = Pre-master-secret Seed = Nonces (client-random & server-random)
Further input: Label = string “master secret”
Computation: first 48 bytes of: PRF(pre-master-secret, “master secret”, Client-Random | Server-Random) Giuseppe Bianchi
PRF (until TLS 1.1, i.e. today!) Employs two hash algorithms Idea: combine both MD5 and SHA-1 Greater robustness! Must break both… Indeed ☺
Input: Desired length Secret Assume even size, split it in two parts (S1,S2)
Seed Label (an ascii string)
Source: Stephen Thomas, SSL&TLS Essentials
PRF(scrt, lbl, sd) = PMD5(lbl | sd) XOR PSHA-1(lbl | sd) MD5 uses S1 as secret SHA-1 uses S2 as secret Giuseppe Bianchi
25
Key generation Master secret [48 bytes]: PRF(pre-master-secret, “master secret”, Client-Random | Server-Random)
Key Block [size depends on cipher suites]: PRF(master-secret, “key expansion”, Server-Random | Client-Random)
Individual keys: Partition key block into up to 6 fields in the following order: Client MAC, Server MAC, Client Key, Server Key, Client IV, Server IV
PRF used also in computation of finished message instead of “normal” MD5 or SHA-1 Hash. E.g. For client finished message: PRF(master-secret, “client finished”, MD5(all handshake msg) | SHA-1(all handshake msg)) [12 bytes] Giuseppe Bianchi
TLS connection management & application support
Giuseppe Bianchi
26
Alert Protocol TLS defines special messages to convey “alert” information between the involved fields Alert Protocol messages encapsulated into TLS Records And accordingly encrypted/authenticated Alert Protocol format (2 bytes): First byte: Alert Level warning(1), fatal(02)
Second Byte: Alert Description 23 possible alerts Alert level
Alert protocol
Content Major type=0x15 version
Minor version
Alert description
Length of fragment payload 0x0002
TLS Record Header Giuseppe Bianchi
Sample alerts See RFC2246 for all alerts and detailed description unexpected_message Inappropriate message received Fatal - should never be observed in communication between proper implementations
bad_record_mac Record is received with an incorrect MAC Fatal
record_overflow Record length exceeds 214+2048 bytes Fatal
handshake_failure Unable to negotiate an acceptable set of security parameters given the options available Fatal
bad_certificate, unsupported_certificate, certificate_revoked, certificate_expired, certificate_unknown Various problems with a certificate (corrupted, signatures did not verify, unsupported, revoked, expired, other unspecified issues which render it unacceptable Warning or Fatal, depends on the implementation
If fatal, terminate and do not allow resumption with same security parameters (clear all!) Giuseppe Bianchi
27
Truncation attack
TCP
TLS
TCP FIN
An attacker may end connection at any time by sending a TCP FIN Part of the intended information exchange is lost How can Server and Client distinguish this from a transaction that “normally” completes? Giuseppe Bianchi
Solution: Close Notify Application Data Close Notify Close Notify
Issued by any party Close Notify = Alert (warning level) Informs that no more data will be transmitted A connection that ends abruptly without a Close Notify may be a truncation attack A remark: note the weakness of TLS against TCP DOS attacks in general! Giuseppe Bianchi
28
Conclusive remarks Performance drawbacks: Increased overhead and latency! Mostly for encryption overhead and handshake overhead
Computational overhead may kill server performance Up to two orders of magnitude » ref: Transport Layer Security: how much does it really costs? Infocom 99
TLS does NOT protect TCP How to protect non SSL/TLS-aware applications? Tools available to protect a generic TCP connection stunnel = TCP over TLS over TCP » www.stunnel.org » Crazy (tcp tunneled over tcp), but as last resort…
DOS attacks to TCP remains a significant issue (no protection at all) Giuseppe Bianchi
DTLS Recently specified RFC 4347 – Datagram TLS – April 2006 TLS over UDP
DTLS design goal: Be as most as possible similar to TLS!
DTLS vs TLS TLS assumes orderly delivery » DTLS: Sequence number explicitly added in record header
TLS assumes reliable delivery » Timeouts added to manage datagram loss
TLS may generate large fragments up to 16384B » DTLS includes fragmentation capabilities to fit into single UDP datagram, and recommends Path MTU discovery
TLS assumes connection oriented protocol » DTLS connection = (TLS handshake – TLS closure Alert)
Giuseppe Bianchi
29
