The Factoring Dead: Preparing for the Cryptopocalypse
by Alex Stamos, Tom Ritter, Thomas Ptacek and Javed Samuel
This presentation looked into the recent leaps in solving discrete logarithm problem (DLP) by Joux et al. It was suggested there is a small but real chance that both RSA and Diffie-Hellman will soon become unusable.
Nevertheless, the presenters recommended deploying elliptic curve cryptography (ECC) so that we’ll be able to transition away from RSA quickly in the event of a mathematical breakthrough.
It was recommended to move to stronger cryptosystems supporting ECC, such as TLS 1.2, which includes ECC cipher suites.
TLS “Secrets”: What everyone forgot to tell you…
by Florent Daigniere, Matta Consulting Ltd
TLS Secrets focused on RFC 5077 TLS session tickets. Session tickets allow a server to perform TLS session resumption without having to store any state, or pass state, between load-balanced machines. Instead of storing session keys, the server sends to the client an encrypted and authenticated blob containing the session keys. The client returns the blob to the server upon subsequent connections, allowing the server to resume the session without having to remember the session keys.
RFC 5077 is not clear on how the server should manage the keys it uses to encrypt and authenticate the session blobs. OpenSSL has implemented the RFC in a way that reduces the security of TLS in two ways:
- It encrypts the session keys with a 128-bit key, even if the strength of the cipher suite in use is stronger (e.g., 256 bits). This reduces the strength of all cipher suites to just 128 bits.
- The server will continue to use the same blob encryption key as long as it runs (which could be years). If this key is compromised, then all TLS sessions whose blobs were encrypted with it can be decrypted, even if they were established with ciphers providing Perfect Forward Secrecy (PFS), which are meant to protect against key compromises.
To correct these problems, the server’s encryption algorithm should be at least as strong as the strongest supported cipher suite, and the lifetime of the keys should be shortened to be no longer than the perfect forward secrecy time window (typically hours).
The presenter argued that session tickets are really only needed in a couple very specific (and unusual) scenarios, and so in nearly all cases they should be disabled. They are enabled by default in OpenSSL.
Truncating TLS Connections to Violate Assumptions in Web Applications
by Ben Smyth & Alfredo Pironti, INRIA
This presentation looked at the behavior of Web browsers in the event of a fatal TLS connection closure (as opposed to a graceful connection closure, the normal case). In the case of a graceful connection closure, all data transmitted by one TLS endpoint is guaranteed to have been received by the other endpoint. When a fatal connection closure occurs the only guarantee is that the received data is a prefix of what was transmitted. Unfortunately, Web browsers do not distinguish between these two cases.
If Web developers are not careful about how they present the results of transactions to the user, then it is possible for a man-in-the-middle attacker to cause the user and the application to have different views about transaction state. Three examples of insecure logout transactions were provided (in the Helios electronic voting system, Microsoft Live accounts and Google accounts).
In all three cases, the victim, assumed to be using a shared computer, would click the “logout” button, the man-in-the-middle attacker would block a carefully chosen TLS packet, and the victim would be presented with a success page indicating that they were logged out, even though the dropped TLS packet caused the logout transaction to fail.
The attacker could then sit down at the shared machine and access the victim’s account. The vulnerable Web applications need to change their behavior so that the success page is only displayed after the logout procedure succeeds.
SSL, Gone in 30 Seconds: A BREACH Beyond CRIME
by Yoel Gluck, Neal Harris & Angelo Prado
BREACH is an extension of last year’s CRIME attack that allowed a man-in-the-middle attacker to extract session cookies from TLS-protected sessions by using data compression to form a cryptographic side channel. While CRIME exploited the communication from browser to server, BREACH turns the attack around and extracts data from the server’s compressed responses back to the client.
For the attack to work, the server must be using HTTP response compression (e.g., DEFLATE), and it must have a page that contains a secret (such as a CSRF token) and reflects a user-supplied value back in the response. All three of these conditions are common, so it is likely that many applications are vulnerable. In a successful attack, the attacker learns the secret.
The presenters demonstrated an attack against Outlook Web App (OWA) that was able to extract a CSRF token by making about 1120 requests to the server. It subsequently used the CSRF token to add a forwarding rule to forward all the user’s incoming messages to the attacker.
C.R.E.A.M.: Cache Rules Evidently Ambiguous, Misunderstood
by Jacob Thompson, Independent Security Evaluators
Over the years, Web browsers have changed the way they handle caching of HTTPS sessions. It used to be that many Web browsers refused to cache anything received over an HTTPS connection, but this is no longer the case in modern browsers.
When presenting sensitive information, websites must send valid cache control headers to prevent Web browsers from writing that information out to disk. It turns out that many prominent websites do not do so: the presenter showed many such examples. For instance, pay statements from ADP (including social security numbers) and credit reports from Equifax (including account numbers) both found their way into the browsers’ disk caches.
To cover all browsers, the presenter recommended using the following cache control headers:
A demonstration page is available, which visitors can use to test how their browser responds to various cache control headers.