etquia
Version:
Dummy package for the grpc-node repository
62 lines (58 loc) • 3.43 kB
text/typescript
// Original file: deps/envoy-api/envoy/extensions/transport_sockets/tls/v3/common.proto
import type { DataSource as _envoy_config_core_v3_DataSource, DataSource__Output as _envoy_config_core_v3_DataSource__Output } from '../../../../../envoy/config/core/v3/DataSource';
export interface TlsSessionTicketKeys {
/**
* Keys for encrypting and decrypting TLS session tickets. The
* first key in the array contains the key to encrypt all new sessions created by this context.
* All keys are candidates for decrypting received tickets. This allows for easy rotation of keys
* by, for example, putting the new key first, and the previous key second.
*
* If :ref:`session_ticket_keys <envoy_v3_api_field_extensions.transport_sockets.tls.v3.DownstreamTlsContext.session_ticket_keys>`
* is not specified, the TLS library will still support resuming sessions via tickets, but it will
* use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
* or on different hosts.
*
* Each key must contain exactly 80 bytes of cryptographically-secure random data. For
* example, the output of ``openssl rand 80``.
*
* .. attention::
*
* Using this feature has serious security considerations and risks. Improper handling of keys
* may result in loss of secrecy in connections, even if ciphers supporting perfect forward
* secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
* discussion. To minimize the risk, you must:
*
* * Keep the session ticket keys at least as secure as your TLS certificate private keys
* * Rotate session ticket keys at least daily, and preferably hourly
* * Always generate keys using a cryptographically-secure random data source
*/
'keys'?: (_envoy_config_core_v3_DataSource)[];
}
export interface TlsSessionTicketKeys__Output {
/**
* Keys for encrypting and decrypting TLS session tickets. The
* first key in the array contains the key to encrypt all new sessions created by this context.
* All keys are candidates for decrypting received tickets. This allows for easy rotation of keys
* by, for example, putting the new key first, and the previous key second.
*
* If :ref:`session_ticket_keys <envoy_v3_api_field_extensions.transport_sockets.tls.v3.DownstreamTlsContext.session_ticket_keys>`
* is not specified, the TLS library will still support resuming sessions via tickets, but it will
* use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
* or on different hosts.
*
* Each key must contain exactly 80 bytes of cryptographically-secure random data. For
* example, the output of ``openssl rand 80``.
*
* .. attention::
*
* Using this feature has serious security considerations and risks. Improper handling of keys
* may result in loss of secrecy in connections, even if ciphers supporting perfect forward
* secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
* discussion. To minimize the risk, you must:
*
* * Keep the session ticket keys at least as secure as your TLS certificate private keys
* * Rotate session ticket keys at least daily, and preferably hourly
* * Always generate keys using a cryptographically-secure random data source
*/
'keys': (_envoy_config_core_v3_DataSource__Output)[];
}