I know there are a lot of different comminucation protocals like: http, tcp, ssh, socks5, SMTP, POP,etc.
I also know that to achieve a comminication, we need to connect localhost:localport to remotehost:remoteport. For example, if we google something, we would connect a random local port to www.google.com: 80. If we ssh a remote host, we would connect a random local port to remotehost: 22.
My question is: Are communication protocol Half-duplex or Full-duplex?
I guess the answer is Half-duplex. Because I think in http connection, at first we send the request from localhost:localport to remotehost:80, and then the remote server send its response from remotehost:80 to localhost:localport. Similarly, in ssh connection, at first we sent the ssh commands to remote host, after receiving the commands, the remote host do something and send the results back to the local host.
So I think in one connection between localhost:localport and remotehost:remoteport, the message is sent either from localhost:localport to remotehost:remoteport, or from remotehost:remoteport to localhost:localport.
Am I right?
As explained in this article:
SSH is a bidirectional full duplex protocol, which means that it’s not synchronous like HTTP where you need to send a message for a response to happen.
With SSH the remote host might want to tell you something even if you have remained silent. This connector uses a callback flow approach to decouple the “sending” operation from the “receiving” operation.
As documented in this IETF draft, most implementations do allow full-duplex HTTP (for 2xx responses).
Full-duplex HTTP follows the basic HTTP request-response semantics but also allows the server to send response body to the client at the same time when the client is transmitting request body to the server.
Requirements for full-duplex HTTP are under-specified in the existing HTTP (Hypertext Transfer Protocol -- HTTP/1.1) specification, and this memo intends to clarify the requirements of full-duplex HTTP on top of the basic HTTP protocol semantics.
Related
My question is about networking. I'm just looking for a simple answer, yet I couldn't find one after 1 hour research. I know there are techniques such as Wi-Fi Hotspot, man-in-the-middle-attack, local network, echo switch, etc. But I couldn't find an answer to my specific question.
Let's say, client A wants to communicate with server B, and server B says client A must authenticate himself via HTTP basic authentication first. My question is, what happens if client A sends the authentication credentials via HTTP layer (insecure), who can read the HTTP headers that the client A sends to server B over the internet? Would it be easy to do that? Like placing a breakpoint between two arbitrary routers, which help to transfer the packets across the internet, in order to read those headers? How does it work in general?
Thank you!
PS.: I am not trying to learn and do it. I just want to know, how dangerous it would be, if the HTTP basic auth is made via the insecure HTTP layer.
Who can read the HTTP headers that the client A sends to server B over
the internet?
Your Network Provider (e.g Wi-fi hotspot Provider).
Your Domain Name System server (DNS, as 192.168.1.1).
Your Internet Service Provider (ISP).
Your Virtual Private Network if using one (VPN server).
Yourself Or a Virus.
and here comes the HTTPS (HTTP + SSL Encryption)
SSL is about communicating in a language that you and the server only understand.
How dangerous it would be if the HTTP basic auth is made via the insecure HTTP layer?
Well, from above, You can totally get that a simple virus or even a public Wi-fi Hotspot Device can capture and see all of your data if the communication was done in a plain HTTP Socket.
A Simple packet may contain all of your Device information including its basic contents as your passwords, credit cards information, The HTML form for the signup/login that you've just completed with all its data, VoIP Calls and messages being sent to the server + upcoming/received ones.
that's why we need SSL encryption and the server should have a valid SSL certificate too.
By the way, your device may have sent thousands of packets while you read this now!
Capturing the packets that your device sends or even the packets that other devices on your network send can be done through any packet capturing tool or software as Wireshark.
My understanding regarding network model communication:
Application layer:
1. HTTP(Not Persistent or stateless): For exchanging messages like get, post, put etc. Here connection is made to webserver and disconnected after sending response. So server will not keep track of the previous requests.
2. Websockets(Persistent or statefull): For creating a communication channel that will be open to exchange data. Here we can keep track of the previous requests. Like we can know how many users are currently connected to our server.
Transport layer:
TCP(Persistant and Statefull): Will let the server know to which application to connect using port number. Both HTTP and web sockets will work upon this layer.
Considering working with HTTP and TCP:
I make a HTTP request from browser(application layer):
Connects to web server sends all files requested and also makes a TCP connection with the application(transport layer).
After sending response it's disconnected.
My confusion:
I got totally confused when I heard, read that TCP is Statefull and Persistant connection.
Q1. Now after step three is browser still connected to webserver because of TCP?
Q2. Is the context object we get in server side in c# code is the complete request packet with HTTP info, TCP info, function to invoke or controller to invoke in MVC etc?
Q3. If client and server are still connected with TCP. Then on next HTTP request does it will use the available TCP connection or will create new TCP and HTTP connection? Why can't it use previous TCP to communicate? Or TCP will be destroyed after HTTP? Or what's happening?
I understand that a SOCKS proxy only establishes a connection at the TCP level while an HTTP proxy interprets traffic at HTTP level. Thus a SOCKS proxy can work for any kind of protocol while an HTTP Proxy can only handle HTTP traffic. But why does an HTTP Proxy like Squid can support protocol like IRC, FTP ? When we use an HTTP Proxy for an IRC or FTP connection, what does specifically happen? Is there any metadata added to the package when it is sent to the proxy over the HTTP protocol?
HTTP proxy is able to support high level protocols other than HTTP if it supports CONNECT method, which is primarily used for HTTPS connections, here is description from Squid wiki:
The CONNECT method is a way to tunnel any kind of connection through an HTTP proxy. By default, the proxy establishes a TCP connection to the specified server, responds with an HTTP 200 (Connection Established) response, and then shovels packets back and forth between the client and the server, without understanding or interpreting the tunnelled traffic
If client software supports connection through 'HTTP CONNECT'-enabled (HTTPS) proxy it can be any high level protocol that can work with such a proxy (VPN, SSH, SQL, version control, etc.)
As others have mentioned, the "HTTP CONNECT" method allows you to establish any TCP-based connection via a proxy. This functionality is needed primarily for HTTPS connections, since for HTTPS connections, the entire HTTP request is encrypted (so it appears to the proxy as a "meaningless" TCP connection). In other words, an HTTPS session over a proxy, or a SSH/FTPS session over a proxy, will both appear as "encrypted sessions" to the proxy, and it won't be able to tell them apart, so it has to either allow them all or none of them.
During normal operation, the HTTP proxy receives the HTTP request, and is "smart enough" to understand the request to be able to do high level things with it (e.g. search its cache to see if it can serve the response without going to the destination server, or consults a whitelist/blacklist to see if this URL is allowed, etc.). In "CONNECT" mode, none of this happens. The proxy establishes a TCP connection to the destination server, and simply forwards all traffic from the client to the destination server and all traffic from the destination server to the client. That means any TCP protocol can work (HTTPS, SSH, FTP - even plain HTTP)
Can someone explain the difference between the HTTP request and it handling and socket requests on 80 port. As I understood, HTTP server listen the 80 port and when someone sends an HTTP request on this port - server handle it. So when we place socket listener on port 80, and then write HTML formatted message to it - does it means that we send usual HTTP request? But as fiddler said - it false. What's the difference on a packet level? Or another lower than presentation-level between HTTP request and HTTP-formed writing to socket? Thanks.
First of all, port 80 is the default port for HTTP, it is not required. You can have HTTP servers listening on other ports as well.
Regarding the difference between "regular" HTTP requests and the ones you make yourself over a socket - there is no difference. The "regular" HTTP requests you are referring to (made by a web browser for example) are also implemented over sockets, just like you would do it manually yourself. And the same goes for the server. The implementation of the HTTP server listens for incoming socket connections and parses the data that passes there just like you would.
As long as you send in your socket valid HTTP protocol (according to the RFC), there should be no difference in the packet level (if the lower network stack is identical).
Keep in mind that the socket layer is just the layer the HTTP data always passes over. It doesn't really matter who put the data there, it just comes out from the other side the same way it was put in.
Please note that you have some degree of freedom when implementing an HTTP yourself. There are many optional fields and the order of the headers doesn't matter. So it is possible that two different HTTP implementations will be different in the packet level, but will behave basically the same.
The best way to actually see what's going on in the packet level, is by using a network sniffer - like wireshark or packetyzer. A sniffer actually records the packets of the network and shows you their content. So if you record several HTTP implementations (from various browsers) and your own socket implementation, you can make the required changes to make them identical in the packet level.
My Question is related to the HTTP Streaming Method for realizing HTTP Server Push:
The "HTTP streaming" mechanism keeps a request open indefinitely. It
never terminates the request or closes the connection, even after the
server pushes data to the client. This mechanism significantly
reduces the network latency because the client and the server do not
need to open and close the connection.
The HTTP streaming mechanism is based on the capability of the server
to send several pieces of information on the same response, without
terminating the request or the connection. This result can be
achieved by both HTTP/1.1 and HTTP/1.0 servers.
The HTTP protocol allows for intermediaries
(proxies, transparent proxies, gateways, etc.) to be involved in
the transmission of a response from server to the client. There
is no requirement for an intermediary to immediately forward a
partial response and it is legal for it to buffer the entire
response before sending any data to the client (e.g., caching
transparent proxies). HTTP streaming will not work with such
intermediaries.
Do I avoid the descibed problems whith proxy servers if i use HTTPS?
HTTPS doesn't use HTTP proxies - this would make security void. HTTPS connection can be routed via some HTTP proxy or just HTTP redirector by using HTTP CONNECT command, which establishes transparent tunnel to the destination host. This tunnel is completely opaque to the proxy, and proxy can't get to know, what is transferred (it can attempt to modify the dataflow, but SSL layer will detect modification and send an alert and/or close connection), i.e. what has been encrypted by SSL.
Update: for your task you can try to use one of NULL cipher suites (if the server allows) to reduce the number of operations, such as perform no encryption, anonymous key exchange etc. (this will not affect proxy's impossibility to alter your data).