crypto/tls ciphers and protocol version supported

[guilhermebr]

By default crypto/tls use TLS1.0 as min_version protocol supported, and if not specified, all ciphers implemented in https://github.com/golang/go/blob/master/src/crypto/tls/cipher_suites.go#L75-L93

For compatibility maybe we can set min_version to SSL3, but accept both SSLv3 and TLS1.0 has security issues, like the POODLE attack (https://www.openssl.org/~bodo/ssl-poodle.pdf)

Accept all ciphers also have security problems. Mozilla opsec team recommends this configuration for Go crypto/tls: https://wiki.mozilla.org/Security/Server_Side_TLS#Go HTTP2 also has some ciphers in blacklist: https://github.com/bradfitz/http2/blob/b6255645465a25b25f804acb9b3a54009e80c2a4/server.go#L281-L302

The question here is: Caddy accept all ciphers and protocols by default, and turns this configurable in caddyfile, or assume the security position for users and don't accept weak ciphers and insecure protocols?

[guilhermebr]

My opnion:

By default: Secure i.e: min_version tls1.1 weak ciphers disabled

tls options:

tls cert key {
    protocols ssl3 tlsv1 tls11 tls12
    ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5
}

[mholt]

This is on the right track. The syntax you've proposed seems pretty good although the ciphers might be space-separated instead of colon-separated? Also, maybe the protocols could use a dot in the version, for readability? e.g. protocols ssl3 tls1.0 tls1.1 tls1.2 -- although I don't want to allow ssl3, see below.

The default behavior of Caddy must strike a good balance between compatibility and security. As such, I think we should first agree on some solid defaults. Here's what I've come up with so far.

• Session caching: Yes - this is already done thanks to your pull request
• SSLv3: No. I don't even think there's any good reason to allow a user to enable SSLv3.
• RC4: No. The RC4 ciphers are weak.

This should allow Caddy's default HTTPS configuration to score an A on SSL Labs' tests.

If we allow TLS 1.0, I don't think we should allow CBC mode ciphers with it. I need to see if TLS 1.2 is widely enough implemented in clients so that we can drop older TLS support too - at least, for default. So I think we need to do a little more research.

[guilhermebr]

Nice @mholt !

I agree about not support SSLv3, but my concern is with freedom of choice, if for some reason I need use SSLv3, maybe for a legacy device or a test case... I think user can have this choice... maybe we change the option name to something like unsecure_SSLv3, then user need to explicitly select the choice and are advised that this option is not secure...

some statistics:

from: https://jve.linuxwall.info/blog/index.php?post/TLS_Survey (11/2014)

Supported Protocols       Count     Percent
-------------------------+---------+-------
SSL2                      85447     18.9264
SSL2 Only                 38        0.0084
SSL3                      449864    99.6443
SSL3 Only                 4443      0.9841
TLS1                      446575    98.9158
TLS1 Only                 736       0.163
TLS1.1                    145266    32.1762
TLS1.1 Only               1         0.0002
TLS1.2                    149921    33.2073
TLS1.2 Only               5         0.0011
TLS1.2 but not 1.1        11888     2.6332

[guilhermebr]

tls cert key {
    protocols TLSv1 TLSv1.1 TLSv1.2
    ciphers AES128-SHA AES256-SHA DES-CBC3-SHA
    cache 128  #default cache capacity is 64
}

[mholt]

:100: That's super-useful, thank you.

Okay, perhaps we can allow the user to force SSLv3 by specifying it in the protocol list, for compatibility. But with a notice in the documentation that the cipher will be removed from Caddy in a future version. (In fact, any of the ciphers or protocols are subject to removal from Caddy at any time.)

You want to draft a PR?

[guilhermebr]

Perfect @mholt!

Sure! I'll send a PR soon as possible =]