In HTTP tunnelling using CONNECT method, when client and proxy communicates over plain HTTP (no TLS), the setup works at TCP layer. Client sends TCP segments to Proxy and Proxy forwards it to final server. As TCP segments are being blindly forwarded, proxy just acts as a hop between client and server providing just anonymisation by replacing client Ip with its own as source IP. Also, client can establish a secure with destination server using TLS (as TLS handshake packets will be forwarded by proxy to final server without interpretation).
However, what happens when connection between client and Proxy is itself encrypted using TLS i.e. the initial CONNECT method was sent on a secure channel. How will client do TLS handshake(client hello, server hello etc.) with the destination server. As I understand it, TLS is used to to encrypt application layer data. Does client prepare the client hello message and pass it as application layer payload to proxy over the TLS channel established with Proxy. Proxy then decrypts this client hello (as application layer payload) and forward it as TCP segment it to server i.e. proxy is relaying application layer data that it received from client as TCP segments to server?
Thank!!
Related
if my application uses(for instance online shopping application ) plain tcp protocol for connecting to our partners' hosts who process payments, tcp is not secure way for transmitting data? TLS X.X or SSL will be applicable only for https (Application Layer protocols)? or TLS/SSL its self a protocol which can work on top of TCP?
Also, Say for example a payment processor shared http endpoint which is TLS enabled one. and I am connecting it with tcp.
--- how the encryption/decryption happens at both ends ?
Thanks in advance.
TLS is a protocol which works on top of TCP. HTTPS is HTTP on top of TLS on top of TCP. There are other protocols which use TLS on top of TCP like IMAPS, FTPS etc. One can also establish a TLS session on top of an existing TCP connection and transfer data with ones own application protocol. One can even do this after other data where already exchanged over the plain TCP connection, as done within SMTP or IMAP (TLS only after STARTTLS command).
AFAIK, HTTP proxy CONNECT HTTP/1.1 requests tunnel a single TCP connection. After any TCP connection is closed, both upstream and downstream connections are closed. Connection reuse isn't possible. Is it possible to make HTTP/2 requests to a proxy to mux multiple tunneled over a single TCP (upstream) connection to avoid the cost of TCP handshake? Does the HTTP/2 standard allow the CONNECT method?
Yes, in HTTP/2 the CONNECT method exists too:
"In HTTP/2, the CONNECT method is used to establish a tunnel over a single HTTP/2 stream to a remote host for similar purposes"
Here are my understandings about these and I see few gaps there; especially when and where to use
HTTP(s) proxy:
Can be used as TLS termination proxy
Can be used to modify HTTP headers
Can be used as a load balancer or a public IP provider in front of DMZ to shield backend servers
TCP Proxy
Can be used as reverse proxy for TCP connections and can support not only HTTP but also other application layer protocols such as FTP
My question(s)
If I only accept HTTP web traffic what are the use cases where we should use TCP proxy instead of HTTP Proxy
Is this understanding connect? TCP clients can connect to a single socket on TCP proxy and TCP Proxy can open up multiple connections to the backend servers something similar load balancers
SOCKS5 Proxy
From Wikipedia
Socket Secure (SOCKS) is an Internet protocol that exchanges network packets between a client and server through a proxy server. SOCKS5 additionally provides authentication so only authorized users may access a server. Practically, a SOCKS server proxies TCP connections to an arbitrary IP address, and provides a means for UDP packets to be forwarded.
SOCKS performs at Layer 5 of the OSI model (the session layer, an intermediate layer between the presentation layer and the transport layer). SOCKS server accepts incoming client connection on TCP port 1080
My questions
What is the use of SOCKS proxy in an web application
Difference between TCP and SOCKS5 proxy
In TCP/IP model is it a transport layer protocol
What are the use cases for proxying UDP connections
If I only accept HTTP web traffic what are the use cases where we should use TCP proxy instead of HTTP Proxy
A TCP proxy terminates the incoming TCP socket, opens outbound socket and moves data in between. It doesn't/can't change the data in between since it doesn't understand any of it. Most often, a TCP proxy is statically configured and can only create connections to a single host:port combination.
An HTTP proxy understands HTTP. It looks at the incoming HTTP request and uses an outbound, potentially changed HTTP request to fulfill the request. The proxy can read the HTTP request's host address and connect to multiple hosts that way. It is aware of the HTTP application level which a TCP proxy isn't. Some HTTP proxies can even fulfill FTP or HTTPS requests for clients just using HTTP.
A "forward" proxy is a proxy connecting from private to public IP space (which was the original idea for a proxy) while a "reverse" proxy connects from public to private IP (e.g. mapping to multiple web servers from a single, public IP). Technically, it's the same, but from the security POV there's a huge difference (in "forward" you trust the clients, in "reverse" you trust the servers).
Is this understanding connect? TCP clients can connect to a single socket on TCP proxy and TCP Proxy can open up multiple connections to the backend servers something similar load balancers
Yes.
Difference between TCP and SOCKS5 proxy
SOCKS5 is a general proxy protocol that can do more than a TCP proxy, including one-to-many connections, listening ports, and UDP.
In TCP/IP model is it a transport layer protocol
To me, SOCKS5 is an application layer protocol to arbitrate a transport protocol connection. Some argue that SOCKS5 is a session layer protocol in between transport and application layer - that holds some truth but the session layer is ill-defined in TCP/IP.
What are the use cases for proxying UDP connections
For instance, SOCKS5 can be used for private-to-public Internet access or for (insecure) public-to-private LAN access.
I am trying to wrap my head around the ssl Tunneling process which is performed by an http proxy after receiving the CONNECT method from a client.
Stuff I can't seem to find or understand in docs, blogs, rfcs:
1) when setting up the tunnel, are the two connections from client-proxy and proxy-destination two separate connections or just one and the same? E.g. is there an tcp handshake between client-proxy and another between proxy-destination?
2) when starting the ssl handshake what node is targeted (ip address/hostname) by the client? The proxy or the destination host? Since ssl requires a point-to-point connection to make the authentication work my feeling tells me it should be the destination host. But then again that wouldn't make sense since the destination host isn't (directly) accessible from the clients perspective (hence the proxy).
when setting up the tunnel, are the two connections from client-proxy and proxy-destination two separate connections or just one and the same? E.g. is there an tcp handshake between client-proxy and another between proxy-destination?
Since the client makes the TCP connection to the proxy there is no other way than that the proxy is making another TCP connection to the server. There is no way to change an existing TCP connection to be connected to a different IP:port.
when starting the ssl handshake what node is targeted (ip address/hostname) by the client? The proxy or the destination host?
The SSL handshake is done with the destination host, not the proxy.
Since ssl requires a point-to-point connection to make the authentication
It doesn't need a point-to-point connection. It just needs that all data gets exchanged unmodified between client and server which is the case when the proxy simply forwards the data.
I have a web application running on port 8080 of a server. I am accessing this application from my windows machine. From which port on my windows machine does the request originate? How does the server send back the response to the same port? Is it all handled by HTTP specification?
It's handled by TCP, which is the underlying transport protocol used by HTTP. When a client connects to a server using TCP, it sets up a client port and includes it in the TCP header of every packet it sends to the server. The server knows which port to send the response to based on seeing this in the header.