Menu
▾
▴
#1281 libcurl shows proxy port instead of destination port on SSL failure
When using curl command line to upload a file to an HTTPS destination via a proxy, the port for the proxy is substituted in place of the ultimate destination's port, causing failure.
This appears to be a problem from at least curl v7.21.2 to the present version. It happen whether you use the -x <proxyhost>:<port> option or HTTPS_PROXY/ALL_PROXY.
Here's a (sanitized) example:
# export HTTPS_PROXY=myproxy.example.com:82
# curl -v -T vmdump.3 'https://supportfiles.sun.com:443/cURL?file=vmdump-nydevsol10-20130917-IDR615.7&root=cores'
About to connect() to proxy myproxy.example.com port 82 (#0)
Trying 192.168.77.59...
Failed to set TCP_KEEPALIVE on fd 6
Adding handle: conn: 0x6d2c0
Adding handle: send: 0
Adding handle: recv: 0
Curl_addHandleToPipeline: length: 1
- Conn 0 (0x6d2c0) send_pipe: 1, recv_pipe: 0
Connected to myproxy.example.com (192.168.77.59) port 82 (#0)
Establish HTTP proxy tunnel to supportfiles.sun.com:443
CONNECT supportfiles.sun.com:443 HTTP/1.1
Host: supportfiles.sun.com:443
User-Agent: curl/7.32.0
Proxy-Connection: Keep-Alive< HTTP/1.1 200 Connection established
<
Proxy replied OK to CONNECT request
SSLv3, TLS handshake, Client hello (1):
Unknown SSL protocol error in connection to supportfiles.sun.com:82
Closing connection 0
curl: (35) Unknown SSL protocol error in connection to supportfiles.sun.com:82
Note how curl shows supportfiles.sun.com:443 first, then later changes it to supportfiles.sun.com:82 later on, at which point the SSL handshake failure occurs.
Obviously, have confirmed that the proxy works as expected with other browsers and command line tools without issue. Only curl seems to have this problem.
I can't say that I agree with your conclusion.
The log shows curl connecting to the proxy's port 82 and sending a CONNECT to the remote host's port 443. Right? libcurl can then not just magically switch ports after the connection is there. It seems to have connected to the proxy on the correct port.
You then get a SSL failure, and the error message then shows an incorrect port number when it identifies the host with which it has a problem. I looks like a problem with the error message to me.
The question is of course then also why there's an SSL error in the first place, but I can't see that it has anything to do with the port number. You could try enforcing SSLv3 or TLSv1 on the connection (with -3 or -1) to see if that makes any difference.
Fair enough.
Using either -3 or -1 doesn't change the behavior.
My next step will be to snoop the traffic and see whether the actual port is changed, or as you note, whether it's just the error message that's incorrect.
I'm attaching my very simple and small patch that fixes the error message.
What OpenSSL version are you using?
I've now merged this fix and pushed as commit 9215cee4c6c3cc15b.
The error message problem is now fixed. Closing this report.