In last week’s post, we talked about how HTTP works to pass information from a server to a browser. But when information is passed back and forth between systems, we need to make sure that it’s protected from being intercepted by others for whom it was not intended. That’s why HTTPS was created. In this week’s post, we’ll talk about how encryption is used in HTTPS, what the difference is between cookies and tokens, the different types of cookies, and how cookies can be protected.
How HTTPS Works:
When two systems communicate with each other, we refer to them as the client and the server. The client is the system making the request, such as a browser, an application, or a mobile device, and the server is the system that supplies the information, such as a datastore. HTTPS is a method of securely transmitting information between the client and the server. HTTPS uses SSL and TLS to encrypt the data being transmitted and decrypt it only when it arrives at its destination. SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are both tools for the encryption and decryption of data; TLS is a newer version of SSL.
Here’s how TLS works: before any data is transmitted, the client and the server first perform a handshake. The handshake begins with the client contacting the server with a suggested encryption method and the server responding back agreeing to use that encryption method. It then continues with the client and the server swapping certificates. A certificate is like an ID card; it verifies the identity of the client or server. The certificates are checked against the CA (Certificate Authority), which is a third-party entity that creates certificates specifically for the purpose of HTTPS communication.
Once the certificates are swapped and verified, the client and the server swap decryption keys, and the handshake is completed. Now the data is encrypted, transmitted from the server to the client, and decrypted once it arrives at the client safely.
Session Cookies and Tokens:
Another important way data is secured is through the use of session cookies or tokens. Session cookies and tokens are strings that are passed in with a client’s request to verify that the person making the request has the right to see the data requested. The main difference between session cookies and tokens is that a session cookie is stored both on the client and the server, and a token is only stored on the client.
In systems that use tokens, the token is created when a user logs in. The token is made up of encrypted information that identifies the user. The token is stored in local storage in the client’s browser and is sent with every HTTPS request to the server. When the server receives the token, it decrypts it, validates the user’s information, and then returns the response.
The most popular system of tokens in use today is JWT (JSON Web Token). You can read more about JWTs in this helpful documentation.
A session cookie is a unique string that is created by the server when the user logs in. It is saved in the server’s datastore as a session id. The server returns the cookie to the client, and the client saves it in the browser while the session is active. Whenever the client makes a request to the server, it sends the cookie with the request. The server then compares the cookie with the one it has saved to make sure it matches before returning the response.
Tokens and session cookies are usually set to expire after a period of time or after an event. For example, a token issued might be good for one hour. Just before the hour is up, a request can be made for a new token (called a refresh token) in order to keep the user signed in. Session cookies usually expire when the user logs out or when the browser is closed.
Persistent Cookies:
Another type of cookie used is the persistent cookie, which is a bit of data saved on the server about the user’s preferences. For example, if a user goes to a website and chooses German as the language they would like on the site, a persistent cookie will remember that information. The next time the user goes to the site, the cookie will be examined and the site will load in German.
Securing Cookies:
Because they are stored on the server, cookies are more vulnerable to being intercepted and used by someone other than the user than tokens are. To help protect cookies, these flags (attributes) can be added to them at the time of creation:
- Secure flag: ensures that the cookie can only be transmitted over HTTPS requests and not over HTTP requests.
- HttpOnly flag: keeps a cookie from being accessed via JavaScript, which helps protect it from Cross-Site Scripting (XSS) attacks.
- SameSite flag: ensures that the cookie can only be sent from the original client that requested the cookie, which helps protect it from Cross-Site Request Forgery attacks.
Hopefully this post has helped you learn how HTTPS works, and how tokens and cookies ensure a client’s validity. Researching this information certainly helped me! But I want to go deeper: how does a message know how to get from one IP address to another? How are HTTP requests intercepted? And how does a router work? I’ll have answers to these questions in next week’s post!