Interface TlsSessionTicketKeysOrBuilder

All Superinterfaces:
com.google.protobuf.MessageLiteOrBuilder, com.google.protobuf.MessageOrBuilder
All Known Implementing Classes:
TlsSessionTicketKeys, TlsSessionTicketKeys.Builder

public interface TlsSessionTicketKeysOrBuilder extends com.google.protobuf.MessageOrBuilder
  • Method Summary

    Modifier and Type
    Method
    Description
    getKeys(int index)
    Keys for encrypting and decrypting TLS session tickets.
    int
    Keys for encrypting and decrypting TLS session tickets.
    Keys for encrypting and decrypting TLS session tickets.
    getKeysOrBuilder(int index)
    Keys for encrypting and decrypting TLS session tickets.
    Keys for encrypting and decrypting TLS session tickets.

    Methods inherited from interface com.google.protobuf.MessageLiteOrBuilder

    isInitialized

    Methods inherited from interface com.google.protobuf.MessageOrBuilder

    findInitializationErrors, getAllFields, getDefaultInstanceForType, getDescriptorForType, getField, getInitializationErrorString, getOneofFieldDescriptor, getRepeatedField, getRepeatedFieldCount, getUnknownFields, hasField, hasOneof
  • Method Details

    • getKeysList

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

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

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

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

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