OpenSSL: HTTPS proxy

Question

So far, my proxy only deals HTTP connections on port 80: I'd like to improve it and make it manage HTTPS requests. Here's how it works:

the proxy is listening on a given port; Chrome can "see" the proxy thanks to SwitchyOmega plugin and connect the traffic on that given port. The proxy reads the packet's header, gets the request (I parse only GET requests until now), e.g. GET http://www.google.it HTTP/1.1, gets the hostname parsing www.google.it, finds the IP address by resolving the hostname with gethostbyname and assumes the server port is number 80.

Now the proxy send to the server what it received from client by opening a socket: this socket is opened, binded, and then connected to the IP address I resolved before from the hostname.

I read here how to turn a socket into an SSL socket: after socket, bind, listen and accept syscalls, set what you need and pass the socket's file descriptor to SSL_set_fd so I can read and write data through the new SSL file descriptor.

What (most above all) bothers me is the creation of SSL context: if SSLv23_server_method is for servers and SSLv23_client_method is for clients, what should I use for my proxy?

I found no particular proxies configuration in OpenSSL documentation.

Thanks in advance for your help.

Edit: more detailed info about how the proxy works.

How are you implementing your HTTP proxy? If the client sends a `GET`/`POST` request to your proxy requesting an absolute HTTPS URL, your proxy needs to connect to the target server and establish its own SSL/TLS session with the server before then relaying the client's HTTP request and server's response. If the client sends a `CONNECT` request to your proxy, it needs to connect to the target server and pass data back and forth *as-is*, no SSL/TLS involved. If the proxy handled the client's or server's SSL/TLS data, it would be acting as a MITM attacker, something SSL/TLS is designed to prevent — Remy Lebeau, Mar 18 '16 at 18:36
SSL/TLS has no concept of proxies, only point-to-point connections. Your proxy has a connection to the client, and a separate connection to the target server, passing data between the two connections. It has to secure (or not) those connections independently of each other, and how you must do that depends on how the client is asking your proxy to relay HTTP. — Remy Lebeau, Mar 18 '16 at 18:39
If I well understood: the proxy gets a request from client, if the request contains the substring `GET https`, the proxy opens an SSLed socket to the server and sends the data; the proxy gets the response from the server and sends the data to the client through another SSLed socket. Instead of having a single secure connection between client and server, with my proxy I would have a secure connection between client and proxy and another secure connection between proxy and server: am I right? — elmazzun, Mar 18 '16 at 19:57
Essentially, yes (IF the client uses SSL to connect to the proxy, that is). In that `GET` scenario, the proxy would read (and decrypt, if needed) the client's request, detect and parse the HTTP/S url, create a connection to the server (and secure it with SSL if HTTPS), send the (SSL-encrypted) request and read the (SSL-decrypted) response, then send the (decrypted) response data to the client connection (re-encrypting it if the client connected using SSL). — Remy Lebeau, Mar 18 '16 at 20:15
Great, turn your last comment into an answer and I'll accept it! — elmazzun, Mar 18 '16 at 20:20
In a `CONNECT` scenario instead, the client would simply connect to the proxy without SSL, request the server host/port to connect to, the proxy would connect to that server without SSL, and if successful then the client and server (not the proxy) would secure their connection endpoints with SSL so they are talking to each other directly (needed for peer validation and such). The SSL handshake and subsequent HTTP data would pass through the proxy as-is, it would only be able to see the raw encrypted data, not the HTTP data. — Remy Lebeau, Mar 18 '16 at 20:21

score 1 · Accepted Answer · answered Mar 18 '16 at 20:31

SSL/TLS has no concept of proxies, only point-to-point connections. Your proxy has a connection to the client, and a separate connection to the target server, and it is simply passing data between the two connections as needed. So the proxy has to secure (or not) those connections independently of each other, and how it must do that depends on how the client is asking the proxy to relay HTTP.

If the client sends a GET/POST/etc request to your proxy requesting an absolute HTTP URL, your proxy needs to connect to the target server without using SSL/TLS, and then relay the client's HTTP request and server's response back and forth. The client may or may not connect to your proxy using SSL/TLS. If it does, that session is only between the client and your proxy, and the data read from, and sent to, the client is encrypted/decrypted accordingly.

If the client sends a GET/POST/etc request to your proxy requesting an absolute HTTPS URL, your proxy needs to connect to the target server and establish its own SSL/TLS session with the server, and then relay the client's HTTP request and server's response back and forth. The proxy is acting as a client to the server, so use a client-based method (sslv23_client_method(), etc). The real client may or may not connect to your proxy using SSL/TLS. If it does, that session is only between the client and your proxy, and the data read from, and sent to, the client is encrypted/decrypted accordingly, separate from the encryption used on the server connection.

If the client sends a CONNECT request to your proxy, the proxy needs to connect to the requested host/port and then pass raw data back and forth as-is. No SSL/TLS is involved on the proxy's part. If the proxy handled the client's or server's SSL/TLS data, it would be acting as a MITM attacker, something SSL/TLS is designed to prevent. If the connection to the server is successful, the client and server (not the proxy) would secure their respective endpoints with SSL/TLS so they are talking to each other directly (needed for exchanging certificates and keys, and validating identities). The SSL/TLS handshake, and subsequent encrypted HTTP request/response data, would pass through the proxy as-is. The proxy would only be able to see the raw encrypted data, not the HTTP data, since only the client and server have the keys needed to decrypt the data.

OpenSSL: HTTPS proxy

1 Answers1