Skip to content

Commit

Permalink
add fallback certificate design doc
Browse files Browse the repository at this point in the history
Signed-off-by: Steve Sloka <slokas@vmware.com>
  • Loading branch information
stevesloka committed Apr 9, 2020
1 parent 8a7825c commit 2bb1123
Showing 1 changed file with 68 additions and 0 deletions.
68 changes: 68 additions & 0 deletions design/fallbackcert.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,68 @@
# Fallback Certificate

Status: Draft

Contour supports virtual host based routing over TLS and utilizes SNI which allows multiple fqdn's to be used on the same network endpoint.
Unfortunately, some requests are sent and do not have the HOST header applied.
When this happens, the request fails since the request does not match any routing rules applied to Envoy.

This design doc looks to enable a fallback certificate, such that when a request is received at Envoy, it will still route to the proper set of endpoints even though standard SNI logic isn't applied.

## Goals

- Allow fallback certificate to be defined
- Enable the fallback cert only for specific vhosts

## Non Goals

- Allowing multiple default certs to be defined

## Background

Contour provides virtual host based routing, so that the TLS request is routed to the appropriate service, based on the hostname specified in the HTTPS’s `HOST` header.
As HOST Header is encrypted during TLS handshake, it can’t be used for virtual host based routing unless client sends HTTPS request specifying hostname using the SNI or the request is first decrypted using a default TLS certificate.
Some users need to support clients which may not be using SNI.
When an HTTPS request is received, Envoy needs to first decrypt the request using a default TLS certificate and then based on the HOST header, route it to appropriate service.
As of now, Contour only provides certificate at virtual host level in an IngressRoute and there is no way to define a default TLS certificate in Contour.

## High-Level Design

Contour will add a new argument to `contour serve` named `--fallback-certificate` which references a secret that is namespaced with a name (e.g. `namespace/name`).
Secondly, a new field will be added to the `HTTPProxy.Spec.VirtualHost.TLS` named `FallbackCertificatedEnabled` to allow virtual hosts to opt into this functionality.
This last point is important as by default, all vhosts will **not** be enabled for this feature.

## Detailed Design

The new argument to `contour serve` must be in the format of `namespace/name`.

The Envoy filter chain will be changed to match on `TransportProtocol: "tls"`:

```go
&envoy_api_v2_listener.FilterChain{
Filters: filters,
FilterChainMatch: &envoy_api_v2_listener.FilterChainMatch{
TransportProtocol: "tls",
},
}
```

The `HTTPProxy` spec will add a new field named `FallbackCertificatedEnabled` and will default to `false`:

```go
type TLS struct {
// required, the name of a secret in the current namespace
SecretName string `json:"secretName,omitempty"`
// Minimum TLS version this vhost should negotiate
// +optional
MinimumProtocolVersion string `json:"minimumProtocolVersion,omitempty"`
// If Passthrough is set to true, the SecretName will be ignored
// and the encrypted handshake will be passed through to the
// backing cluster.
// +optional
Passthrough bool `json:"passthrough,omitempty"`

// +optional
FallbackCertificatedEnabled bool `json:"fallbackCertificateEnabled,omitempty""`

}
```

0 comments on commit 2bb1123

Please sign in to comment.