Add configuration for TLS session ticket encryption key, to allow#178
Add configuration for TLS session ticket encryption key, to allow#178htuch merged 6 commits intoenvoyproxy:masterfrom ggreenway:tls-ticket-key
Conversation
session resumption across hot-restart or between multiple envoy instances. Signed-off-by: Greg Greenway <ggreenway@apple.com>
|
This commit is paired with envoyproxy/envoy#1747 |
| // Keys to encrypt/decrypt TLS session tickets for session resumption. The first | ||
| // key is used to encrypt new tickets that are created. All keys are candidates | ||
| // for decrypting received tickets. | ||
| repeated DataSource tls_session_ticket_key = 4; |
There was a problem hiding this comment.
+1 I was going to make the same comment. We will definitely want session ticket keys to be able to be provided via KDS.
There was a problem hiding this comment.
@PiotrSikora it would be kind of nice if there was a common message that people can use as opposed to everyone supplying their own name, etc.
There was a problem hiding this comment.
Would it make sense to have a message like "KdsReference", and then make this oneof KdsReference or repeated Datasource?
Signed-off-by: Greg Greenway <ggreenway@apple.com>
|
|
||
| message TlsSessionTicketKeys { | ||
| // Optional identifier for this set of keys | ||
| string name = 1; |
There was a problem hiding this comment.
Should there also be a ConfigSource for kds here, similar to #180
There was a problem hiding this comment.
This should be KdsSecretConfig, but you might want to wait a day or two, before #180 is merged.
There was a problem hiding this comment.
Yeah, let's wait for #180 to get merged and then I'll fix this up.
There was a problem hiding this comment.
This is now merged, do you want to rebase/merge?
|
|
||
| // Keys to encrypt/decrypt TLS session tickets for session resumption. The first | ||
| // key is used to encrypt new tickets that are created. All keys are candidates | ||
| // for decrypting received tickets. |
There was a problem hiding this comment.
Should I document the expected format here? The only reason it seems weird is because if the format ever changes (due to different crypto being used), it seems weird to modify an existing protobuf field (even though the modification is only documentation, and doesn't break the protobuf wire format).
There was a problem hiding this comment.
I think the format should be documented here, even though it doesn't affect the wire format.
Signed-off-by: Greg Greenway <ggreenway@apple.com>
Signed-off-by: Greg Greenway <ggreenway@apple.com>
| // If specified, Envoy will reject connections without a valid and matching SNI. | ||
| google.protobuf.BoolValue require_sni = 3; | ||
|
|
||
| TlsSessionTicketKeys tls_session_ticket_keys = 4; |
There was a problem hiding this comment.
Should I have a SdsSecretConfig here paired with this? I don't grok the relationship between the inline-secrets vs the pointer-to-SDS secrets.
There was a problem hiding this comment.
Maybe we can add a oneof for new users @PiotrSikora ?
There was a problem hiding this comment.
Yeah, I was looking at this to figure out what to do:
repeated TlsCertificate tls_certificates = 2;
repeated SdsSecretConfig sds_secret_configs = 6;
Is that two separate fields instead of oneof for backwards compatibility reasons? If so, should I add a comment to that effect?
Signed-off-by: Greg Greenway <ggreenway@apple.com>
4 participants
session resumption across hot-restart or between multiple envoy
instances.
Signed-off-by: Greg Greenway ggreenway@apple.com