[
https://issues.apache.org/jira/browse/HTTPCLIENT-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13575502#comment-13575502
]
Oleg Kalnichevski commented on HTTPCLIENT-1318:
-----------------------------------------------
> HttpClient is not intended to support connections to SSL proxies?
I am sorry my previous comment may have been misleading. HttpClient supports
SSL tunneling via HTTP CONNECT. SSL tunneling usually implies that the client
is expected to connect the proxy with plain HtrusteTTP, establish a tunnel to
the target host with HTTP CONNECT and upgrade that connection to SSL. What it
does not support is secure connections to the proxy itself.
> Is that decision set in stone or would you consider a patch allowing that
> support?
I personally see little sense in encrypting connections to HTTP proxy as
proxies are meant to be trusted a priori. However, we'll never refuse a quality
patch.
> One curious aspect though is that the SSL proxy works fine in step 1, just
> not in step 3, so at least some support for SSL proxies appears to be working
> great in HttpClient.
Is there any chance you could put together a test case for this scenario? I am
still unsure I understand what is going on. You assertion that
URIUtils#extractHost is at fault by not taking protocol scheme into account
seems wrong to me. So, a test case reproducing the problem would help a lot.
Oleg
> Redirect to TLS site via TLS proxy fails - incorrectly marked as insecure
> target route
> --------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1318
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1318
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.2.3
> Environment: All
> Reporter: Adam Fisk
> Fix For: 4.2.4
>
>
> When configured to use a TLS proxy to a target site that is also TLS with a
> redirect response, HttpClient will incorrectly create a new target route
> marked as http and insecure rather than https and secure when generating the
> new request to the redirected location. This will result in exceptions like
> the trace below with:
> "Unable to establish route: planned =
> {}->https://localhost:7777->http://www.exceptional.io; current =
> {s}->https://localhost:7777->http://www.exceptional.io";
> In fact, the test producing that exception is targeting
> https://www.exceptional.io not http://www.exceptional.io, which is apparently
> correctly determined in the original request but not in the redirected
> request. One candidate for the suspect code is line 1112 of handleResponse in
> DefaultRequestDirector where the following line:
> HttpHost newTarget = URIUtils.extractHost(uri);
> creates a new target that is always HTTP regardless of whether or not the
> original target was HTTPS, with havoc ensuing from there. This is
> reproducible in this test over at LittleProxy:
> https://github.com/adamfisk/LittleProxy/blob/master/src/test/java/org/littleshoot/proxy/EndToEndStoppingTest.java
> org.apache.http.client.ClientProtocolException
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:909)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
> at
> org.littleshoot.proxy.EndToEndStoppingTest.runSiteTestWithHttpClient(EndToEndStoppingTest.java:167)
> at
> org.littleshoot.proxy.EndToEndStoppingTest.testWithHttpClient(EndToEndStoppingTest.java:92)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> Caused by: org.apache.http.HttpException: Unable to establish route: planned
> = {}->https://localhost:7777->http://www.exceptional.io; current =
> {s}->https://localhost:7777->http://www.exceptional.io
> at
> org.apache.http.impl.client.DefaultRequestDirector.establishRoute(DefaultRequestDirector.java:846)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:649)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
> ... 27 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
