I have a TCP server sitting on one host in a VPC, and a TCP client sitting on a separate host and VPC. Right now they are able to transmit data to each other using any matching ports, but I want their data to be transmitted to each other over HTTPS (port 443), is there a standard way of doing this?
My initial thought it to have Nginx running on both hosts to handle SSL over 443 with streams to handle the TCP traffic, but I'm lost when it comes to configuring the stream block in Nginx to wrap the TCP traffic with SSL on 443 for outgoing traffic for the server, or how to receive it on the client side and forward it to the TCP client. Any and all help is appreciated.
Related
Let say I have a server XYZ that listens on port 50000 for TCP clients and port 80 for HTTP clients. And on the other side, I have a client that uses a WebSocket to establish a socket connection to port 50000 and will use HTTP port 80 for the handshake (of course).
Now, when the client begins, it will first send a request to server XYZ via the HTTP port 80, and the server will receive its request on port 80 for the handshake and will send a response for welcome. So, in that case, both parties are using port 80 (of course).
Now, when the handshake is done, the standard documentation says that the same TCP connection that is used for HTTP request/response for handshake purposes is then converted to the TCP socket connection. Ok right.
But, but if this whole handshake process and TCP connection for the HTTP request/response uses port 80 the first time, and that the same TCP connection is converted to the TCP socket connection, and this whole process is done via port 80, then how does the same TCP connection get converted to port 50000 for the TCP socket on both parties? Does the client initialize another TCP connection internally for changing to port 50000?
So, can anyone tell how the port conversion is performed and works in the WebSocket from port 80 to a different port in both parties? How does a complete single socket connection get established on the different ports? How does the same TCP connection change/flip its ports?
A TCP socket connection cannot change ports at all. Once a connection has been established, its ports are locked in and cannot be changed. If you have a TCP socket connection on port 80, the only way to have a connection on port 50000 is to make a completely separate TCP socket connection.
A WebSocket cannot connect to port 80 and then switch to port 50000. However, an HTML page that is served to a browser from port 80 can contain client-side scripting that allows the browser to make a WebSocket object and connect it to port 50000. The two TCP connections (HTTP and WebSocket) are completely separate from each other (in fact, the HTTP socket connection does not even need to stay open once the HTML is served, since HTTP is a stateless protocol).
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 load balancer group with few target servers and they are SSL enabled.
Now I want to do the TCP monitoring on the target servers port (443)
Does TCP monitor work with the backends which are on https ?
TCP Monitor, according to me, does a socket connect on the given Host and Port. What this means is, if there is an open port on the target server, then server is considered alive and kicking.
Since this is only a socket connect; protocol HTTP,HTTPS does not matter as long as there is port open and has a listener on the port.
I am looking at traffic generated by my computer when socks server is defined.
I read over the internet and see that its possible to route udp also trough the proxy server.
when i try using different apps that uses UDP and allows socks settings, it uses it only for tcp traffic. why?
I have defined SOCKS5, as i understand that v4 doesnt support udp (why?)
i tried an example, Vuze client - its expert mode allows to prefer udp traffic, setup socks server and even at this point, any udp goes directly to peers.
My wish is to monitor the traffic and see how its transmitted, is it over UDP connection with socks server, or does it actually connects to the socks server in TCP and sends the data, which is then sent via udp to the destination?
When a client wants to relay UDP traffic over the SOCKS5 proxy, the client makes a UDP associate request over the TCP. SOCKS5 server then returns an available UDP port to the client to send UDP packages to.
Client then starts sending the UDP packages that needs to be relayed to the new UDP port that is available on SOCKS5 server. SOCKS5 server redirects these UDP packages to the remote server and redirects the UDP packages coming from the remote server back to the client.
When client wants to terminate the connection, it sends a FIN package over the TCP. The SOCKS5 server then terminates the UDP connection created for the client and then terminates the TCP connection.
Double SSH Tunnel Manager support SOCKS5 With UDP
3proxy Server support UDP