Practical

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 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 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 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 , 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 C TLS TCP 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

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 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 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 : 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 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), (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 Machine Authentication Protocol Once the server to which the client is connecting is authenticated, SSH allows a trust-on-first-use server endpoint authentication SSH authenticates the user which wants to log in through asking the user if the fingerprint of the server public key is The authentication of the user typing on client host can be performed trusted with four methods (RFC4252): It is possible to employ a full PKI (RFC4521) as an alternative Password: a simple password is sent encrypted with the public key of If the user deems that the server key authentic, the key is added to the server: the server checks if the password is the correct one a local storage, and considered ok for all future connections 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 local key storage is a simple text file with one IP address-public The authentication is simply performed through verifying a user-signed key pair per line (have a look at ~/.ssh/known hosts) nonce on the server with the public key previously stored Trust revocation is simply performed via removing the offending Host Based: The user is authenticated by signing a nonce with the key from the storage file 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 15 / 32 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 16 / 32 SSH - Key material and its storage Authentication

Key handling features Kerberos SSH implementations support both GPG and X.509 standard Willing to reduce the number of passwords and still perform sound certificates for key storage seamlessly authentication, the Kerberos system was designed at MIT in late The keys of a user are typically stored in a directory within his home ’80s [1] directory on the system (~/.ssh on , pub keys ending in .pub) After refinement the fifth version of Kerberos became standardised in The stored keys are: RFC1510 which has been currently superseded by RFC4120 (drop the known keys, server keys which have been recognised as authentic from block cipher set single DES and add AES) the authorised keys to authenticate the user on the host at login the actual keypairs the user may employ when using the SSH client The Kerberos protocol authenticates users registered on a centralized authentication point and thus share with it a common secret Using Pluggable Authentication Modules (PAM) allows SSH implementations to use a smartcard, secure token or other delegates The whole authentication procedure is performed without the use of to perform authentication public key primitives and is thus very fast Secure tokens require the server to have a corresponding PAM module Kerberos is based on authentication proofs known as tickets requesting a signature to them

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

Authentication Authentication

Kerberos - Roles Kerberos - Authentication to AS The Kerberos protocol identifies the following roles: Client AS Client: it is the machine the user logs on, and the one the user Hash Password interfaces with to perform his tasks Cleartext Username Retrieve User Key Authentication Server (AS): it is the machine which stores the credentials of all users and takes care of performing the authentication Encrypt with Service Server (SS): It is a server which offers services upon Client/TGS Session Key Kerberos-based authentication (say, a remote shell) Encrypt with AS key The typical workflow of a user in a Kerberos authentication system is 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 split into three steps: client network address ticket validity period Client/TGS session key ticket validity period 1 Authentication to the AS Client/TGS session key

2 Request of a service authorization to the AS Client/TGS Session Key 3 Request of a service to a SS

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

Kerberos - Service Authorization Request to AS Kerberos - Service Request to SS

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

client ID Obtain and decrypt client network address client ID client network address ticket validity period Client ID ticket validity period Client/SS session key Timestamp Decrypt with Client/SS session key Decrypt with Client/SS Session Key Encrypt with Timestamp+1 Encrypt with Client/SS Session Key Timestamp+1 Client/SS Session Key Timestamp+1 and if correct start using service And obtain

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

Authentication Mixing Networks

Kerberos - Pros and Cons Anonymous network access Pro: The user needs to remember/type a single password Goal: provide anonymous access to contents via Internet Con: single point of failure for the authentication: the AS must First attempt: anonymizing proxies: a simple L5 proxy not performing always be available or the whole authentication mechanism freezes any caching and exposing his own identity (i.e. IP address) (usually coped with through keeping multiple AS as backups) Main issues: single point of failure, relies on the trustworthyness of Con: Due to the ticket timestamps, all the machines in the the actual anonymizing proxy authentication domain should be synchronizeda: this is usually coped Further attempts made: with through the use of the (cleartext, unauthenticated) Network Time Protocol to perform synchronizations First generation P2P mixing networks (e.g. Tarzan): everyone may either be a router or be an actual endpoint, traffic bounced around The password administration protocol is not standardised, although a High latency mixing networks (e.g. Babel, MixMaster): Seek to hide proposal is described in RFC3244 everything, including content fruition latencies, from an eavesdropper, encrypt fully the traffic, insert long artificial delays adefault configuration mandates a lag among them lesser than 5 minutes

G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 23 / 32 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 24 / 32 Second Generation Mixing networks Tor - Basics Tor: a low-latency, onion routing mixing network First generation mixing networks were trying to solve multiple problems (content anonymization, source anonymization, latency Tor actors hiding) with a single approach Relays: The actual nodes of the mixing network, they relay the In the light of the ideas and shortcomings of the first generation was information around, all communications among them are performed designed Tor [2] over TLS. They are typically known as Onion Relays (OR) Designed to be: Clients: A client connects to the Tor network via a so-called Onion Reliable in transport: Tor provides anonymization of TCP data flows Proxy (OP), sets up a circuit for communication choosing randomly Low latency: it should be possible to employ it for interactive workloads the relays it should pass through, and uses them to communicate with Easy to deploy: no modifications to the transport/network stack another endpoint, the target, outside the Tor Network Providing confidentiality and integrity of transmitted data Perfect forward secrecy: avoid issues with routers seized by malicious Exit point: A relay which agrees to act as the last relay of the entities communication and communicates with the target endpoint 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 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 26 / 32

Tor - Communication Tor - Communication

Tor communication principles Tor Circuit Setup (2 hops long for the sake of clarity) A circuit is a transport path in the Tor network, akin to a physical OP OR1 OR2 Tgt : it can be built or torn down by an OP Create [c1, RSA (gx)] Pick x pub-OR1 All Tor communications are on top of TLS (= contained as the Pick y, k1=(gx)y payload of a TLS connection) acting as blind “piping” Created [c1, gy, H(k1|"handshake")] First hop TLS performs only server authentication, no client authentication Relay [ c1, AESk1( Extend [OR2, RSApub-OR2(g x2)] ) Circuits are designed to be built telescopically, i.e. acknowledging Pick x2 x2 Create c2, RSApub-OR2(g ) each hop added to them: they need to be involving at least 3 relays Pick y2, k2=(gx2)y2 The basic transport unit in Tor is the cell: Created [c2, gy2, H(k2|"handshake")]

Relay [c1, AESk1(

control cells: they relay control messages for circuit setup and Second hop Extended gy2, H(k2|"handshake")] ) 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 Figure: c1,c2 cell IDs; commands in teletype font, cell content within [ ]

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

Tor Data Relay (2 hops circuit for the sake of clarity) Tor Circuit Characteristics Every OR knows the network identity of its neighbours only OP OR1 OR2 Tgt

Only the OP has full knowledge of the ORs involved in the circuit! Relay [c1, AESk1( Relay [c2, AESk2( Long term RSA OR public keys are made available to the OP via a Begin slashdot.org:80)] ) ] Relay [c2, AESk2( Begin set of trusted OR which act as key directories slashdot.org:80)] TCP Handshake They mantain a list of the active Tor ORs, together with their long Relay [c1, AESk1( Relay[c2, AESk2(Connected)] term public keys, thus acting as notaries Open Stream Relay [c2, AESk2(Connected)] ) ] Tor supports EC-Based asymmetric crypto for higher efficiency

Once a circuit is set up, it requires an active teardown procedure to Relay [c1, AESk1( be destroyed (akin to TCP Fin-Fin/Ack-Ack) Relay [c2, AESk2( Data, GET ... HTTP/1.1)] ) ] Relay [c2, AESk2( Data This allows to reuse the same circuit for more than a single TCP GET ... HTTP/1.1)] connection of the OP, to reduce latencies Data GET ... HTTP/1.1 Relay [c1, AESk1( ... The OP is the one in charge of asking for a circuit teardown Transmission Relay[c2, AESk2(Data, ...)] Relay [c2, AESk2(Data, ...)] ) ]

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

Tor - Communication BibliographyI

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 Clifford Neuman and Theodore Ts’o. Kerberos: An Authentication Service for Computer Networks. Each OR peels away a layer of the encryption, and executes the IEEE Communications 32 (9): 33-8, also available at http://gost.isi.edu/publications/kerberos-neuman-tso.html. command specified in the cell which he has just decrypted The Tor Project. Only the exit node knows the actual content of the transmission, Tor Protocol Specification. ://gitweb.torproject.org/torspec.git/tree/tor-spec.txt.

however he does not known who generated such content William Stallings. Protocol basics: Secure shell protocol - the internet protocol journal, volume 12, no.4. Note that Tor is not designed to solve user content confidentiality: https://www.cisco.com/c/en/us/about/press/internet-protocol-journal/back-issues/table-contents-46/ data exiting from the Tor network are not automatically encrypted 124-ssh.html. 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 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 32 / 32