I've read that WS only works on HTTP, and that WSS works on both HTTP and HTTPS. Are WSS (Secure Web Socket) connections just as secure on an HTTP server as they are on an HTTPS server? Is a Web Socket Secure (WSS) connection still encrypted through TLS/SSL if the website/server is not?
"wss works on both http and https" ??? This is a strange phrase.
wss is secure only because it means "WebSocket protocol over https". WebSocket protocol itself is not secure. There is no Secure WebSocket protocol, but there are just "WebSocket protocol over http" and "WebSocket protocol over https". See also this answer.
As the author of nv-websocket-client (WebSocket client library for Java), I also doubt the phrase "if the HTML/JavaScript that opens the secure WebSocket connection comes over non-secure HTTP, the WebSocket connection is still secure" in the answer by oberstet.
Read RFC 6455 (The WebSocket Protocol) to reach the right answer. To become a true engineer, don't avoid reading RFCs. Only searching technical blogs and StackOverflow for answers will never bring you to the right place.
Is a web socket secure (wss) connection still encrypted through TLS/SSL if the website/server is not?
Yes.
Are wss (Secure Web Socket) connections just as secure on an http server as they are on an https server?
Yes (see above). There is one thing to note: if the HTML/JavaScript that opens the secure WebSocket connection comes over non-secure HTTP, the WebSocket connection is still secure, but an attacker might modify the HTML/JavaScript while being sent from the Web server to browser. A HTTP connection isn't protected against man-in-the-middle sniffing or modification.
Related
We are using IIS and ISAPI DLL's to deliver our web application. We can see the websocket upgrade request coming from the browser in our ISAPI application. We could accept the request and pass the connection to a thread to continue the conversation. The thread would now be the "websocket server" so in this sense we are able to handle incoming http (and https on 443) then switch from http to websocket, is that right?
I am assuming Microsoft's implementation of websockets only works with asp.net?
Some people have said to me "put the websocket server on a different port and have the javascript connect to that port." But, then the websocket server is not using HTTPS (SSL).
For example:
var socket = new WebSocket('ws://echo.websocket.org');
I have lots of books and examples but this simple issue is eluding me.
The thread would now be the "websocket server" so in this sense we are able to handle incoming http (and https on 443) then switch from http to websocket, is that right?
Yes, if the client side send the request which contains the Upgrade: websocket, the websocket serve will switch from http to websocket.
I am assuming Microsoft's implementation of websockets only works with asp.net?
If you means the websocket .net library, it will just work with .net application like asp.net, it is developed based on the .net framework.
For example: var socket = new WebSocket('ws://echo.websocket.org');
As far as I know, the websocket also contains the secure connection like https.
Like below image shows:
More details about the difference between http and websocket, you could refer to below article:
https://developerinsider.co/difference-between-http-and-http-2-0-websocket/
I have a question about SSL. As I know, when we use browser to request from https server, it will make an SSL handshake first then all data will be encryption in the connection. But if I make a request without browser (like request module in nodejs, postman...), will it be an SSL handshake and data encryption on the connection?
Anyone know please explain to me, thank you.
First, stop saying SSL. Its successor is TLS, and it will have 20 years next January.
TLS is a protocol sitting on top of TCP typically (other variants can also use UDP), and provides on top of TCP features some new features about endpoints authentication and transport confidentiality and integrity.
In a way, you can understand it as being sandwiched between TCP and the higher level application protocol, like HTTP.
Saying otherwise you can use many others protocols on top of TLS: you have all email related ones (SMTP, IMAP, POP, etc.), you can have FTP on top of it (while probably not a good idea nowadays), XMPP for realtime communications, etc.
In short, any protocol using TCP could use TLS with some adaptation.
So HTTP is one case among others. HTTP is between an HTTP client and an HTTP server, or webserver for short.
A browser is an HTTP client. One among many ones. When you use curl or wget you are also an HTTP client. So if any HTTP client access an http:// link it will first do the TLS handshake, after the TCP connection and before starting to do anything really related to the HTTP protocol.
You have specialized libraries dealing with TLS so that not all program need to recode everything about this again, since it is also complicated.
The question is regarding Web Socket connection establishment procedure.
from RFC 6455 , i understand that WebSocket technology was developed for browser based applications to establish full duplex TCP connection with the server.
My questions,
So when we Say browser based , the only way to establish web Socket connection is using javaScripts? i.e all browser based clients can establish webSocket connection using JS?
Can we use the WebSockets URL to render webPage on the borwser? Does browsers supports?
Like typing ws://www.sample.com/login in the address bar will display login page?
Does browser understands "ws" as protocol and establishes connection and display the page?
So for my question2 i understand as, to establish a WebSocket connection from Browser, We should already have a webPage and logic in that webPage will establish the WebSocket connection. Please correct me if i am wrong.
Thanks
Pradeep
For the WebSocket API, the client-side code must be JavaScript, yes. The server-side code can pretty much be whatever language you want.
To answer your other question, the WebSocket protocols (both ws and wss) cannot be used to load a web page directly. The WebSocket protocols can only be used to establish a connection with a server-side script, which upon a successful handshake, will upgrade the HTTP connection to a WebSocket connection to reduce the headers sent between the client and server.
So, yes, in general, you should already have a web page coded separately, and then add the WebSocket logic on top of that to establish a socket connection with the server as necessary.
What is the difference between HTTPS and SSL? I read about them and found following:
HTTPS: HTTPS is a combination of HTTP with SSL/TLS. It means that HTTPS is basically HTTP connection which is delivering the data secured using SSL/TLS.
SSL: SSL is a secure protocol that works on the top of HTTP to provide security. That means SSL encrypted data will be routed using protocols like HTTP for communication.
I am wondering where is the difference between these two? Or both are identical?
The explanation of SSL that you've found is wrong.
SSL (Secure Socket Layer) or TLS (Transport Layer Security) works on top of the transport layer, in your examples TCP. TLS can be used for more or less any protocol, HTTPS is just one common instance of it.
HTTP is an application layer protocol.
In regular, non-encrypted HTTP, the protocol stack can look like this:
HTTP
TCP
IP
Ethernet
When using HTTPS, the stack looks like this:
HTTP
TLS (SSL)
TCP
IP
Ethernet
HTTPS runs over SSL (as it's name suggests, HTTP-over-SSL), not SSL over HTTP. First SSL session is established, then all HTTP data are wrapped into secured SSL packets before sending and after receiving.
SSL (Secure Sockets Layer) is a standard security technology to create an encrypted link between a server and a client. This link ensures that all data passed between the server and the client remain private and secure.
It was designed to support protocols such as FTP, HTTP, TELNET.
Hypertext Transfer Protocol Secure (HTTPS) or “HTTP Secure,” is an application specific implementation that is a combination of the Hypertext Transfer Protocol (HTTP) with the SSL/TLS. HTTPS is used to provide encrypted communication and secure identification of a server, so that no middle man can intercept the data easily.
As everything in HTTP is in plain text (or encoded) , it is used with SSL/TLS to encrypt it.
Found this link which explains SSL, TLS, HTTPS :
http://nexsniper.blogspot.com/2017/11/what-is-ssl-tls-and-https.html
I've just started learning SSL and boy is it confusing
Q1 - How long does SSL connection between a client and server persist? Until client surfs to some other URL or…?
Q2
A) Assume a client (browser) establishes a SSL connection with a IIS server.
Now how does IIS figure out on each postback that it is dealing with same authenticated client/browser and thus that it already has a SSL connection established with that client?
B) Assuming SSL connection isn’t lost if browser surfs to some other URL:
Suppose that moments after SSL connection is established, client surfs to some other URL, and shortly there after it again requests ( via https ) the original page ( one with which it has SSL connection established).
How will IIS server be able to figure out that current request for a page comes from a client that already has SSL connection established with that page and thus will use already established SSL connection?
thanx
EDIT:
Assuming browser surfs to some other URL and if on returning back to original page the SSL connection is still established, how will browser "remember" the value of symetric encryption key, which the two sides used for communicating?
I realize it depends on what browser you use, but with IE and Firefox, I assume when you close a browser, it sends Connection.Close() ( or something to that effect ) to the server and thus SSL connection is immediately closed?
But if you browse away to some other URL, then if browsers doesn't send any notification to the server, wouldn't then SSL connection remain established for quite some time ( even 10 or more minutes ) and thus browser could easily surf back to that page as if nothing happened?!
I appreciate it
Q1. The SSL connection is only good for a single TCP connection between the client and the server. Current browsers (anything with HTTP/1.1 support) can reuse a single connection for downloading multiple resources. Current browsers also make multiple TCP connections to a server in order to download multiple resources in parallel. Because of this, you'll see multiple SSL connections for one page view.
Q2A. If the browser still has a TCP connection open with that server, it can reuse that connection. Otherwise, a new TCP connection with SSL and IIS authentication is negotiated.
Q2B. Same as Q2A. You can't depend on this, but the TCP connections won't be disposed of immediately. There's a chance you could reuse an existing one depending on your browser.
A1. An SSL connection persists until either the client or server closes it. When that happens depends on the protocol being used. For HTTP, most modern clients will make a few parallel connections to the server to fetch the page and its resources, and reuse those connections until the page is loaded.
A2A. The client must authenticate itself on each request if the authentication uses HTTP auth. If the client is using SSL certificate authorization, then this is obviously maintained on a per-connection basis so that subsequent requests on the same connection retain the same credentials.
A2B. The server would know this because presumably the request would come in on that already established SSL connection.
post-edit answers:
What I think you may be missing is that SSL is linked intrinsically to TCP. You cannot have an SSL "connection" to the server that doesn't ride on top of a TCP connection. You break one, you break the other.
Most SSL implementations include "shortcut" negotiation where subsequent new connections can leverage the public key encryption that has already taken place and instead directly use the most recently negotiated symmetric key. The details of this, however, are hidden within the SSL implementation. From the point of view of the user and/or client software, the fiction is maintained that the entire negotiation took place just like it did on the first connection.
If the SSL connection is still established, then it follows that the symmetric key information is still maintained on both ends.
Yes.
Yes, although it would be improbable for the client to keep a connection to a server once it has navigated away to some other site.