-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CONNECT-UDP example configuration error #33775
Comments
@jeongseokson could you take a look at this one please? |
Hi @Bfarkiani, thank you for reporting the issue. Does sending a CONNECT-UDP request directly to the server-proxy work? I will try to test the forwarding and terminating proxy two-hop setup myself and see if there's any issue in the current example configs. |
Hi @jeongseokson
So, it seems that sending directly to the server works fine. |
Thanks for the update. I will test the two proxy setup myself when time permits to see if I can reproduce the issue. |
Dear @jeongseokson |
Hi @Bfarkiani, I started looking into this issue last week. I will follow up soon after gathering more information reproducing the issue myself. |
I reproduced the setup and tried the same. The issue is due to certificate verification on the forwarding proxy side when establishing a QUIC connection with the upstream terminating proxy. This happens regardless of CONNECT-UDP when a self-signed certificate is used in the terminating proxy. #17700 is a relevant discussion around this issue. I am not sure if we provided a way to disable upstream certificate checks when Envoy is working as a QUIC client. @danzh2010 Could you provide some insight on this? |
There is no way to bypass |
Thanks for the reply Dan. But the masque_client has |
Sorry I'm confused about this comment . Is below log observed on the client envoy? If so it means it failed handshake with masque client as a server (given
And this is downstream config. What confuses me is that you said
No other than via the |
@Bfarkiani Do you have anything to add regarding the @danzh2010 My understanding is that it's the TLS handshake failure between the forwarding proxy (client Envoy) and the terminating proxy (server Envoy), not between the masque client and the forwarding proxy. Is there a reason you believe it's still a handshake failure between the masque_client and the forwarding envoy? To try to solve the issue, I set the |
I figured out that Please try this @Bfarkiani. If you created your own self-signed certificate, you should specify the SAN there to match the one in the config. I checked other http3 example configs of Envoy and they have Unfortunately, the CONNECT-UDP request still doesn't go through even after the TLS handshake is successfully done. This one looks like an actual issue related to the HTTP Datagram implementation. I will take a look into it as well, but please try to do it yourself just to make sure we encounter the same issue @Bfarkiani. |
Dear @jeongseokson client:
Server:
The command I am using for masque client is
What server envoy prints is And what happens for packets: Seems that there is a connection. Although masque client shows nothing. As you see also server envoy prints "No hostname indicated in SNI" even with auto_sni. |
@Bfarkiani, I think you shouldn't use |
@jeongseokson |
@Bfarkiani I think we've reached the same actual error in the existing forwarding proxy mode I mentioned in a previous comment. Fixing this would probably require some modification to the existing HTTP Datagram handler unfortunately. I will create a separate issue for tracking this as this isn't a configuration issue. |
@jeongseokson |
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions. |
@RyanTheOptimist could you reopen this issue and mark no-stale-bot please? I don't think it's fully resolved yet |
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions. |
Just want to clarify that the issue raised in this post (as the title says) is about the incorrect example config (No SNI specified), which has been resolved. We uncovered the other issue in the CONNECT-UDP forwarding mode in the process, and I created #34836 for that. I think we can mark this issue resolved and use #34836 to track the issue separately, which I am currently working on. |
That makes sense, thanks for the details. OK let's close this issue once #34836 is reopened |
If you are reporting any crash or any potential security issue, do not
open an issue in this repo. Please report the issue via emailing
envoy-security@googlegroups.com where the issue will be triaged appropriately.
Title: CONNECT-UDP example configuration error
Description:
I am trying to test the configuration provided in https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/http/upgrades#connect-udp-support. I am also using quiche masque_client https://github.com/google/quiche/tree/main/quiche/quic/masque. Also I am using envoy:dev latest container. The client side proxy configuration is as below:
Server side proxy (192.168.170.128) that terminates connect-udp and forward request to google is as follows:
And the command for masque client is
./masque_client --disable_certificate_verification=true 127.0.0.1:10000 https://www.google.com
It fails. The output of client envoy is
The server envoy output is
The client and server envoy proxies both use the same self-signed certificate, and the configuration is the same as provided in the website.
If I enable auto_sni in client side :
I still get the following error
I also changed server proxy to the follow and nothing changed:
Thank you for checking this.
The text was updated successfully, but these errors were encountered: