- Fix the session_timeout formatting so that it links to the RFC
reference correctly.
- Make some minor grammar improvements.
- Quote the session_timeout field name
Signed-off-by: James Peach <jpeach@apache.org>
Mirrored from https://github.com/envoyproxy/envoy @ bd1ac13275246c2a9a865912682ed9904ed7a78a
When these fields were originally added, we didn't fully understand how the `CertificateValidationContext` configuration worked. A `CertificateProvider` cannot provide a full `CertificateValidationContext` proto; it provides only the CA certs (i.e., the `trusted_ca` field within the `CertificateValidationContext` proto). So this PR makes the following changes:
- Duplicates the `CertificateProvider` and `CertificateProviderInstance` messages from `CommonTlsContext` as `CertificateProviderPlugin` and `CertificateProviderPluginInstance` outside of `CommonTlsContext` (in common.proto instead of tls.proto). (Note that this also paves the way for reusing these messages for SPIFFE validation in the future.)
- Adds new `CertificateProviderPlugin` and `CertificateProviderPluginInstance` fields to `CertificateValidationContext`, as an alternative to the existing `trusted_ca` field. (Added annotations to make this a `oneof` in the future.)
- In `CommonTlsContext`, I have deprecated the `validation_context_certificate_provider` and `validation_context_certificate_provider_instance` fields both in the `validation_context_type` oneof and in `CombinedValidationContext`.
- In `CommonTlsContext`, I have replaced the `tls_certificate_certificate_provider` and `tls_certificate_certificate_provider_instance` fields with new fields that use the new messages outside of `CommonTlsContext`.
Risk Level: Low
Testing: N/A
Docs Changes: Included in PR
Release Notes: N/A
Platform Specific Features: N/A
Signed-off-by: Mark D. Roth <roth@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ b29d6543e7568a8a3e772c7909a1daa182acc670
This fixes the refs in protos and removes the sed operations for build
The benefits are:
- less indirection in proto refs
- (small) speedup of build
- simplify docs build
- simplify reuse of proto comments (eg generating jsonschemas)
Signed-off-by: Ryan Northey <ryan@synca.io>
Mirrored from https://github.com/envoyproxy/envoy @ 45ec050f91407147ed53a999434b09ef77590177
Fixing "warning: Import ... but not used" warnings from protoc
Risk Level: Low
Testing: manually built protos
Signed-off-by: Chris Heisterkamp <cheister@squareup.com>
Mirrored from https://github.com/envoyproxy/envoy @ 209b8f96498162834856a4330f27deafdf7e0518
Risk Level: LOW
Testing: Unit and format
Fixes#10535
Signed-off-by: Abhay Narayan Katare <abhay.katare@india.nec.com>
Mirrored from https://github.com/envoyproxy/envoy @ 6321e5d95f7e435625d762ea82316b7a9f7071a4
Add OCSP stapling support with configurable stapling policy. A pre-fetched OCSP response can be configured with its corresponding certificate via the new ocsp_staple field in the TlsCertificate message. The new ocsp_staple_policy field on DownstreamTlsContext determines whether an OCSP response is required and whether to continue using the TLS certificate for new connections once its OCSP response expires. The ocsp_staple_policy defaults to LENIENT_STAPLING, which allows the operator to omit ocsp_staples from the configuration and will only use OCSP responses that are present and valid. This should therefore not break any existing configurations.
Risk Level: Medium - touches some core functionality of certificate selection but does not alter any existing behavior
Testing: added
Docs Changes: Added OCSP Stapling subsection in the SSL section of the architecture overview.
Release Notes: Added
Runtime flags:
envoy.reloadable_features.check_ocsp_policy
envoy.reloadable_features.require_ocsp_response_for_must_staple_certs
Signed-off-by: Daniel Goldstein <danielgold95@gmail.com>
Signed-off-by: Stephan Zuercher <zuercher@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ cdd3a837056dc6935c0d8e0fb693d4de89b998e9
Additional Description: This PR necessitated decoupling SslHandshakerImpl from ContextConfig a bit. We now pass an int representing the index of the extended_info struct rather than the ContextConfig.
This PR moves SslHandshakerImpl to its own build target, moves SslHandshaker construction into the ContextConfig, and adds a HandshakerFactoryContext and HandshakerFactory for modifying the ContextConfig's behavior when constructing a Handshaker. This PR also adds a control (requireCertificates) to turn off the release asserts that a context must have certificates.
This PR builds off work in https://github.com/envoyproxy/envoy/pull/12571 and refines work done (and abandoned) in https://github.com/envoyproxy/envoy/pull/12075/. For more discussion please see the comments section of https://github.com/envoyproxy/envoy/pull/12075/.
Risk Level: Low. This PR does not modify existing handshaking behavior, it just adds an extension point for modifying it.
Testing: A representative alternative implementation was added under :handshaker_test.
Docs Changes: N/a
Release Notes: N/a
Signed-off-by: James Buckland <jbuckland@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 7d6e7a4e559bdf0346687f7f404412e2412ea6fb
This is necessary to provide TLS transport socket docs and to be able to have the TLS transport
socket added to the threat model docs (via its security_posture tag).
I did both v2/v3, since this is not technically a change to v2, justa file re-org, and the shadowing
machinery prefers file consistency across versions.
Risk level: Low (refactoring)
Testing: Docs generation and manual inspection.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ ab32f5fd01ca8b23ee16dcffb55b1276e55bf1fa
data-plane-api(Azure Pipelines)