Skip to content
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

ssl handshake error with authenticated http proxy #650

Open
sidarthagracias opened this issue Jan 5, 2018 · 9 comments
Open

ssl handshake error with authenticated http proxy #650

sidarthagracias opened this issue Jan 5, 2018 · 9 comments

Comments

@sidarthagracias
Copy link

I'm seeing an issue when connecting to a server using https through a http proxy using basic authentication (username/password). The exception returned from request is "Error in SSL handshake"

I am able to make the connection successfully without proxy authentication. Also I have done a curl test which succeeds with/without authentication

Looking through packet traces in wireshark I see the following

with curl
1: curl -> to proxy: CONNECT
2: proxy -> curl: Proxy Authentication Required
3: curl-> proxy: CONNECT with Authentication
4: proxy -> curl sdk Conection established
5 curl -> proxy client Hello to server url
6 proxy -> server Client Hello
7 server -> proxy Server Hello
8: proxy -> sdk Server Hello
... Successfully completes TLS handshake

with cpprestsdk
1: sdk -> proxy: CONNECT with auth
It looks like with sdk we just have one authentication scheme (BASIC) and don't do the authentication discovery step like curl above. Is this correct?
2: proxy -> sdk connection established
3: sdk -> proxy Client Hello
4: stray packet with protocol SSL going to server, wireshark marks this packet as "Continuation Data"
5: proxy -> server Client Hello
6: server -> sdk FIN, ACK terminating the connection

I believe the server ins't completing the handshake because of that stray packet in step 4. I cannot tell what is generating this packet. I do not see this packet being sent from sdk to proxy. I was wondering if this packet might be generated because of the way the connection to the http proxy is formed. I compared at the Client Hello packets between successful and failed attempts and those seem to match up.

I have tested on mac and linux with the squid proxy.

@dimarusyy
Copy link
Contributor

You are right, proxy implementation has only basic auth support (no NTLM support or discovery).
I've been experiencing the similar issue before I did debugging and found out that connection was failing because of TLS handshake handler returning error code.
I can't say for sure, but curl may just ignore SSL handshake error while sdk does not and you need to specify valid certificate or set handshake handler.

@sidarthagracias
Copy link
Author

thank you for taking a look, hmm It doesn't look like a cert error, the error is in the SSL handshake which precedes certificate exchange. I am also able to connect successfully when no proxy authentication is used, which makes me suspect the initial connection made to the proxy might be faulty. I will try testing against a different proxy and check if I see the same results.

@dimarusyy
Copy link
Contributor

Hello, let me add some notes :
First, I tried only CCProxy and http requiests worked absolutely fine for me via proxy with and without auth.
When I installed squid, I was getting very similar error with what you are describing.
So, I would suggest to debug sdk and check 2 items :

  1. what handle_cert_verification() call returns. You need to be sure ssl connection is not interrupted because of handshake error.
  2. check squid settings how ssl requests are handled : is certificate required or not?

To say more, we (in our project) use patch for sdk that allows to set handshake handler and certificate (I wonder why it was not implemented). And I can say that sdk works for me with CCProxy and squid.

@sidarthagracias
Copy link
Author

ohh interesting, if CCProxy works but Squid does not, it seems this would point to an issue with the proxy (or a specific compatibility issue).

From my reading of the tcpdumps the way the TLS setup happens is
1: client hello (client -> server)
2: server hello (server -> client)
3 certificate, server hello done (server -> client)

with squid proxy auth I see the server terminate connection at step 2, so we never get to the point of server returning its certificate.

Thanks for the information, I'll run the test against a different proxy and hopefully be able to pinpoint if this is an issue with the specific proxy used

@sidarthagracias
Copy link
Author

So after some more debugging I think I have gotten to the bottom of this
specifically when adding the proxy auth http header we do (http_client_asio.cpp)
if(m_context->m_http_client->client_config().proxy().credentials().is_set()) { request_stream << m_context->generate_basic_proxy_auth_header() << CRLF; }
and
std::string generate_basic_proxy_auth_header() { std::string header; header.append("Proxy-Authorization: Basic "); header.append(generate_base64_userpass(m_http_client->client_config().proxy().credentials())); header.append(CRLF); return header; }
so the auth header already terms with a CRLF but then we add a second CRLF when adding the auth header, it seems like this is what causes the problem. When I look at the generated http payload it seems like the CRLF causes the payload to be split into 2 different payload.
Removing the extra CRLF and everything works correctly.

I am testing this with squid proxy.
I would love if a contributing dev could comment on this as I don't have a lot of expertise in this area

@zowers
Copy link

zowers commented Aug 21, 2018

I can confirm the issue is present.
removing CRLF inside the if statement fixes it

- request_stream << m_context->generate_basic_proxy_auth_header() << CRLF;
+ request_stream << m_context->generate_basic_proxy_auth_header();

@gbottesi
Copy link

Hello guys,
This small fix has been here for more than five months. It requires removing 8 characters from code source and should not require hours of work ? I am volunteer to do it if you want, but I am not allowed to create branches and thus Pull requests on the repo. Could you please have a look to this : cpprestsdk does just not work with proxies right now.
Thanks

@piwinux
Copy link

piwinux commented Feb 18, 2020

It seems this as been fixed with #1183
See this commit : 47cd408

@mahdit83
Copy link

mahdit83 commented Mar 3, 2020

I found this and try lots of possibilities but finally get that our server certificate was not valid and with replace with valid certificate this issue gone.

This is also my question link in stackoverflow to see what was my condition.https://stackoverflow.com/q/60443490/1498586

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants