Re: [reSIProcate] reviewing TLS version code
I've made some changes to this code today
- SSL_OP_NO_SSL3 is now set by default in the stack
- SSLv23 is now default for repro (no longer TLSv1)
- reSIProcate and repro now have configuration options for the OpenSSL
method (TLSv1 or SSLv23), setting the OpenSSL option flags (which can be
conveniently entered as strings) and customizing the cipher list
The nmap output for the new defaults is attached - notice that despite
the fact the stack is now using SSLv23_method(), it does not mention SSL
v3 in the output but it does now show additional TLS versions 1.1 and 1.2.
On 06/12/14 19:36, Daniel Pocock wrote:
>
>
> There are some issues around how the TLS version is chosen.
>
> reSIProcate (the library) offers a choice between using OpenSSL
> SSLv23_method() and TLSv1_method(). These are described in the OpenSSL
> docs[1].
>
> repro, the proxy, has simply been using TLSv1_method(). I've just added
> a configuration option to allow users to select SSLv23_method(),
> although TLSv1_method is still default.
>
> Some people may be thinking that is bad news, with SSLv2 being
> considered dangerous and SSLv3 now being shunned as well thanks to the
> POODLE[2] exploit.
>
> Looking closely at the OpenSSL docs, it says that SSLv23_method "may
> understand the SSLv2, SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols".
> "may" meaning it is not definitely exposing the system to SSLv2 and
> SSLv3. In practice, most recent OpenSSL builds don't have SSLv2 support
> at all and there are other options to disable SSLv3 at runtime.
>
> What SSLv23_method does actually do is to allow a dynamic choice of TLS
> version.
>
> If TLSv1_method() is used (as hardcoded in repro right now) then that
> means ONLY TLS v1.0 and not v1.1 or v1.2 or beyond.
>
> On the other handing,
> - using SSLv23_method allows any the TLS versions (1.0, 1.1 and 1.2)
> - using SSLv23_method does not enable SSLv2 if the OpenSSL binary was
> not compiled with SSLv2 support or if SSL_OP_NO_SSL2 is used
> - using SSLv23_method and setting SSL_OP_NO_SSL3 eliminates SSLv3
> support and the POODLE risk while allowing a dynamic choice of TLS v1.0,
> v1.1 or v1.2
>
> To summarize, SSLv23_method with SSL_OP_NO_SSL3 may be better for
> compatibility. The only question is
>
> a) how to implement this in reSIProcate while still allowing users of
> the stack some flexibility to override
>
> b) how to do this in a way that ensures ABI compatibility. Not only
> would I like to backport the change to v1.9.x but there may be more
> vulnerabilities in future where changes to this code have to be
> backported without breaking ABI.
>
> As a side-issue, I found that manually adding SSLv3 to
> BaseSecurity::ExportableSuite increases the number of possible ciphers
> and while I wouldn't recommend using some of them, I can understand that
> some users of the stack may also want an easy way to enable them in
> certain situations.
>
> I ran nmap against repro to show what it understands and I attach the
> output for each of these permutations:
>
> a) TLSv1_method with SSLv3 in ExportableSuite
> b) SSLv23_method with SSLv3 in ExportableSuite
> c) SSLv23_method without SSLv3 in ExportableSuite
>
> In particular, notice that the SSLv23_method output files all include
> TLS v1.1 and v1.2 while the TLSv1 output doesn't show that.
>
>
> 1. https://www.openssl.org/docs/ssl/SSL_CTX_new.html
>
> 2. https://www.us-cert.gov/ncas/alerts/TA14-290A
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
$ nmap --script ssl-enum-ciphers 195.8.117.56 -p 5061
Starting Nmap 6.00 ( http://nmap.org ) at 2014-12-07 16:53 CET
Nmap scan report for 195.8.117.56
Host is up (0.027s latency).
PORT STATE SERVICE
5061/tcp open sip-tls
| ssl-enum-ciphers:
| TLSv1.0
| Ciphers (6)
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - unknown strength
| TLS_RSA_WITH_DES_CBC_SHA - unknown strength
| TLS_RSA_WITH_RC4_128_MD5 - unknown strength
| TLS_RSA_WITH_RC4_128_SHA - strong
| Compressors (1)
| NULL
| TLSv1.1
| Ciphers (6)
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - unknown strength
| TLS_RSA_WITH_DES_CBC_SHA - unknown strength
| TLS_RSA_WITH_RC4_128_MD5 - unknown strength
| TLS_RSA_WITH_RC4_128_SHA - strong
| Compressors (1)
| NULL
| TLSv1.2
| Ciphers (10)
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - unknown strength
| TLS_RSA_WITH_AES_256_CBC_SHA256 - unknown strength
| TLS_RSA_WITH_AES_256_GCM_SHA384 - unknown strength
| TLS_RSA_WITH_DES_CBC_SHA - unknown strength
| TLS_RSA_WITH_RC4_128_MD5 - unknown strength
| TLS_RSA_WITH_RC4_128_SHA - strong
| Compressors (1)
| NULL
|_ Least strength = unknown strength
Nmap done: 1 IP address (1 host up) scanned in 52.20 seconds