How does SSL/TLS make HTTPS secure?

HTTPS stands for HyperText Transfer Protocol Secure which is the secure version of the HTTP. It is the primary protocol used to exchange data between a web browser and website. As HTTPS is the secure version, it adds encryption in HTTP in order to increase the security of the data being exchanged. Let’s dive deeper to understand how exactly is the data secured on the web. Overview of HTTP HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response or requests to various commands. For example, when you enter a URL in your browser, this actually sends an HTTP command to the Web server directing it to fetch and transmit the requested Web page. HTTP is also a stateless protocol because each command is executed independently, without any knowledge of the commands that came before it. As a request-response protocol, HTTP gives users a way to interact with web resources such as HTML files by transmitting hypertext messages between clients and servers. HTTP clients generally use Transmission Control Protocol (TCP) connections to communicate with servers. HTTP utilises specific request methods in order to perform various tasks: GET: Requests a representation of the specified resource. Requests using this method should only retrieve data. HEAD: Asks for a response identical to that of a GET request, but without the response body. POST: This method is used to submit an entity to the specified resource, often causing a change in state or side effects on the server. PUT: This method replaces all current representations of the target resource with the request payload. DELETE: This method deletes the specified resource. TRACE: This method performs a message loop-back test along the path to the target resource. OPTIONS: This method is used to describe the communication options for the target resource. CONNECT: This method establishes a tunnel to the server identified by the target resource. PATCH: This method is used to apply partial modifications to a resource. What is the difference between HTTP and HTTPS? The most important difference between the two protocols is the SSL certificate. In fact, HTTPS is basically an HTTP protocol with additional security. However, this additional security can be extremely important, especially for websites that take sensitive data from its users, such as credit card information and passwords. So how does HTTPS works? The SSL certificate encrypts the information that users supply to the site, which basically translates the data into a code. Even if someone manages to steal the data being communicated between the sender and the recipient, they would not be able to understand it due to this encryption. But in addition to adding that extra layer of security, HTTPS is also secured via TLS (Transport Layer Security) protocol. TLS helps provide data integrity, which helps prevent the transfer of data from being modified or corrupted, and authentication, which proves to your users that they are communicating with the intended website. Users can identify whether a site uses HTTPS protocol by the web address. The very first part of the web address (before the “www”) indicates whether the site uses HTTP or HTTPS protocols. How does SSL/TLS make it secure? One of the most important parts of the SSL/TLS protocol is the SSL/TLS handshake. The handshake is where each connection is established. The TLS handshake consists of three steps: Setting up cipher suites. Authenticating both server and client side. Exchanging symmetric session keys. Let’s get deeper into these steps. Setting up cipher suite Web browsers are the most common client. Likewise, on the server side, popular operating systems like Windows Server, Apache, and NGINX all have very different feature support. And all of this gets even more complicated when you add in custom configurations. So, the first steps of the TLS handshake require the client and server to share their capabilities so they can find the cryptographic features they mutually support. Once a client and server agree on the exact encryption methods they will use. This is called a cipher suite and then the server sends the client its SSL certificate. Authenticating both server and client side The client checks to make sure the certificate is “authentic.” This is an extremely important step. To truly have a secure connection, you can’t just encrypt your data, you also need to know it’s being sent to the right website/organisation. SSL/TLS certificates provide that authentication. But the way they do it depends on the cipher suite being used. All trusted SSL certificates are issued by a Certificate Authority (CA), which is a company that has been approved to issue digital certificates. These organisations must follow strict guidelines for issuance and validation so that the certificates they issue continue to be trusted. This is primarily to ensure that you can only get a certificate for a website or company you truly own. You can think of a CA kind of like a notary in this context — its signature signifies the entity on the certificate is who it says it is. During the authentication portion of the TLS handshake, the client performs several cryptographically secure checks to make sure the certificate provided by the server is authentic. This includes checking the digital signature and making sure the certificate originates from a trusted CA. During this stage, the client also verifies that the server owns the private key associated with the certificate. The server sends the public key through the SSL Certificate. The public key is used to encrypt data and the private key is used to decrypt. This is known as “asymmetric” public key encryption because the two functions are performed by different keys. The encryption is effectively one-way. With the most common public key cryptosystem, RSA, the client will encrypt random data with the public key that needs to be used to generate the session key. The server will only be able to decrypt and use that data if it has the private key, which provides proof of possession. Exchanging symmetric session keys The last part of the TLS handshake involves creating the “session key,” which is the key that will actually be used for secure communication. Session keys are “symmetric,” meaning the same key is used for encryption and decryption. These keys can achieve strong encryption much more efficiently than asymmetric keys, making them appropriate for sending data back and forth in an HTTPS connection. The exact method for generating the key varies based on the cipher suite that was chosen, with the two most common schemes being RSA and Diffie-Hellman. To end the handshake, each party lets the other know they have done all the necessary work, then both run check-sums to make sure the handshake occurred without any malicious tampering or corruption. The entire SSL handshake takes place in a few hundred milliseconds and it’s all behind the scenes. It’s the first thing that must happen in an HTTPS connection, even preceding the webpage loading. Once the SSL handshake is complete, the encrypted and authenticated HTTPS connection begins and all the data being sent and received between you and the server is protected using the session key. The SSL/TLS handshake is a fascinating process that is critical for a secure internet, and yet it happens quickly and quietly behind the scenes where most people never give it a second thought. Hope it was helpful.Thanks for reading. Reference Links: https://www.webopedia.com/TERM/H/HTTP.html HTTP request methods https://www.thesslstore.com/blog/explaining-ssl-handshake/