It is possible having a wss protocol over http ? i've read on a forum that ws work with http, but wss works only with https ?
Is that true ?
Cause i'm trying to test it on my wamp on localhost, but not working
ws tells a WebSocket client library to use http to connect to a WebSocket server. Likewise, wss tells a WebSocket client library to use https to connect to a WebSocket server. Just that. "ws protocol" and "wss protocol" are strange words. "WebSocket protocol" is the right word. WebSocket protocol can be used over both plain HTTP connections (http) and secure HTTP connections (https).
Note that communication between a WebSocket client and a WebSocket server starts as a normal HTTP protocol. To start WebSocket communication, a WebSocket client sends a request like below to a WebSocket server (This is an excerpt from RFC 6455, 1.2. Protocol Overview).
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
As you can see, this is a normal HTTP GET request. A WebSocket server can wait for this kind of requests on an unsecured port (http, 80 is the default) or on a secured port (https, 443 is the default). It's up to WebSocket servers.
If a WebSocket server you are using is waiting for requests on an unsecured port, pass ws to a WebSocket client library you are using. Otherwise, if the WebSocket server is waiting for requests on a secured port, pass wss to the WebSocket client library.
Some implementations of WebSocket client libraries accept not only ws and wss but also http and https just for developers' convenience.
"WSS on http" is a strange word. On the other hand, "WebSocket protocol on http" and "WebSocket protocol on https" make sense.
Related
I am trying to use the same port on the same host.
Websocket URL
ws://aaa.bbb.cc.ddd:eeee/ws
HTTP URL
http://aaa.bbb.cc.ddd:eeee/docs
But when I open the "http://aaa.bbb.cc.ddd:eeee/docs" page, I get this error message.
Failed to open a WebSocket connection: invalid Connection header: keep-alive.
You cannot access a WebSocket server directly with a browser. You need a WebSocket client.
Http does not work. But, websocket is connected normally.
How can I solve this problem?
The WebSocket protocol is not the HTTP protocol.
Although the WebSocket protocol does initiate a new connection using an HTTP request, it quickly upgrades the connection to full WebSocket (which requires a Connection: upgrade header in the initial request, not Connection: keep-alive).
You can't use a vanilla web browser to directly communicate with a WebSocket URL, as such a browser doesn't know how to finish the upgrade, let alone process any WebSocket packets. So, you must use a valid WebSocket client (such as the WebSocket API that modern browsers expose to client-side scripting).
Many proxy soft provides multiple protocol over one port.
1.
Is there any byte (above or in TCP/UDP package) reserved to mark which protocol client is using?
As I know, HTTP protocol is just carried by TCP's data segment, and there is no any other mark.
So how proxy software tell the protocol when received a request?
(By guessing the first one or two bytes received? It doesn't sounds a good idea)
2.
What's the difference between HTTP proxy and HTTPS proxy?
Here are my guesses
"HTTP proxy" only means a service that can provide proxy for HTTP protocol, And a "HTTPS proxy" can provides service for HTTPS protocol? (means the only difference is whether they can deal HTTP CONNECT method) So the HTTPS proxy is just a functionally enhanced HTTP proxy
Or
HTTPS proxy offers extra security layer between client and proxy server? (to protect the HTTP CONNECT method headers?) So the communication process is quite different between HTTP proxy and HTTPS
proxy, and both HTTP proxy and HTTPS proxy can service HTTP/HTTPS protocol ?
Is there any byte (above or in TCP/UDP package) reserved to mark which protocol client is using?
It is not a single byte, but a HTTP request is clearly distinguishable from a SOCKS request, as a look at the respective standards (RFC 7230, RFC 1928) would show. It isn't the case that all protocols can be easily distinguished, but it is true for SOCKS and HTTP.
What's the difference between HTTP proxy and HTTPS proxy?
A HTTPS proxy is a HTTP proxy used for https:// requests. This is done by using the CONNECT method to create a tunnel through the proxy to the final server and then doing end-to-end HTTPS (TLS+HTTP) inside this tunnel.
... Or HTTPS proxy offers extra security layer between client and proxy server?
This exists too, but it is usually called "HTTP proxy over TLS", "HTTP proxy over HTTPS", "encrypted proxy connection" or similar, but not "HTTPS proxy".
We are trying to make a secure communication between our embedded system and web server.Firstly we implement HTTP connection to in our microcontroller. I am just connecting to 80 port of my web server and send simple GET request to this port as example below :
GET /foo.php?msg=test HTTP/1.1
HOST: foo.com
My questions is,How we will turn this to HTTPS ? Which port i should connect ?
Will be any difference on structure of GET request above ? Will i have to do some encryption manually or connect to "https" link instead "http" is enuogh for secure communication.
Thanks for any information
The only difference between a HTTP request and a HTTPS request is that the first is send over a plain TCP connection while the other is send over a TLS connection, i.e.:
with HTTP you establish a TCP connection and send the request over this connection
with HTTPS you establish a TCP connection, upgrade this connection to TLS (including proper certificate validation etc!) and then send the same request as you did with HTTP over this connection.
Apart from that I recommend to either use an established library for HTTP or carefully read the standard. Although HTTP looks simply it is actually not and there are many questions here where users try to do a simply HTTP request and trip over behavior they did not expect.
For example in your case the server might send the response with chunked encoding, with content-length or simply end it with connection close. And it might wait for further requests on the same connection since HTTP/1.1 implicitly enables HTTP keep-alive. Does your code really account for all these cases?
I'm not clear why the handshake for WebSocket is HTTP. Wiki says "The handshake resembles HTTP so that servers can handle HTTP connections as well as WebSocket connections on the same port." What is the benefit of this? Once you start communicating over WebSocket you are using port 80 also...so why can't the initial handshake be in WebSocket format?
Also, how do you have both WebSocket and HTTP servers listening on port 80? Or is it typically the same application functioning as HTTP and WebSocket servers?
Thanks y'all :)
WebSockets are designed to work almost flawlessly with existing web infrastructures. That is the reason why WS connections starts as HTTP and then switches to a persistent binary connection.
This way the deployment is simplified. You don't need to modify your router's port forwarding and server listen ports... Also, because it starts as HTTP it can be load balanced in the same way that a normal HTTP request, firewalls are more lean to let the connection through, etc.. etc... Last but not the least, the HTTP handshake also carry cookies, which it is great to integrate with the rest of the app in the same way that AJAX does.
Both, traditional HTTP request-response and WS, can operate in the same port. Basiclally the WS client sends a HTTP request asking for "Upgrade:websocket", then if the server accepts the WS connections, replies with a HTTP response indicating "101 Switching Protocols", from that point the connection remains open and both ends consider it as a binary connection.
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)