Skip to content

API Server supports insecure TLS ciphersuites  #91444

@pjbgf

Description

@pjbgf

Description
API Server allows administrators to configure TLS connections to use a variety of insecure cipher suites. In particular it supports the use of RC4 and 3DES in its symmetric suites. RC4 has known bias in its output and should never be used, while 3DES is an extremely deprecated 64-bit block cipher which is both slow and unneeded. Additionally, non-forward secure key exchange is supported (TLS_RSA_*). This, along with SHA-based cipher suites, should be deprecated and replaced.

Recommendation
Remove support for any cipher suite that uses RC4 or 3DES as well as non-forward secure key exchange suites (TLS_RSA_*). Deprecate all but the following cipher suite options for TLS versions up through 1.2:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

How to reproduce it:

  1. Start the api-server with weak/insecure cipher suites using --tls-cipher-suites:
--tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Note: that TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is not currently classified as weak or insecure, however it is required for the API Server running with HTTP2 enabled (default).

  1. Using a modified kubectl that only supports weak/insecure ciphers, a user can disable HTTP2 and establish a insecure connection with the API Server:
$ DISABLE_HTTP2=true kubectl_weak get pods --all-namespaces
I0514 09:03:11.918628   16970 http.go:122] HTTP2 has been explicitly disabled
NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE
kube-system   kube-dns-c74654849-jqv9t   2/3     Running   0          45s

Anything else we need to know?:
This issue is derived from #81145, which focused on the kubelet.

To view the original finding, begin on page 89 of the Kubernetes Security Review Report.

See #81146 for current status of all issues created from these findings.

The vendor considers the original issue of Informational Severity.

Environment:

  • Kubernetes version: 1.18.3

/area security
/sig auth
/sig api-machinery
/wg security-audit

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/securityhelp wantedDenotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.kind/cleanupCategorizes issue or PR as related to cleaning up code, process, or technical debt.priority/awaiting-more-evidenceLowest priority. Possibly useful, but not yet enough support to actually get it done.sig/api-machineryCategorizes an issue or PR as relevant to SIG API Machinery.sig/authCategorizes an issue or PR as relevant to SIG Auth.sig/securityCategorizes an issue or PR as relevant to SIG Security.triage/acceptedIndicates an issue or PR is ready to be actively worked on.wg/security-auditCategorizes an issue or PR as relevant to WG Security Audit.

    Type

    No type

    Projects

    Status

    Closed / Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions