Practical cryptography Common Use scenarios Secure Transport Protocols After analyzing all the required cryptographic primitives (symmetric and asymmetric ciphers, hashes), we can tackle: 1 The TLS secure transport protocol (HTTPS and Secure Mail Alessandro Barenghi Transport) 2 The Secure SHell (SSH) protocol (secure interactive terminal access) Dipartimento di Elettronica, Informazione e Bioingegneria (DEI) 3 The Tor Onion Routing protocol (Transport anonymity) Politecnico di Milano In all cases the bulk of the data is encrypted with an ephemeral key alessandro.barenghi - at - polimi.it with a block cipher The ephemeral key is agreed via an asymmetric key cipher All protocols employ public key authentication mechanisms to provide authenticated connections G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 1 / 32 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 2 / 32 TLS - A brief history TLS (SSL) - Basics and Standards The SSL times Overview The Secure Socket Layer (SSL) protocol was designed in 1995 by Tal TLS v1.2 (RFC5246) employs a hybrid encryption scheme: ElGamal to provide transport security for HTTP over TCP. The first Public key ciphers are employed to provide endpoint authentication and public version was SSL 2.0 exchange securely an ephemeral session key Secret key ciphers are employed to provide high throughput data TLS - Birth and evolution transmission, employing the session key as a shared secret In 1999 the IETF standardized the first version of TLS, starting from X.509 certificates are employed to provide authentication to the SSL v3.0, and fixing some security issues which were persisting since communication endpoints to avoid impersonation attacks SSL v2.0 (SSL and TLS are not interoperable) The TLS transport layer provides no enforced integrity guarantee, TLS was updated three times since then (v1.1, v1.2, v1.3) save when the mode of operation of the symmetric cipher does so The most widespread version is v1.2, v1.3 was standardized less than 2 Abuses of the missing integrity check have been exploited in practical years ago, v1.1 e v1.0 are expected to be deprecated by 2020 attacks (e.g. BEAST), leading to a strong recommendation of TLS fino alla versione 1.2 consente il downgrade trasparente della authenticated encryption modes connessione a SSLv3 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 3 / 32 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 4 / 32 TLS (SSL) - Basics and Standards Practical key sizes Ciphersuites Summary and recommendations The set of primitives employed by TLS is known as ciphersuite The computational security margin of the primitives of the ciphersuite It is expressed as TLS A WITH B C, where A,B,C are: should match Asymm. cipher, used in authentication (e.g. ) during key exch. A RSA The following table was provided by the Coordination & Support Default kex performed via RSA, Diffie-Hellman (DH RSA) and EC-based Diffie-Hellman (ECDH RSA) available Action ECRYPT in 2018, relying on a report by ENISA, is available at Authentication can be skipped specifying DH anon to have an www.keylength.com unauthenticated Diffie-Hellman based kex B Symm. cipher + mode of operation , used in data encryption, (e.g., Sec. Secret key/private key/digest size [b] AES GCM, 3DES2 CBC,RC4,Salsa20) Margin RSA ECDSA DSA AES Hash No padding strategy for block ciphers (random padding allowed) (key/group) NULL can be specified to employ TLS for endpoint auth. only Legacy 1024 160 160/1024 80 160 C Hash function, for MAC/signing (e.g. SHA256, SHA ! SHA-1) 10 years 3072 256 256/3072 128 256 The TLS standard advises against MD2,MD4,MD5 only after v1.1 30+ years 15360 512 512/15360 256 512 Example of a ciphersuite : TLS DHE RSA WITH AES 256 CBC SHA256 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 5 / 32 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 6 / 32 TLS v1.2 TLS (SSL) - Server only authentication Client Server Single sided authentication 1 [cli ! srv] ClientHello message w/ highest TLS version supported and the supported cipher suites in clear 2 [srv ! cli] ServerHello message w/ the protocol version and ciphersuite SYN TCP TLS choice, and a session random number (nonce) in clear SYN/ACK ACK 3 [srv ! cli] X.509 Certificate, and a ServerHelloDone message ClientHello ServerHello 4 Certificate [cli,local] Checks the certificate, [cli ! srv] ClientKeyExchange message ClientKeyExchange ServerHelloDone with premasterkey enciphered with the server's public key ChangeCipherSpec Finished ChangeCipherSpec 5 [srv and cli,local] Compute session key from nonces and premasterkey Finished Application 6 [ ! ] ChangeCipherSpec message, notifying that the Data cli srv Application communication will be encrypted and Finished message, containing a MAC Data of all the previous messages 7 [srv,local] decrypts the Finished message and [srv ! cli] an identical one G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 7 / 32 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 8 / 32 TLS (SSL) - Mutual authentication TLS (SSL) - Issues and Solutions Mutual Authentication Common Issues In the previous scheme, only the client authenticates the server Issue: Public key based key exchange is expensive, especially if identity: TLS supports also mutually authenticated communications there are many sessions in a short amount of time The mutual authentication is achieved through the client sending his Solution: fast session resume: the two endpoints exchange only the Hello messages, with the random nonce of the session they want to own certificate before the ClientKeyExchange message resume and switch to encrypted mode. After sending the ClientKeyExchange message, the client sends a The authentication between the parties is implicitly handled by the fact CertificateVerify message, which is a signature over all the previous that they both know the same session secret messages, allowing the server to check that the one who initiated the Issue: Long term private key leak implies that all the previous communication was effectively the client communications can be decrypted: no forward secrecy In this case, both the server and the client can close the connection if Solution: Enclose the secret session key in a Diffie-Hellman key the identity of the other is not the correct one preventing exchange protocol, allowing the DH parameters to be renewed by the impersonation attacks server. This is known as Ephemeral Diffie-Hellman (DHE). G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 9 / 32 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 10 / 32 TLS - Uses TLS - Common pitfalls De Facto standards Issues and mitigation HTTPS: HTTPS is basically plain HTTP traffic carried by an Weak ciphersuites open up to attacks: Don't use DES (small key) , SSL/TLS transport layer RC2 (small key), RC4 (broken in 2013 in the TLS use scenario) Secure SMTP/IMAP/POP3: all these protocols can (and should) be An attacker may force a downgrade of the ciphersuite altering the used with an TLS transport layer ClientHello message: Remove from accepted ciphersuites the vulnerable ones altogether OpenVPN: OpenVPN exploits TLS (instead of IpSEC or PPTP) as the transport protocol for point-to-point VPNs Cipher renegotiation allows an attacker to splice a request into a TLS setup: a fix is standardized in RFC5746 and implemented in Handling legacy application level protocols recent OpenSSL/GNUTLS/NSS The Heartbleed bug: affecting OpenSSL, it is not a TLS weakness, TLS is designed to provide confidentiality and endpoint it's simply a CS-101 programming error (missing check on the size of authentication for any TCP based communication. a memcpy): get a fixed implementation stunnel: The Stunnel utility provides a TLS transport wrapper for When possible, use an authenticated mode of operation (e.g., GCM) any protocol you like acting as a portmapper and TLS v1.2 to fix padding-based attacks (e.g. BEAST) G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 11 / 32 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 12 / 32 TLS 1.3 SSH - Basics Novit`arispetto alla versione precedente Overview Cut down by 1 RTT the setup latency: client sends session key share The Secure SHell Protocol suite was designed at first (1995) to and supported ciphers with ClientHello protect remote login/shell applications from eavesdropping (i.e. Added features: provide confidentiality) Perfect forward secrecy providing key exchange now mandatory In the years it has grown to a full fledged protocol suite ChaCha20 (tweakable block cipher), Poly1305 (MAC), ED25519 (DSA) (encompassing 15 RFC) with separated layers for authentication, Removed Features (bugs?): transport and multiple connection handling Transparent downgrading to previous versions: TLS v.1.3 server writes DOWNGRD in the first characters of nonce if downgrading to v1.2 Most popular implementations (OpenSSH and Putty) support Weak primitives: (e.g., MD5, SHA-1, SHA-2-224, DES, RC4, custom advanced features such as providing a forwarding tunnel for a TCP DH groups) connection flow and a dedicated file transfer protocol (SFTP) Export-grade ciphers (e.g., RSA-512) SSH uses a hybrid (asymmetric+symmetric) encryption scheme Data compression (may leak information) and ciphersuite renegotiation similar to TLS, while allowing different methods for authentication (in-flight downgrades were possible) G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 13 / 32 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 14 / 32 SSH - Session authentication SSH - Session authentication User Authentication Protocol