If you've ever deployed a website, you've probably heard of SSL. The protocol for a URL with SSL applied starts with https://, and unlike http://, it has an added s meaning Secure. You can see that the address of this very site, https://blog.itcode.dev, also has SSL applied. The same goes for NAVER and Google. As you can see, SSL isn't a concept that's only familiar to web developers. If you've ever used the internet, it's safe to say you've encountered SSL whether you realized it or not.

So what exactly is this SSL thing? SSL stands for Secure Socket Layer, literally an encrypted socket layer. It was first developed by Netscape in 1994, and versions were released up through 3.0.

SSL is a protocol for encrypting communication between a web server and a client.

For communication without SSL applied, plain text is sent as-is, as shown in the diagram above. If a third party intercepts the communication packets in any way, they can easily view the contents.

It would be fine if the communication contents were trivial, but it's a different story if it involves sensitive data such as a user's personal information or payment details.

Applying SSL can solve this problem technically. Since requests are sent encrypted, even if the communication packets are intercepted, the original content can't be recovered without the decryption key.

While learning about SSL, you'll also come across the concept of TLS. In fact, you'll often find SSL and TLS used interchangeably.

SSL's version 3.0 was released in 1996, and it's now been deprecated due to security vulnerabilities.

TLS, developed by the Internet Engineering Task Force (IETF), is a communication security protocol that addresses the security vulnerabilities of SSL 3.0. The current version of TLS, 1.3, was released in 2018.

TLS improves upon SSL, but the term SSL is commonly used as an umbrella term for communication security protocols on the internet in general.

However, since even SSL's final version, 3.0, was banned in 2015, every communication security protocol in use today is actually TLS. It's a situation much like hobbang and jjinppang.

Why bring up hobbang and jjinppang?
The food we commonly call "hobbang" or "jjinppang" interchangeably is officially called jjinppang (steamed bun). Hobbang is the name of a steamed bun product released by Samlip Foods, which became so famous over time that it ended up replacing the original name in everyday usage.
Similar examples include Choco Pie and Band-Aid.

1. The URL protocol is https, with a default port of 443.
2. Communication data is encrypted, so even if a packet is intercepted, the data remains protected.
3. SSL certificates make it possible to verify the trustworthiness of a domain.
4. Speed is slower due to the encryption/decryption that occurs during data transmission and reception.

The way SSL communicates is outlined below, and this whole series of steps is called a HandShake. It's said to be named this way because the client and server repeatedly exchange requests/responses to perform the preparatory work needed for communication, much like a handshake.

1. ClientHello Request

When a client accesses a specific address, it sends a request to the corresponding server. Accessing NAVER sends a request to NAVER's server.

• Random data
• Encryption protocol information (protocol, version, etc.)
• Encryption schemes supported by the client
• Session ID
• Other extended information

This request contains the information listed above. It sends the client's key information to the server, allowing the server to identify the client and understand what encryption methods are available, among other details.

2. ServerHello Response

Once the server receives the ClientHello request, it sends back a kind of reply containing the following information.

• Random data (unrelated to the data sent in ClientHello)
• The encryption scheme the server will use
• Certificate
  • CA
  • Domain
  • Public key

The random data has no correlation whatsoever with the data sent in ClientHello — it's entirely separate data.

Among the encryption schemes the client indicated it supports, the server selects one it will use and declares it, so both sides can send and receive using the same encryption scheme.

Along with the certificate information, the server's public key is sent for encrypted communication with the server. If data is encrypted with the server's public key, the server can receive it and decrypt it using its private key to analyze the request.

3. Certificate Review

The client reviews the certificate sent by the server to check whether it's actually the certificate for that server, whether it was issued by a trusted CA, and whether it was genuinely issued by that CA, among other checks.

If there's nothing wrong with the certificate, the address bar will display as shown above (based on Microsoft Chromium Edge).

If there is a problem, you'll see a window like the one below.

This is a warning message the browser sends to the user, cautioning that the site's certificate is invalid and therefore cannot be trusted.

Of course, this could be a minor issue caused by the site administrator's mistake, such as an expired certificate or an incorrectly replaced certificate. However, if you see a warning like this while visiting an unfamiliar site, it's possible that the site couldn't obtain a certificate through legitimate means, so it's best to avoid accessing it.

Even for sites with no malicious intent, your data won't be protected in this situation, so be cautious.

4. Premaster Secret Exchange

The random data exchanged in ClientHello and ServerHello is combined to generate a Premaster Secret.

This is then encrypted with the public key received in ServerHello. This data can only be decrypted using the server's private key. In other words, even if this data is intercepted, its contents remain protected.

The server decrypts the received data and is able to store the same Premaster Secret as the client.

5. Session Key Generation

Based on the Premaster Secret each side holds, a Master Secret and Session Key are generated. Through this, the client and server end up holding identical keys, enabling encrypted communication between them.

6. Data Transmission and Reception

Necessary data is communicated after being encrypted/decrypted using symmetric-key encryption based on the stored Session Key.

7. Session Termination

When the connection with the client is closed, the Session Key that was used is discarded.

SSL is a security protocol designed to prevent packet interception, information leaks, and similar issues by encrypting communication packets.

While everything has now been replaced with TLS, the term SSL itself has become a proper noun and is used broadly to refer to communication security protocols in general.

In the modern era, it's an essential requirement for deploying a website, so make sure to understand it well.

In the next chapter, we'll cover SSL certificates.