Secure Transport Protocols

Alessandro Barenghi

Dipartimento di Elettronica, Informazione e Bioingegneria (DEI) Politecnico di Milano alessandro.barenghi - at - polimi.it

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 1 / 32 Practical cryptography

Common Use scenarios 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 Transport) 2 The Secure SHell (SSH) protocol (secure interactive terminal access) 3 The Tor Onion Routing protocol (Transport anonymity) In all cases the bulk of the data is encrypted with an ephemeral key 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 2 / 32 TLS - A brief history

The SSL times The Secure Socket Layer (SSL) protocol was designed in 1995 by Tal ElGamal to provide transport security for HTTP over TCP. The first public version was SSL 2.0

TLS - Birth and evolution In 1999 the IETF standardized the first version of TLS, starting from SSL v3.0, and fixing some security issues which were persisting since SSL v2.0 (SSL and TLS are not interoperable) TLS was updated three times since then (v1.1, v1.2, v1.3) The most widespread version is v1.2, v1.3 was standardized less than 2 years ago, v1.1 e v1.0 are expected to be deprecated by 2020 TLS fino alla versione 1.2 consente il downgrade trasparente della connessione a SSLv3

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 3 / 32 TLS (SSL) - Basics and Standards

Overview TLS v1.2 (RFC5246) employs a hybrid encryption scheme: Public key ciphers are employed to provide endpoint authentication and exchange securely an ephemeral session key Secret key ciphers are employed to provide high throughput data transmission, employing the session key as a shared secret X.509 certificates are employed to provide authentication to the communication endpoints to avoid impersonation attacks The TLS transport layer provides no enforced integrity guarantee, save when the mode of operation of the symmetric cipher does so Abuses of the missing integrity check have been exploited in practical attacks (e.g. BEAST), leading to a strong recommendation of authenticated encryption modes

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 4 / 32 TLS (SSL) - Basics and Standards

Ciphersuites The set of primitives employed by TLS is known as ciphersuite It is expressed as TLS A WITH B C, where A,B,C are: A Asymm. cipher, used in authentication (e.g. RSA) during key exch. Default kex performed via RSA, Diffie-Hellman (DH RSA) and EC-based Diffie-Hellman (ECDH RSA) available Authentication can be skipped specifying DH anon to have an unauthenticated Diffie-Hellman based kex B Symm. cipher + mode of operation , used in data encryption, (e.g., AES GCM, 3DES2 CBC,RC4,Salsa20) No padding strategy for block ciphers (random padding allowed) NULL can be specified to employ TLS for endpoint auth. only C Hash function, for MAC/signing (e.g. SHA256, SHA → SHA-1) The TLS standard advises against MD2,MD4,MD5 only after v1.1 Example of a ciphersuite : TLS DHE RSA WITH AES 256 CBC SHA256

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 5 / 32 Practical key sizes

Summary and recommendations The computational security margin of the primitives of the ciphersuite should match The following table was provided by the Coordination & Support Action ECRYPT in 2018, relying on a report by ENISA, is available at www.keylength.com

Sec. Secret key/private key/digest size [b] Margin RSA ECDSA DSA AES Hash (key/group) Legacy 1024 160 160/1024 80 160 10 years 3072 256 256/3072 128 256 30+ years 15360 512 512/15360 256 512

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 6 / 32 TLS v1.2

Client Server

SYN C TLS TCP SYN/ACK ACK ClientHello ServerHello Certificate ClientKeyExchange ServerHelloDone ChangeCipherSpec Finished ChangeCipherSpec Finished Application Data Application Data

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 7 / 32 TLS (SSL) - Server only authentication

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 choice, and a session random number (nonce) in clear

3 [srv → cli] X.509 Certificate, and a ServerHelloDone message

4 [cli,local] Checks the certificate, [cli → srv] ClientKeyExchange message with premasterkey enciphered with the server’s public key

5 [srv and cli,local] Compute session key from nonces and premasterkey

6 [cli → srv] ChangeCipherSpec message, notifying that the communication will be encrypted and Finished message, containing a MAC 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 8 / 32 TLS (SSL) - Mutual authentication

Mutual Authentication In the previous scheme, only the client authenticates the server identity: TLS supports also mutually authenticated communications The mutual authentication is achieved through the client sending his own certificate before the ClientKeyExchange message After sending the ClientKeyExchange message, the client sends a CertificateVerify message, which is a signature over all the previous messages, allowing the server to check that the one who initiated the communication was effectively the client In this case, both the server and the client can close the connection if the identity of the other is not the correct one preventing impersonation attacks

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 9 / 32 TLS (SSL) - Issues and Solutions

Common Issues Issue: Public key based key exchange is expensive, especially if there are many sessions in a short amount of time Solution: fast session resume: the two endpoints exchange only the Hello messages, with the random nonce of the session they want to resume and switch to encrypted mode. The authentication between the parties is implicitly handled by the fact that they both know the same session secret Issue: Long term private key leak implies that all the previous communications can be decrypted: no forward secrecy Solution: Enclose the secret session key in a Diffie-Hellman key exchange protocol, allowing the DH parameters to be renewed by the server. This is known as Ephemeral Diffie-Hellman( DHE).

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 10 / 32 TLS - Uses

De Facto standards HTTPS: HTTPS is basically plain HTTP traffic carried by an SSL/TLS transport layer Secure SMTP/IMAP/POP3: all these protocols can (and should) be used with an TLS transport layer OpenVPN: OpenVPN exploits TLS (instead of IpSEC or PPTP) as the transport protocol for point-to-point VPNs

Handling legacy application level protocols TLS is designed to provide confidentiality and endpoint authentication for any TCP based communication. stunnel: The Stunnel utility provides a TLS transport wrapper for any protocol you like acting as a portmapper

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 11 / 32 TLS - Common pitfalls

Issues and mitigation Weak ciphersuites open up to attacks: Don’t use DES (small key) , RC2 (small key), RC4 (broken in 2013 in the TLS use scenario) An attacker may force a downgrade of the ciphersuite altering the ClientHello message: Remove from accepted ciphersuites the vulnerable ones altogether Cipher renegotiation allows an attacker to splice a request into a TLS setup: a fix is standardized in RFC5746 and implemented in recent OpenSSL/GNUTLS/NSS The Heartbleed bug: affecting OpenSSL, it is not a TLS weakness, it’s simply a CS-101 programming error (missing check on the size of a memcpy): get a fixed implementation When possible, use an authenticated mode of operation (e.g., GCM) and TLS v1.2 to fix padding-based attacks (e.g. BEAST)

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 12 / 32 TLS 1.3

Novit`arispetto alla versione precedente Cut down by 1 RTT the setup latency: client sends session key share and supported ciphers with ClientHello Added features: Perfect forward secrecy providing key exchange now mandatory ChaCha20 (tweakable block cipher), Poly1305 (MAC), ED25519 (DSA) Removed Features (bugs?): Transparent downgrading to previous versions: TLS v.1.3 server writes DOWNGRD in the first characters of nonce if downgrading to v1.2 Weak primitives: (e.g., MD5, SHA-1, SHA-2-224, DES, RC4, custom DH groups) Export-grade ciphers (e.g., RSA-512) Data compression (may leak information) and ciphersuite renegotiation (in-flight downgrades were possible)

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 13 / 32 SSH - Basics

Overview The Secure SHell Protocol suite was designed at first (1995) to protect remote login/shell applications from eavesdropping (i.e. provide confidentiality) In the years it has grown to a full fledged protocol suite (encompassing 15 RFC) with separated layers for authentication, transport and multiple connection handling Most popular implementations (OpenSSH and Putty) support advanced features such as providing a forwarding tunnel for a TCP connection flow and a dedicated file transfer protocol (SFTP) SSH uses a hybrid (asymmetric+symmetric) encryption scheme similar to TLS, while allowing different methods for authentication

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 14 / 32 SSH - Session authentication

Machine Authentication Protocol SSH allows a trust-on-first-use server endpoint authentication through asking the user if the fingerprint of the server public key is trusted It is possible to employ a full PKI (RFC4521) as an alternative If the user deems that the server key authentic, the key is added to a local storage, and considered ok for all future connections The local key storage is a simple text file with one IP address-public key pair per line (have a look at ~/.ssh/known hosts) Trust revocation is simply performed via removing the offending key from the storage file

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 15 / 32 SSH - Session authentication

User Authentication Protocol Once the server to which the client is connecting is authenticated, SSH authenticates the user which wants to log in The authentication of the user typing on client host can be performed with four methods (RFC4252): Password: a simple password is sent encrypted with the public key of the server: the server checks if the password is the correct one Public Key: at bootstrap time, the user saves in a secure manner a copy of its personal public key on the server he wants to connect to. The authentication is simply performed through verifying a user-signed nonce on the server with the public key previously stored Host Based: The user is authenticated by signing a nonce with the host wide private key, the check is done with the host public key Keyboard Interactive: delegates authentication (GSSAPI/PAM) None: RFC4252 Explicitly notes that this is not recommended.

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 16 / 32 SSH - Key material and its storage

Key handling features SSH implementations support both GPG and X.509 standard certificates for key storage seamlessly The keys of a user are typically stored in a directory within his home directory on the system (~/.ssh on Linux, pub keys ending in .pub) The stored keys are: the known keys, server keys which have been recognised as authentic the authorised keys to authenticate the user on the host at login the actual keypairs the user may employ when using the SSH client Using Pluggable Authentication Modules (PAM) allows SSH implementations to use a smartcard, secure token or other delegates to perform authentication Secure tokens require the server to have a corresponding PAM module requesting a signature to them

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 17 / 32 Authentication

Kerberos Willing to reduce the number of passwords and still perform sound authentication, the Kerberos system was designed at MIT in late ’80s [1] After refinement the fifth version of Kerberos became standardised in RFC1510 which has been currently superseded by RFC4120 (drop from block cipher set single DES and add AES) The Kerberos protocol authenticates users registered on a centralized authentication point and thus share with it a common secret The whole authentication procedure is performed without the use of public key primitives and is thus very fast Kerberos is based on authentication proofs known as tickets

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 18 / 32 Authentication

Kerberos - Roles The Kerberos protocol identifies the following roles: Client: it is the machine the user logs on, and the one the user interfaces with to perform his tasks Authentication Server (AS): it is the machine which stores the credentials of all users and takes care of performing the authentication Service Server (SS): It is a server which offers services upon Kerberos-based authentication (say, a remote shell) The typical workflow of a user in a Kerberos authentication system is split into three steps: 1 Authentication to the AS 2 Request of a service authorization to the AS 3 Request of a service to a SS

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 19 / 32 Authentication

Kerberos - Authentication to AS Client AS Hash Password Cleartext Username Retrieve User Key

Encrypt with

Client/TGS Session Key

Encrypt with AS key Client/TGS Session Key client ID client ID client network address Client/TGS Session Key ticket validity period client ID Client/TGS session key + client network address client network address ticket validity period Client/TGS session key ticket validity period Client/TGS session key

Client/TGS Session Key

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 20 / 32 Authentication

Kerberos - Service Authorization Request to AS Client AS Client ID Encrypt with Timestamp Requested Service ID client ID Client ID client network address ticket validity period Decrypt with Timestamp Client/TGS session key

Requested Service ID Client ID Timestamp

Encrypt with SS key client ID client network address client ID client network address ticket validity period ticket validity period Client/SS session key Decrypt with Client/SS session key Client/SS Session Key Encrypt with Client/SS Session Key Client/SS Session Key And obtain

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 21 / 32 Authentication

Kerberos - Service Request to SS

Client ID Client Timestamp SS Encrypt with Requested Service ID client ID client network address Client ID ticket validity period Client/SS session key Timestamp Decrypt with SS key Requested Service ID client ID client network address ticket validity period Client/SS session key

Obtain and decrypt

Client ID Timestamp Decrypt with Timestamp+1 Encrypt with Timestamp+1 Timestamp+1 and if correct start using service

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 22 / 32 Authentication

Kerberos - Pros and Cons Pro: The user needs to remember/type a single password Con: single point of failure for the authentication: the AS must always be available or the whole authentication mechanism freezes (usually coped with through keeping multiple AS as backups) Con: Due to the ticket timestamps, all the machines in the authentication domain should be synchronizeda: this is usually coped with through the use of the (cleartext, unauthenticated) Network Time Protocol to perform synchronizations The password administration protocol is not standardised, although a proposal is described in RFC3244

adefault configuration mandates a lag among them lesser than 5 minutes

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 23 / 32 Mixing Networks

Anonymous network access Goal: provide anonymous access to contents via Internet First attempt: anonymizing proxies: a simple L5 proxy not performing any caching and exposing his own identity (i.e. IP address) Main issues: single point of failure, relies on the trustworthyness of the actual anonymizing proxy Further attempts made: First generation P2P mixing networks (e.g. Tarzan): everyone may either be a router or be an actual endpoint, traffic bounced around High latency mixing networks (e.g. Babel, MixMaster): Seek to hide everything, including content fruition latencies, from an eavesdropper, encrypt fully the traffic, insert long artificial delays

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 24 / 32 Second Generation Mixing networks

Tor: a low-latency, onion routing mixing network First generation mixing networks were trying to solve multiple problems (content anonymization, source anonymization, latency hiding) with a single approach In the light of the ideas and shortcomings of the first generation was designed Tor [2] Designed to be: Reliable in transport: Tor provides anonymization of TCP data flows Low latency: it should be possible to employ it for interactive workloads Easy to deploy: no modifications to the transport/network stack Providing confidentiality and integrity of transmitted data Perfect forward secrecy: avoid issues with routers seized by malicious entities Not designed to be: concealing latencies, performing application-layer content anonymization (e.g. User-Agent removal in HTTP)

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 25 / 32 Tor - Basics

Tor actors Relays: The actual nodes of the mixing network, they relay the information around, all communications among them are performed over TLS. They are typically known as Onion Relays (OR) Clients: A client connects to the Tor network via a so-called Onion Proxy (OP), sets up a circuit for communication choosing randomly the relays it should pass through, and uses them to communicate with another endpoint, the target, outside the Tor Network Exit point: A relay which agrees to act as the last relay of the communication and communicates with the target endpoint

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 26 / 32 Tor - Communication

Tor communication principles A circuit is a transport path in the Tor network, akin to a physical wire: it can be built or torn down by an OP All Tor communications are on top of TLS (= contained as the payload of a TLS connection) acting as blind “piping” TLS performs only server authentication, no client authentication Circuits are designed to be built telescopically, i.e. acknowledging each hop added to them: they need to be involving at least 3 relays The basic transport unit in Tor is the cell: control cells: they relay control messages for circuit setup and teardown relay cells: they are the actual cells carrying the user data to be relayed Each cell contains a 2 byte circuit ID: the relays can multiplex many circuits over a single TLS connection

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 27 / 32 Tor - Communication

Tor Circuit Setup (2 hops long for the sake of clarity)

OP OR1 OR2 Tgt

Create [c1, RSA (gx)] Pick x pub-OR1 Pick y, k1=(gx)y Created [c1, gy, H(k1|"handshake")] First hop

Relay [ c1, AESk1( Extend [OR2, RSApub-OR2(g x2)] ) Pick x2 x2 Create c2, RSApub-OR2(g )

Pick y2, k2=(gx2)y2 Created [c2, gy2, H(k2|"handshake")]

Relay [c1, AESk1( Second hop Extended gy2, H(k2|"handshake")] )

Figure: c1,c2 cell IDs; commands in teletype font, cell content within [ ]

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 28 / 32 Tor - Communication

Tor Circuit Characteristics Every OR knows the network identity of its neighbours only Only the OP has full knowledge of the ORs involved in the circuit! Long term RSA OR public keys are made available to the OP via a set of trusted OR which act as key directories They mantain a list of the active Tor ORs, together with their long term public keys, thus acting as notaries Tor supports EC-Based asymmetric crypto for higher efficiency Once a circuit is set up, it requires an active teardown procedure to be destroyed (akin to TCP Fin-Fin/Ack-Ack) This allows to reuse the same circuit for more than a single TCP connection of the OP, to reduce latencies The OP is the one in charge of asking for a circuit teardown

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 29 / 32 Tor - Communication

Tor Data Relay (2 hops circuit for the sake of clarity)

OP OR1 OR2 Tgt

Relay [c1, AESk1(

Relay [c2, AESk2( Begin slashdot.org:80)] ) ] Relay [c2, AESk2( Begin slashdot.org:80)] TCP Handshake Relay [c1, AESk1( Relay[c2, AESk2(Connected)]

Open Stream Relay [c2, AESk2(Connected)] ) ]

Relay [c1, AESk1(

Relay [c2, AESk2( Data, GET ... HTTP/1.1)] ) ] Relay [c2, AESk2( Data GET ... HTTP/1.1)] Data GET ... HTTP/1.1 Relay [c1, AESk1( ... Transmission Relay[c2, AESk2(Data, ...)] Relay [c2, AESk2(Data, ...)] ) ]

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 30 / 32 Tor - Communication

Tor Data Relay The client opens a communication with the target via a begin SOCKS command, which is encrypted multiple times with the symmetric keys of the OR in the circuit Each OR peels away a layer of the encryption, and executes the command specified in the cell which he has just decrypted Only the exit node knows the actual content of the transmission, however he does not known who generated such content Note that Tor is not designed to solve user content confidentiality: data exiting from the Tor network are not automatically encrypted An external eavesdropper only sees TLS traffic among the different ORs and the OP, with the exit nodes communicating with the targets: no inference can be made on the source of such communication, unless the attacker controls both the entry point and the exit node

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 31 / 32 BibliographyI

Clifford Neuman and Theodore Ts’o. Kerberos: An Authentication Service for Computer Networks. IEEE Communications 32 (9): 33-8, also available at http://gost.isi.edu/publications/kerberos-neuman-tso.html.

The Tor Project. Tor Protocol Specification. https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt.

William Stallings. Protocol basics: Secure shell protocol - the internet protocol journal, volume 12, no.4. https://www.cisco.com/c/en/us/about/press/internet-protocol-journal/back-issues/table-contents-46/ 124-ssh.html.

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 32 / 32