Class TlsSessionTicketKeys.Builder

java.lang.Object
com.google.protobuf.AbstractMessageLite.Builder
com.google.protobuf.AbstractMessage.Builder<TlsSessionTicketKeys.Builder>
com.google.protobuf.GeneratedMessage.Builder<TlsSessionTicketKeys.Builder>
io.envoyproxy.envoy.extensions.transport_sockets.tls.v3.TlsSessionTicketKeys.Builder
All Implemented Interfaces:
com.google.protobuf.Message.Builder, com.google.protobuf.MessageLite.Builder, com.google.protobuf.MessageLiteOrBuilder, com.google.protobuf.MessageOrBuilder, TlsSessionTicketKeysOrBuilder, 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

  • Field Details

  • Constructor Details

    • Builder

      private Builder()

    • Builder

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

  • Method Details

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

    • buildPartial0

      private void buildPartial0(TlsSessionTicketKeys result)

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

    • ensureKeysIsMutable

      private void ensureKeysIsMutable()

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

    • internalGetKeysFieldBuilder

      private com.google.protobuf.RepeatedFieldBuilder<DataSource, DataSource.Builder, DataSourceOrBuilder> internalGetKeysFieldBuilder()