Get desktop application:
View/edit binary Protocol Buffers messages
SetUpSession is a bidirectional stream used by applications to offload operations from the TLS handshake.
The identity corresponding to the TLS configurations that MUST be used for the TLS handshake. If a managed identity already exists, the local identity and authentication mechanisms are ignored. If a managed identity doesn't exist and the local identity is not populated, S2A will try to deduce the managed identity to use from the SNI extension. If that also fails, S2A uses the default identity (if one exists).
The authentication mechanisms that the application wishes to use to authenticate to S2A, ordered by preference. S2A will always use the first authentication mechanism that matches the managed identity.
Requests the certificate chain and TLS configuration corresponding to the local identity, which the application MUST use to negotiate the TLS handshake.
Signs or decrypts the input bytes using a private key corresponding to the local identity in the request. WARNING: More than one OffloadPrivateKeyOperationReq may be sent to the S2Av2 by a server during a TLS 1.2 handshake.
Encrypts or decrypts the input bytes using a resumption key corresponding to the local identity in the request.
Verifies the peer's certificate chain using (a) trust bundles corresponding to the local identity in the request, and (b) the verification mode in the request.
Status of the session response. The status field is populated so that if an error occurs when making an individual request, then communication with the S2A may continue. If an error is returned directly (e.g. at the gRPC layer), then it may result that the bidirectional stream being closed.
Contains the certificate chain and TLS configurations corresponding to the local identity.
Contains the signed or encrypted output bytes using the private key corresponding to the local identity.
Contains the encrypted or decrypted output bytes using the resumption key corresponding to the local identity.
Contains the validation result, peer identity and fingerprints of peer certificates.
Used in: ,
If true, the application MUST perform ALPN negotiation.
The ordered list of ALPN protocols that specify how the application SHOULD negotiate ALPN during the TLS handshake. The application MAY ignore any ALPN protocols in this list that are not supported by the application.
The ALPN protocols that the application can negotiate during a TLS handshake.
Used in:
Used in:
Applications may specify an identity associated to an authentication mechanism. Otherwise, S2A assumes that the authentication mechanism is associated with the default identity. If the default identity cannot be determined, the request is rejected.
A token that the application uses to authenticate itself to S2A.
The TLS 1.0-1.2 ciphersuites that the application can negotiate when using S2A.
Used in: ,
The side in the TLS connection.
Used in:
Used in:
The role of the application in the TLS connection.
The server name indication (SNI) extension, which MAY be populated when a server is offloading to S2A. The SNI is used to determine the server identity if the local identity in the request is empty.
Used in:
Next ID: 8
Used in:
The certificate chain that the client MUST use for the TLS handshake. It's a list of PEM-encoded certificates, ordered from leaf to root, excluding the root.
The minimum TLS version number that the client MUST use for the TLS handshake. If this field is not provided, the client MUST use the default minimum version of the client's TLS library.
The maximum TLS version number that the client MUST use for the TLS handshake. If this field is not provided, the client MUST use the default maximum version of the client's TLS library.
The ordered list of TLS 1.0-1.2 ciphersuites that the client MAY offer to negotiate in the TLS handshake.
The policy that dictates how the client negotiates ALPN during the TLS handshake.
Next ID: 12
Used in:
The certificate chain that the server MUST use for the TLS handshake. It's a list of PEM-encoded certificates, ordered from leaf to root, excluding the root.
The minimum TLS version number that the server MUST use for the TLS handshake. If this field is not provided, the server MUST use the default minimum version of the server's TLS library.
The maximum TLS version number that the server MUST use for the TLS handshake. If this field is not provided, the server MUST use the default maximum version of the server's TLS library.
The ordered list of TLS 1.0-1.2 ciphersuites that the server MAY offer to negotiate in the TLS handshake.
Whether to enable TLS resumption.
Whether the server MUST request a client certificate (i.e. to negotiate TLS vs. mTLS).
Returns the maximum number of extra bytes that |OffloadResumptionKeyOperation| can add to the number of unencrypted bytes to form the encrypted bytes.
The policy that dictates how the server negotiates ALPN during the TLS handshake.
Used in:
Used in: , ,
The SPIFFE ID of a connection endpoint.
The hostname of a connection endpoint.
The UID of a connection endpoint.
The username of a connection endpoint.
The GCP ID of a connection endpoint.
Additional identity-specific attributes.
Used in:
The operation the private key is used for.
The signature algorithm to be used for signing operations.
The input bytes to be signed or decrypted.
Raw bytes to be hashed and signed, or decrypted.
A SHA256 hash to be signed. Must be 32 bytes.
A SHA384 hash to be signed. Must be 48 bytes.
A SHA512 hash to be signed. Must be 64 bytes.
Used in:
When performing a TLS 1.2 or 1.3 handshake, the (partial) transcript of the TLS handshake must be signed to prove possession of the private key. See https://www.rfc-editor.org/rfc/rfc8446.html#section-4.4.3.
When performing a TLS 1.2 handshake using an RSA algorithm, the key exchange algorithm involves the client generating a premaster secret, encrypting it using the server's public key, and sending this encrypted blob to the server in a ClientKeyExchange message. See https://www.rfc-editor.org/rfc/rfc4346#section-7.4.7.1.
Used in:
The signed or decrypted output bytes.
Used in:
The operation the resumption key is used for.
The bytes to be encrypted or decrypted.
Used in:
Used in:
The encrypted or decrypted bytes.
Used in:
The SPIFFE ID from the peer leaf certificate, if present. This field is only populated if the leaf certificate is a valid SPIFFE SVID; in particular, there is a unique URI SAN and this URI SAN is a valid SPIFFE ID.
The URIs that are present in the SubjectAltName extension of the peer leaf certificate. Note that the extracted URIs are not validated and may not be properly formatted.
The DNSNames that are present in the SubjectAltName extension of the peer leaf certificate.
The (ordered) list of fingerprints in the certificate chain used to verify the given leaf certificate. The order MUST be from leaf certificate fingerprint to root certificate fingerprint. A fingerprint is the base-64 encoding of the SHA256 hash of the DER-encoding of a certificate. The list MAY be populated even if the peer certificate chain was NOT validated successfully.
The local identity used during session setup.
The SHA256 hash of the DER-encoding of the local leaf certificate used in the handshake.
Used in:
RSA Public-Key Cryptography Standards #1.
ECDSA.
RSA Probabilistic Signature Scheme.
ED25519.
Used in:
The status code that is specific to the application and the implementation of S2A, e.g., gRPC status code.
The status details.
The TLS versions supported by S2A's handshaker module.
Used in: ,
Used in:
The verification mode that S2A MUST use to validate the peer certificate chain.
Used in:
The certificate chain to be verified. The chain MUST be a list of DER-encoded certificates, ordered from leaf to root, excluding the root.
Used in:
The certificate chain to be verified. The chain MUST be a list of DER-encoded certificates, ordered from leaf to root, excluding the root.
The expected hostname of the server.
The UnrestrictedClientPolicy specified by the user.
Used in:
The default verification mode supported by S2A.
The SPIFFE verification mode selects the set of trusted certificates to use for path building based on the SPIFFE trust domain in the peer's leaf certificate.
The connect-to-Google verification mode uses the trust bundle for connecting to Google, e.g. *.mtls.googleapis.com endpoints.
Internal use only.
Internal use only.
Internal use only.
Internal use only.
Internal use only.
Used in:
The result of validating the peer certificate chain.
The validation details. This field is only populated when the validation result is NOT SUCCESS.
The S2A context contains information from the peer certificate chain. The S2A context MAY be populated even if validation of the peer certificate chain fails.
Used in: