public static final class TlsSessionTicketKeys.Builder extends com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder> implements TlsSessionTicketKeysOrBuilder
envoy.api.v2.auth.TlsSessionTicketKeys| Modifier and Type | Method and Description |
|---|---|
TlsSessionTicketKeys.Builder |
addAllKeys(Iterable<? extends DataSource> values)
Keys for encrypting and decrypting TLS session tickets.
|
TlsSessionTicketKeys.Builder |
addKeys(DataSource.Builder builderForValue)
Keys for encrypting and decrypting TLS session tickets.
|
TlsSessionTicketKeys.Builder |
addKeys(DataSource value)
Keys for encrypting and decrypting TLS session tickets.
|
TlsSessionTicketKeys.Builder |
addKeys(int index,
DataSource.Builder builderForValue)
Keys for encrypting and decrypting TLS session tickets.
|
TlsSessionTicketKeys.Builder |
addKeys(int index,
DataSource value)
Keys for encrypting and decrypting TLS session tickets.
|
DataSource.Builder |
addKeysBuilder()
Keys for encrypting and decrypting TLS session tickets.
|
DataSource.Builder |
addKeysBuilder(int index)
Keys for encrypting and decrypting TLS session tickets.
|
TlsSessionTicketKeys.Builder |
addRepeatedField(com.google.protobuf.Descriptors.FieldDescriptor field,
Object value) |
TlsSessionTicketKeys |
build() |
TlsSessionTicketKeys |
buildPartial() |
TlsSessionTicketKeys.Builder |
clear() |
TlsSessionTicketKeys.Builder |
clearField(com.google.protobuf.Descriptors.FieldDescriptor field) |
TlsSessionTicketKeys.Builder |
clearKeys()
Keys for encrypting and decrypting TLS session tickets.
|
TlsSessionTicketKeys.Builder |
clearOneof(com.google.protobuf.Descriptors.OneofDescriptor oneof) |
TlsSessionTicketKeys.Builder |
clone() |
TlsSessionTicketKeys |
getDefaultInstanceForType() |
static com.google.protobuf.Descriptors.Descriptor |
getDescriptor() |
com.google.protobuf.Descriptors.Descriptor |
getDescriptorForType() |
DataSource |
getKeys(int index)
Keys for encrypting and decrypting TLS session tickets.
|
DataSource.Builder |
getKeysBuilder(int index)
Keys for encrypting and decrypting TLS session tickets.
|
List<DataSource.Builder> |
getKeysBuilderList()
Keys for encrypting and decrypting TLS session tickets.
|
int |
getKeysCount()
Keys for encrypting and decrypting TLS session tickets.
|
List<DataSource> |
getKeysList()
Keys for encrypting and decrypting TLS session tickets.
|
DataSourceOrBuilder |
getKeysOrBuilder(int index)
Keys for encrypting and decrypting TLS session tickets.
|
List<? extends DataSourceOrBuilder> |
getKeysOrBuilderList()
Keys for encrypting and decrypting TLS session tickets.
|
protected com.google.protobuf.GeneratedMessageV3.FieldAccessorTable |
internalGetFieldAccessorTable() |
boolean |
isInitialized() |
TlsSessionTicketKeys.Builder |
mergeFrom(com.google.protobuf.CodedInputStream input,
com.google.protobuf.ExtensionRegistryLite extensionRegistry) |
TlsSessionTicketKeys.Builder |
mergeFrom(com.google.protobuf.Message other) |
TlsSessionTicketKeys.Builder |
mergeFrom(TlsSessionTicketKeys other) |
TlsSessionTicketKeys.Builder |
mergeUnknownFields(com.google.protobuf.UnknownFieldSet unknownFields) |
TlsSessionTicketKeys.Builder |
removeKeys(int index)
Keys for encrypting and decrypting TLS session tickets.
|
TlsSessionTicketKeys.Builder |
setField(com.google.protobuf.Descriptors.FieldDescriptor field,
Object value) |
TlsSessionTicketKeys.Builder |
setKeys(int index,
DataSource.Builder builderForValue)
Keys for encrypting and decrypting TLS session tickets.
|
TlsSessionTicketKeys.Builder |
setKeys(int index,
DataSource value)
Keys for encrypting and decrypting TLS session tickets.
|
TlsSessionTicketKeys.Builder |
setRepeatedField(com.google.protobuf.Descriptors.FieldDescriptor field,
int index,
Object value) |
TlsSessionTicketKeys.Builder |
setUnknownFields(com.google.protobuf.UnknownFieldSet unknownFields) |
getAllFields, getField, getFieldBuilder, getOneofFieldDescriptor, getParentForChildren, getRepeatedField, getRepeatedFieldBuilder, getRepeatedFieldCount, getUnknownFields, hasField, hasOneof, internalGetMapField, internalGetMutableMapField, isClean, markClean, newBuilderForField, onBuilt, onChanged, setUnknownFieldsProto3findInitializationErrors, getInitializationErrorString, internalMergeFrom, mergeDelimitedFrom, mergeDelimitedFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, newUninitializedMessageException, toStringaddAll, addAll, mergeFrom, newUninitializedMessageExceptionequals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, waitpublic static final com.google.protobuf.Descriptors.Descriptor getDescriptor()
protected com.google.protobuf.GeneratedMessageV3.FieldAccessorTable internalGetFieldAccessorTable()
internalGetFieldAccessorTable in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>public TlsSessionTicketKeys.Builder clear()
clear in interface com.google.protobuf.Message.Builderclear in interface com.google.protobuf.MessageLite.Builderclear in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>public com.google.protobuf.Descriptors.Descriptor getDescriptorForType()
getDescriptorForType in interface com.google.protobuf.Message.BuildergetDescriptorForType in interface com.google.protobuf.MessageOrBuildergetDescriptorForType in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>public TlsSessionTicketKeys getDefaultInstanceForType()
getDefaultInstanceForType in interface com.google.protobuf.MessageLiteOrBuildergetDefaultInstanceForType in interface com.google.protobuf.MessageOrBuilderpublic TlsSessionTicketKeys build()
build in interface com.google.protobuf.Message.Builderbuild in interface com.google.protobuf.MessageLite.Builderpublic TlsSessionTicketKeys buildPartial()
buildPartial in interface com.google.protobuf.Message.BuilderbuildPartial in interface com.google.protobuf.MessageLite.Builderpublic TlsSessionTicketKeys.Builder clone()
clone in interface com.google.protobuf.Message.Builderclone in interface com.google.protobuf.MessageLite.Builderclone in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>public TlsSessionTicketKeys.Builder setField(com.google.protobuf.Descriptors.FieldDescriptor field, Object value)
setField in interface com.google.protobuf.Message.BuildersetField in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>public TlsSessionTicketKeys.Builder clearField(com.google.protobuf.Descriptors.FieldDescriptor field)
clearField in interface com.google.protobuf.Message.BuilderclearField in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>public TlsSessionTicketKeys.Builder clearOneof(com.google.protobuf.Descriptors.OneofDescriptor oneof)
clearOneof in interface com.google.protobuf.Message.BuilderclearOneof in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>public TlsSessionTicketKeys.Builder setRepeatedField(com.google.protobuf.Descriptors.FieldDescriptor field, int index, Object value)
setRepeatedField in interface com.google.protobuf.Message.BuildersetRepeatedField in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>public TlsSessionTicketKeys.Builder addRepeatedField(com.google.protobuf.Descriptors.FieldDescriptor field, Object value)
addRepeatedField in interface com.google.protobuf.Message.BuilderaddRepeatedField in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>public TlsSessionTicketKeys.Builder mergeFrom(com.google.protobuf.Message other)
mergeFrom in interface com.google.protobuf.Message.BuildermergeFrom in class com.google.protobuf.AbstractMessage.Builder<TlsSessionTicketKeys.Builder>public TlsSessionTicketKeys.Builder mergeFrom(TlsSessionTicketKeys other)
public final boolean isInitialized()
isInitialized in interface com.google.protobuf.MessageLiteOrBuilderisInitialized in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>public TlsSessionTicketKeys.Builder mergeFrom(com.google.protobuf.CodedInputStream input, com.google.protobuf.ExtensionRegistryLite extensionRegistry) throws IOException
mergeFrom in interface com.google.protobuf.Message.BuildermergeFrom in interface com.google.protobuf.MessageLite.BuildermergeFrom in class com.google.protobuf.AbstractMessage.Builder<TlsSessionTicketKeys.Builder>IOExceptionpublic List<DataSource> getKeysList()
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_api_field_auth.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
repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }getKeysList in interface TlsSessionTicketKeysOrBuilderpublic int getKeysCount()
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_api_field_auth.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
repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }getKeysCount in interface TlsSessionTicketKeysOrBuilderpublic DataSource getKeys(int index)
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_api_field_auth.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
repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }getKeys in interface TlsSessionTicketKeysOrBuilderpublic TlsSessionTicketKeys.Builder setKeys(int index, DataSource value)
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_api_field_auth.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
repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }public TlsSessionTicketKeys.Builder setKeys(int index, DataSource.Builder builderForValue)
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_api_field_auth.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
repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }public TlsSessionTicketKeys.Builder addKeys(DataSource value)
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_api_field_auth.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
repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }public TlsSessionTicketKeys.Builder addKeys(int index, DataSource value)
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_api_field_auth.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
repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }public TlsSessionTicketKeys.Builder addKeys(DataSource.Builder builderForValue)
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_api_field_auth.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
repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }public TlsSessionTicketKeys.Builder addKeys(int index, DataSource.Builder builderForValue)
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_api_field_auth.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
repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }public TlsSessionTicketKeys.Builder addAllKeys(Iterable<? extends DataSource> values)
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_api_field_auth.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
repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }public TlsSessionTicketKeys.Builder clearKeys()
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_api_field_auth.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
repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }public TlsSessionTicketKeys.Builder removeKeys(int index)
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_api_field_auth.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
repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }public DataSource.Builder getKeysBuilder(int index)
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_api_field_auth.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
repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }public DataSourceOrBuilder getKeysOrBuilder(int index)
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_api_field_auth.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
repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }getKeysOrBuilder in interface TlsSessionTicketKeysOrBuilderpublic List<? extends DataSourceOrBuilder> getKeysOrBuilderList()
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_api_field_auth.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
repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }getKeysOrBuilderList in interface TlsSessionTicketKeysOrBuilderpublic DataSource.Builder addKeysBuilder()
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_api_field_auth.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
repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }public DataSource.Builder addKeysBuilder(int index)
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_api_field_auth.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
repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }public List<DataSource.Builder> getKeysBuilderList()
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_api_field_auth.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
repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }public final TlsSessionTicketKeys.Builder setUnknownFields(com.google.protobuf.UnknownFieldSet unknownFields)
setUnknownFields in interface com.google.protobuf.Message.BuildersetUnknownFields in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>public final TlsSessionTicketKeys.Builder mergeUnknownFields(com.google.protobuf.UnknownFieldSet unknownFields)
mergeUnknownFields in interface com.google.protobuf.Message.BuildermergeUnknownFields in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>Copyright © 2018–2021 The Envoy Project. All rights reserved.