Pluggable Authenticated Proxy Support

[coliemcgarry]

Hi there,
Excellent library, and we're using this indirectly via the cpprestsdk library (Casablanca).

We do need to address one limitation - "Authenticated Proxy Support", specifically NTLM and Negotiate (and maybe in the future Kerberos).

We previously added support in a different project for these schemes (on Windows) by using the Windows SSPI API, and we noticed there's an issue in the WebSocketpp repo using a similar approach (#337). Actually, we built and ran with this, and it works (successfully running NTLM authentication), however it does introduce some platform specific code (windows).

To improve on this solution, it would probably be a good idea to externalize this from WebSocketpp, thereby avoid any unnecessary dependencies. To achieve this we would introduce callbacks/handlers to react to the 407 proxy responses. This interface would need access to the proxy specific headers returned, and would calculate updated headers for the next step in the authentication flow. Once complete the normal flow would continue.

An alternative approach may be to get WebSocketpp report the 407 to the upper layers, along with the response headers. Then let the upper layers run the proxy authentication flow, calculation the required authentication header token - then restart the websocket with the calculated auth token header. (I am assuming that the auth token can be shared with a new socket connection - but I'm not an expert in this area).

At this point, we don't know much about authenticated proxy support for non-windows platforms, but by including the callback/handler, it should be possible to include solutions for each platform.

Please let me know if we're on the right wave-length here, or if you have any alternate suggestions.

If we can agree on an approach, then we can work on this feature, and submit via pull request.

Regards,
Colie

[zaphoyd]

Since there seems to be some demand for a variety of different proxy auth schemes, something pluggable here seems like a good idea.

I am definitely not interested in platform specific code in the core library, but I am not opposed to shipping (or linking to) platform specific policies. As an example, this is how syslog logging support was done in the library. The core logging system is pluggable and the platform specific syslog logging policy can be optionally pulled in via a custom config (but doesn't require modifying the core library).

It should be possible to allow the auth flow to happen inline without restarting the connection. The logic for this is already present, it would mostly be a matter of exposing the right handlers. The main challenge is that I believe there are some proxy auth schemes that involve multiple round trips which is a bit more tricky than just a "handle this one extra HTTP step".

Are there any special quirks of this sort that the proxy schemes you are interested in need? In particular... is it sufficient to exchange HTTP requests/responses? or do some of these schemes need to send arbitrary bytes on the wire during the handshake (as say TLS does)?

[GamePad64]

Well, it would be very platform-specific, isn't it?

[zaphoyd]

Most likely. I am not super familiar with HTTP proxies though. Wondering if anyone who is can shed light at least on whether they largely stick to HTTP or whether it is an anything goes situation. The former will be a lot easier to add quickly and cleanly, but if there are a bunch of systems that don't speak HTTP then handing the raw bytes over to the proxy negotiation module is probably the most flexible.

[coliemcgarry]

Peter,
Last year, we added authenticated proxy support for a different websocket library. Multiple customers have used this, and in our experience proxy auth is via standard http requests/responses. Once the connection is open through the proxy, then normal tls negotiation takes place of over this.

Regarding multiple steps: Yes - there can be multiple steps to the negotiation.

Also, with one particular proxy, we needed to run the auth flow to completion, then once we calculated the correct 'Proxy-Authenticate' header, we had to close the socket, and then connect specifying the calculated 'Proxy-Authenticate' header.

I'm working on change to WebSocketpp to let client code inject a proxy auth handler. I'm not quite there, but when I've a working version, I'll push my changes to my fork to better explain the change.

Thanks for pointing me a plugin example (syslog) - I need to take a look at that.

[GamePad64]

Another complicated question is creating a server socket behind a proxy (SOCKS4/5). Instead of bind/accept it has to connect to proxy, send a bind request, and then read.

[coliemcgarry]

I've been working through the proxy auth flows, and in a lot of cases I can continue the flow in line i.e. we receive the auth challenge, and I reply with the updated token etc.
There are cases where the proxy returns the header 'Connection: Close' - when we receive the initial proxy challenge.
In this case I need to close the connection, and open a new connection.
I plan to add a 'proxy_reconnect' handler/callback to the endpoint object, and the client code will start a new connection within this callback.
Is this a reasonable approach, or would you recommend an alternate approach? (Maybe there's already some functionality in the library like this - if so let me know)