Tag Archives: SSL

TLS/SSL Vulnerabilities

“Which SSL ciphers should I disable?”

A client recently gave me a list of their supported ciphers and asked me which SSL ciphers they should disable – effectively looking for the most secure SSL ciphers they can use. Instead of the fast answer of “disable the insecure ones”, I thought I’d try and write up something useful.

So here’s a handy reference guide I’m working on. This has been time consuming to develop and no doubt will be added to over time. This isn’t intended to be read from start-to-finish, but is more of a handy SSL/TLS issue cheat-sheet.

Continue reading: TLS/SSL Vulnerabilities

CRIME against TLS?

Compression Ratio Info-leak Made Easy

CRIME is an attack against SSL, like Heartbleed, but it has a much smaller probability of exploitation. The authors of CRIME also wrote the BEAST attack. The attack can allow an attacker to recover web cookies and thereby perform session hijacking attacks, much like BEAST and the specific restrictions for the attack are similar. The attacker requires the ability to repeatedly inject predictable data whilst monitoring the resulting encrypted traffic. This requires the attacker to achieve two main prerequisites before the attack is possible: the attacker must be able to observe network traffic and manipulate the victim’s browser to submit requests to the target site.

The manipulation could be possible through Cross-site scripting attacks; JavaScript is not required and an attack could be possible with HTML Injection alone however it would be less efficient.

For CRIME to be possible the server must support compression of the request before encryption. TLS supports DEFLATE which is vulnerable, as is SPDY. The client must also support compression but only a small percentage of browsers do.

What is BEAST?

Browser Exploit Against SSL/TLS

BEAST is an attack against SSL/TLS which is the cryptographic system that protects data sent online. A practical attack was found to be possible against TLS v1.0 and SSLv3.0 (and below). The issue is that the Initialisation Vector (IV) utilised as part of the encryption process can be determined by an attacker. IVs are utilised to prevent encrypted data from being deterministic, they essentially make it harder for attackers to determine patterns in encrypted data. Without them if a repeating pattern is evident in the plaintext then it will be evident in the ciphertext and this type of informations is greatly useful to an attacker. IVs are designed to prevent this, however with the BEAST attack they are shown to be deterministic which greatly reduces their use as a protection mechanism.

It reduces the protection but the deterministic nature is of limited use to an attacker and they are only able to retrieve small amounts of information from the encrypted data, however with attacks against web applications small amounts of data can cause a large impact – if an attacker is able to retrieve information such as session tokens.

Continue reading: What is BEAST?



A vulnerability exists in outdated version of OpenSSL which allows an attacker to cause the server to disclose up to 64kb of server memory contents. This can cause secret keys, authentication tokens, usernames and passwords to be compromised. This can lead to an attacker being able to impersonate users and decrypt data transferred between a user and the server.

Continue reading: Heartbleed

HSTS: HTTP Strict Transport Security

HSTS is a web security mechanism to prevent downgrade attacks, it’s a mechanism that allows a web server to instruct web browsers to only communicate with the server over SSL, so that all subsequent traffic is encrypted, even if a user attempts to visit an insecure link (the browser will ‘correct’ the user and request the secure site instead).

Continue reading: HSTS: HTTP Strict Transport Security