ETCD TLS still supports weak 64-bit block ciphers

[msi-normr]

Description:
ETCD TLS still supports weak 64-bit block ciphers
Nessus security scanner indicates ETCD TLS port can still communicate using weak 64-bit block ciphers which is a security vaulnerabilty (SWEET32).

Steps to Reproduce:
1.) Setup ETCD for TLS
2.) Initiate a query to the ETCD https port and specify a weak cipher (ECDHE-RSA-DES-CBC3-SHA, DES-CBC3-SHA)
curl -v https://lama1-1-1:4001/v2/members --cert /etc/ssl/local_certs/etcd2/etcd2.crt --key /etc/ssl/local_certs/etcd2/etcd2.key --ciphers ECDHE-RSA-DES-CBC3-SHA

Actual Results:
ETCD responded from the query using the weak cipher

cs1-1-1 ~ # curl -v https://lama1-1-1:4001/v2/members --cert /etc/ssl/local_certs/etcd2/etcd2.crt --key /etc/ssl/local_certs/etcd2/etcd2.key --ciphers ECDHE-RSA-DES-CBC3-SHA

• Trying 10.10.48.224...
• TCP_NODELAY set
• Connected to lama1-1-1 (10.10.48.224) port 4001 (#0)
• ALPN, offering http/1.1
• Cipher selection: ECDHE-RSA-DES-CBC3-SHA
• successfully set certificate verify locations:
• CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
• TLSv1.2 (OUT), TLS header, Certificate Status (22):
• TLSv1.2 (OUT), TLS handshake, Client hello (1):
• TLSv1.2 (IN), TLS handshake, Server hello (2):
• TLSv1.2 (IN), TLS handshake, Certificate (11):
• TLSv1.2 (IN), TLS handshake, Server key exchange (12):
• TLSv1.2 (IN), TLS handshake, Server finished (14):
• TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
• TLSv1.2 (OUT), TLS change cipher, Client hello (1):
• TLSv1.2 (OUT), TLS handshake, Finished (20):
• TLSv1.2 (IN), TLS change cipher, Client hello (1):
• TLSv1.2 (IN), TLS handshake, Finished (20):
• SSL connection using TLSv1.2 / ECDHE-RSA-DES-CBC3-SHA
• ALPN, server did not agree to a protocol
• Server certificate:
• subject: C=US; ST=Illinois; L=Chic; O=Mot_S Inc; OU=Test; CN=lama1-1-1
• start date: Jul 12 23:28:38 2017 GMT
• expire date: Jul 6 23:28:38 2042 GMT
• subjectAltName: host "lama1-1-1" matched cert's "lama1-1-1"
• issuer: C=US; ST=Illinois; L=Chic; O=Mot_S Inc; OU=Test; CN=Sxxxxxxx_CA_xxxxxxxxxx
• SSL certificate verify ok.

GET /v2/members HTTP/1.1
Host: lama1-1-1:4001
User-Agent: curl/7.54.0
Accept: /

< HTTP/1.1 200 OK
< Content-Length: 183
< Content-Type: application/json
< Date: Thu, 27 Jul 2017 18:56:52 GMT
< X-Etcd-Cluster-Id: 7417be5c0ca6813f
<
{"members":[{"id":"b8c5b89e3b6c0487","name":"f0bc2c5cee094fb7997f02f07cd80a55","peerURLs":["https://cs1-1-1:2380"],"clientURLs":["http://10.10.48.223:2379","https://cs1-1-1:4001"]}]}

• Connection #0 to host lama1-1-1 left intact
  cs1-1-1 ~ # echo $?
  0

Expected Results:
Expecting ETCD to fail query.

Occurs On:
CoreOS 1409.5.0 (Ladybug)
ETCD v3.1.6
openssl 1.0.2k

Additional Information:

• Openssl indicates this is fixed in v1.1.0 current CoreOS versions still use OpenSSL 1.0.2k
• Is there any plans for ETCD to have a http server that will have ciphers configurable.

/usr/lib/systemd/system/etcd-member.service

[Unit]
Description=etcd (System Application Container)
Documentation=https://github.com/coreos/etcd
Wants=network.target
Conflicts=etcd.service
Conflicts=etcd2.service

[Service]
Type=notify
Restart=on-failure
RestartSec=10s
TimeoutStartSec=0
LimitNOFILE=40000

Environment="ETCD_IMAGE_TAG=v3.1.6"
Environment="ETCD_NAME=%m"
Environment="ETCD_USER=etcd"
Environment="ETCD_DATA_DIR=/var/lib/etcd"
Environment="RKT_RUN_ARGS=--uuid-file-save=/var/lib/coreos/etcd-member-wrapper.uuid"

ExecStartPre=/usr/bin/mkdir --parents /var/lib/coreos
ExecStartPre=-/usr/bin/rkt rm --uuid-file=/var/lib/coreos/etcd-member-wrapper.uuid
ExecStart=/usr/lib/coreos/etcd-wrapper $ETCD_OPTS
ExecStop=-/usr/bin/rkt stop --uuid-file=/var/lib/coreos/etcd-member-wrapper.uuid

[Install]
WantedBy=multi-user.target

/etc/systemd/system/etcd-member.service.d/10-require-certs.conf

[Unit]
Requires=link_etcd2_cert.service
After=link_etcd2_cert.service

/etc/systemd/system/etcd-member.service.d/50-options.conf

[Service]
Environment="ETCD_DISCOVERY=https://discovery.etcd.io/5fe45a47005f6cd5853d4639236b74b9"
Environment="ETCD_ADVERTISE_CLIENT_URLS=http://10.10.48.223:2379,https://cs1-1-1:4001"
Environment="ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379,https://0.0.0.0:4001"
Environment="ETCD_INITIAL_ADVERTISE_PEER_URLS=https://cs1-1-1:2380"
Environment="ETCD_LISTEN_PEER_URLS=https://cs1-1-1:2380"
Environment="ETCD_CERT_FILE=/etc/ssl/certs/etcd2/etcd2.crt"
Environment="ETCD_KEY_FILE=/etc/ssl/certs/etcd2/etcd2.key"
Environment="ETCD_PEER_TRUSTED_CA_FILE=/etc/ssl/certs/etcd2/etcd2-chain.pem"
lines 1-43

cs1-1-1 ~ # cat /etc/os-release
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1409.5.0
VERSION_ID=1409.5.0
BUILD_ID=2017-06-22-2222
PRETTY_NAME="Container Linux by CoreOS 1409.5.0 (Ladybug)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://issues.coreos.com"
COREOS_BOARD="amd64-usr"

cs1-1-1 ~ # openssl version
OpenSSL 1.0.2k 26 Jan 2017

[heyitsanthony]

If etcd is going to worry about weak ciphers, maybe there should be a FIPS-140 mode? It seems the suggested way is cgo out to a certified library. /cc @xiang90

[xiang90]

@heyitsanthony

Agreed.

[swestcott]

Weak cipher support in etcd was flagged up in a security test on our Kubernetes cluster too. We can reduce the risk via security group controls, but being able to whitelist ciphers would address the root cause.

[swestcott]

Further to the above, I feel that allowing users to choose ciphers themselves would offer greater flexibility and allow cipher configuration to be tailored for different regulatory environments. For example, PCI DSS refer to NIST SP 800-52 for TLS configuration.

This is the approach Kubernetes have taken via kubernetes/kubernetes#48859

[xiang90]

@swestcott

It seems k8s approach is simpler, but it requires users to understand exactly what they expect, and it is go specific.

We probably should adopt the similar approach. Would you want to help on this?

Or would @spzala ?

[swestcott]

@xiang90 Understood, but I think it's responsible to expect users working in regulated environments to understand such settings. This also means users can response more quickly to any future cipher compromises.

We'll look to get a PR raised in the new year /cc @ThatsMrTalbot

[philips]

The Kubernetes solution looks reasonable to me.

I feel we should pick some default set of ciphers too. What about this list? https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-cipher-suites

Did Kubernetes select a default set? I couldn't tell from glancing at the PR.

[xiang90]

@philips

I feel we should pick some default set of ciphers too. What about this list?

This might break existing users after a upgrade. Every time we tighten TLS/security or fix security related bugs, we break some users though...

[philips]

True. Is Kubernetes just rolling with all ciphers?

On Fri, Dec 22, 2017 at 1:38 PM Xiang Li ***@***.***> wrote: @philips <https://github.com/philips> I feel we should pick some default set of ciphers too. What about this list? This might break existing users after a upgrade. Every time we tighten TLS/security or fix security related bugs, we break some users though... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#8320 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACDCNWxY14csJ-MlwqCbQZ0FIbGa3x8ks5tDCFngaJpZM4OlxmM> .

-- CTO, CoreOS, Inc Tectonic is enterprise Kubernetes https://coreos.com/tectonic

[xiang90]

Is Kubernetes just rolling with all ciphers?

The default one is all available ones in Go TLS as far as I can tell.

@swestcott probably have more details to fill in here.

[swestcott]

The default one is all available ones in Go TLS as far as I can tell.

@xiang90 Yes, that's my understanding too. All ciphers by default, with an optional whitelist.