Lecture 5 Transport Layer Security

What is the Secure Socket Layer (SSL)?

"TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery." SSL version 1.0 and 2.0 contained many security flaws that prompted a complete redesign of the protocol.

What are the three phases of a TLS 1.3 handshake?

- Key Exchange: Establish shared keying material and select the cryptographic parameters. Everything after this phase is encrypted. - Server Parameters: Establish other handshake parameters (whether the client is authenticated, application-layer protocol support, etc.). - Authentication: Authenticate the server (and, optionally, the client) and provide key confirmation and handshake integrity.

What is 0-RTT and 1-RTT?

0-RTT Handshakes (also known as "Zero-RTT ") is a TLS 1.3 TLS Handshake proposal when clients and servers share a PSK. Pre-Shared Key (PSK) is a Cryptographic Key that is shared between the parties before the session begins. The Pre-Shared Key may be referred to as a Shared Secret TLS 1.3 allows clients to send data on the first flight ("early data"). If you have connected to a TLS 1.3 server before you can immediately start sending encrypted data, like an HTTP request, without any round-trip at all, making TLS essentially zero overhead :) When a 1.3 client connects to a 1.3 server they agree on a resumption key (or PSK, pre-shared key), and the server gives the client a Session Ticket that will help it remember it. The Ticket can be an encrypted copy of the PSK — to avoid state — or a reference number. The next time the client connects, it sends the Session Ticket in the ClientHello and then immediately, without waiting for any round trip, sends the HTTP request encrypted with the PSK. The server figures out the PSK from the Session Ticket and uses that to decrypt the 0-RTT data. The client also sends a key share, so that client and server can switch to a new fresh key for the actual HTTP response and the rest of the connection.

Describe the TLS 1.3 handshake.

1 The client contacts the server and requests a secure connection. The server replies with the list of cipher suites — algorithmic toolkits of creating encrypted connections — that it knows how to use. The client compares this against its own list of supported cipher suites, selects one, and lets the server know that they'll both be using it. 2. The server then provides its digital certificate, an electronic document issued by a third-party authority confirming the server's identity. We'll discuss digital certificates in more detail in a moment, but for now the most important thing you need to know about them is that they contain the server's public cryptographic key. Once the client receives the certificate, it confirms the certificate's authenticity. 3. Using the server's public key, the client and server establish a session key that both will use for the rest of the session to encrypt communication. There are several techniques for doing this. The client may use the public key to encrypt a random number that's then sent to the server to decrypt, and both parties then use that number to establish the session key. Alternately, the two parties may use what's called a Diffie-Hellman key exchange to establish the session key.

What are cipher suites in TLS?

A cipher suite is a set of cryptographic algorithms. The schannel SSP implementation of the TLS/SSL protocols use algorithms from a cipher suite to create keys and encrypt information. A cipher suite specifies one algorithm for each of the following tasks: - Key exchange - Bulk encryption - Message authentication Key exchange algorithms protect information required to create shared keys. These algorithms are asymmetric (public key algorithms) and perform well for relatively small amounts of data. Bulk encryption algorithms encrypt messages exchanged between clients and servers. These algorithms are symmetric and perform well for large amounts of data. Message authentication algorithms generate message hashes and signatures that ensure the integrity of a message.

What are the two primary components of TLS?

A handshake protocol that authenticates the communicating parties, negotiates cryptographic modes and parameters, and establishes shared keying material. The handshake protocol is designed to resist tampering; an active attacker should not be able to force the peers to negotiate different parameters than they would if the connection were not under attack. A record protocol that uses the parameters established by the handshake protocol to protect traffic between the communicating peers. The record protocol divides traffic up into a series of records, each of which is independently protected using the traffic keys.

What are the three mandatory cipher suites?

Authenticated encryption with additional data (AEAD): • TLS_AES_128_GCM_SHA256 (must implement) • TLS_AES_256_GCM_SHA384 (should implement) • TLS_CHACHA20_POLY1305_SHA256 (should imp.) Digital signatures: • RSA (with SHA256) • ECDSA (with SHA256)

Renegotiation, where the handshake process is repeated to perform renegotiation, is forbidden in TLS 1.3. Why?

Because there is no secure binding between the initial handshake and the renegotiation, applications that don't differentiate between the initial and later traffic (time-of-check vs. time-of-use) may be vulnerable to a type of restricted MitM attack. In a TLS Renego MITM attack, an adversary makes a TLS connection that was first attempted by a legitimate client. The attacker can either establish the connection before the client does, or effectuate the attack using session renegotiation. Mutual certificate-based client authentication connections are unfortunately not immune. The most glaringly nonsensical conceptual flaw was evident in SSL v2. The MITM attacker could simply create a false termination message, splice into the SSL session, and deceive the parties into thinking their communication was still "secure".

The Change Cipher Spec Protocol is used to signal a switch from the current to the pending connection state. Explain it!

ChangeCipherSpec messages are used in SSL to indicate, that the communication is shifted from unencrypted to encrypted. This message informs that, the data following will be encrypted with the shared secret. Or in other words, you can say that, this message is used to tell the other party(Server & Client), that the negotiated secret key and cipher suite will be used for the current communication now onwards. • Not used in TLS 1.3 by default, but may be used to provide backward compatibility with middleboxes • Consists of a fixed one byte message

In TLS 1.2 a session may be shared by multiple connections, thereby avoiding the overhead of establishing each connection from scratch. How does this work?

Connection - A transient, application-to-application, communication channel - Associated with one session Session - An association between client & server - Created by the Handshake Protocol - May be shared by multiple connection

While TLS is dependent on a reliable transport to ensure that records are not lost or re-ordered, DTLS is insensitive to re-ordering or loss of records. How is this possible?

DTLS achieves this by: • Not allowing stream ciphers so that records can be decrypted independently • Including explicit sequence numbers in the records - TLS only include implicit sequence numbers in the MAC (to provide replay and re-ordering protection)

What is DTLS replay detection?

DTLS optionally supports replay detection using a sliding window mechanism (as in IPsec) 1. If the sequence number is lower than the left edge of the window, the record is discarded 2.If the sequence number falls within the window and is already marked as received, the record is discarded 3. If the MAC verification fails, the record is discarded 4. If the MAC verifies, the sequence number is higher than the right edge of the window, or falls within the window and is not marked as received, the window is updated You have a lowest acceptable sequence number and a highest sequence number received so far.

How does DTLS provide reliability for the handshake protocol?

DTLS use timeouts and retransmissions to provide reliability for the Handshake Protocol

What is the Datagram Transport Layer Security (DTLS)?

Datagram Transport Layer Security (DTLS) is based on TLS but does not require reliable or in-order delivery. Datagram Transport Layer Security (DTLS) is a communications protocol designed to protect data privacy and preventing eavesdropping and tampering. It is based off the Transport Layer Security (TLS) protocol, which is a protocol that provides security to computer-based communications networks. The main difference between DTSL and TLS is that DTLS uses UDP and TLS uses TCP. It is used across web browsing, mail, instant messaging and VoIP. To enable reuse and reduce the risk of introducing new vulnerabilities, DTLS is only different from TLS where required.

What is the TLS Handshake protocol?

Enables the client and server to authenticate each other and select a encryption algorithm prior to sending the data. The cryptographic parameters used by the secure channel are produced by the TLS handshake protocol. This sub-protocol of TLS is used by the client and server when first communicating with each other. The handshake protocol allows peers to negotiate a protocol version, select cryptographic algorithms, optionally authenticate each other, and establish shared secret keying material. Once the handshake is complete, the peers use the established keys to protect the application-layer traffic. A failure of the handshake or other protocol error triggers the termination of the connection, optionally preceded by an alert message.

What is HTTP over SSL (HTTPS)?

HTTPS (HTTP over SSL or HTTP Secure) is the use of Secure Socket Layer (SSL) or Transport Layer Security (TLS) as a sublayer under regular HTTP application layering. HTTPS encrypts and decrypts user page requests as well as the pages that are returned by the Web server. The use of HTTPS protects against eavesdropping and man-in-the-middle attacks. Suppose you visit a Web site to view their online catalog. When you're ready to order, you will be given a Web page order form with a Uniform Resource Locator (URL) that starts with https://. When you click "Send," to send the page back to the catalog retailer, your browser's HTTPS layer will encrypt it. The acknowledgement you receive from the server will also travel in encrypted form, arrive with an https:// URL, and be decrypted for you by your browser's HTTPS sublayer. Protects - URL, document contents, form data, cookies, HTTP headers

What is the Heartbleed bug?

Heartbleed is a bug that affects the OpenSSL service, which is a cryptographic library that's used to encrypt data on more than two-thirds of all the websites on the Internet. If you've ever seen that locked padlock logo in your browser, or visited a site using the https: protocol, then you're familiar with OpenSSL. The Heartbleed bug exposes data held in a server's RAM, meaning just about anyone has access to, and can snoop on Internet traffic, even when it's supposedly encrypted. Interlopers, if any, could take advantage of Heartbleed to obtain the keys and data that they'd need to decipher and read all the encrypted data that recently passed through a server.

Why is TLS negation a problem?

Negotiation provides flexibility to meet different and future requirements, but also increases complexity. Makes the protocol more difficult to fully understand/verify - E.g., renegotiation vulnerability first discovered after many years Some negotiated sessions provide minimal security - E.g., no authentication, weak certificate chains, no confidentiality protection ... especially in - May down grade to previous weaker version (if allowed by configuration)

What is Perfect Forward Secrecy (PFS)?

PFS is an encryption style known for producing temporary private key exchanges between clients and servers. For every individual session initiated by a user, a unique session key is generated. If one of these session keys is compromised, data from any other session will not be affected. Therefore, past sessions and the information within them are protected from any future attacks. 1. Eaves dropper records conversation 2. Later gains access to the (long term) secret 3. If it is still impossible for the eavesdropper to decrypt the conversation, the protocol is said to provide PFS - Also provides protection against passive attackers after the long term key has been compromised Supported in TLS through ephemeral Diffie-Hellmann (DHE), i.e., where the DH parameters are signed with a certificate so that the parameters can be changed each time

How does DTLS protect against DoS attacks?

Since a datagram can be sent "as is", it is subject to IP spoofing: an evildoer can send a datagram with a fake source address. In particular a ClientHello message. If the DTLS server allocates resources when it receives a ClientHello, then there is ample room for DoS. In the case of TLS, a ClientHello occurs only after the three-way handshake of TCP is completed, which implies that the client uses a source IP address that it can actually receive. Being able to DoS a server without showing your real IP is a powerful weapon; hence DTLS includes an optional defense. The defensive mechanism in DTLS is a "cookie": the client sends its ClientHello, to which the server responds with an HelloVerifyRequest message which contains an opaque cookie, which the client must send back as a second ClientHello. The server should arrange for a type of cookie which can be verified without storing state; i.e. a cookie with a time stamp and a MAC. This cookie mechanism is really an emulation of the TCP three-way handshake. It implies one extra roundtrip, i.e. brings DTLS back to TLS-over-TCP performance for the initial handshake. Cookie = HMAC(Secret, Client-IP, Client-Parameters)

The Handshake Protocol is initiated when a client creates a connection to a server. Describe the TLS 1.2 session establishment.

Step 1: The entire connection/handshake begins with the client sending a "client hello" message to the server. This message consists of cryptographic information such as supported protocols and supported CipherSuites. It's also comprised of a random value or random byte string. Step 2: In response to the client's "client hello" message, server responds with "server hello" message. This message includes the CipherSuite that the server has chosen out of the ones offered by the client. The server also sends its certificate along with the session ID and another random value. Step 3: Now the client verifies the certificate sent by the server. Once the verification is done, it sends a random byte string, also called "pre-master secret," and encrypts it using the public key of server's certificate. Step 4: Once the server receives the pre-master secret, the client, and server both generate a master key along with session keys (ephemeral keys). These session keys will be used to symmetrically encrypt the data. Step 5: Now the client sends a "Change Cipher Spec" message to the server to let it know that it's going to switch to symmetric encryption with the help of session keys. Along with it, it also sends "Client Finished" message. Step 6: In reply to the client's "Change Cipher Spec" message, the server does the same and switches its security state to symmetric encryption. The server concludes the handshake by sending "server finished" message.

What is TLS?

TLS (Transport Layer Security) is just an updated, more secure, version of SSL. TLS resides at, or arguably on top of, the transport layer. TLS is a cryptographic protocol that provides end-to-end communications security over networks and is widely used for internet communications and online transactions. It is an IETF standard intended to prevent eavesdropping, tampering and message forgery. Common applications that employ TLS include Web browsers, instant messaging, e-mail and voice over IP. TLS is more efficient and secure than SSL as it has stronger message authentication, key-material generation and other encryption algorithms. For example, TLS supports pre-shared keys, secure remote passwords, elliptical-curve keys and Kerberos whereas SSL does not. TLS and SSL are not interoperable, but TLS does offer backward compatibility for older devices still using SSL.

What is the Alert Protocol?

The Alert Protocol is used to convey TLS related alerts to the peer entity. The primary use of this protocol is to report the cause of failure. Status changes include such things as error condition like invalid message received or message cannot be decrypted, as well as things like the connection has closed. Close notify: Notifies the recipient that the sender will not send any more messages on this connection to prevent truncation attacks Error alerts: - Fatal: the connection is closed upon transmission/receipt. In TLS 1.3 all error alerts are fatal - Warning: the connection can generally continue, if this is not acceptable the receiver should sent a fatal alert (e.g., alerts related to certificate verification problems)

What is the primary goal of TLS and what three properties should it provide?

The primary goal of TLS is to provide a secure channel between two communicating peers; the only requirement from the underlying transport is a reliable, in-order data stream. Specifically, the secure channel should provide the following properties: - Authentication: The server side of the channel is always authenticated; the client side is optionally authenticated. Authentication can happen via asymmetric cryptography or PSK. - Confidentiality: Data sent over the channel after establishment is only visible to the endpoints. TLS does not hide the length of the data it transmits, though endpoints are able to pad TLS records in order to obscure lengths and improve protection against traffic analysis techniques. Uses symmetric encryption. - Integrity: Data sent over the channel after establishment cannot be modified by attackers without detection. Used HMAC before TLS 1.3 These properties should be true even in the face of an attacker who has complete control of the network.

What is the TLS record Protocol (integrity)?

The record protocol is the secure communications provider. Its purpose is to encrypt, and authenticate packets. The record layer functions can be called at any time after the handshake process is finished, when there is need to receive or send data. Data is fragmented, compressed and then used to comprise an HMAC. The Mac is then added to the compressed data one with padding. It is then encrypted. Compression and HMAC was removed in TLS 1.3

How does TLS work?

There are three main components to TLS: Encryption, Authentication, and Integrity. - Encryption: hides the data being transferred from third parties. - Authentication: ensures that the parties exchanging information are who they claim to be. - Integrity: verifies that the data has not been forged or tampered with. A TLS connection is initiated using a sequence known as the TLS handshake. The TLS handshake starts with a syn/syn ack/ack exchange similar to the one used in TCP, and then establishes a cypher suite for each communication. The cypher suite is a set of algorithms that specifies details such as which shared encryption key will be used for that particular session. TLS is able to set the matching encryption keys over an unencrypted channel thanks to a technology known as public key cryptography. The handshake also handles authentication, which usually consists of the server proving its identity to the client. This is done using public keys. Public keys are encryption keys that use one-way encryption, meaning that anyone can unscramble the key to ensure its authenticity, but only the original sender can generate the key. Once data is encrypted and authenticated, it is then signed with a message authentication code (MAC). The recipient can then verify the MAC to ensure the integrity of the data. This is kind of like the tamper-proof foil found on a bottle of aspirin; the consumer knows no one has tampered with their medicine because the foil is intact when they purchase it.

What is the TLS key exchange?

There are three ways of doing a key exchange: RSA: Client generates 48-byte premasterSecret and sends it encrypted with the servers public key in ClientKeyExchange. Not used in 1.3. EC) Diffie-Hellman: Client/server has the following alternatives: - Send certificate containing the public DH parameters (not used in 1.3) - Send public values in (unsigned) key exchange messages. Anonymous DH-vulnerable to MitM. (not used in 1.3) - Server sends signed DH public value, client sends its public value (and optionally authenticates using CertificateVerify) - DH ephemeral Pre-Shared Key (PSK) - Established out of band or through previous connection - Can be used with (EC)DHE to provide PFS PSK is a set of cryptographic protocols that provide secure communication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys shared in advance among the communicating parties.

RFC7525 is a recommendation for using TLS. What are the points?

• Never use/support SSL. (D)TLS 1.2 should be used. • Use strict TLS (to protect against TLS stripping) • TLS compression should be disabled (to protect against compression attacks) • Use a cipher suite with forward secrecy (i.e., ephemeral DH using at least 2048-bit keys), AES-GCM 128/256, and SHA 256/384 • The host name and certificate path must both be properly validated

TLS resides on top of the transport layer. What implication does it have?

• Not dependent on being implemented within OS stack → Widespread deployment, many implementations • Applications must use TLS API instead of TCP API → Not transparent to applications • The underlying reliable transport makes TLS simpler • Lower layer protocols (IP, TCP) are not protected

What are some differences between TLS 1.2 and 1.3?

• Static RSA and DH have been removed - all public-key based key exchange now provide PFS • All data following the initial hello messages are encrypted • A 1-RTT mode for establishing new connections • A 0-RTT mode when resuming previous connections - should not be used by default due to weaker securirty • Session renegotiation is prohibited, except that the server may request client authentication at any time - authentication binds to initialization handshake

Consider both TLS and DTLS. Which would you use?

• TLS is relatively easy to utilize, but its apparent simplicity can be deceptive - E.g., easy to create insecure configurations or implementations, especially in previous versions - Depends on certificates for authentication - must be properly validated • The newer versions are generally more secure • DTLS is a good alternative for applications not requiring a reliable transport

An implication of utilizing TCP for providing a reliable transport is that the connection must be broken if the TLS message authentication fails. How does this work?

• There is no way for TLS to make TCP retransmit the segment • TCP only provides a non-cryptographic checksum that can be easily bypassed by an attacker • Means a TLS connection can be broken by modifying (or inserting) a single packet