Java HTTPS connection redirection

Question

I am writing a simple program in Java that receives connection requests from a browser (e.g. Firefox), parses the request for statistical information, and then redirects the request to its original destination. The program then reads the response from the recipient, analyzes the response for statistical information, then redirects the response to the browser.

The pseudo-code of this operation is as follows:

 // Accept connection from browser and read request 1. Socket browserConnection = serverSocket.accept(); 2. browserConnection.getInputStream().read(buffer); 3. SocketInetAddress destInetAddress = parseHttpRequest(buffer); // Connect to destination and forward request 4. Socket destConnection = new Socket(destInetAddress); 5. destConnection.getOutputStream().write(buffer); // Read response from destination 6. destConnection.getInputStream().read(buffer); 7. parseHttpResponse(buffer); // Forward response to browser 8. browserConnection.getOutputStream().write(buffer); 

This works well with HTTP connections, but I get connection reset for HTTPS connections.

NOTE. I know the difference between HTTP and HTTPS connections, which, unlike HTTP, is not just a one-time send , and then some receives . My code for HTTPS reads as much as needed, and also writes as much as necessary.

Why do I get connections from any HTTPS server (for example, https://www.google.com , https://www.comodo.com , etc.) Am I trying to connect ?!

Answer 1

With the HTTPS proxy server, the browser sends a CONNECT command to the proxy server to establish a TCP connection with the target server (for example, https://www.google.com ). After the proxy establishes a connection, it returns an OK message to the browser. The browser will then start SSL handshaking with the target server to initiate encrypted data transfer. A proxy should not interfere with data. All the proxy needs to do is transfer the byte stream between the browser and the destination server.

Answer 2

HTTPS is protected to prevent man-in-the-middle attacks. What you're talking about, whether it is legal or not, is what looks like a man-in-the-middle attack. With HTTPS, you cannot just intercept packets destined for another destination and read them. However, you can have packets directed at you, provide your client with a security certificate, decode packets, do whatever you want with them, transcode them and transfer them to another destination. The difference is that the client must know that you exist and who you are. Otherwise, he will not be able to contact you using HTTPS.