Default TLS implementations leave consuming systems open to multiple vulnerabilities.

[huornlmj]

The default implementation for TLS endpoints expose the long deprecated TLS 1.0 and TLS 1.1 versions along with dangerous ciphers that expose systems to version downgrade attacks, SWEET32 (CVE-2016-2183, CVE-2016-6329), BEAST (CVE-2011-3389), LUCKY13 (CVE-2013-0169). There should be a way for consumers to control which versions and ciphers are exposed.

This was confirmed with a default endpoint and tested with version 3.0.4 of testssl.sh.

[alvaroaleman]

Please specify what TLS endpoints exactly you are referring to.

Generally, tls clients can be configured to (not) accept a given TLS version and ciphers so I don't really see this as a problem here.

[huornlmj]

This is to do with webhook servers that are provisioned rather than clients. Here's a listening TLS webhook's testssl.sh report (portions):

 Testing protocols via sockets except NPN+ALPN 

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      offered (deprecated)
 TLS 1.1    offered (deprecated)
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): final
 NPN/SPDY   h2 (advertised)
 ALPN/HTTP2 h2 (offered)

And

 Testing vulnerabilities 

 Heartbleed (CVE-2014-0160)                not vulnerable (OK), no heartbeat extension
 CCS (CVE-2014-0224)                       not vulnerable (OK)
 Ticketbleed (CVE-2016-9244), experiment.  not vulnerable (OK), reply empty
 ROBOT                                     not vulnerable (OK)
 Secure Renegotiation (RFC 5746)           supported (OK)
 Secure Client-Initiated Renegotiation     not vulnerable (OK)
 CRIME, TLS (CVE-2012-4929)                not vulnerable (OK)
 BREACH (CVE-2013-3587)                    no HTTP compression (OK)  - only supplied "/" tested
 POODLE, SSL (CVE-2014-3566)               not vulnerable (OK), no SSLv3 support
 TLS_FALLBACK_SCSV (RFC 7507)              Downgrade attack prevention supported (OK)
 SWEET32 (CVE-2016-2183, CVE-2016-6329)    VULNERABLE, uses 64 bit block ciphers
 FREAK (CVE-2015-0204)                     not vulnerable (OK)
 DROWN (CVE-2016-0800, CVE-2016-0703)      not vulnerable on this host and port (OK)
                                           make sure you don't use this certificate elsewhere with SSLv2 enabled services
                                           https://censys.io/ipv4?q=55C6D7ECA3EACF7A02B79CCD69A5C57BB848A4A8029A2E5AE27AED5B5EF52429 could help you to find out
 LOGJAM (CVE-2015-4000), experimental      not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with <= TLS 1.2
 BEAST (CVE-2011-3389)                     TLS1: ECDHE-RSA-AES256-SHA AES256-SHA ECDHE-RSA-AES128-SHA AES128-SHA ECDHE-RSA-DES-CBC3-SHA DES-CBC3-SHA 
                                           VULNERABLE -- but also supports higher protocols  TLSv1.1 TLSv1.2 (likely mitigated)
 LUCKY13 (CVE-2013-0169), experimental     potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS. Check patches
 RC4 (CVE-2013-2566, CVE-2015-2808)        no RC4 ciphers detected (OK)

[coderanger]

Low impact but would be nice to clean up. If you would be interested in tackling this, the TLS config is here

controller-runtime/pkg/webhook/server.go

Lines 195 to 198 in 82c68b9

	cfg := &tls.Config{
	NextProtos: []string{"h2"},
	GetCertificate: certWatcher.GetCertificate,
	}

. Would just need to work out the right args to get a slightly newer session :) (and also confirm support with kube-apiserver back as far as controller-runtime itself supports)

[alvaroaleman]

My point is: You can just configure your client to not accept certain tls versions and/or ciphers. A tls connection always has two participating parties that both need to accept a given tls version and cipher.

[coderanger]

The only client we care about for the webhooks system is kube-apiserver, which we don't control directly though if it also needs TLS improvements I'm sure k/k would be happy for those too :)

[huornlmj]

If the client can control which cipher and TLS version is used then the server is not controlling it resulting in a vulnerable connection. In this case a client can propose a weak or deprecated cipher and version in the TLS handshake and the server will support it and allow it to happen. I have not prepared a POC exploit purely because it's been done quite some time ago to explain the weaknesses in TLS 1.0 and TLS 1.1 and the weak ciphers mentioned. I'm more a security researcher than a coder which is why I'm not providing a fix, just reporting the issue.

[coderanger]

@huornlmj I think you may misunderstand how this code works. Thank you for your report however these are special purpose endpoints and not used for general HTTP for arbitrary clients. If you would like to confirm the vulnerability, you would need to specifically check the client settings on the k/k side. That said, we should fix the easy ones since it's probably as simple as a few options in the Config struct.

[huornlmj]

Glad to help @coderanger . I acknowledge I am not up to speed with the project itself, but I'm applying the maxim 'trust no-one' here, as there may well be network adversaries within the domain that the trusted client and trusted server reside in.

[alvaroaleman]

Fixed by #1548