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

Class TlsSessionTicketKeys.Builder

    • Method Detail

      • getDescriptor

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

      • internalGetFieldAccessorTable

        protected com.google.protobuf.GeneratedMessageV3.FieldAccessorTable internalGetFieldAccessorTable()
        Specified by:
        internalGetFieldAccessorTable in class com.google.protobuf.GeneratedMessageV3.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.GeneratedMessageV3.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.GeneratedMessageV3.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

      • clone

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

      • setField

        public TlsSessionTicketKeys.Builder setField​(com.google.protobuf.Descriptors.FieldDescriptor field,
                                             Object value)
        Specified by:
        setField in interface com.google.protobuf.Message.Builder
        Overrides:
        setField in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>

      • clearField

        public TlsSessionTicketKeys.Builder clearField​(com.google.protobuf.Descriptors.FieldDescriptor field)
        Specified by:
        clearField in interface com.google.protobuf.Message.Builder
        Overrides:
        clearField in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>

      • clearOneof

        public TlsSessionTicketKeys.Builder clearOneof​(com.google.protobuf.Descriptors.OneofDescriptor oneof)
        Specified by:
        clearOneof in interface com.google.protobuf.Message.Builder
        Overrides:
        clearOneof in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>

      • setRepeatedField

        public TlsSessionTicketKeys.Builder setRepeatedField​(com.google.protobuf.Descriptors.FieldDescriptor field,
                                                     int index,
                                                     Object value)
        Specified by:
        setRepeatedField in interface com.google.protobuf.Message.Builder
        Overrides:
        setRepeatedField in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>

      • addRepeatedField

        public TlsSessionTicketKeys.Builder addRepeatedField​(com.google.protobuf.Descriptors.FieldDescriptor field,
                                                     Object value)
        Specified by:
        addRepeatedField in interface com.google.protobuf.Message.Builder
        Overrides:
        addRepeatedField in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>

      • isInitialized

        public final boolean isInitialized()
        Specified by:
        isInitialized in interface com.google.protobuf.MessageLiteOrBuilder
        Overrides:
        isInitialized in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>

      • mergeFrom

        public TlsSessionTicketKeys.Builder mergeFrom​(com.google.protobuf.CodedInputStream input,
                                              com.google.protobuf.ExtensionRegistryLite extensionRegistry)
                                       throws 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:
        IOException

      • getKeysList

        public 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​(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 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 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) = { ... }

      • setUnknownFields

        public final TlsSessionTicketKeys.Builder setUnknownFields​(com.google.protobuf.UnknownFieldSet unknownFields)
        Specified by:
        setUnknownFields in interface com.google.protobuf.Message.Builder
        Overrides:
        setUnknownFields in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>

      • mergeUnknownFields

        public final TlsSessionTicketKeys.Builder mergeUnknownFields​(com.google.protobuf.UnknownFieldSet unknownFields)
        Specified by:
        mergeUnknownFields in interface com.google.protobuf.Message.Builder
        Overrides:
        mergeUnknownFields in class com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>