io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys Maven / Gradle / Ivy
The newest version!
// Generated by the protocol buffer compiler. DO NOT EDIT!
// source: envoy/api/v2/auth/common.proto
package io.envoyproxy.envoy.api.v2.auth;
/**
* Protobuf type {@code envoy.api.v2.auth.TlsSessionTicketKeys}
*/
public final class TlsSessionTicketKeys extends
com.google.protobuf.GeneratedMessageV3 implements
// @@protoc_insertion_point(message_implements:envoy.api.v2.auth.TlsSessionTicketKeys)
TlsSessionTicketKeysOrBuilder {
private static final long serialVersionUID = 0L;
// Use TlsSessionTicketKeys.newBuilder() to construct.
private TlsSessionTicketKeys(com.google.protobuf.GeneratedMessageV3.Builder builder) {
super(builder);
}
private TlsSessionTicketKeys() {
keys_ = java.util.Collections.emptyList();
}
@java.lang.Override
@SuppressWarnings({"unused"})
protected java.lang.Object newInstance(
UnusedPrivateParameter unused) {
return new TlsSessionTicketKeys();
}
@java.lang.Override
public final com.google.protobuf.UnknownFieldSet
getUnknownFields() {
return this.unknownFields;
}
private TlsSessionTicketKeys(
com.google.protobuf.CodedInputStream input,
com.google.protobuf.ExtensionRegistryLite extensionRegistry)
throws com.google.protobuf.InvalidProtocolBufferException {
this();
if (extensionRegistry == null) {
throw new java.lang.NullPointerException();
}
int mutable_bitField0_ = 0;
com.google.protobuf.UnknownFieldSet.Builder unknownFields =
com.google.protobuf.UnknownFieldSet.newBuilder();
try {
boolean done = false;
while (!done) {
int tag = input.readTag();
switch (tag) {
case 0:
done = true;
break;
case 10: {
if (!((mutable_bitField0_ & 0x00000001) != 0)) {
keys_ = new java.util.ArrayList();
mutable_bitField0_ |= 0x00000001;
}
keys_.add(
input.readMessage(io.envoyproxy.envoy.api.v2.core.DataSource.parser(), extensionRegistry));
break;
}
default: {
if (!parseUnknownField(
input, unknownFields, extensionRegistry, tag)) {
done = true;
}
break;
}
}
}
} catch (com.google.protobuf.InvalidProtocolBufferException e) {
throw e.setUnfinishedMessage(this);
} catch (com.google.protobuf.UninitializedMessageException e) {
throw e.asInvalidProtocolBufferException().setUnfinishedMessage(this);
} catch (java.io.IOException e) {
throw new com.google.protobuf.InvalidProtocolBufferException(
e).setUnfinishedMessage(this);
} finally {
if (((mutable_bitField0_ & 0x00000001) != 0)) {
keys_ = java.util.Collections.unmodifiableList(keys_);
}
this.unknownFields = unknownFields.build();
makeExtensionsImmutable();
}
}
public static final com.google.protobuf.Descriptors.Descriptor
getDescriptor() {
return io.envoyproxy.envoy.api.v2.auth.CommonProto.internal_static_envoy_api_v2_auth_TlsSessionTicketKeys_descriptor;
}
@java.lang.Override
protected com.google.protobuf.GeneratedMessageV3.FieldAccessorTable
internalGetFieldAccessorTable() {
return io.envoyproxy.envoy.api.v2.auth.CommonProto.internal_static_envoy_api_v2_auth_TlsSessionTicketKeys_fieldAccessorTable
.ensureFieldAccessorsInitialized(
io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys.class, io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys.Builder.class);
}
public static final int KEYS_FIELD_NUMBER = 1;
private java.util.List keys_;
/**
*
* 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) = { ... }
*/
@java.lang.Override
public java.util.List getKeysList() {
return keys_;
}
/**
*
* 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) = { ... }
*/
@java.lang.Override
public java.util.List
getKeysOrBuilderList() {
return keys_;
}
/**
*
* 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) = { ... }
*/
@java.lang.Override
public int getKeysCount() {
return keys_.size();
}
/**
*
* 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) = { ... }
*/
@java.lang.Override
public io.envoyproxy.envoy.api.v2.core.DataSource getKeys(int index) {
return keys_.get(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) = { ... }
*/
@java.lang.Override
public io.envoyproxy.envoy.api.v2.core.DataSourceOrBuilder getKeysOrBuilder(
int index) {
return keys_.get(index);
}
private byte memoizedIsInitialized = -1;
@java.lang.Override
public final boolean isInitialized() {
byte isInitialized = memoizedIsInitialized;
if (isInitialized == 1) return true;
if (isInitialized == 0) return false;
memoizedIsInitialized = 1;
return true;
}
@java.lang.Override
public void writeTo(com.google.protobuf.CodedOutputStream output)
throws java.io.IOException {
for (int i = 0; i < keys_.size(); i++) {
output.writeMessage(1, keys_.get(i));
}
unknownFields.writeTo(output);
}
@java.lang.Override
public int getSerializedSize() {
int size = memoizedSize;
if (size != -1) return size;
size = 0;
for (int i = 0; i < keys_.size(); i++) {
size += com.google.protobuf.CodedOutputStream
.computeMessageSize(1, keys_.get(i));
}
size += unknownFields.getSerializedSize();
memoizedSize = size;
return size;
}
@java.lang.Override
public boolean equals(final java.lang.Object obj) {
if (obj == this) {
return true;
}
if (!(obj instanceof io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys)) {
return super.equals(obj);
}
io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys other = (io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys) obj;
if (!getKeysList()
.equals(other.getKeysList())) return false;
if (!unknownFields.equals(other.unknownFields)) return false;
return true;
}
@java.lang.Override
public int hashCode() {
if (memoizedHashCode != 0) {
return memoizedHashCode;
}
int hash = 41;
hash = (19 * hash) + getDescriptor().hashCode();
if (getKeysCount() > 0) {
hash = (37 * hash) + KEYS_FIELD_NUMBER;
hash = (53 * hash) + getKeysList().hashCode();
}
hash = (29 * hash) + unknownFields.hashCode();
memoizedHashCode = hash;
return hash;
}
public static io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys parseFrom(
java.nio.ByteBuffer data)
throws com.google.protobuf.InvalidProtocolBufferException {
return PARSER.parseFrom(data);
}
public static io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys parseFrom(
java.nio.ByteBuffer data,
com.google.protobuf.ExtensionRegistryLite extensionRegistry)
throws com.google.protobuf.InvalidProtocolBufferException {
return PARSER.parseFrom(data, extensionRegistry);
}
public static io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys parseFrom(
com.google.protobuf.ByteString data)
throws com.google.protobuf.InvalidProtocolBufferException {
return PARSER.parseFrom(data);
}
public static io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys parseFrom(
com.google.protobuf.ByteString data,
com.google.protobuf.ExtensionRegistryLite extensionRegistry)
throws com.google.protobuf.InvalidProtocolBufferException {
return PARSER.parseFrom(data, extensionRegistry);
}
public static io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys parseFrom(byte[] data)
throws com.google.protobuf.InvalidProtocolBufferException {
return PARSER.parseFrom(data);
}
public static io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys parseFrom(
byte[] data,
com.google.protobuf.ExtensionRegistryLite extensionRegistry)
throws com.google.protobuf.InvalidProtocolBufferException {
return PARSER.parseFrom(data, extensionRegistry);
}
public static io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys parseFrom(java.io.InputStream input)
throws java.io.IOException {
return com.google.protobuf.GeneratedMessageV3
.parseWithIOException(PARSER, input);
}
public static io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys parseFrom(
java.io.InputStream input,
com.google.protobuf.ExtensionRegistryLite extensionRegistry)
throws java.io.IOException {
return com.google.protobuf.GeneratedMessageV3
.parseWithIOException(PARSER, input, extensionRegistry);
}
public static io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys parseDelimitedFrom(java.io.InputStream input)
throws java.io.IOException {
return com.google.protobuf.GeneratedMessageV3
.parseDelimitedWithIOException(PARSER, input);
}
public static io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys parseDelimitedFrom(
java.io.InputStream input,
com.google.protobuf.ExtensionRegistryLite extensionRegistry)
throws java.io.IOException {
return com.google.protobuf.GeneratedMessageV3
.parseDelimitedWithIOException(PARSER, input, extensionRegistry);
}
public static io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys parseFrom(
com.google.protobuf.CodedInputStream input)
throws java.io.IOException {
return com.google.protobuf.GeneratedMessageV3
.parseWithIOException(PARSER, input);
}
public static io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys parseFrom(
com.google.protobuf.CodedInputStream input,
com.google.protobuf.ExtensionRegistryLite extensionRegistry)
throws java.io.IOException {
return com.google.protobuf.GeneratedMessageV3
.parseWithIOException(PARSER, input, extensionRegistry);
}
@java.lang.Override
public Builder newBuilderForType() { return newBuilder(); }
public static Builder newBuilder() {
return DEFAULT_INSTANCE.toBuilder();
}
public static Builder newBuilder(io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys prototype) {
return DEFAULT_INSTANCE.toBuilder().mergeFrom(prototype);
}
@java.lang.Override
public Builder toBuilder() {
return this == DEFAULT_INSTANCE
? new Builder() : new Builder().mergeFrom(this);
}
@java.lang.Override
protected Builder newBuilderForType(
com.google.protobuf.GeneratedMessageV3.BuilderParent parent) {
Builder builder = new Builder(parent);
return builder;
}
/**
* Protobuf type {@code envoy.api.v2.auth.TlsSessionTicketKeys}
*/
public static final class Builder extends
com.google.protobuf.GeneratedMessageV3.Builder implements
// @@protoc_insertion_point(builder_implements:envoy.api.v2.auth.TlsSessionTicketKeys)
io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeysOrBuilder {
public static final com.google.protobuf.Descriptors.Descriptor
getDescriptor() {
return io.envoyproxy.envoy.api.v2.auth.CommonProto.internal_static_envoy_api_v2_auth_TlsSessionTicketKeys_descriptor;
}
@java.lang.Override
protected com.google.protobuf.GeneratedMessageV3.FieldAccessorTable
internalGetFieldAccessorTable() {
return io.envoyproxy.envoy.api.v2.auth.CommonProto.internal_static_envoy_api_v2_auth_TlsSessionTicketKeys_fieldAccessorTable
.ensureFieldAccessorsInitialized(
io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys.class, io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys.Builder.class);
}
// Construct using io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys.newBuilder()
private Builder() {
maybeForceBuilderInitialization();
}
private Builder(
com.google.protobuf.GeneratedMessageV3.BuilderParent parent) {
super(parent);
maybeForceBuilderInitialization();
}
private void maybeForceBuilderInitialization() {
if (com.google.protobuf.GeneratedMessageV3
.alwaysUseFieldBuilders) {
getKeysFieldBuilder();
}
}
@java.lang.Override
public Builder clear() {
super.clear();
if (keysBuilder_ == null) {
keys_ = java.util.Collections.emptyList();
bitField0_ = (bitField0_ & ~0x00000001);
} else {
keysBuilder_.clear();
}
return this;
}
@java.lang.Override
public com.google.protobuf.Descriptors.Descriptor
getDescriptorForType() {
return io.envoyproxy.envoy.api.v2.auth.CommonProto.internal_static_envoy_api_v2_auth_TlsSessionTicketKeys_descriptor;
}
@java.lang.Override
public io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys getDefaultInstanceForType() {
return io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys.getDefaultInstance();
}
@java.lang.Override
public io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys build() {
io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys result = buildPartial();
if (!result.isInitialized()) {
throw newUninitializedMessageException(result);
}
return result;
}
@java.lang.Override
public io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys buildPartial() {
io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys result = new io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys(this);
int from_bitField0_ = bitField0_;
if (keysBuilder_ == null) {
if (((bitField0_ & 0x00000001) != 0)) {
keys_ = java.util.Collections.unmodifiableList(keys_);
bitField0_ = (bitField0_ & ~0x00000001);
}
result.keys_ = keys_;
} else {
result.keys_ = keysBuilder_.build();
}
onBuilt();
return result;
}
@java.lang.Override
public Builder clone() {
return super.clone();
}
@java.lang.Override
public Builder setField(
com.google.protobuf.Descriptors.FieldDescriptor field,
java.lang.Object value) {
return super.setField(field, value);
}
@java.lang.Override
public Builder clearField(
com.google.protobuf.Descriptors.FieldDescriptor field) {
return super.clearField(field);
}
@java.lang.Override
public Builder clearOneof(
com.google.protobuf.Descriptors.OneofDescriptor oneof) {
return super.clearOneof(oneof);
}
@java.lang.Override
public Builder setRepeatedField(
com.google.protobuf.Descriptors.FieldDescriptor field,
int index, java.lang.Object value) {
return super.setRepeatedField(field, index, value);
}
@java.lang.Override
public Builder addRepeatedField(
com.google.protobuf.Descriptors.FieldDescriptor field,
java.lang.Object value) {
return super.addRepeatedField(field, value);
}
@java.lang.Override
public Builder mergeFrom(com.google.protobuf.Message other) {
if (other instanceof io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys) {
return mergeFrom((io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys)other);
} else {
super.mergeFrom(other);
return this;
}
}
public Builder mergeFrom(io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys other) {
if (other == io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys.getDefaultInstance()) return this;
if (keysBuilder_ == null) {
if (!other.keys_.isEmpty()) {
if (keys_.isEmpty()) {
keys_ = other.keys_;
bitField0_ = (bitField0_ & ~0x00000001);
} else {
ensureKeysIsMutable();
keys_.addAll(other.keys_);
}
onChanged();
}
} else {
if (!other.keys_.isEmpty()) {
if (keysBuilder_.isEmpty()) {
keysBuilder_.dispose();
keysBuilder_ = null;
keys_ = other.keys_;
bitField0_ = (bitField0_ & ~0x00000001);
keysBuilder_ =
com.google.protobuf.GeneratedMessageV3.alwaysUseFieldBuilders ?
getKeysFieldBuilder() : null;
} else {
keysBuilder_.addAllMessages(other.keys_);
}
}
}
this.mergeUnknownFields(other.unknownFields);
onChanged();
return this;
}
@java.lang.Override
public final boolean isInitialized() {
return true;
}
@java.lang.Override
public Builder mergeFrom(
com.google.protobuf.CodedInputStream input,
com.google.protobuf.ExtensionRegistryLite extensionRegistry)
throws java.io.IOException {
io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys parsedMessage = null;
try {
parsedMessage = PARSER.parsePartialFrom(input, extensionRegistry);
} catch (com.google.protobuf.InvalidProtocolBufferException e) {
parsedMessage = (io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys) e.getUnfinishedMessage();
throw e.unwrapIOException();
} finally {
if (parsedMessage != null) {
mergeFrom(parsedMessage);
}
}
return this;
}
private int bitField0_;
private java.util.List keys_ =
java.util.Collections.emptyList();
private void ensureKeysIsMutable() {
if (!((bitField0_ & 0x00000001) != 0)) {
keys_ = new java.util.ArrayList(keys_);
bitField0_ |= 0x00000001;
}
}
private com.google.protobuf.RepeatedFieldBuilderV3<
io.envoyproxy.envoy.api.v2.core.DataSource, io.envoyproxy.envoy.api.v2.core.DataSource.Builder, io.envoyproxy.envoy.api.v2.core.DataSourceOrBuilder> keysBuilder_;
/**
*
* 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) = { ... }
*/
public java.util.List getKeysList() {
if (keysBuilder_ == null) {
return java.util.Collections.unmodifiableList(keys_);
} else {
return keysBuilder_.getMessageList();
}
}
/**
*
* 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) = { ... }
*/
public int getKeysCount() {
if (keysBuilder_ == null) {
return keys_.size();
} else {
return keysBuilder_.getCount();
}
}
/**
*
* 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) = { ... }
*/
public io.envoyproxy.envoy.api.v2.core.DataSource getKeys(int index) {
if (keysBuilder_ == null) {
return keys_.get(index);
} else {
return keysBuilder_.getMessage(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) = { ... }
*/
public Builder setKeys(
int index, io.envoyproxy.envoy.api.v2.core.DataSource value) {
if (keysBuilder_ == null) {
if (value == null) {
throw new NullPointerException();
}
ensureKeysIsMutable();
keys_.set(index, value);
onChanged();
} else {
keysBuilder_.setMessage(index, value);
}
return this;
}
/**
*
* 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) = { ... }
*/
public Builder setKeys(
int index, io.envoyproxy.envoy.api.v2.core.DataSource.Builder builderForValue) {
if (keysBuilder_ == null) {
ensureKeysIsMutable();
keys_.set(index, builderForValue.build());
onChanged();
} else {
keysBuilder_.setMessage(index, builderForValue.build());
}
return this;
}
/**
*
* 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) = { ... }
*/
public Builder addKeys(io.envoyproxy.envoy.api.v2.core.DataSource value) {
if (keysBuilder_ == null) {
if (value == null) {
throw new NullPointerException();
}
ensureKeysIsMutable();
keys_.add(value);
onChanged();
} else {
keysBuilder_.addMessage(value);
}
return this;
}
/**
*
* 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) = { ... }
*/
public Builder addKeys(
int index, io.envoyproxy.envoy.api.v2.core.DataSource value) {
if (keysBuilder_ == null) {
if (value == null) {
throw new NullPointerException();
}
ensureKeysIsMutable();
keys_.add(index, value);
onChanged();
} else {
keysBuilder_.addMessage(index, value);
}
return this;
}
/**
*
* 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) = { ... }
*/
public Builder addKeys(
io.envoyproxy.envoy.api.v2.core.DataSource.Builder builderForValue) {
if (keysBuilder_ == null) {
ensureKeysIsMutable();
keys_.add(builderForValue.build());
onChanged();
} else {
keysBuilder_.addMessage(builderForValue.build());
}
return this;
}
/**
*
* 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) = { ... }
*/
public Builder addKeys(
int index, io.envoyproxy.envoy.api.v2.core.DataSource.Builder builderForValue) {
if (keysBuilder_ == null) {
ensureKeysIsMutable();
keys_.add(index, builderForValue.build());
onChanged();
} else {
keysBuilder_.addMessage(index, builderForValue.build());
}
return this;
}
/**
*
* 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) = { ... }
*/
public Builder addAllKeys(
java.lang.Iterable values) {
if (keysBuilder_ == null) {
ensureKeysIsMutable();
com.google.protobuf.AbstractMessageLite.Builder.addAll(
values, keys_);
onChanged();
} else {
keysBuilder_.addAllMessages(values);
}
return this;
}
/**
*
* 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) = { ... }
*/
public Builder clearKeys() {
if (keysBuilder_ == null) {
keys_ = java.util.Collections.emptyList();
bitField0_ = (bitField0_ & ~0x00000001);
onChanged();
} else {
keysBuilder_.clear();
}
return this;
}
/**
*
* 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) = { ... }
*/
public Builder removeKeys(int index) {
if (keysBuilder_ == null) {
ensureKeysIsMutable();
keys_.remove(index);
onChanged();
} else {
keysBuilder_.remove(index);
}
return this;
}
/**
*
* 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) = { ... }
*/
public io.envoyproxy.envoy.api.v2.core.DataSource.Builder getKeysBuilder(
int index) {
return getKeysFieldBuilder().getBuilder(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) = { ... }
*/
public io.envoyproxy.envoy.api.v2.core.DataSourceOrBuilder getKeysOrBuilder(
int index) {
if (keysBuilder_ == null) {
return keys_.get(index); } else {
return keysBuilder_.getMessageOrBuilder(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) = { ... }
*/
public java.util.List
getKeysOrBuilderList() {
if (keysBuilder_ != null) {
return keysBuilder_.getMessageOrBuilderList();
} else {
return java.util.Collections.unmodifiableList(keys_);
}
}
/**
*
* 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) = { ... }
*/
public io.envoyproxy.envoy.api.v2.core.DataSource.Builder addKeysBuilder() {
return getKeysFieldBuilder().addBuilder(
io.envoyproxy.envoy.api.v2.core.DataSource.getDefaultInstance());
}
/**
*
* 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) = { ... }
*/
public io.envoyproxy.envoy.api.v2.core.DataSource.Builder addKeysBuilder(
int index) {
return getKeysFieldBuilder().addBuilder(
index, io.envoyproxy.envoy.api.v2.core.DataSource.getDefaultInstance());
}
/**
*
* 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) = { ... }
*/
public java.util.List
getKeysBuilderList() {
return getKeysFieldBuilder().getBuilderList();
}
private com.google.protobuf.RepeatedFieldBuilderV3<
io.envoyproxy.envoy.api.v2.core.DataSource, io.envoyproxy.envoy.api.v2.core.DataSource.Builder, io.envoyproxy.envoy.api.v2.core.DataSourceOrBuilder>
getKeysFieldBuilder() {
if (keysBuilder_ == null) {
keysBuilder_ = new com.google.protobuf.RepeatedFieldBuilderV3<
io.envoyproxy.envoy.api.v2.core.DataSource, io.envoyproxy.envoy.api.v2.core.DataSource.Builder, io.envoyproxy.envoy.api.v2.core.DataSourceOrBuilder>(
keys_,
((bitField0_ & 0x00000001) != 0),
getParentForChildren(),
isClean());
keys_ = null;
}
return keysBuilder_;
}
@java.lang.Override
public final Builder setUnknownFields(
final com.google.protobuf.UnknownFieldSet unknownFields) {
return super.setUnknownFields(unknownFields);
}
@java.lang.Override
public final Builder mergeUnknownFields(
final com.google.protobuf.UnknownFieldSet unknownFields) {
return super.mergeUnknownFields(unknownFields);
}
// @@protoc_insertion_point(builder_scope:envoy.api.v2.auth.TlsSessionTicketKeys)
}
// @@protoc_insertion_point(class_scope:envoy.api.v2.auth.TlsSessionTicketKeys)
private static final io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys DEFAULT_INSTANCE;
static {
DEFAULT_INSTANCE = new io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys();
}
public static io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys getDefaultInstance() {
return DEFAULT_INSTANCE;
}
private static final com.google.protobuf.Parser
PARSER = new com.google.protobuf.AbstractParser() {
@java.lang.Override
public TlsSessionTicketKeys parsePartialFrom(
com.google.protobuf.CodedInputStream input,
com.google.protobuf.ExtensionRegistryLite extensionRegistry)
throws com.google.protobuf.InvalidProtocolBufferException {
return new TlsSessionTicketKeys(input, extensionRegistry);
}
};
public static com.google.protobuf.Parser parser() {
return PARSER;
}
@java.lang.Override
public com.google.protobuf.Parser getParserForType() {
return PARSER;
}
@java.lang.Override
public io.envoyproxy.envoy.api.v2.auth.TlsSessionTicketKeys getDefaultInstanceForType() {
return DEFAULT_INSTANCE;
}
}
© 2015 - 2025 Weber Informatics LLC | Privacy Policy