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

      All Methods Instance Methods Abstract Methods 
      Modifier and Type Method Description
      DataSource getKeys​(int index)
      Keys for encrypting and decrypting TLS session tickets.
      int getKeysCount()
      Keys for encrypting and decrypting TLS session tickets.
      java.util.List<DataSource> getKeysList()
      Keys for encrypting and decrypting TLS session tickets.
      DataSourceOrBuilder getKeysOrBuilder​(int index)
      Keys for encrypting and decrypting TLS session tickets.
      java.util.List<? extends DataSourceOrBuilder> getKeysOrBuilderList()
      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 Detail

      • getKeysList

        java.util.List<DataSource> getKeysList()
         Keys for encrypting and decrypting TLS session tickets. The
         first key in the array contains the key to encrypt all new sessions created by this context.
         All keys are candidates for decrypting received tickets. This allows for easy rotation of keys
         by, for example, putting the new key first, and the previous key second.
        
         If :ref:`session_ticket_keys <envoy_v3_api_field_extensions.transport_sockets.tls.v3.DownstreamTlsContext.session_ticket_keys>`
         is not specified, the TLS library will still support resuming sessions via tickets, but it will
         use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
         or on different hosts.
        
         Each key must contain exactly 80 bytes of cryptographically-secure random data. For
         example, the output of ``openssl rand 80``.
        
         .. attention::
        
         Using this feature has serious security considerations and risks. Improper handling of keys
         may result in loss of secrecy in connections, even if ciphers supporting perfect forward
         secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
         discussion. To minimize the risk, you must:
        
         * Keep the session ticket keys at least as secure as your TLS certificate private keys
         * Rotate session ticket keys at least daily, and preferably hourly
         * Always generate keys using a cryptographically-secure random data source
         
        repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
      • 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

        java.util.List<? extends DataSourceOrBuilder> getKeysOrBuilderList()
         Keys for encrypting and decrypting TLS session tickets. The
         first key in the array contains the key to encrypt all new sessions created by this context.
         All keys are candidates for decrypting received tickets. This allows for easy rotation of keys
         by, for example, putting the new key first, and the previous key second.
        
         If :ref:`session_ticket_keys <envoy_v3_api_field_extensions.transport_sockets.tls.v3.DownstreamTlsContext.session_ticket_keys>`
         is not specified, the TLS library will still support resuming sessions via tickets, but it will
         use an internally-generated and managed key, so sessions cannot be resumed across hot restarts
         or on different hosts.
        
         Each key must contain exactly 80 bytes of cryptographically-secure random data. For
         example, the output of ``openssl rand 80``.
        
         .. attention::
        
         Using this feature has serious security considerations and risks. Improper handling of keys
         may result in loss of secrecy in connections, even if ciphers supporting perfect forward
         secrecy are used. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for some
         discussion. To minimize the risk, you must:
        
         * Keep the session ticket keys at least as secure as your TLS certificate private keys
         * Rotate session ticket keys at least daily, and preferably hourly
         * Always generate keys using a cryptographically-secure random data source
         
        repeated .envoy.config.core.v3.DataSource keys = 1 [(.validate.rules) = { ... }
      • 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) = { ... }