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
Related
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.
I have a question: What is the difference between sniffing and forwarding.
I mean that when I am in the MITM position (the gateway of a client), I can access to all the HTTPS website with this client browser.
In addition, I can check the generated traffic on the gateway side (including HTTPS requests/answers - encrypted of course!).
But as soon as I am using tools called "sniffers" (ettercap for instance) on the gateway side I am getting certificate errors and cannot even acces those HTTPS websites on the client side.
I am thus wondering what is the difference between sniffing and forwarding the traffic, in both cases we have access to the exact same information on the gateway side (generated traffic).
Finally, when sending HTTPS requests, those request has to go throw numerous routers to reach the server destination, a router is not a sniffer I suppose that is why we don't get the SSL certificate errors, right?
Sniffing is passive, whereas forwarding (MITM) is active.
When forwarding (MITM), you are part of the route. The traffic goes from the client to your IP address, then on to the server.
When sniffing, you're simply on the same physical network as the client and are able to receive a copy of the packets that the client is sending to the server.
If sniffing is causing HTTPS to fail, then there's something wrong. Perhaps you have mixed up the two terms?
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.
I've built a NodeJS TCP server that sits on secured port 443.
Instead of sending HTTP snippets, I am using 443 to send my custom data through.
It all works ok, until someone tries to navigate to the https address of node server.
Like to ask how do I send a 404 Not Found HTTPS response if someone were to navigate to the https address of my node server?
E.g:
if( isHTTPRequest ) {
socket.write("HTTP/1.1 404 Not Found");
return;
}
Above doesn't work.
There's nothing magic about port 443; it doesn't intrinsically make things secure. It's functionally the same as port 442, 444, 80, or any other. The only thing that's special about 443 is that by convention, HTTPS servers listen on that port.
The thing that makes HTTPS servers secure is that they implement the TLS protocol. TLS is a cryptographic protocol that provides an application a secure communication channel. TLS provides the security; the server then runs regular HTTP on top of the TLS channel.
TLS isn't just limited to HTTP servers. Any application can use it; its high-level APIs provide a data stream that works just like a regular TCP stream.
Fortunately, node includes a complete TLS implementation that is almost entirely API-compatible with a regular TCP stream provided by the net module. So instead of:
net.createServer(function(socket) {
socket.write('stuff that gets sent in the clear');
});
Do this:
tls.createServer({
cert: fs.readFileSync('cert.pem'), // the pem-encoded certificate
key: fs.readFileSync('key.pem'), // the private key that goes with your cert
ca: [] // you may need to include the CA's intermediate certs if applicable
}, function(socket) {
socket.write('stuff that will be encrypted');
});
Likewise, clients use tls.connect() instead of net.connect().
You generate your private key using OpenSSL, then submit a CSR to a Certificate Authority, who will give you a certificate that will be broadly accepted. You can also self-sign, but self-signed certificates won't be accepted by clients by default.
Finally, given that you're writing a custom server (not a HTTP server), you shouldn't be listening on port 443. Convention says that HTTPS servers listen on port 443, and your custom protocol isn't HTTP. Select a different port, preferably one that isn't already assigned.
You could let openssl client do the hard part. Check out their documentation and examples.
Can a (||any) proxy server cache content that is requested by a client over https? As the proxy server can't see the querystring, or the http headers, I reckon they can't.
I'm considering a desktop application, run by a number of people behind their companies proxy. This application may access services across the internet and I'd like to take advantage of the in-built internet caching infrastructure for 'reads'. If the caching proxy servers can't cache SSL delivered content, would simply encrypting the content of a response be a viable option?
I am considering all GET requests that we wish to be cachable be requested over http with the body encrypted using asymmetric encryption, where each client has the decryption key. Anytime we wish to perform a GET that is not cachable, or a POST operation, it will be performed over SSL.
The comment by Rory that the proxy would have to use a self-signed cert if not stricltly true.
The proxy could be implemented to generate a new cert for each new SSL host it is asked to deal with and sign it with a common root cert. In the OP's scenario of a corportate environment the common signing cert can rather easily be installed as a trusted CA on the client machines and they will gladly accept these "faked" SSL certs for the traffic being proxied as there will be no hostname mismatch.
In fact this is exactly how software such as the Charles Web Debugging Proxy allow for inspection of SSL traffic without causing security errors in the browser, etc.
No, it's not possible to cache https directly. The whole communication between the client and the server is encrypted. A proxy sits between the server and the client, in order to cache it, you need to be able to read it, ie decrypt the encryption.
You can do something to cache it. You basically do the SSL on your proxy, intercepting the SSL sent to the client. Basically the data is encrypted between the client and your proxy, it's decrypted, read and cached, and the data is encrypted and sent on the server. The reply from the server is likewise descrypted, read and encrypted. I'm not sure how you do this on major proxy software (like squid), but it is possible.
The only problem with this approach is that the proxy will have to use a self signed cert to encrypt it to the client. The client will be able to tell that a proxy in the middle has read the data, since the certificate will not be from the original site.
I think you should just use SSL and rely on an HTTP client library that does caching (Ex: WinInet on windows). It's hard to imagine that the benefits of enterprise wide caching is worth the pain of writing a custom security encryption scheme or certificate fun on the proxy. Worse, on the encryption scheme you mention, doing asymmetric ciphers on the entity body sounds like a huge perf hit on the server side of your application; there is a reason that SSL uses symmetric ciphers for the actual payload of the connection.
How about setting up a server cache on the application server behind the component that encrypts https responses? This can be useful if you have a reverse-proxy setup.
I am thinking of something like this:
application server <---> Squid or Varnish (cache) <---> Apache (performs SSL encryption)