Here at 31C3, Sebastian Schinzel just gave a presentation based on Revisiting SSL/TLS Implementations: New Bleichenbacher Side Channels and Attacks. The particular attack that caught my eye was the failure to generate a fake PMS before checking for bad padding, not after. Doing it afterwards exposes a timing difference of up to a few microseconds which can be measured over the network.

Of course, this depends on the OpenSSL RAND_pseudo_bytes function taking a measureable amount of time. In LibreSSL, we replaced the random number generator with arc4random which should be much faster. Time to measure. Thanks to benno for setting me up with a 5.5 test machine. (5.5 is the perfect release to test: new chacha20 arc4random, but still vanilla OpenSSL.)

#include <openssl/rand.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <machine/pctr.h>

int
main(int argc, char **argv)
{
        uint64_t before, after;
        int i;
        char buf[48];

        for (i = 0; i < 100; i++)
                RAND_pseudo_bytes(buf, sizeof(buf));
        before = rdtsc();
        for (i = 0; i < 10000; i++)
                RAND_pseudo_bytes(buf, sizeof(buf));
        after = rdtsc();
        printf("RAND_bytes duration: %f\n", (after - before) / 10000.0);
        for (i = 0; i < 100; i++)
                arc4random_buf(buf, sizeof(buf));
        before = rdtsc();
        for (i = 0; i < 10000; i++)
                arc4random_buf(buf, sizeof(buf));
        after = rdtsc();
        printf("arc4random duration: %f\n", (after - before) / 10000.0);
        return 0;
}

Results:

RAND_bytes duration: 24759.2385000
arc4random duration: 2376.2070000

10x faster. Not bad. That microsecond timing attack is now a nanosecond timing attack (albeit for larger values of nanosecond.)