Class TlsSessionTicketKeys.Builder
- java.lang.Object
-
- com.google.protobuf.AbstractMessageLite.Builder
-
- com.google.protobuf.AbstractMessage.Builder<BuilderT>
-
- com.google.protobuf.GeneratedMessage.Builder<TlsSessionTicketKeys.Builder>
-
- io.envoyproxy.envoy.extensions.transport_sockets.tls.v3.TlsSessionTicketKeys.Builder
-
- All Implemented Interfaces:
com.google.protobuf.Message.Builder
,com.google.protobuf.MessageLite.Builder
,com.google.protobuf.MessageLiteOrBuilder
,com.google.protobuf.MessageOrBuilder
,TlsSessionTicketKeysOrBuilder
,java.lang.Cloneable
- Enclosing class:
- TlsSessionTicketKeys
public static final class TlsSessionTicketKeys.Builder extends com.google.protobuf.GeneratedMessage.Builder<TlsSessionTicketKeys.Builder> implements TlsSessionTicketKeysOrBuilder
Protobuf typeenvoy.extensions.transport_sockets.tls.v3.TlsSessionTicketKeys
-
-
Field Summary
Fields Modifier and Type Field Description private int
bitField0_
private java.util.List<DataSource>
keys_
private com.google.protobuf.RepeatedFieldBuilder<DataSource,DataSource.Builder,DataSourceOrBuilder>
keysBuilder_
-
Method Summary
All Methods Static Methods Instance Methods Concrete Methods Modifier and Type Method Description TlsSessionTicketKeys.Builder
addAllKeys(java.lang.Iterable<? extends DataSource> values)
Keys for encrypting and decrypting TLS session tickets.TlsSessionTicketKeys.Builder
addKeys(int index, 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(DataSource value)
Keys for encrypting and decrypting TLS session tickets.TlsSessionTicketKeys.Builder
addKeys(DataSource.Builder builderForValue)
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
build()
TlsSessionTicketKeys
buildPartial()
private void
buildPartial0(TlsSessionTicketKeys result)
private void
buildPartialRepeatedFields(TlsSessionTicketKeys result)
TlsSessionTicketKeys.Builder
clear()
TlsSessionTicketKeys.Builder
clearKeys()
Keys for encrypting and decrypting TLS session tickets.private void
ensureKeysIsMutable()
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.java.util.List<DataSource.Builder>
getKeysBuilderList()
Keys for encrypting and decrypting TLS session tickets.int
getKeysCount()
Keys for encrypting and decrypting TLS session tickets.private com.google.protobuf.RepeatedFieldBuilder<DataSource,DataSource.Builder,DataSourceOrBuilder>
getKeysFieldBuilder()
java.util.List<DataSource>
getKeysList()
Keys for encrypting and decrypting TLS session tickets.DataSourceOrBuilder
getKeysOrBuilder(int index)
Keys for encrypting and decrypting TLS session tickets.java.util.List<? extends DataSourceOrBuilder>
getKeysOrBuilderList()
Keys for encrypting and decrypting TLS session tickets.protected com.google.protobuf.GeneratedMessage.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
removeKeys(int index)
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
setKeys(int index, DataSource.Builder builderForValue)
Keys for encrypting and decrypting TLS session tickets.-
Methods inherited from class com.google.protobuf.GeneratedMessage.Builder
addRepeatedField, clearField, clearOneof, clone, getAllFields, getField, getFieldBuilder, getOneofFieldDescriptor, getParentForChildren, getRepeatedField, getRepeatedFieldBuilder, getRepeatedFieldCount, getUnknownFields, getUnknownFieldSetBuilder, hasField, hasOneof, internalGetMapField, internalGetMapFieldReflection, internalGetMutableMapField, internalGetMutableMapFieldReflection, isClean, markClean, mergeUnknownFields, mergeUnknownLengthDelimitedField, mergeUnknownVarintField, newBuilderForField, onBuilt, onChanged, parseUnknownField, setField, setRepeatedField, setUnknownFields, setUnknownFieldSetBuilder, setUnknownFieldsProto3
-
Methods inherited from class com.google.protobuf.AbstractMessage.Builder
findInitializationErrors, getInitializationErrorString, internalMergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, newUninitializedMessageException, toString
-
Methods inherited from class com.google.protobuf.AbstractMessageLite.Builder
addAll, addAll, mergeDelimitedFrom, mergeDelimitedFrom, mergeFrom, newUninitializedMessageException
-
Methods inherited from class java.lang.Object
equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait
-
-
-
-
Field Detail
-
bitField0_
private int bitField0_
-
keys_
private java.util.List<DataSource> keys_
-
keysBuilder_
private com.google.protobuf.RepeatedFieldBuilder<DataSource,DataSource.Builder,DataSourceOrBuilder> keysBuilder_
-
-
Method Detail
-
getDescriptor
public static final com.google.protobuf.Descriptors.Descriptor getDescriptor()
-
internalGetFieldAccessorTable
protected com.google.protobuf.GeneratedMessage.FieldAccessorTable internalGetFieldAccessorTable()
- Specified by:
internalGetFieldAccessorTable
in classcom.google.protobuf.GeneratedMessage.Builder<TlsSessionTicketKeys.Builder>
-
clear
public TlsSessionTicketKeys.Builder clear()
- Specified by:
clear
in interfacecom.google.protobuf.Message.Builder
- Specified by:
clear
in interfacecom.google.protobuf.MessageLite.Builder
- Overrides:
clear
in classcom.google.protobuf.GeneratedMessage.Builder<TlsSessionTicketKeys.Builder>
-
getDescriptorForType
public com.google.protobuf.Descriptors.Descriptor getDescriptorForType()
- Specified by:
getDescriptorForType
in interfacecom.google.protobuf.Message.Builder
- Specified by:
getDescriptorForType
in interfacecom.google.protobuf.MessageOrBuilder
- Overrides:
getDescriptorForType
in classcom.google.protobuf.GeneratedMessage.Builder<TlsSessionTicketKeys.Builder>
-
getDefaultInstanceForType
public TlsSessionTicketKeys getDefaultInstanceForType()
- Specified by:
getDefaultInstanceForType
in interfacecom.google.protobuf.MessageLiteOrBuilder
- Specified by:
getDefaultInstanceForType
in interfacecom.google.protobuf.MessageOrBuilder
-
build
public TlsSessionTicketKeys build()
- Specified by:
build
in interfacecom.google.protobuf.Message.Builder
- Specified by:
build
in interfacecom.google.protobuf.MessageLite.Builder
-
buildPartial
public TlsSessionTicketKeys buildPartial()
- Specified by:
buildPartial
in interfacecom.google.protobuf.Message.Builder
- Specified by:
buildPartial
in interfacecom.google.protobuf.MessageLite.Builder
-
buildPartialRepeatedFields
private void buildPartialRepeatedFields(TlsSessionTicketKeys result)
-
buildPartial0
private void buildPartial0(TlsSessionTicketKeys result)
-
mergeFrom
public TlsSessionTicketKeys.Builder mergeFrom(com.google.protobuf.Message other)
- Specified by:
mergeFrom
in interfacecom.google.protobuf.Message.Builder
- Overrides:
mergeFrom
in classcom.google.protobuf.AbstractMessage.Builder<TlsSessionTicketKeys.Builder>
-
mergeFrom
public TlsSessionTicketKeys.Builder mergeFrom(TlsSessionTicketKeys other)
-
isInitialized
public final boolean isInitialized()
- Specified by:
isInitialized
in interfacecom.google.protobuf.MessageLiteOrBuilder
- Overrides:
isInitialized
in classcom.google.protobuf.GeneratedMessage.Builder<TlsSessionTicketKeys.Builder>
-
mergeFrom
public TlsSessionTicketKeys.Builder mergeFrom(com.google.protobuf.CodedInputStream input, com.google.protobuf.ExtensionRegistryLite extensionRegistry) throws java.io.IOException
- Specified by:
mergeFrom
in interfacecom.google.protobuf.Message.Builder
- Specified by:
mergeFrom
in interfacecom.google.protobuf.MessageLite.Builder
- Overrides:
mergeFrom
in classcom.google.protobuf.AbstractMessage.Builder<TlsSessionTicketKeys.Builder>
- Throws:
java.io.IOException
-
ensureKeysIsMutable
private void ensureKeysIsMutable()
-
getKeysList
public java.util.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_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
repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
- Specified by:
getKeysList
in interfaceTlsSessionTicketKeysOrBuilder
-
getKeysCount
public 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_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
repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
- Specified by:
getKeysCount
in interfaceTlsSessionTicketKeysOrBuilder
-
getKeys
public 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_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
repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
- Specified by:
getKeys
in interfaceTlsSessionTicketKeysOrBuilder
-
setKeys
public 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_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
repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
-
setKeys
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_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
repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
-
addKeys
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_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
repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
-
addKeys
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_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
repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
-
addKeys
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_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
repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
-
addKeys
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_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
repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
-
addAllKeys
public TlsSessionTicketKeys.Builder addAllKeys(java.lang.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_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
repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
-
clearKeys
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_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
repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
-
removeKeys
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_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
repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
-
getKeysBuilder
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_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
repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
-
getKeysOrBuilder
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_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
repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
- Specified by:
getKeysOrBuilder
in interfaceTlsSessionTicketKeysOrBuilder
-
getKeysOrBuilderList
public java.util.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_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
repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
- Specified by:
getKeysOrBuilderList
in interfaceTlsSessionTicketKeysOrBuilder
-
addKeysBuilder
public 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_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
repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
-
addKeysBuilder
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_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
repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
-
getKeysBuilderList
public java.util.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_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
repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
-
getKeysFieldBuilder
private com.google.protobuf.RepeatedFieldBuilder<DataSource,DataSource.Builder,DataSourceOrBuilder> getKeysFieldBuilder()
-
-