Package io.envoyproxy.envoy.extensions.transport_sockets.tls.v3

Class 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 type envoy.extensions.transport_sockets.tls.v3.TlsSessionTicketKeys

    • Constructor Detail

      • Builder

        private Builder()

      • Builder

        private Builder​(com.google.protobuf.AbstractMessage.BuilderParent parent)

    • Method Detail

      • getDescriptor

        public static final com.google.protobuf.Descriptors.Descriptor getDescriptor()

      • internalGetFieldAccessorTable

        protected com.google.protobuf.GeneratedMessage.FieldAccessorTable internalGetFieldAccessorTable()
        Specified by:
        internalGetFieldAccessorTable in class com.google.protobuf.GeneratedMessage.Builder<TlsSessionTicketKeys.Builder>

      • clear

        public TlsSessionTicketKeys.Builder clear()
        Specified by:
        clear in interface com.google.protobuf.Message.Builder
        Specified by:
        clear in interface com.google.protobuf.MessageLite.Builder
        Overrides:
        clear in class com.google.protobuf.GeneratedMessage.Builder<TlsSessionTicketKeys.Builder>

      • getDescriptorForType

        public com.google.protobuf.Descriptors.Descriptor getDescriptorForType()
        Specified by:
        getDescriptorForType in interface com.google.protobuf.Message.Builder
        Specified by:
        getDescriptorForType in interface com.google.protobuf.MessageOrBuilder
        Overrides:
        getDescriptorForType in class com.google.protobuf.GeneratedMessage.Builder<TlsSessionTicketKeys.Builder>

      • getDefaultInstanceForType

        public TlsSessionTicketKeys getDefaultInstanceForType()
        Specified by:
        getDefaultInstanceForType in interface com.google.protobuf.MessageLiteOrBuilder
        Specified by:
        getDefaultInstanceForType in interface com.google.protobuf.MessageOrBuilder

      • build

        public TlsSessionTicketKeys build()
        Specified by:
        build in interface com.google.protobuf.Message.Builder
        Specified by:
        build in interface com.google.protobuf.MessageLite.Builder

      • buildPartial

        public TlsSessionTicketKeys buildPartial()
        Specified by:
        buildPartial in interface com.google.protobuf.Message.Builder
        Specified by:
        buildPartial in interface com.google.protobuf.MessageLite.Builder

      • buildPartialRepeatedFields

        private void buildPartialRepeatedFields​(TlsSessionTicketKeys result)

      • isInitialized

        public final boolean isInitialized()
        Specified by:
        isInitialized in interface com.google.protobuf.MessageLiteOrBuilder
        Overrides:
        isInitialized in class com.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 interface com.google.protobuf.Message.Builder
        Specified by:
        mergeFrom in interface com.google.protobuf.MessageLite.Builder
        Overrides:
        mergeFrom in class com.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 interface TlsSessionTicketKeysOrBuilder

      • 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 interface TlsSessionTicketKeysOrBuilder

      • 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 interface TlsSessionTicketKeysOrBuilder

      • 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 interface TlsSessionTicketKeysOrBuilder

      • 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 interface TlsSessionTicketKeysOrBuilder

      • 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) = { ... }