[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SSL 3.0 and older ciphers selected in applications



On 08/12/14 11:12, Kurt Roeckx wrote:
> On Mon, Dec 08, 2014 at 09:16:45AM +0100, Daniel Pocock wrote:
>> Hi all,
>>
>> I've made some changes to TLS code in reSIProcate
>>
>> - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method()
> This has no effect in jessie.  SSLv2 and SSLv3 are disabled if you
> use the SSLv23_* methods.  The only way to enable SSLv3 is to use
> the SSLv3_* methods.  You should always use the SSLv23 method as
> those are the only that support more than 1 protocol version.

Can you please clarify that - if somebody explicitly calls
SSL_CTX_clear_options with SSL_OP_NO_SSLv3 will they get back support
for SSLv3 in SSLv23_method?

> I would love to see people stopping the SSLv3 methods, and they
> have been removed in experimental.  I'm also working on only
> having the SSLv23 method available.

In VoIP, this is not so trivial.  People have devices like IP phones and
ISDN gateways to use on their LAN.  Some of the older ones may not
support anything more than SSL v3 very well.

If these devices are used on a private VLAN then the risk of using old
crypto is not the same as the risk on the public Internet so I prefer to
give these people config options to support their hardware but disabled
by default.

Just one other point: if somebody is trying sending the client hello
using SSL v2 record layer but indicating support for TLS v1.0, should
TLSv1_method or SSLv23_method accept that?

There is an example of it here:
https://issues.asterisk.org/jira/browse/ASTERISK-13845

and it looks something like this:

Secure Sockets Layer
    SSLv2 Record Layer: Client Hello
        ...
        Version: TLS 1.0 (0x0301)
        ...

I've noticed that the reSIProcate code using TLSv1_method refuses to
accept connections from peers like that.

Should SSLv23_method support that even with v2 and v3 disabled?



Reply to: