I'm implementing an SSL tunnelling proxy, just like what Squid proxy's CONNECT tunnel provides
However, I observed that sometimes the SSL connections go through me return SSL Errors.Those errors are: invalid TLS padding, bad record MAC...
My proxy is simple, just read() from downstream socket then write() to upstream socket. (I also implemented data buffering when one of those pair sockets is not writable)
Hope you can help me with this
Edited: Mine is just a tunnel forwarding proxy, I do not intercept the SSL connection between client and server. Just read() then write()
Related
I need to explore the traffic from one program.
The program makes something like a connection through the WebSockets.
Fiddler displays this:
Request Headers: CONNECT 144.***:443 HTTP/1.0
Response: HTTP/1.0 200 Connection Established
End empty body.
But the HTTP analyzer displays full information after that response, and that information continues flowing. Very likely like WebSockets (one connection and receive more answers).
And fiddler display zero traffic.
How can I explore such traffic through the fiddler?
A CONNECT call is always the first command a client sends if it uses a Proxy. Translated CONNECT just means: Please start a connection to the following server and that port. Through that connection the real HTP calls are then transmitted. Therefore CONNECT is not a real HTTP
request.
Fiddler does not show the content of CONNECT requests/responses to port 443 endpoints because those connections are HTTPS/TLS protected (hence the shown data would be useless). You need to enable HTTPS decryption and install the Fiddler root CA certificate into the client app/OS to see the decrypted content of those connections.
With TCP it is pretty easy because is connection-based and once a connection is established you can set up the SSL object associated with that connection once and stream data...UDP however is connection-less, so does this mean I have to set up a new SSL object for each UDP packet I get from a client? Is there a way I could use the same SSL object for subsequent reads from the socket as long as I'm talking to the same client?
Even with UDP you can still "bind" and "connect" a socket. If you are using OpenSSL then use DTLSv1_listen() to await a connection from a new client. When one arrives, create a new socket which is connected to the client's address/port and use a new SSL object for that socket. All subsequent DTLS packets to/from that client can use the same SSL object.
I'm trying to implement an HTTP proxy for learning and debug purpose.
The support of plain HTTP transactions was pretty straightforward to implement and now I'm looking to implement support for SSL/TLS tunnels.
From RFC 7230:
A "tunnel" acts as a blind relay between two connections without
changing the messages. Once active, a tunnel is not considered a party
to the HTTP communication, though the tunnel might have been initiated
by an HTTP request.
It's not very clear whether I shall build the TLS socket from the socket on which the HTTP CONNECT transaction took place. I assume it is the case, since HTTP is stateless, but I just want to be sure.
When a client connects to an HTTP proxy, CONNECT is used to have the proxy establish a persistent TCP connection with the target TCP server. Then the proxy blindly passes data as-is back and forth between the two TCP connections until either the client or server disconnects, then the proxy disconnects the other party. This allows the client to send data to the server and vice versa, such as TLS packets. This is important so the TLS server can verify the client's identity during the TLS handshake.
So, to answer your question - yes, the client must establish a TLS session with the target server using the same TCP socket that it used to issue the CONNECT request on. Once the CONNECT request has succeeded, the client can treat the existing TCP connection as if it had connected to the server directly. The proxy is transparent at that point, neither party needs to care that it is present.
I have chosen QuteCom SIP client for windows to chat.I have installed and configured the account with my public server. My SIP server is kamailio.The connection to the server is not established. The application is connecting to the server for a long time.
Any help is appreciated.
If looks like keep connecting, then I guess the SIP messages don't get to the server.
You can install Wireshark to monitor traffic on windows host on port 5060 (the SIP port) in order to see if SIP messages are sent to the server.
On server, you can install ngrep for the purpose of seeing if traffic from the phone comes there. The command would be like:
ngrep -d any -qt -W byline port 5060
If you don't see traffic coming to the SIP server, then might be a firewall or an ALG between the client and the server, or, a firewall even on client host or server itself.
If it is something in between (not on client host or server), then you should try to use TCP or better TLS.
Note that if you have the firewall on the server, you will see the SIP packets coming on the network, but they will be dropped by the kernel before getting to application layer. Typically on Linux you can see the firewall rules with:
iptables -L
If the SIP packets come to the server, then set debug=3 in kamailio.cfg, restart kamailio and watch the syslog file (e.g., /var/log/syslog or /var/log/messgaes) for kamailio-specific debug messages -- you should get hints of what happens during processing.
I'm connected to a network that sends and receives a bunch of data packets, but these packets are visible to others (can be sniffed) so I want to tunnel them. I don't know how! I know about socket programming, proxies, vpns, all of the protocols like PPTP, SSH, SSL, TLS, etc. I'm looking for the actual CODE that takes the packages before they're sent,*sends them by tunneling (encapsulating the data)*
How can I do this?
Any information regarding this subject or how to tunnel is appreciated!
Use ssh and socks proxy:
ssh -D 5000 remotehost.com
Then, while your SSH session is alive, you can configure your local apps (such as your web browser) to use this connection as an encrypted tunnel. Just configure them use use localhost:5000 as the socks proxy server, and you're good to go. Note that the packets will only be encrypted between your client and the remote ssh server - once they leave the server, they will be in whatever form they usually are.
If you are on windows, you can do with with putty.