# Bib on TLS attacks
###### tags: `bibliography`

[toc]

# Attack on record layer

## Lucky 13

### [Lucky Thirteen: Breaking the TLS and DTLS Record Protocols](https://www.ieee-security.org/TC/SP2013/papers/4977a526.pdf)
* 2013 IEEE S&P, by Nadhem J. AlFardan and Kenneth G. Paterson
* Can be combined with BEAST (CHECK)
* (D)TLS record protocol uses MAC-Encode-Encrypt (MEE): MAC, padding and encrypt.
* Exactly 13 bytes of header data are incoporated in the MAC calculation, hence the title.
* The TLS 1.1 and 1.2 RFCs recommend checking the MAC as if there was a zero-length pad. As noted in those RFCs: "This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size of the timing signal."
* In all version of TLS and DTLS, the padding consists of p +1 copies of some byte value p where 0<=p<=255. Examples are 00, 01 01, 02 02 02, etc (so not PCKS7?)
* Sequence number is not transmitted over the ire in TLS. But in DTLS, it is included as part of the record header.
* "For TLS, any error arising during decryption should be treated as fatal, meaning an encrypted error message is sent to the sender and the session terminated with all keys and other cryptographic material being disposed of. For DTLS, such errors may be rated non-fatal and the session would proceed to process the next ciphertext."
* In HMAC implementation, an 8-byte length field followed by padding of a specifiied byte format are appended to the message M to be hashed. The padding is at least 1 byte in length (what's the byte in padding?)
* Messages M of length up to 55 bytes can be encoded into a single 64-byte block, meanin that the first inner hash opereation in HMAC is done in 2 compression functions with 2 more being rqeuired for the outer hash operation, for a total of 4 compression functions.

# Attack on handshake

## Renegotiation attack

### Bulletproof TLS and PKI (2nd edition)
* First discovered by Marsh Ray in 2009, and independently discovered by Martin Rex in the same year.
* Addressed by using the Renegotiation indication extension in 2010.
* This attack allows an attacker to prepend arbitrary plaintext to the victim's request. For example, the injected data "GET ... X-Ignore: ".
>
GET /path/to/resource.jsp HTTP/1.0
X-Ignore: GET /index.jsp http/1.0
Cookie: JSESSIONID=B3DF4B07AE33CA7DF207651CDB42136A

* Attack not explained clearly in the book.

### TLS Renegotiation Vulnerability (IETF-76 meeting)
* By Joe Salowey and Eric Rescorla
* Discovered by Marsh Ray and Steve Dispensa of PhoneFactor in 08/2009 and Re-discovered by Martin Rex suring Channel Binding discussions on the TLS list 11/2009.
* Re-negotiation is a new handshake run under the protection of the existing channel; upon completion, the new channel replaces the old channel
* Slide 4 is brief, but describes the attack clearly.

### Renegotiating TLS (white paper 2009)
* By Marsh Ray and Steve Dispensa Nov 2009
* "In general, these problems allow an MITM to inject an arbitrary amount of chosen plaintext into the beginning of the application protocol stream, leading to avariety of abuse possibilities."
* Appendix gives a screenshot of a proof-of-concept attack (similar to the example code above using X-ignore)

### Transport Layer Security (TLS) Renegotiation Indication Extension (RFC 5746, Feb 2010)

* Describes a countermeasure to the renegotiation attack
* Add a new extension "renegotiation_info".
* The "extension data" field 1) is of zero length in both the ClientHello and the ServerHello if this is the initial handshake for a connection; 2) contains "client_verify_data" for ClientHellos that are renegotiating; 3) contains the concatenation of Client_verify_data and server_verify_data for ServerHellos that are renegotiating.