Conversation
|
|
|
We can't look at this until you sign the CLA. |
atollena
left a comment
atollena
left a comment
There was a problem hiding this comment.
This is something that datadog would benefit from for some internal use cases that currently use double proxying with a sidecar, so I'm supportive of it. Happy to help with the Go API, although you can probably focus on a single language (c-core).
| Many proxy deployments support HTTPS connections, where the client establishes a TLS connection to the proxy before sending the HTTP CONNECT request. This ensures that: | ||
| 1. Proxy authentication credentials are encrypted | ||
| 2. The target hostname in the CONNECT request is not visible to network observers | ||
| 3. The proxy can be authenticated via its TLS certificate |
There was a problem hiding this comment.
The proxy can also identify the client from its client TLS certificate, if provided. The identity can then be used the same way as basic proxy auth, and replace it.
There was a problem hiding this comment.
Good point. We currently don't have a need for this on our side as our proxy uses basic auth, but if agreed to on grpc side, I can include it in the proposal.
I should get the CLA signed soon by my employer at which point they can start looking at both PRs.
|
You still need to sign the CLA before we can look at this. |
|
/easycla |
|
It's finally signed now. Sorry for the delay, I was struggling with EasyCLA. |
4 participants
This PR adds a gRFC for HTTPS proxy support where the connection to the proxy itself is TLS-encrypted. This ensures that proxy authentication credentials (such as BasicAuth username and password) are transmitted securely rather than in plaintext.
The C implementation is provided in this PR: grpc/grpc#41377
This adresses issue grpc/grpc#30347