Mitigating the BEAST TLS Vulnerability

The BEAST TLS attack vector was first publicized in 2011. Mitigating this attack is relatively simple: servers have only to prioritize ciphers that aren't susceptible to the attack. However, unless instructed otherwise, OpenSSL uses the client's preferences when negotiating the cipher. To prevent nefarious (or naive) clients from prioritizing susceptible ciphers servers must configure SSL sessions using OpenSSL's SSL_OP_CIPHER_SERVER_PREFERENCE context option.

Proposed Solution

This patch adds a new boolean ssl context option, "honor_cipher_order", to mitigate BEAST vulnerabilities in encrypted stream servers.

Suggested Usage

<?php
$bindTo = 'tls://127.0.0.1:12345';
$flags = STREAM_SERVER_BIND | STREAM_SERVER_LISTEN;
$ctx = stream_context_create(['ssl' => [
    'local_cert' => '/path/to/cert.pem',
    'ciphers' => '<place your ordered cipher list here>',
    'honor_cipher_order' => TRUE
]]);
$server = stream_socket_server($bindTo, $errNo, $errStr, $flags, $ctx);

How Problematic Is This Really?

The 2011 BEAST attack8 targets a 2004 vulnerability in TLS 1.0 and earlier protocol versions, previously thought to be impractical to exploit. For a period of time, server-side mitigation of the BEAST attack was considered appropriate, even though the weakness is on the client side. Unfortunately, to mitigate server-side requires RC4, which we now recommend to disable. Because of that, and because the BEAST attack is by now largely mitigated client-side, we no longer recommend server-side mitigation.

The impact of a successful BEAST attack is similar to that of session hijacking.

-- SSL Labs Best Practices Report (September 2013)

Other Considerations

It's not really possible to include tests for this functionality without adding new functions to retrieve the negotiated cipher from an encrypted socket stream. I don't generally feel like creating functions solely for use in testing things is a good idea, so there are no .phpt tests included. I may PR a new function to get meta information about the SSL session in the future, though. In such a case I'll go ahead and add tests for this scenario.