CODEWITHSUNDEEP
c++openssl
MikelSV
MikelSV

Reputation: 195

openssl accept connection use my buffer

In normal: browser send to my proxy: "CONNECT... \r\n\r\n", proxy send "200 OK\r\n\r\n", browser send encrypted request, proxy call SSL_accept(socket). OK.

Problem: browser send to my proxy server: "CONNECT... \r\n\r\n" + next encrypted request. Proxy send "200 OK\r\n\r\n", call SSL_accept(socket) returned SSL_ERROR_SSL or SSL_ERROR_SYSCALL because proxy read in buffer part of encrypted request.

Solutions:

  1. Use recv(sock, buf, buffer_size, MSG_PEEK) and recv(sock, buf, used_size, 0). Problem: all data will be read, or endless signal in pool().

  2. How to call SSL_accept() use my buffer with part of encrypted data?

  3. Any solutions?

Upvotes: 0

Views: 309

Answers (1)

Remy Lebeau
Remy Lebeau

Reputation: 596176

The problem is with your proxy, not the client.

Per Section 3.3 of the CONNECT specification:

3.3. Data Pipelining

It is legal for the client to send some data intended for the server before the "200 Connection established" (or any other success or error code) is received. This allows for reduced latency and increased efficiency when any handshake data intended for the remote server can be sent in the same TCP packet as the proxy request. This allows the proxy to immediately forward the data once the connection to the remote server is established, without waiting for two round-trip times to the client (sending 200 to client; waiting for the next packet from client).

This means that the proxy server cannot assume that reading from the client socket descriptor would only return the proxy request.) Rather, there may be any amount of opaque data following the proxy request that must be forwarded to the server once the connection is established. However, if the connection to the remote server fails, or if it is disallowed by the proxy server, the data intended to the remote server will be discarded by the proxy.

The real mistake is that your HTTP proxy should not be calling SSL_accept() to begin with, as it is not the target of the client's TLS handshake. The requested server is the target, and accordingly only it can properly respond to the handshake. Your proxy must not respond to the handshake. It is likely to cause failure on the client side (especially if the client is doing its job correctly to validate the response is not from a man-in-the-middle).

Your proxy must establish a normal unencrypted connection to the requested server and then pass any raw data as-is back and forth. Your proxy is not a participant in the client/server encryption session, it is merely a pass-through to facilitate data exchange between the client and server, nothing more.

Do not attempt to interpret the client's or server's data in any way, it is not your data to process. Everything after the initial CONNECT request is opaque to the proxy and must be forwarded as-is. You don't know how, and cannot make any assumptions about how, the client and server are communicating with each other.

Upvotes: 1

Related Questions