Birthday attacks against TLS ciphers with 64bit block size vulnerability (Sweet32) #9496
Comments
|
Do we have a kops patch to fix SWEET32 issue? Any idea which version of kops will fix this vulnerability? |
|
Kops does not provide option to set TLSmin version and Ciphers for etcd-manager. Any idea when will this be made available? |
|
kops 1.18 will support specifying environment variables passed to etcd and many etcd settings support environment variables like ETCD_CIPHER_SUITES. Is that sufficient for your use case? |
|
Thanks @rifelpet for confirmation. Will it also allow TLSmin version? Right now openssl connection can be made using TLSv1 or TLSv1_1. Will it also allow kube-scheduler to set TLS min version and Ciphers, similar to settings available for kube-api sever and kubelet? Not sure whether anyone raised it, Qualys scans are failing for these services showing vulnerabilities like SWEET32, triple handshake and TLSv1.0 usage. This hampers PCI compliance requirement for production setups. |
|
I think this issue suggests you can force TLS 1.2 by specifying a specific list of ciphers which means the |
|
If kops 1.18 is going to use etcd 3.4 then I believe this will help our use case to solve qualys reported vulnerabilities. Thanks. |
|
I think a related question here is also what we should set by default. Should we be as relaxed as etcd default here or can we be stricter? |
|
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
|
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
|
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
|
@fejta-bot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
1. What
kopsversion are you running? The commandkops version, will displaythis information.
version 1.16.0 (git-4b0e62b82)
2. What Kubernetes version are you running?
kubectl versionwill print theversion if a cluster is running or provide the Kubernetes version specified as
a
kopsflag.Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.5", GitCommit:"e6503f8d8f769ace2f338794c914a96fc335df0f", GitTreeState:"clean", BuildDate:"2020-06-26T03:47:41Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.10", GitCommit:"1bea6c00a7055edef03f1d4bb58b773fa8917f11", GitTreeState:"clean", BuildDate:"2020-02-11T20:05:26Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}
3. What cloud provider are you using?
openssl s_client -connect X.X.X.X:3996 -tls1 - should fail but its not happening.
kubeScheduler:
tlsMinVersion: VersionTLS12
tlsCipherSuites:
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA
kubeControllerManager:
tlsMinVersion: VersionTLS12
tlsCipherSuites:
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA
kubeAPIServer:
tlsMinVersion: VersionTLS12
tlsCipherSuites:
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA
kubelet:
anonymousAuth: false
authenticationTokenWebhook: true
authorizationMode: Webhook
tlsMinVersion: VersionTLS12
tlsCipherSuites:
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA
kubernetesApiAccess:
kubernetesVersion: 1.15.10
masterPublicName: api.{{.cluster_name.value}}
networkCIDR: {{.vpc_cidr_block.value}}
networkID: {{.vpc_id.value}}
5. What happened after the commands executed?
kube-apiserver.manifest shows that tlsMinVersion and tlsCipherSuites are set but still openssl can use TLSv1 to connect to kubernetes services on respective ports-
kube-scheduler - 10259
kubelet - 10250
kube-controller - 10257
kube-apiserver - 443
etcd-manager - 3996 and 3997
6. What did you expect to happen?
We want to fix SWEET32 vulnerability detected by Qualys scan.
7. Please provide your cluster manifest. Execute
kops get --name my.example.com -o yamlto display your cluster manifest.You may want to remove your cluster name and other sensitive information.
apiVersion: kops.k8s.io/v1alpha2
kind: Cluster
metadata:
creationTimestamp: null
name: XXX
spec:
api:
loadBalancer:
type: Internal
authorization:
rbac: {}
channel: stable
cloudProvider: aws
configBase: s3://XXX
dnsZone: xxx
etcdClusters:
etcdMembers:
name: a
name: b
name: c
memoryRequest: 100Mi
name: main
etcdMembers:
name: a
name: b
name: c
memoryRequest: 100Mi
name: events
iam:
allowContainerRegistry: true
legacy: false
kubeAPIServer:
tlsCipherSuites:
tlsMinVersion: VersionTLS12
kubeControllerManager:
tlsCipherSuites:
tlsMinVersion: VersionTLS12
kubeDNS:
provider: CoreDNS
kubeScheduler: {}
kubelet:
anonymousAuth: false
authenticationTokenWebhook: true
authorizationMode: Webhook
tlsCipherSuites:
tlsMinVersion: VersionTLS12
kubernetesApiAccess:
kubernetesVersion: 1.15.10
masterPublicName: xxx
networkCIDR: xxxxx
networkID: xxxx
networking:
weave:
mtu: 8912
nonMasqueradeCIDR: xxx
sshAccess:
subnets:
id: xx
name: xx
type: Private
zone: ap-southeast-2a
id: xx
name: xx
type: Private
zone: ap-southeast-2b
id: sxx
name: xx
type: Private
zone: xx
name: uxxx
type: Utility
zone: xx
name: xx
type: Utility
zone: xx
name: xx
type: Utility
zone: xxc
topology:
bastion:
bastionPublicName: xxx
dns:
type: Private
masters: private
nodes: private
apiVersion: kops.k8s.io/v1alpha2
kind: InstanceGroup
metadata:
creationTimestamp: "2020-07-03T03:57:45Z"
generation: 1
labels:
kops.k8s.io/cluster: xxx
name: bastions
spec:
associatePublicIp: true
cloudLabels:
JiraTicket: N/A
image: xx
machineType: t2.small
maxSize: 1
minSize: 1
nodeLabels:
kops.k8s.io/instancegroup: bastions
role: Bastion
subnets:
apiVersion: kops.k8s.io/v1alpha2
kind: InstanceGroup
metadata:
creationTimestamp: "2020-07-03T03:57:45Z"
generation: 1
labels:
kops.k8s.io/cluster: xxx
name: masterxxx
spec:
image: kope.io/xxx
machineType: t2.medium
maxSize: 1
minSize: 1
nodeLabels:
kops.k8s.io/instancegroup: xx
role: Master
subnets:
apiVersion: kops.k8s.io/v1alpha2
kind: InstanceGroup
metadata:
creationTimestamp: "2020-07-03T03:57:45Z"
generation: 1
labels:
kops.k8s.io/cluster: xx
name: mastxxx
spec:
image: kope.io/xxx
machineType: t2.medium
maxSize: 1
minSize: 1
nodeLabels:
kops.k8s.io/instancegroup: xx
role: Master
subnets:
apiVersion: kops.k8s.io/v1alpha2
kind: InstanceGroup
metadata:
creationTimestamp: "2020-07-03T03:57:45Z"
generation: 1
labels:
kops.k8s.io/cluster: xxx
name: mastxxx
spec:
image: kope.io/xxx
machineType: t2.medium
maxSize: 1
minSize: 1
nodeLabels:
kops.k8s.io/instancegroup: xx
role: Master
subnets:
apiVersion: kops.k8s.io/v1alpha2
kind: InstanceGroup
metadata:
creationTimestamp: "2020-07-03T03:57:46Z"
generation: 1
labels:
kops.k8s.io/cluster: xxx
name: nodes
spec:
image: kope.io/xxxx
machineType: t2.large
maxSize: 3
minSize: 3
nodeLabels:
kops.k8s.io/instancegroup: nodes
role: Node
subnets:
8. Please run the commands with most verbose logging by adding the
-v 10flag.Paste the logs into this report, or in a gist and provide the gist link here.
CONNECTED(00000003)
139811536363584:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:../ssl/record/rec_layer_s3.c:1407:SSL alert number 70
no peer certificate available
No client certificate CA names sent
SSL handshake has read 7 bytes and written 102 bytes
Verification: OK
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1593934012
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
9. Anything else do we need to know?
The text was updated successfully, but these errors were encountered: