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).
Related
I have configured a coturn server which I need to use with DataChannel for a chat app.
I am trying to reach a point where I can get the coturn server provide me with a tcp allocation.
I am using the standard call of RTCPeerConnection in JS client, providing the turn URI, username and credentials.
The transport I am providing in the URI params is TCP ?transport=tcp.
With all this, I am always receiving a UDP allocation and the server logs ChannelBind requests (UDP based)
Question:
How can I achieve TCP allocations throught webRTC client, to guarantee proper data delivery of the chat app in case of using my relay server?
RFC 6062, opening a TCP port on the TURN server is not supported by WebRTC. It is optional in the spec and nobody needs it since reliability is provided by SCTP.
TCP in the turn uri refers to the protocol between the client and the TURN server
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.
You have two application that need to exchange information among them in a local area network. The first application uses TCP for communication while the second uses UDP. Can we link both applications directly? If your answer is no, explain how we can link them?
(from a homework assignment)
I think the answer is no, we need to use some translator or middleware between them. But what?
As you figured out, you can't simply combine 2 types of connections into one.
TCP is a state-full connection, which requires two computers to establish the connection,
opposing to UDP which is stateless/connectionless connection that requires just one computer, send and forget style.
If you want them to communicate with each other, you must have a middle-ware.
The TCP application should have a TCP Client and TCP Server
The Middle-ware should have a TCP Server that will listen to the TCP application's client and establish connection and a TCP Client that will establish connection with the TCP application's server.
Now the middle-ware can fully communicate with the TCP Application.
In order to do so with the UDP Application, you should listen to UDP at a certain port in order to listen to incoming data from the UDP Application, and send to it over UDP to the UDP Applicaiton (the UDP Application need to listen on that port)
I've read about WebSockets and I wonder why browser couldn't simply open trivial TCP connection and communicate with server like any other desktop application. And why this communication is possible via websockets?
It's easier to communicate via TCP sockets when you're working within an intranet boundary, since you likely have control over the machines on that network and can open ports suitable for making the TCP connections.
Over the internet, you're communicating with someone else's server on the other end. They are extremely unlikely to have any old socket open for connections. Usually they will have only a few standard ones such as port 80 for HTTP or 443 for HTTPS. So, to communicate with the server you are obliged to connect using one of those ports.
Given that these are standard ports for web servers that generally speak HTTP, you're therefore obliged to conform to the HTTP protocol, otherwise the server won't talk to you. The purpose of web sockets is to allow you to initiate a connection via HTTP, but then negotiate to use the web sockets protocol (assuming the server is capable of doing so) to allow a more "TCP socket"-like communication stream.
Web browsers operate at the Application layer, whereas TCP operates at the Transport Layer. As a web application developer, it's easier to send messages over the wire via the Application Layer instead of raw bytes at the Transport Layer.
Underlying WebSockets is TCP, it's just abstracted away for simplicity.
Websocket is a application layer protocol while TCP is transport layer protocol. At transport layer, we usually have TCP and UDP protocol. Any message from application layer need to go through transport layer to be transmitted to other machine. Hence, websocket and tcp have a relationship to each other and can not be comparable.
To make it simple, the websocket communications are done over TCP port number 80 (or 443 in the case of TLS-encrypted connections), which is of benefit for those environments which block non-web Internet connections using a firewall.
Would you like to use existed TCP port or open a new TCP port that might be blocked by firewall?