Package io.envoyproxy.envoy.api.v2.auth

Class TlsSessionTicketKeys.Builder

java.lang.Object
com.google.protobuf.AbstractMessageLite.Builder
com.google.protobuf.AbstractMessage.Builder<BuilderT>
com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder>
io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys.Builder
All Implemented Interfaces:
com.google.protobuf.Message.Builder, com.google.protobuf.MessageLite.Builder, com.google.protobuf.MessageLiteOrBuilder, com.google.protobuf.MessageOrBuilder, TlsSessionTicketKeysOrBuilder, Cloneable
Enclosing class:
TlsSessionTicketKeys
public static final class TlsSessionTicketKeys.Builder extends com.google.protobuf.GeneratedMessageV3.Builder<TlsSessionTicketKeys.Builder> implements TlsSessionTicketKeysOrBuilder
Protobuf type envoy.api.v2.auth.TlsSessionTicketKeys

  • Method Details

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

    • mergeFrom

      public TlsSessionTicketKeys.Builder mergeFrom(com.google.protobuf.Message other)
      Specified by:
      mergeFrom in interface com.google.protobuf.Message.Builder
      Overrides:
      mergeFrom in class com.google.protobuf.AbstractMessage.Builder<TlsSessionTicketKeys.Builder>

    • mergeFrom

      public TlsSessionTicketKeys.Builder mergeFrom(TlsSessionTicketKeys other)

    • 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_api_field_auth.DownstreamTlsContext.session_ticket_keys>`
 is not specified, the TLS library will still support resuming sessions via tickets, but it will
 use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
 or on different hosts.

 Each key must contain exactly 80 bytes of cryptographically-secure random data. For
 example, the output of ``openssl rand 80``.

 .. attention::

   Using this feature has serious security considerations and risks. Improper handling of keys
   may result in loss of secrecy in connections, even if ciphers supporting perfect forward
   secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
   discussion. To minimize the risk, you must:

   * Keep the session ticket keys at least as secure as your TLS certificate private keys
   * Rotate session ticket keys at least daily, and preferably hourly
   * Always generate keys using a cryptographically-secure random data source
      repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }
      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_api_field_auth.DownstreamTlsContext.session_ticket_keys>`
 is not specified, the TLS library will still support resuming sessions via tickets, but it will
 use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
 or on different hosts.

 Each key must contain exactly 80 bytes of cryptographically-secure random data. For
 example, the output of ``openssl rand 80``.

 .. attention::

   Using this feature has serious security considerations and risks. Improper handling of keys
   may result in loss of secrecy in connections, even if ciphers supporting perfect forward
   secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
   discussion. To minimize the risk, you must:

   * Keep the session ticket keys at least as secure as your TLS certificate private keys
   * Rotate session ticket keys at least daily, and preferably hourly
   * Always generate keys using a cryptographically-secure random data source
      repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }
      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_api_field_auth.DownstreamTlsContext.session_ticket_keys>`
 is not specified, the TLS library will still support resuming sessions via tickets, but it will
 use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
 or on different hosts.

 Each key must contain exactly 80 bytes of cryptographically-secure random data. For
 example, the output of ``openssl rand 80``.

 .. attention::

   Using this feature has serious security considerations and risks. Improper handling of keys
   may result in loss of secrecy in connections, even if ciphers supporting perfect forward
   secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
   discussion. To minimize the risk, you must:

   * Keep the session ticket keys at least as secure as your TLS certificate private keys
   * Rotate session ticket keys at least daily, and preferably hourly
   * Always generate keys using a cryptographically-secure random data source
      repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }
      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_api_field_auth.DownstreamTlsContext.session_ticket_keys>`
 is not specified, the TLS library will still support resuming sessions via tickets, but it will
 use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
 or on different hosts.

 Each key must contain exactly 80 bytes of cryptographically-secure random data. For
 example, the output of ``openssl rand 80``.

 .. attention::

   Using this feature has serious security considerations and risks. Improper handling of keys
   may result in loss of secrecy in connections, even if ciphers supporting perfect forward
   secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
   discussion. To minimize the risk, you must:

   * Keep the session ticket keys at least as secure as your TLS certificate private keys
   * Rotate session ticket keys at least daily, and preferably hourly
   * Always generate keys using a cryptographically-secure random data source
      repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }

    • 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_api_field_auth.DownstreamTlsContext.session_ticket_keys>`
 is not specified, the TLS library will still support resuming sessions via tickets, but it will
 use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
 or on different hosts.

 Each key must contain exactly 80 bytes of cryptographically-secure random data. For
 example, the output of ``openssl rand 80``.

 .. attention::

   Using this feature has serious security considerations and risks. Improper handling of keys
   may result in loss of secrecy in connections, even if ciphers supporting perfect forward
   secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
   discussion. To minimize the risk, you must:

   * Keep the session ticket keys at least as secure as your TLS certificate private keys
   * Rotate session ticket keys at least daily, and preferably hourly
   * Always generate keys using a cryptographically-secure random data source
      repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }

    • 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_api_field_auth.DownstreamTlsContext.session_ticket_keys>`
 is not specified, the TLS library will still support resuming sessions via tickets, but it will
 use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
 or on different hosts.

 Each key must contain exactly 80 bytes of cryptographically-secure random data. For
 example, the output of ``openssl rand 80``.

 .. attention::

   Using this feature has serious security considerations and risks. Improper handling of keys
   may result in loss of secrecy in connections, even if ciphers supporting perfect forward
   secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
   discussion. To minimize the risk, you must:

   * Keep the session ticket keys at least as secure as your TLS certificate private keys
   * Rotate session ticket keys at least daily, and preferably hourly
   * Always generate keys using a cryptographically-secure random data source
      repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }

    • 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_api_field_auth.DownstreamTlsContext.session_ticket_keys>`
 is not specified, the TLS library will still support resuming sessions via tickets, but it will
 use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
 or on different hosts.

 Each key must contain exactly 80 bytes of cryptographically-secure random data. For
 example, the output of ``openssl rand 80``.

 .. attention::

   Using this feature has serious security considerations and risks. Improper handling of keys
   may result in loss of secrecy in connections, even if ciphers supporting perfect forward
   secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
   discussion. To minimize the risk, you must:

   * Keep the session ticket keys at least as secure as your TLS certificate private keys
   * Rotate session ticket keys at least daily, and preferably hourly
   * Always generate keys using a cryptographically-secure random data source
      repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }

    • 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_api_field_auth.DownstreamTlsContext.session_ticket_keys>`
 is not specified, the TLS library will still support resuming sessions via tickets, but it will
 use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
 or on different hosts.

 Each key must contain exactly 80 bytes of cryptographically-secure random data. For
 example, the output of ``openssl rand 80``.

 .. attention::

   Using this feature has serious security considerations and risks. Improper handling of keys
   may result in loss of secrecy in connections, even if ciphers supporting perfect forward
   secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
   discussion. To minimize the risk, you must:

   * Keep the session ticket keys at least as secure as your TLS certificate private keys
   * Rotate session ticket keys at least daily, and preferably hourly
   * Always generate keys using a cryptographically-secure random data source
      repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }

    • 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_api_field_auth.DownstreamTlsContext.session_ticket_keys>`
 is not specified, the TLS library will still support resuming sessions via tickets, but it will
 use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
 or on different hosts.

 Each key must contain exactly 80 bytes of cryptographically-secure random data. For
 example, the output of ``openssl rand 80``.

 .. attention::

   Using this feature has serious security considerations and risks. Improper handling of keys
   may result in loss of secrecy in connections, even if ciphers supporting perfect forward
   secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
   discussion. To minimize the risk, you must:

   * Keep the session ticket keys at least as secure as your TLS certificate private keys
   * Rotate session ticket keys at least daily, and preferably hourly
   * Always generate keys using a cryptographically-secure random data source
      repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }

    • 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_api_field_auth.DownstreamTlsContext.session_ticket_keys>`
 is not specified, the TLS library will still support resuming sessions via tickets, but it will
 use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
 or on different hosts.

 Each key must contain exactly 80 bytes of cryptographically-secure random data. For
 example, the output of ``openssl rand 80``.

 .. attention::

   Using this feature has serious security considerations and risks. Improper handling of keys
   may result in loss of secrecy in connections, even if ciphers supporting perfect forward
   secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
   discussion. To minimize the risk, you must:

   * Keep the session ticket keys at least as secure as your TLS certificate private keys
   * Rotate session ticket keys at least daily, and preferably hourly
   * Always generate keys using a cryptographically-secure random data source
      repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }

    • 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_api_field_auth.DownstreamTlsContext.session_ticket_keys>`
 is not specified, the TLS library will still support resuming sessions via tickets, but it will
 use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
 or on different hosts.

 Each key must contain exactly 80 bytes of cryptographically-secure random data. For
 example, the output of ``openssl rand 80``.

 .. attention::

   Using this feature has serious security considerations and risks. Improper handling of keys
   may result in loss of secrecy in connections, even if ciphers supporting perfect forward
   secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
   discussion. To minimize the risk, you must:

   * Keep the session ticket keys at least as secure as your TLS certificate private keys
   * Rotate session ticket keys at least daily, and preferably hourly
   * Always generate keys using a cryptographically-secure random data source
      repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }

    • 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_api_field_auth.DownstreamTlsContext.session_ticket_keys>`
 is not specified, the TLS library will still support resuming sessions via tickets, but it will
 use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
 or on different hosts.

 Each key must contain exactly 80 bytes of cryptographically-secure random data. For
 example, the output of ``openssl rand 80``.

 .. attention::

   Using this feature has serious security considerations and risks. Improper handling of keys
   may result in loss of secrecy in connections, even if ciphers supporting perfect forward
   secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
   discussion. To minimize the risk, you must:

   * Keep the session ticket keys at least as secure as your TLS certificate private keys
   * Rotate session ticket keys at least daily, and preferably hourly
   * Always generate keys using a cryptographically-secure random data source
      repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }

    • 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_api_field_auth.DownstreamTlsContext.session_ticket_keys>`
 is not specified, the TLS library will still support resuming sessions via tickets, but it will
 use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
 or on different hosts.

 Each key must contain exactly 80 bytes of cryptographically-secure random data. For
 example, the output of ``openssl rand 80``.

 .. attention::

   Using this feature has serious security considerations and risks. Improper handling of keys
   may result in loss of secrecy in connections, even if ciphers supporting perfect forward
   secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
   discussion. To minimize the risk, you must:

   * Keep the session ticket keys at least as secure as your TLS certificate private keys
   * Rotate session ticket keys at least daily, and preferably hourly
   * Always generate keys using a cryptographically-secure random data source
      repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }

    • getKeysOrBuilder

      public DataSourceOrBuilder getKeysOrBuilder(int index)
       Keys for encrypting and decrypting TLS session tickets. The
 first key in the array contains the key to encrypt all new sessions created by this context.
 All keys are candidates for decrypting received tickets. This allows for easy rotation of keys
 by, for example, putting the new key first, and the previous key second.

 If :ref:`session_ticket_keys <envoy_api_field_auth.DownstreamTlsContext.session_ticket_keys>`
 is not specified, the TLS library will still support resuming sessions via tickets, but it will
 use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
 or on different hosts.

 Each key must contain exactly 80 bytes of cryptographically-secure random data. For
 example, the output of ``openssl rand 80``.

 .. attention::

   Using this feature has serious security considerations and risks. Improper handling of keys
   may result in loss of secrecy in connections, even if ciphers supporting perfect forward
   secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
   discussion. To minimize the risk, you must:

   * Keep the session ticket keys at least as secure as your TLS certificate private keys
   * Rotate session ticket keys at least daily, and preferably hourly
   * Always generate keys using a cryptographically-secure random data source
      repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }
      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_api_field_auth.DownstreamTlsContext.session_ticket_keys>`
 is not specified, the TLS library will still support resuming sessions via tickets, but it will
 use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
 or on different hosts.

 Each key must contain exactly 80 bytes of cryptographically-secure random data. For
 example, the output of ``openssl rand 80``.

 .. attention::

   Using this feature has serious security considerations and risks. Improper handling of keys
   may result in loss of secrecy in connections, even if ciphers supporting perfect forward
   secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
   discussion. To minimize the risk, you must:

   * Keep the session ticket keys at least as secure as your TLS certificate private keys
   * Rotate session ticket keys at least daily, and preferably hourly
   * Always generate keys using a cryptographically-secure random data source
      repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }
      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_api_field_auth.DownstreamTlsContext.session_ticket_keys>`
 is not specified, the TLS library will still support resuming sessions via tickets, but it will
 use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
 or on different hosts.

 Each key must contain exactly 80 bytes of cryptographically-secure random data. For
 example, the output of ``openssl rand 80``.

 .. attention::

   Using this feature has serious security considerations and risks. Improper handling of keys
   may result in loss of secrecy in connections, even if ciphers supporting perfect forward
   secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
   discussion. To minimize the risk, you must:

   * Keep the session ticket keys at least as secure as your TLS certificate private keys
   * Rotate session ticket keys at least daily, and preferably hourly
   * Always generate keys using a cryptographically-secure random data source
      repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }

    • 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_api_field_auth.DownstreamTlsContext.session_ticket_keys>`
 is not specified, the TLS library will still support resuming sessions via tickets, but it will
 use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
 or on different hosts.

 Each key must contain exactly 80 bytes of cryptographically-secure random data. For
 example, the output of ``openssl rand 80``.

 .. attention::

   Using this feature has serious security considerations and risks. Improper handling of keys
   may result in loss of secrecy in connections, even if ciphers supporting perfect forward
   secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
   discussion. To minimize the risk, you must:

   * Keep the session ticket keys at least as secure as your TLS certificate private keys
   * Rotate session ticket keys at least daily, and preferably hourly
   * Always generate keys using a cryptographically-secure random data source
      repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }

    • 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_api_field_auth.DownstreamTlsContext.session_ticket_keys>`
 is not specified, the TLS library will still support resuming sessions via tickets, but it will
 use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
 or on different hosts.

 Each key must contain exactly 80 bytes of cryptographically-secure random data. For
 example, the output of ``openssl rand 80``.

 .. attention::

   Using this feature has serious security considerations and risks. Improper handling of keys
   may result in loss of secrecy in connections, even if ciphers supporting perfect forward
   secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
   discussion. To minimize the risk, you must:

   * Keep the session ticket keys at least as secure as your TLS certificate private keys
   * Rotate session ticket keys at least daily, and preferably hourly
   * Always generate keys using a cryptographically-secure random data source
      repeated .envoy.api.v2.core.DataSource keys = 1 [(.validate.rules) = { ... }

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