0

I am running a proxy service, thus I can only use TCP passthrough, or users would get certificate warnings.

Unfortunately very little is known in tcp logs, and I want to ensure no illegal activities are being done on the server.

So the question is - Is it possible to passthrough HTTPS while at the same time decrypting the requests to store http logs?

Thank you.

Tomas Randomas
  • 3
  • 2

1 Answers1

1

There are two key exchange methods used with TLS (i.e. in HTTPS): RSA key exchange and Diffie-Hellman (DH).

With RSA key exchange it is in theory possible to pass the original traffic encrypted and but still decrypt the content as long as the private key of the servers certificate is known to the client. But this is not supported by haproxy and RSA key exchange is considered obsolete cryptography today anyway so it should better not be used.

With DH key exchange such passive content decryption is not possible by design.

What is possible instead and also supported by haproxy is to terminate the clients TLS connection at haproxy and create another one from haproxy to the target server. This requires haproxy to have both the certificate and the private key of the server. This will not work if mutual authentication is required though since haproxy cannot pass the original clients certificate to the server since haproxy does not have the private key for the clients certificate.

Steffen Ullrich
  • 13,227
  • 27
  • 39
  • okay, but is it possible to 'terminate' the HTTPS traffic and see it as http (for any website) if you only have a self signed certificate on haproxy? I have found an interesting project called teeproxy, which can duplicate packets, so if the first option is available I could send 2 packets , first being sent to my "TCP passthrough" frontend, and another to "SSL termination" frontend, giving the the layer 7 logs of clients requests. Or that's totally wrong? – Tomas Randomas Jul 22 '18 at 15:48
  • @TomasRandomas: there is no "terminate" HTTPS, only real terminate. Terminating HTTPS means that the client gets the certificate from the system which terminated the connection. In case of termination by haproxy this is the certificate configured in haproxy. And if only a self-signed is configured there then the client gets a certificate warning since the certificate will not be trusted. teeproxy or similar will not help with this. – Steffen Ullrich Jul 22 '18 at 15:55
  • What I'm trying to say is something like this- request comes to teeproxy > teeproxy sends that packet to port 1 and port 2 haproxy is listening on port 1 with SSL passthrough , and forwards the request to the backend and to the user (without terminating). While haproxy would listen on port 2 with SSL termination, when packet comes on port 2, it would get decrypted and sent to 'test server'( for http logs) That's just the idea I have, although my knowledge in networking is very limited, and that's why I want to ensure that something like this would be even realistic – Tomas Randomas Jul 22 '18 at 16:05
  • @TomasRandomas: TLS is end-to-end encryption between exactly two parties. What you imagine is the same connection starting at the client terminating at haproxy port 2 and the original target server, i.e. one-end-to-two-ends. Does not work with TLS. – Steffen Ullrich Jul 22 '18 at 16:23
  • Thank you for the clarification, just to make sure 100%, there is no way to decrypt an SSL packet in this scenario: User makes a request "https://google.com" > you receive it , decrypt it and store the request without anything else – Tomas Randomas Jul 22 '18 at 16:29
  • @TomasRandomas: to do this you must have a certificate and matching private key where the certificate was issued by a CA trusted by the client. If you cannot control the client to install such a CA and if you are not Google to be able to get this certificate legally then you will not be able to decrypt the traffic. That's what the end-to-end-protection in TLS is actually designed for in the first place. – Steffen Ullrich Jul 22 '18 at 17:00