When someone ask you ” Do you know how HTTPS works ? “. You face becomes more like this.
Well it took some time for me to understand what’s going behind HTTPS. As you already know that we see HTTPS when we visit any websites which involves doing sensitive actions like doing online transaction, logging to any social networking websites etc.
Well let’s break HTTPS.
HTTPS = HTTP + SSL
HTTPS (HTTP over SSL or HTTP Secure) is the use of Secure Socket Layer (SSL) or Transport Layer Security (TLS) as a sub layer under regular HTTP application layering. HTTPS encrypts and decrypts user page requests as well as the pages that are returned by the Web server. The use of HTTPS protects against eavesdropping and man-in-the-middle attacks. HTTPS was developed by Netscape. Unless a different port is specified, HTTPS uses port 443 instead of HTTP port 80 in its interactions with the lower layer, TCP/IP.
So to go ahead with this topic you need to understand
So once you are done reading the above two articles, let’s see how HTTPS is working in the background. The most important entity involved here is Certificate Authority. Now you will say what I am taking about.Check out the below video before moving any further.
Well how will you verify that a website you are visiting is authentic and not a malicious one. Well Certificate authority reviews the identity of the website before issuing the certificate to the Site Owner. Certificate is kind of an assurance badge that you can see on any https website.
Now if you have read the fundamentals of cryptography as mentioned earlier then let’s dive in.
Below are the series of steps that goes behind the scene when you connect to a website running on HTTPS :
Entities involved during the HTTPS Process
Client= Browser ( Firefox,Chrome,IE,Opera etc )
Server= Webserver ( Apache,Websphere,Nginx etc )
Website Name = https://www.hackertron.com
- User open client and types the Website name and hit enter.
- Now Server respond back to client saying that I am an HTTPS website. Server also send a message which is encrypted with Certificate Authority’s private key.
- All the clients ships with preinstalled public key of the known CA providers. Now Client will try to decrypt the message with the appropriate key of corresponding CA. If it is able to decrypt the message, then it means the Website is real, verified and not malicious.
- Now Server sends back a set of algorithms which it currently supports to the client.
- Client receives the options from the server and negotiate with the server which it can accept.
- Once both parties have negotiated which encryption scheme they want to use for Symmetric and Asymmetric cryptography, the real action happens.
- Client now generate a shared secret key and encrypt the key with the public key is embedded in the SSL certificate. We can actually see this key.
8. Now server receives the encrypted key from the client and decrypt it using its own private key which gives him the shared secret key
9. Both the parties have the shared secret key and can use it to encrypt further communication
Really really fun facts
Can a coffee shop monitor my HTTPS traffic over their network?
Nope. The magic of public-key cryptography means that an attacker can watch every single byte of data exchanged between your client and the server and still have no idea what you are saying to each other beyond roughly how much data you are exchanging. However, your normal HTTP traffic is still very vulnerable on an insecure wi-fi network, and a flimsy website can fall victim to any number of workarounds that somehow trick you into sending HTTPS traffic either over plain HTTP or just to the wrong place completely. For example, even if a login form submits a username/password combo over HTTPS, if the form itself is loaded insecurely over HTTP then an attacker could intercept the form’s HTML on its way to your machine and modify it to send the login details to their own endpoint.
Can my company monitor my HTTPS traffic over their network?
If you are also using a machine controlled by your company, then yes. Remember that at the root of every chain of trust lies an implicitly trusted CA, and that a list of these authorities is stored in your browser. Your company could use their access to your machine to add their own self-signed certificate to this list of CAs. They could then intercept all of your HTTPS requests, presenting certificates claiming to represent the appropriate website, signed by their fake-CA and therefore unquestioningly trusted by your browser. Since you would be encrypting all of your HTTPS requests using their dodgy certificate’s public key, they could use the corresponding private key to decrypt and inspect (even modify) your request, and then send it onto it’s intended location. They probably don’t. But they could.
Incidentally, this is also how you use a proxy to inspect and modify the otherwise inaccessible HTTPS requests made by an iPhone app.
HTTPS is not unbreakable, and the SSL protocol has to evolve constantly as new attacks against it are discovered and squashed. But it is still an impressively robust way of transmitting secret data without caring who sees your messages. There are of course many implementation details not mentioned here, such as the exact format and order of the handshake messages, abbreviated handshakes to pick up recent sessions without having to renegotiate keys and cipher suites, and the numerous different encryption options available at each stage. The key thing to remember is that whilst HTTPS keeps data safe on the wire to its destination, it in no way protects you against XSS or database leaks or web attacks.