[PATCH] SSL: guard use of all SSL options for bug workarounds
Richard Fussenegger, BSc
richard at fussenegger.info
Mon Sep 8 11:01:02 UTC 2014
Wouldn't it be better to drop support for ancient OpenSSL versions? It
would be a great step for performance and security. Are there any good
reasons to support old OpenSSL versions?
On 9/8/2014 10:06 AM, Piotr Sikora wrote:
> Hey Maxim,
>> After looking into http://trac.nginx.org/nginx/ticket/618,
>> I'm rather sceptical about BoringSSL-related fixes.
> To be fair, it was a regression that was fixed pretty fast once reported.
>> On the other hand, if they indeed remove something we use, it may
>> be a good enough reason to reconsider the use of the flags
> Most of the defines that they removed (SSL_OP_MICROSOFT_SESS_ID_BUG,
> SSL_OP_NETSCAPE_CHALLENGE_BUG, SSL_OP_SSLREF2_REUSE_CERT_TYPE_BUG and
> SSL_OP_MSIE_SSLV2_RSA_PADDING) were for options that were removed from
> BoringSSL along SSLv2 support.
> They also removed SSL_OP_TLS_BLOCK_PADDING_BUG, which was broken for a
> while and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS, which nginx uses to
> disable CBC 0/n record splitting, which they replaced with CBC 1/n-1
> record splitting that is not enabled by default (see my other patch).
> This, however, doesn't mean that those options aren't doing anything
> in OpenSSL (or LibreSSL, for that matter), especially when you insist
> on supporting ancient versions of OpenSSL, so I don't think that we
> should remove them from nginx.
> Best regards,
> Piotr Sikora
> nginx-devel mailing list
> nginx-devel at nginx.org
This email is free from viruses and malware because avast! Antivirus protection is active.
More information about the nginx-devel