 | How does HTTPS actually work |  |
| How does HTTPS actually work | |
When it comes to your standard HTTP protocol, HTTPS is covered by a generous amount of scrumptious SSL/ TLS encryption. It prevents anyone from modifying or viewing requests which make up the browsing experience. HTTPS stores the credit card details, communications, and password details safely between the server and your computer.
HTTPS is used for layering SSL/ TLS as it understands the HTTP protocol. Clients and servers would continue to speak an exactly similar HTTP to one another, however, over a secure SSL connection which both encrypts and decrypts the responses and requests. There are 2 main purposes of the SSL layer as mentioned below.
With the help of a handshake, the SSL connection between the server and client is set up. The goals of the connection are as follows:
Both of the parties will use the algorithm agreed upon and the keys to send messages to one another securely once the connection has been established. This handshake can be broken up into 3 main phases which are Key Exchange, Certificate Exchange and Hello. These terms are explained in details:
The handshake starts with the client sending a message of Hello. It would contain all of the information which the server requires to connect through SSL to the client. The maximum SSL version is supported and it includes various cipher suites. The response of the server would be a Hello and it would contain similar information that the client needs.
After the contact has been established, the client requires the server to prove its identity. It is achieved with the help of the SSL certificate. It is similar to a passport. The SSL certificate contains different data which includes the property that it is attached to, name of the owner, the public key of the certificate, the information about the validity dates of the certificate and the digital signature.
A symmetric algorithm will allow the encryption of the actual message data exchanged between the server and client. Its exact nature would be agreed during the Hello phase. A single key is used by the symmetric algorithm for both encryption and decryption as compared to asymmetric algorithms which need a public/private key pair. The symmetric key is what both of the parties have to agree on.
An SSL certificate is actually a text file at its most basic level and just about anyone with a text editor will be able to create one. The digital signature allows the party to verify whether another party is legitimate. Certificates are trusted due to 2 reasons:
Now, the first criteria can be checked easily as the browser already has a pre-installed list of trusted SSL certificates. These can be viewed, added or removed from the Certificate Authorities.
The SSL certificates have a private/public key pair. The private key is guarded and the public key is distributed as a part of the certificate. Both of the pair of asymmetric keys is used for the SSL handshake for exchange of the further key. Only the server can decrypt with the private key, while anyone can encrypt with the public key. The certificate may be signed by another authority which would ensure that they have verified the controlled of the certificate. The authority is only able to create a valid signature.
All of the root CA certificates are actually self-signing. It means that the digital signature would be created with the private key of the certificate. Although one can generate their own self-signed certificate, it would not be trusted as it is a random certificate. Hence, the burden is on OS publishers and all browsers to trust only clean root CAs.
The truth is that the client is not trying to verify the party which sent the certificate, but it is actually checking to ensure if it can trust the public key contained in it. As SSL certificates are completely public and open, any attacker can grab hold of the Microsoft certificate and intercept the client request and show a legitimate certificate. Although the client would accept this and start the handshake, it would encrypt the key for the actual data encryption with the real public key of Microsoft and as the attacker does not have Microsoft’s private key for decryption, they would be stuck. Unless the attacker does not control a trusted private key certificate, the order would be maintained.
The thing about public-key cryptography is that the attacker may watch every byte of data that is exchanged between the server and the client. They would still have no idea what one is saying beyond how much data is exchanged. However, the normal HTTP traffic is quite vulnerable over an insecure wifi network. But, the answer is a no.
If one is using a machine that is controlled by the company, then the answer would be a yes. It all lies on the implicitly trusted CA. A list of the authorities would be stored on the browser. The company would use their access to the machine to add self-signed certificates. These would then intercept all of the HTTPS requests.
HTTPS isn’t entirely unbreakable. The SSL protocol needs to evolve regularly as there are new attacks which have to be discovered and put an end to. It is an impressive way of transmitting secret data. However, it does not protect one from database leaks or XSS.