SSF through authenticating proxy and SSL interception

[Arno0x]

Hi,

I'm back with my attempts to make SSFC work through a corporate proxy.

First test: Simple forward proxy with no authentication and no SSL interception (tinyproxy): everything works like a charm, no problem.

Second test: Corporate proxy with NTLM authentication of domain authenticated users. I've tried all possible combination of the "Credentials" section in the config file:

• reuse NTLM (which is exactly what my browser does) to authenticate against the corporate proxy
• setting the username and domain alone
• specifying the user's password (ie: hardcoding it in the config file) It all fails. Looking at what's going on the wire (wireshark) I can tell that the NTLMSSP_NEGOTIATE phase looks wrong, comparing with other similar activity from my web browser for instance.

Third test: Still using the same corporate proxy, but this time, I'm handling the NTLM authentication to an intermediate local proxy (cntlm). This time, the authenticating phase passes and I can see the SSL handshake starting (in wireshark), but then I get the following error message from ssfc:

[2016-09-21 14:45:20][info] config[ssf]: loading file <config.json>
[2016-09-21 14:45:20][info] config[tls]: CA cert path: <./certs/trusted/ca.crt>
[2016-09-21 14:45:20][info] config[tls]: cert path: <./certs/certificate.crt>
[2016-09-21 14:45:20][info] config[tls]: key path: <./certs/private.key>
[2016-09-21 14:45:20][info] config[tls]: key password: <>
[2016-09-21 14:45:20][info] config[tls]: dh path: <./certs/dh4096.pem>
[2016-09-21 14:45:20][info] config[tls]: cipher suite: <DHE-RSA-AES256-GCM-SHA384>
[2016-09-21 14:45:20][info] config[HTTP proxy]: <127.0.0.1:8080>
[2016-09-21 14:45:20][info] config[HTTP proxy]: reuse NTLM credentials <false>
[2016-09-21 14:45:20][info] config[HTTP proxy]: reuse Kerberos credentials <true>
[2016-09-21 14:45:20][info] config[circuit]: <None>
[2016-09-21 14:45:21][info] client: connecting to <REDACTED_:-):8011>
[2016-09-21 14:45:21][info] client: running (Ctrl + C to stop)
[2016-09-21 14:45:21][info] network[proxy]: connected (auth: None)
[2016-09-21 14:45:21][error] client: error when connecting to server: sslv3 alert handshake failure
[2016-09-21 14:45:21][error] client: connected to remote server NOK
[2016-09-21 14:45:21][info] client: stop

From a network perspective, I see a RST packet from the upstream (corporate) proxy. It might be related to the fact the corporated proxy does some SSL inspection, or it does not support the SSL/TLS parameters negociated by ssfc.

I'm afraid this post is not very useful in identifying where the bug lies. I'll update the issue if I find something new.

Arno

[securesocketfunneling]

Wow, thanks for your report ! It is really appreciated !

Second test: Corporate proxy with NTLM authentication of domain authenticated users.

Were you running the Windows binaries for this test ? NTLM auth on Linux is not implemented in 2.2.0. It is an enhancement that we would like to add in a future version.

Third test:

Hmm, hard to tell what can be wrong. If the proxy tries to MITM the connection, the connection will fail since the client is doing a mutual TLS authentication. Maybe the debug log level (-v debug) can help us to determine where the TLS negotiation is failing.

Anyway, thanks for giving us some time to make this project better !