Add "honor_server_ciphers" ssl context option to mitigate BEAST #490
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 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_server_ciphers"
, to mitigate BEAST vulnerabilities in encrypted stream servers.Suggested Usage
How Problematic Is This Really?
-- 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.