[Pkg-openssl-devel] Bug#736287: ruby1.9.1: insecure SSL defaults (DES and unauthenticated ciphers)
Antonio Terceiro
terceiro at debian.org
Wed Jan 22 00:49:01 UTC 2014
Hello,
I am cc'ing the security team and openssl maintainers.
Dear security team and openssl maintainers, it would be really nice if
you could advice me on this issue.
On Tue, Jan 21, 2014 at 11:20:49PM +0000, brian m. carlson wrote:
> Package: ruby1.9.1
> Version: 1.9.3.484-1
> Severity: grave
> Tags: security
>
> Upstream bug 9424 [0] indicates that ruby has insecure SSL and TLS
> defaults. Using the gist linked to [1] in the bug report, I get the
> following output:
>
> vauxhall ok % /usr/bin/ruby1.9.1 howsmytls.rb
> {
> "given_cipher_suites": [
> "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
> "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
> "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384",
> "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
> "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
> "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",
> "TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA",
> "TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA",
> "TLS_DHE_DSS_WITH_AES_256_GCM_SHA384",
> "TLS_DHE_RSA_WITH_AES_256_GCM_SHA384",
> "TLS_DHE_RSA_WITH_AES_256_CBC_SHA256",
> "TLS_DHE_DSS_WITH_AES_256_CBC_SHA256",
> "TLS_DHE_RSA_WITH_AES_256_CBC_SHA",
> "TLS_DHE_DSS_WITH_AES_256_CBC_SHA",
> "TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA",
> "TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA",
> "TLS_ECDH_anon_WITH_AES_256_CBC_SHA",
> "TLS_SRP_SHA_WITH_AES_256_CBC_SHA",
> "TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384",
> "TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384",
> "TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384",
> "TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384",
> "TLS_ECDH_RSA_WITH_AES_256_CBC_SHA",
> "TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA",
> "TLS_RSA_WITH_AES_256_GCM_SHA384",
> "TLS_RSA_WITH_AES_256_CBC_SHA256",
> "TLS_RSA_WITH_AES_256_CBC_SHA",
> "TLS_RSA_WITH_CAMELLIA_256_CBC_SHA",
> "TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA",
> "TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA",
> "TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA",
> "TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA",
> "TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
> "TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA",
> "TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA",
> "TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA",
> "TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA",
> "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA",
> "TLS_RSA_WITH_3DES_EDE_CBC_SHA",
> "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
> "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
> "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
> "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA",
> "TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA",
> "TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA",
> "TLS_DHE_DSS_WITH_AES_128_GCM_SHA256",
> "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256",
> "TLS_DHE_RSA_WITH_AES_128_CBC_SHA256",
> "TLS_DHE_DSS_WITH_AES_128_CBC_SHA256",
> "TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
> "TLS_DHE_DSS_WITH_AES_128_CBC_SHA",
> "TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA",
> "TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA",
> "TLS_ECDH_anon_WITH_AES_128_CBC_SHA",
> "TLS_SRP_SHA_WITH_AES_128_CBC_SHA",
> "TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256",
> "TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256",
> "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256",
> "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256",
> "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA",
> "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA",
> "TLS_RSA_WITH_AES_128_GCM_SHA256",
> "TLS_RSA_WITH_AES_128_CBC_SHA256",
> "TLS_RSA_WITH_AES_128_CBC_SHA",
> "TLS_RSA_WITH_CAMELLIA_128_CBC_SHA",
> "TLS_DHE_RSA_WITH_SEED_CBC_SHA",
> "TLS_DHE_DSS_WITH_SEED_CBC_SHA",
> "TLS_RSA_WITH_SEED_CBC_SHA",
> "TLS_ECDHE_RSA_WITH_RC4_128_SHA",
> "TLS_ECDHE_ECDSA_WITH_RC4_128_SHA",
> "TLS_ECDH_anon_WITH_RC4_128_SHA",
> "TLS_ECDH_RSA_WITH_RC4_128_SHA",
> "TLS_ECDH_ECDSA_WITH_RC4_128_SHA",
> "TLS_RSA_WITH_RC4_128_SHA",
> "TLS_RSA_WITH_RC4_128_MD5",
> "TLS_DHE_RSA_WITH_DES_CBC_SHA",
> "TLS_DHE_DSS_WITH_DES_CBC_SHA",
> "TLS_RSA_WITH_DES_CBC_SHA",
> "TLS_EMPTY_RENEGOTIATION_INFO_SCSV"
> ],
> "ephemeral_keys_supported": true,
> "session_ticket_supported": true,
> "tls_compression_supported": false,
> "unknown_cipher_suite_supported": false,
> "beast_vuln": false,
> "able_to_detect_n_minus_one_splitting": false,
> "insecure_cipher_suites": {
> "TLS_DHE_DSS_WITH_DES_CBC_SHA": [
> "uses keys smaller than 128 bits in its encryption"
> ],
> "TLS_DHE_RSA_WITH_DES_CBC_SHA": [
> "uses keys smaller than 128 bits in its encryption"
> ],
> "TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA": [
> "is open to man-in-the-middle attacks because it does not authenticate the server"
> ],
> "TLS_ECDH_anon_WITH_AES_128_CBC_SHA": [
> "is open to man-in-the-middle attacks because it does not authenticate the server"
> ],
> "TLS_ECDH_anon_WITH_AES_256_CBC_SHA": [
> "is open to man-in-the-middle attacks because it does not authenticate the server"
> ],
> "TLS_ECDH_anon_WITH_RC4_128_SHA": [
> "is open to man-in-the-middle attacks because it does not authenticate the server"
> ],
> "TLS_RSA_WITH_DES_CBC_SHA": [
> "uses keys smaller than 128 bits in its encryption"
> ],
> "TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA": [
> "is open to man-in-the-middle attacks because it does not authenticate the server"
> ],
> "TLS_SRP_SHA_WITH_AES_128_CBC_SHA": [
> "is open to man-in-the-middle attacks because it does not authenticate the server"
> ],
> "TLS_SRP_SHA_WITH_AES_256_CBC_SHA": [
> "is open to man-in-the-middle attacks because it does not authenticate the server"
> ]
> },
> "tls_version": "TLS 1.2",
> "rating": "Bad"
> }
>
> Clearly, negotiating plain DES ciphers or ciphers without authentication
> by default is unacceptable. I have no opinion on SRP, since I don't
> know enough about it. Please patch this vulnerability. I will clone
> the bug to ruby2.0 once I get the bug number.
>
> [0] https://bugs.ruby-lang.org/issues/9424
> [1] https://gist.github.com/8302049.git
While this is fair enough, I tend to agree with Ruby upstream that if
this is a problem in openssl, it should be fixed there and not in every
SSL client that uses OpenSSL:
$ apt-cache rdepends libssl1.0.0 | wc -l
743
I am mostly clueless about SSL/TLS internals, but I suspect that if
those ciphers are known to be insecure and are still supported by
default, it is probably to keep compatibility with older servers out
there? If we drop these insecure ciphers, which fraction of existing
servers will not be interoperable with a secure SSL/TLS client?
--
Antonio Terceiro <terceiro at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-openssl-devel/attachments/20140121/ad83bde0/attachment.sig>
More information about the Pkg-openssl-devel
mailing list