-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
jetty client with proxy - ssl traffic between both proxy and servers #9501
Comments
No, the forward proxy only establishes a TCP connection to the server, not a TLS connection.
Should be: HttpProxy httpProxy = new HttpProxy(new Origin.Address("localhost", 8443), true); I understand it is only a test, but: req.method(req.getMethod()).send(new BufferingResponseListener() {
@Override
public void onComplete(Result result) {
System.out.println(result.isFailed());
System.out.println(result.getFailure());
System.out.println(result.getResponse().getStatus());
try {
httpClient.stop();
} catch (Exception e) {
throw new RuntimeException(e);
}
}
}); You cannot stop the Your code should work, assuming the certificates are correct. |
thank you for the input! and re-run the test. I've also removed the stopping of the client, unfortunately no improvements. The proxy we are using for testing is pproxy, that we start like this: You can find debug logs attached looking.forward to hearing from you |
Same issue as #6483, the proxy sends a |
ok, let me look at the issue and try with a jetty What is strange that it works fine with python |
The python client is more forgiving when it receives a You should use a I'm changing the Jetty client to ignore |
Now Connection: close is ignored for 2xx responses to a CONNECT method. In this way the tunnel is kept open, and bad proxies that were sending Connection: close are now supported as apparently they are still out there. Fixes also #6483. Signed-off-by: Simone Bordet <[email protected]>
@Michal-Cho can you try the code in #9508 and report back if it works for you? |
sure, let me check |
@sbordet in a quick test I got a correct response 200 :) |
It should be, there have not been many changes in the |
@sbordet fyi - I've backported the fix to jetty 9 and it seems to work in a quick test, but I guess we can not count on any new official release there ;) |
@Michal-Cho re: new Jetty 9.4.x releases you are correct. Out of curiosity, what's stopping you from upgrading? |
we will upgrade but having a fix in 9 would be much simpler as a short term solution :) |
The only way we cut new Jetty 9 releases anymore is through a support contract that sponsors the release. |
@sbordet if we go with the upgrade - which jetty release could contain the fix and what would be a release date? |
The fix would be present in the next Jetty 10/11 release. As for the date we don't have a precise date for the next release. |
Now Connection: close is ignored for 2xx responses to a CONNECT method. In this way the tunnel is kept open, and bad proxies that were sending Connection: close are now supported as apparently they are still out there. Fixes also #6483. Signed-off-by: Simone Bordet <[email protected]>
Jetty version
11.0.13
Java version
zulu 17.0.6
Question
Hello!
In our project we need to use jetty client with proxy that requires SSL, same as final destinations servers. We store needed certificates in keystore, both for proxy and dest servers
What I have figured out so far is that I need to create a
HttpProxy
object (using constructor withSslContextFactory.Client
) and add it to client'sProxyConfiguration
collections.It is the same
SslContextFactory.Client
that is used in the client and it is working fine if we skip a proxy and run traffic client<--> server directly.I can see in wireshark the following
once a client needs to send a request it contacts a proxy
TLS handshake is successful - seems to be correct
Traffic between proxy and final server gets broken and my client receives
java.nio.channels.ClosedChannelException
I would assume that the proxy server should try to establish connection to the final destination server using certificates that it could get from the client. But that does not work.
I've written simple program to reproduce the issue:
If we run similar request from a simple python code:
we get correct response.
Proxy does not require authentication for now.
My question here is - have I understood the jetty flow correctly? Or am I missing something? What confuses me is that it works with the pyton script and it works fine without proxy (so it means that my keystore is correct)
I will be really grateful for any hints/advice where I could find more information about setup described above
The text was updated successfully, but these errors were encountered: