Reject TLS secrets with certificate that has no CN or SANs

[erwbgy]

Envoy crashes when processing a TLS certificate that does not have SubjectAltNames or a CN field in the Subject.

Create a key, certificate and TLS Secret and then an Ingress that uses this Secret:

$ openssl req -new -newkey rsa:2048 -days 365 -nodes -subj="/DC=com/DC=domain/DC=my" -x509 -keyout server.key -out server.crt -sha256
$ kubectl create secret tls tls-secret-bad --cert=server.crt --key=server.key
secret/tls-secret-bad created

$ cat ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: contour
  name: test
spec:
  rules:
  - host: my.domain.com
    http:
      paths:
      - backend:
          serviceName: test
          servicePort: 8080
        path: /
  tls:
  - hosts:
    - my.domain.com
    secretName: tls-secret-bad

$ kubectl create -f ingress.yaml
ingress.extensions/test created

$ kubectl create deployment test --image=gcr.io/google_containers/explorer:1.0
deployment.apps/test created

$ kubectl expose deployment test --port=8080
service/test exposed

The envoy Pod logs show an assertion failure:

$ kubectl -n projectcontour logs envoy-7ms2h
...
[2019-11-29 09:32:24.547][1][info][upstream] [source/server/lds_api.cc:60] lds: add/update listener 'ingress_https'
[2019-11-29 09:32:24.547][1][info][upstream] [source/server/lds_api.cc:60] lds: add/update listener 'stats-health'
[2019-11-29 09:32:24.549][1][critical][assert] [source/extensions/transport_sockets/tls/context_impl.cc:838] assert failure: cn_index >= 0.
[2019-11-29 09:32:24.549][1][critical][backtrace] [bazel-out/k8-opt/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:81] Caught Aborted, suspect faulting address 0x1
[2019-11-29 09:32:24.549][1][critical][backtrace] [bazel-out/k8-opt/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:69] Backtrace (use tools/stack_decode.py to get line numbers):
[2019-11-29 09:32:24.549][1][critical][backtrace] [bazel-out/k8-opt/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:75] #0: [0x7f492059e420]
[2019-11-29 09:32:24.551][1][critical][backtrace] [bazel-out/k8-opt/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:73] #1: Envoy::Extensions::TransportSockets::Tls::ServerContextImpl::ServerContextImpl() [0xbadb44]

and stay in CrashLoopBackOff until the offending Ingress is removed.

[prateekjainaa]

I will be interested to know the use case why these fields will be empty.

[erwbgy]

Clearly there isn't a use case, but it should not be possible to break Contour for the entire cluster just by creating one bad Ingress and Secret.

[jpeach]

On Nov 29, 2019, at 8:24 PM, Keith Burdis <[email protected]> wrote:  Envoy crashes when processing a TLS certificate that does not have a CN field in the Subject or SubjectAltNames. Is there an envoy issue for this crash?

[erwbgy]

I couldn't find one so I raised envoyproxy/envoy#9182

[jpeach]

Thanks @erwbgy

[davecheney]

I'm working on this now. The specific fix is straight forward but opens a lot of other questions about what other kinds of certificates will envoy reject. Obviously we'll fix this specific issue quick smart, but the yakity-sax whack-a-mole song is starting to grow in volume

[jpeach]

On Dec 3, 2019, at 6:10 PM, Dave Cheney <[email protected]> wrote:  I'm working on this now. The specific fix is straight forward but opens a lot of other questions about what other kinds of certificates will envoy reject. Obviously we'll fix this specific issue quick smart, but the yakity-sax whack-a-mole song is starting to grow in volume Are you also going to validate the certificate chain? What about ensuring it the certificate matches the vhost name?

[davecheney]

Are you also going to validate the certificate chain? What about ensuring it the certificate matches the vhost name?

I'm classifying this class of problems into three groups

a. crashes envoy
b. doesn't crash envoy but will block updates if envoy NACKs a discovery response
c. valid configuration with nonsense values; a cert that doesn't match a signing chain.

At the moment, I'm prioritising a and b, the list of possible validation failures feels large enough.

[jpeach]

On Dec 3, 2019, at 7:25 PM, Dave Cheney <[email protected]> wrote:  Are you also going to validate the certificate chain? What about ensuring it the certificate matches the vhost name? I'm classifying this class of problems into three groups a. crashes envoy b. doesn't crash envoy but will block updates if envoy NACKs a discovery response c. valid configuration with nonsense values; a cert that doesn't match a signing chain. At the moment, I'm prioritising a and b, the list of possible validation failures feels large enough. (B) and (C) make sense to me, but for (A), my preference is to fix envoy. This issue has been there for ever AFAIK, so I don’t think there’s any urgency.

[davecheney]

(B) and (C) make sense to me, but for (A), my preference is to fix envoy. This issue has been there for ever AFAIK, so I don’t think there’s any urgency.

I don't want to have to explain to cluster admins that a user can crash their envoy process by creating a secret without a common name.