Skip to content

SSL

SSL

Manual SSL/TLS Checking with openssl

Console HTTPS Proxy
Server used to test SSL of a Client
Testing TLS/SSL encryption anywhere on any port
A tool for testing for certificate validation vulnerabilities of TLS connections made by a client device or an application.
SSL Handshake breakdown
How TLS 1.3 works
How TLS 1.2 works
See this page fetch itself, byte by byte, over TLS
Examine and validate Certificates
Generate Good SSL Configs

TLS

The key difference between TLS 1.0 and TLS 1.1 (at least with regard to IV handling) is how this IV is transmitted.
In TLS 1.0, the IV is actually considered a secret, and handled with the same care as the key; when both sides negotiate a key securely, they negotiate an IV at the same time.
For the remainder of the session, the CBC residue is the previous (encrypted) block.

Renegotiation attack

  1. The client connects to the attacker thinking its the server.
  2. The attacker pauses the client.
  3. The attacker makes a connection to the server with a request.
  4. The attacker makes a renegotiation request with the server.
  5. Server renegotiates with the attacker.
  6. The attacker sends the original request by the client to the server.
  7. The server is confused and thinks that the initial request from the attacker is the correct request and adds the header parameters to that request?

The main part of this is that the attacker sends the GET parameter. Then the attacker sends a non finished ignored HTTP Header. So when the client makes the connection the original GET request is added to the ignored header and not to the start of the request. This makes it so that the attacker controls the HTTP VERB and endpoint but uses the client headers including the cookie data.

GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 
X-Ignore-This: GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 
Cookie: victimscookie

Solution

  • Disable SSL 3.0

FREAK

Downgrades TLS Connection to RSA_EXPORT Cipher.
The RSA_EXPORT Cipher uses keys that use 512-bit encryption. These small primes can easily be crack.

Solution

  • Don't allow the RSA_EXPORT cipher

LogJam

For the Diffie-Hellman Key exchange a lot of the same 512 bit primes are being used.

Source

Solution

  • Generate your own 2048 DH
  • Don't use DH

BEAST

TLS 1.0 and previous uses CBC mode where the next message uses the previous ciphertext as the IV. Basically chaining the Messages together and not using a random IV.

By using the xor of the previous ciphertext of the block before the plain text we want to decode with the xor of the ciphertext of the previous block to our attack we can use it to guess the plaintext. We guess the plain text when we get the same cipher text as the encrypted version.

Using the Url as padding you can guess one character at a time if you are guessing a cookie with a known name.

Solution

  • Use TLS 1.1+
  • Dont use CBC on SSL3.0 or TLS 1.0

POODLE

When eve is in between a client and server they are able to force an TLS error. The Connection then will try to downgrade the protocol to SSL 3.0. Since SSL 3.0 has lower security protocols this makes it more vulnerable.

If the client still supports SSL 3.0 using a man-in-the-middle attack the TLS version can be downgraded to SSL 3.0. When the connection has been downgraded you can use other SSL 3.0 vulnerabilities like Lucky 13 and BEAST.

Solution

  • Dont use SSL 3.0

SWEET32

This attack is using the birthday paradox on 64-bit block size ciphers like Blowfish and 3DES

When a single connection using Blowfish and 3DES is monitored and contains 32GB of blocks it has reached the birthday bound for 64-bit block size. For comparison a 128-bit block size would need 256 EB of packet information.

Solution

DROWN

Is a padding oracle attack that attacks TLS by making a SSLv2 Request to the same server with the same private key. Using this an attacker can use the SSLv2 protocol and modify the ciphertext of the message you want to decrypt and can determine the difference in padding errors and decrypted data. This can be used to leak data about the secret keys.

Solution

  • Dont use SSL 2.0 with any private key

LUCKY13

TLS 1.1 and 1.2 use RC4 and AES in CBC mode. These implementation decrypts the message and then checks the padding first before checking authorization. This allows an attacker to differentiate the difference between a bad padding and an authorization error. This is somewhat mitigated by having encrypted error responses but this does leave timing attacks. Since it takes time to authenticate a message if it fails before then it is detectable.

Solution

  • Do not use CBC Block Chaining

CRIME

CRIME works on encrypted TLS connections. When compression on the HTTP protocol is enabled together it is done on the plain-text HTML data. This means that any change in the length means that there is a repeat information being replaced with compression.

By making requests using different parameters and checking the length of the response. You can match the pattern from the parameters to information in sensitive data like the cookie or other headers.

Example

Since the block size of the encryption is 8 bytes there needs to be a difference of 8 bytes to see any change in the size of the data.

To overcome this the URL can have padding which change which blocks are in which part and do it byte by byte.

Example of Blocks:

Block 1: Cookie test=s
Block 2: ecret

It would be easy to get the consents of the first block by adding the same block in a URL parameter.

To get the first character in block 2 we would be to decrease the padding by 1 which makes ookie test=se in the same block.
Since the all character other then the newest character is known to the attacker doing the same attack as before will work. This then will repeat for all remaining characters in the block.

Solution

  • Do not use the deflate compression with sensitive HTTP data

BREACH

CRIME attacks TLS layer compression
BREACH attacks HTTP layer compression

Solution

  • Do not use the deflate compression with sensitive TCP connections

ROBOT

A Padding Oracle attack on the RSA PKCS #1 v1.5 padding scheme.

Because there is a different Error on invalid padding then there is with invalid encryption an attacker can decrypt transmissions by playing with the padding and the data.

This can work because RSA has malleability in its encrypted data allowing the ability to multiply messages by any number to the public key power. This creates a valid message.

\[ \texttt{public\_key} = (e,n) \\ plaintext = m \\~\\ \begin{aligned} \texttt{cyphertext\_orig} & = Enc(m) \equiv m^e \pmod{n} \\ \texttt{cyphertext\_new} & = Enc(m) \cdot x^e \pmod{n} \\ & = (mx)^e \pmod{n} \\ & \equiv Enc(mx) \end{aligned} \]

Because RSA PKCS #1 v1.5 padding format is made up of the following blocks. It allows random data to reliably be interpreted as correct padding.

padded_message = "\x00\x02" + RANDOM_DATA + "\x00" + ORIGIONAL_MESSAGE
#then encrypt the padded message

The second is the tolerant nature of the RSA PKCS #1 v1.5 padding format that allows an attacker to create valid messages with a high probability.

Example

Source

Solution