Looking for an `:ssl` option building an https proxy

Questions / Help
, ,
1

Hi,

I am building an https proxy and need to forward the encrypted incoming payload of the requests, the proxy being a Man in the middle. I ended up building a gen_tcp server that replies to CONNECT queries from the client by connecting to the remote secure host and forwarding the payloads from both sides.

[gen_tcp listen, accepts...]

  def handle_info({:tcp, socket, payload}, %State{socket: socket, client_socket: nil} = state) do

   [set host, port...]

    with {:ok, client_socket} <-
           :ssl.connect(
             String.to_charlist(host),
             port || 443,
             [
               {:log_level, :all},
               {:packet, :raw},
               {:mode, :binary},
               {:verify, :verify_peer},
               {:cacerts, :public_key.cacerts_get()}
             ],
             @connect_timeout
           ) do
      :gen_tcp.send(socket, "HTTP/1.1 200 OK\r\n\r\n")

      :inet.setopts(socket, active: :once)
      :ssl.setopts(client_socket, active: :once)
      {:noreply, %{state | client_socket: client_socket, start: start}}
    end
  end

[...]

  def handle_info({:ssl, socket, payload}, %State{client_socket: socket} = state) do
    :ssl.setopts(socket, active: :once)
    :gen_tcp.send(state.socket, payload)
    {:noreply, state}
  end

  def handle_info({:tcp, socket, payload}, %State{socket: socket} = state) do
    :inet.setopts(socket, active: :once)
    :ssl.send(state.client_socket, payload)
    {:noreply, state}
  end

The problem here is that the incoming payload (from the remote server) is decrypted by the erlang :ssl library which makes the client receive clear messages instead of encrypted ones, raising an SSL error. Note that the forwarding looks fine with the HTTP version of the snippet.

Does anyone know if there is an :ssl.connect option that disables payload decrypt?

Thanks.

2

This doesn’t make much sense. SSL is part of Presentation Layer(Layer 6) when TCP is at Transport Layer(Layer 4), you don’t want the features provided by SSL protocol, you don’t use it, hence why :gen_tcp and :ssl are separated applications.

Can you be more specific here, is it a generic http client that uses :ssl under the hood and what kind of behavior you are actually expecting?

The generic advice would be:

  1. Force it to use http instead of https (assuming this is what you want to do), even though this is not the best idea even in private networks these days;
  2. Re-encrypt back the traffic with a self-signed key, this option will require you to tune the key verification phase done by :ssl on client, nothing hard (at least if you understand how certificates work);
  3. Same as 2 but have the proxy exposed to the internet where you can fetch letsencypt certificates for a specific domain name, then use that key to re-encrypt the traffic back, in theory if you are doing this right, the internal clients will be able to resolve the https certificates successfully with the default configuration.
3

Thank you for your reply.

The issue was the proxy was performing the handshake instead of the client which caused the encryption/decrypt problem. The solution was to open a TCP connection toward the target server (not an SSL one) and let the client upgrade to TLS.

1 Like
4

Makes complete sense if you are using :ssl on proxy.

In your case this is not a https proxy, but one at TCP/SSL level, as once the ssl handshake is complete, there is no way you can decrypt and filter the traffic on your proxy.

1 Like