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)