Part 8. How to Secure Communication and Storage

Symmetric-key encryption uses a single encryption key, which must be kept a secret, for both encryption and decryption. For example, as shown in Figure 92, Alice can use an encryption key to encrypt the plaintext "Hello, World" into ciphertext before sending it to Bob, and then Bob can use the same encryption key to decrypt the ciphertext back into plaintext:

Under the hood, symmetric-key encryption algorithms use the encryption key to perform a number of transformations on the plaintext, mostly consisting of substitutions and transpositions. A substitution is where you exchange one symbol for another: you’ve most likely come across a simple substitution cipher where you uniformly swap one letter in the alphabet for another, such as shifting each letter by one, so A becomes B, B becomes C, and so on. A transposition is where the order of symbols is rearranged: again, you’ve most likely come across a simple transposition cipher in the form of anagrams, where you randomly rearrange the letters in a word, so that "hello" becomes "leohl." Modern encryption algorithms also use substitution and transposition, but in much more complicated, non-uniform patterns that depend on the encryption key.

Some of the well-known symmetric-key encryption algorithms include DES, 3DES, RC2, RC4, RC5, RC6, Blowfish, Twofish, AES, Salsa20, and ChaCha20. Many of these are now dated and considered insecure, so the primary ones you should be using in most contexts as of 2024 are the following:

The main advantage of symmetric-key encryption is that it is typically faster and more efficient than asymmetric-key encryption. The main drawback of symmetric-key encryption is that it’s hard to distribute the encryption key in a secure manner. If you try to send it to someone as plaintext, then a third party could intercept the message, steal the key, and use it to decrypt anything you encrypted later. You could try to encrypt the key, but that requires another encryption key, so that just brings you back to square one. Until the 1970s, the only solution we had was to share keys via an out-of-band channel, such as exchanging them in-person, which does not scale very well. However, in the 1970s, we got a new solution, asymmetric-key encryption, which is the topic of the next section.

Asymmetric-key encryption, also known as public-key encryption, uses a pair of related keys, which include a public key that can be shared with anyone and used to encrypt data, and a private key, which must be kept a secret, and can be used to decrypt data. For example, as shown in Figure 93, Alice can use Bob’s public key to encrypt the plaintext "Hello, World" into ciphertext before sending it to Bob, and Bob can use his private key to decrypt the ciphertext back into plaintext:

The public and private key and the encryption and decryption are all based on mathematical functions. The math behind these functions is beautiful, and worth learning, but beyond the scope of the book. All you need to know for now is that you can use these functions to create a linked public and private key, such that data encrypted with the public key can only be decrypted with the corresponding private key, and that it’s safe to share the public key, as there’s no way to derive the corresponding private key from it (other than brute force, which is not feasible with the large numbers used in asymmetric-key encryption).

The two most common asymmetric-key encryption algorithms you should be using today are:

The huge advantage of asymmetric-key encryption is that you don’t need to share an encryption key in advance. Instead, each user shares their public keys, and all other users can use those to encrypt data. This has made it possible to have secure digital communications over the Internet, even with total strangers, where you have no pre-existing out-of-band channel to exchange encryption keys. That said, asymmetric-key encryption has two major drawbacks: first, it is considerably slower than symmetric-key encryption, and second, it is usually limited in the size of messages you can encrypt. Therefore, it’s rare to use asymmetric-key encryption by itself. Instead, you typically use hybrid encryption, as per the next section.

Hybrid encryption combines both asymmetric and symmetric encryption, using asymmetric-key encryption initially to exchange an encryption key, and then symmetric-key encryption for all messages after that. For example, if Alice wants to send a message to Bob, she first generates a random encryption key to use for this session, encrypts it using Bob’s public key and asymmetric-key encryption, and then sends this encrypted message to Bob. After that, she uses symmetric-key encryption with the randomly-generated encryption key to encrypt all subsequent messages to Bob. This provides a number of advantages:

ECIES, which I recommended for asymmetric-key encryption in the previous section, is actually a hybrid encryption approach: it is a trusted standard for doing a secure key exchange using elliptic curve cryptography for asymmetric-key encryption, followed by symmetric-key encryption using one of several configurable algorithms (e.g., AES-GCM).

Now that you’ve seen some of the basic theory behind encryption, let’s see what it looks like in practice by trying out a few real-world examples.

Let’s do a quick example of encrypting and decrypting data on the command-line using OpenSSL, which is installed by default on most Unix, Linux, and macOS systems. We’ll start with symmetric encryption. Run the following command to encrypt the text "Hello, World" using AES with a 128-bit key and the CBC (Cipher Block Chaining) encryption mode:

openssl will prompt you for a passphrase (twice). If you were exchanging data between two automated systems, you’d use a randomly-generated, 128-bit key instead of a password. However, for this quick learning exercise, and in use cases where you need a human being to memorize the key, you use a password, which is much shorter, and OpenSSL will use a key derivation function called PBKDF2 to derive a 128-bit key from that password. Note that this derivation process does not add any entropy, so text encrypted with a short password is much easier to break through brute force than a proper 128-bit key, but for use cases where you rely on memorization, that’s a risk you have to accept.

Once you enter your passphrase, you’ll get back a base64-encoded string, such as the "U2Fsd…​" text you see in the preceding output. This is the ciphertext! As you can see, there’s no way to guess this jumble of letters and numbers came from the text "Hello, World." You could safely send this to someone, and even if the message is intercepted, there is no way for the malicious attacker to understand what it said without the encryption key (the passphrase). The only way to get back the plaintext is to decrypt it using the same algorithm and key (passphrase):

You’ll again be prompted for your passphrase (once), so make sure to enter the same one, and OpenSSL will once again use PBKDF2 to derive the encryption key, and from that, it should be able to decrypt the ciphertext back into the original "Hello, World" plaintext. Congrats, you’ve successfully encrypted and decrypted data using AES!

Let’s now try an asymmetric-key encryption example. First, you need to create a key pair as follows:

This creates a 2048-bit RSA private key in the file private-key.pem and the corresponding public key in public-key.pem. You can now use the public key to encrypt the text "Hello, World" as follows:

This should output a bunch of base64-encoded text, which is the ciphertext. Once again, the ciphertext is indistinguishable from a random string, so you can safely send it around, and no one will be able to figure out the original plaintext without the private key. To decrypt this text, run the following command:

This command first decodes the base64 text and then uses the private key to decrypt the ciphertext, which should give you back "Hello, World." Congrats, you’ve successfully encrypted and decrypted data using RSA! And that means it’s time for one of my favorite jokes:

Now that you’ve had a chance to experiment with encryption, let’s move on to the next major cryptography topic, hashing.

When making a file available for download, it’s common to share the hash of the file contents, too. For example, if you make a binary called my-app available through a variety of sources—e.g., APT repos for Ubuntu, MacPorts for macOS, Chocolatey repos for Windows, and so on—you could compute the SHA-256 hash of my-app, and post the value on your website. Anyone who downloads my-app can then compute the SHA-256 of the file they downloaded and compare that to the official hash on your website: if they match, they can be confident they downloaded the exact same file, and that nothing has corrupted it or modified it along the way. That’s because if you change even 1 bit of the file, the resulting hash will be completely different.

A message authentication code (MAC) combines a hash with a secret key to create an authentication tag for some data that allows you to not only verify the integrity of the data (that no one modified it), but also the authenticity (that the data truly came from an intended party). For example, you can use a MAC to ensure the integrity and authenticity of cookies on your website. When a user logs in, you might want to store a cookie in their browser with their username, so they don’t have to log in again. If you do this naively and store just the username, then a malicious actor could easily create a cookie pretending to be any user they wanted to be.

The solution is to store not only the username in the cookie, but also an authentication tag, which you compute from the username and a secret key. Every time you get a cookie, you compute the authentication tag on the username, and if it matches what’s stored in the cookie, you can be confident that this was a cookie only your website could’ve written, and that it could not have been modified in any way. That’s because if you modify even 1 bit of the username, you would get a completely different authentication tag, and without the secret key, there is no way for a malicious actor to guess what that new tag should be.

The standard MAC algorithms you should be using are:

One of the most common uses of MACs is to make symmetric-key encryption more secure, as discussed in the next section.

Symmetric-key encryption can prevent unauthorized parties from seeing your data, but how would you ever know if they modified that data (e.g., injected some noise into the ciphertext or swapped it out entirely)? The answer is that, instead of using symmetric-key encryption by itself, you almost always use authenticated encryption, which combines symmetric-key encryption with a MAC. The symmetric-key encryption prevents unauthorized parties from reading your data (confidentiality) and the MAC prevents them from modifying your data (integrity and authenticity).

The way it works is that for every encrypted message, you use a MAC to calculate an authentication tag, and you include this associated data (AD) with the message as plaintext. When you receive a message with AD, you use the same MAC with the same secret key to calculate your own authentication tag, and if it matches the authentication tag in the AD, you can be confident that the encrypted data could not have been tampered with in any way. If even 1 bit of the encrypted data had been changed, the authentication tag would have been completely different, and there’s no way for someone to guess the new tag without the secret key.

Both of the encryption algorithms I recommended in the symmetric-key encryption section, AES-GCM and ChaCha20-Poly1305, are actually authenticated encryption with associated data (AEAD) protocols that combine a MAC with encryption, as in almost all cases, this is more secure to use than symmetric-key encryption alone.

If you combine a hash function with asymmetric-key encryption, you get a digital signature, which can allow you to validate the integrity and authenticity of a message. You can take any message and pass it, along with your private key, through a hash function, to get an output called a signature, which you can then send to others along with the original message, as shown in Figure 94:

Anyone else can validate the signature using your public key and the message: if the signature is valid, then you can be confident the message came from someone who has access to the private key. If even a single bit of that message was modified, the signature will be completely different, and there’s no way to guess the new value without access to the private key.

There are a set of cryptographic hashing algorithms used specifically for storing user passwords. You’ll learn more about password storage later in this blog post, so for now, I’ll just mention that when storing passwords for users of your software, you do not use encryption. Instead, you use hashing, and specifically, you use specialized password hashing functions that are intentionally designed to be slow and use up a lot of computing resources (e.g., RAM). See Section 8.2.1.3 for the full details.

You’ve now seen a few of the common use cases for hash functions. To get a better feel for them, let’s try some out with a few real-world examples.

Let’s start with an example of using hash functions to check the integrity of a file. First, create a file called file.txt that contains the text "Hello, World":

Next, use OpenSSL to calculate a hash for the file using SHA-256:

You should get back the exact same 8663bab6d124806b…​ hash output as I did: given the same input, a hash function always produces exactly the same output. Now, watch what happens if you modify just one character of the file, such as making the "w" in "World" lower case:

Calculate the SHA-256 hash again:

As you can see, the hash is completely different!

Now, let’s try an example of using a MAC to check the integrity and authenticity of a file. You can use the exact same openssl command, but this time, add the -hmac <PASSWORD> argument, with some sort of password to use as a secret key, and you’ll get back an authentication tag:

If you had the same file.txt contents and used the same password as me, you should get back the exact same authentication tag (3b86a735fa627cb6…​). But once again, watch what happens if you modify file.txt, perhaps this time making the "H" lower case in "Hello":

Generate the authentication tag again:

Once again, changing even a single character in a file results in a totally different output. But now, you can only get this output if you have the secret key (the password). With a different secret key, such as "password1" instead of "password," the output will not be the same:

Finally, let’s try a digital signature. If you still have your public and private keys from the encryption example section earlier in this blog post, you can re-use them. First, compute the signature for file.txt using your private key, and write the output to file.txt.sig:

Next, you can validate the signature using your public key:

Try modifying anything—the signature in file.txt.sig, the contents of file.txt, your private key, or your public key—and the signature verification will fail. For example, remove the comma from the text in file.txt, and then try to verify the signature again:

Now that you’ve had a chance to see encryption and hashing in action, you should understand the primitives that make secure storage and communication possible, so let’s move on to these use cases, starting with secure storage.

To store personal secrets securely, such as passwords, you typically need to use symmetric-key encryption, so your secrets are encrypted when they are on disk, and can only be decrypted with an encryption key. As you may remember, rolling your own cryptography is a bad idea, even for personal secrets, so instead, you should use a mature, off-the-shelf password manager, which is a piece of software specifically designed to provide secure storage and access for personal secrets. Some of the major players in this space include standalone password managers such as 1Password, Bitwarden, NordPass, Dashlane, Enpass, and KeePassXC; password managers built into operating systems, such as macOS password manager and Windows Credential Manager; and password managers built into web browsers, such as Google Password Manager and Firefox Password Manager.

As the name "password manager" implies, these tools are primarily designed to help you manage passwords, but many of them also allow you to store many other types of secrets, such as personal API tokens, credit card numbers, and so on. Most password managers are apps that require you to memorize a single password to login, and once you’re logged in, you can use the app to store new secrets and access all the secrets you stored previously. Under the hood, these apps encrypt all the data they store, typically using your password as the basis for the encryption key.

That means that the password you pick to access your password manager is likely your single most important password. It’s essential that you pick a strong password here. Here are the key factors that make a password strong:

So, how do you come up with a unique, long, hard-to-guess password that you can actually remember? The best strategy I’ve seen is to use Diceware, where you take a list of thousands of easy-to-remember English words that are each 4-6 characters, roll the dice a bunch of times to pick 4-6 such words at random, and glue them together to create a password that is unique, long, and hard-to-guess—but easy to memorize, especially with a little bit of visualization. This idea was beautifully captured in XKCD #936, as shown in Figure 95:

You can follow the instructions on the Diceware website to come up with a Diceware password by hand, or you can use the web-based Diceware Password Generator, the CLI tool diceware, or similar password generators that are built into your password manager tool (many of which are based on Diceware).

Generally speaking, using almost any reputable password manager is going to be more secure than not using one at all. That said, here are some of the key factors to look for when picking a password manager:

Now that you’ve seen how to store personal secrets, let’s discuss how to store infrastructure secrets.

To store infrastructure secrets securely, such as database passwords and TLS certificates, you again need to use symmetric-key encryption, and again, you will want to rely on battle-tested, off-the-shelf software. However, password managers are usually not the right fit for this use case, as they are typically designed to store permanent secrets that are accessed by a human being (who can memorize a password), whereas with infrastructure, you often need to use temporary secrets (those that expire after some period of time) and are accessed by automated software (where there’s no human being around to type in a password). For this use case, you should use a secret store designed to protect infrastructure secrets (with symmetric-key encryption), integrate with your infrastructure (e.g., integrate with databases, servers, etc.), and support authentication for both human and machine users. Human users authenticate to the secret store through passwords or single sign-on (SSO). Machine users authenticate to the secret store using one of the mechanisms you learned about in Section 5.1.5: sometimes through manually-managed machine user credentials, but preferably, through automatically-provisioned, temporary credentials, such as IAM roles and OIDC.

There are two primary kinds of secret stores that you typically use for infrastructure secrets:

Consider again the example of the app in a Kubernetes cluster that needs access to a secret such as a database password. Here is a typical workflow of using a KMS, such as AWS KMS, to solve this problem:

And here is the typical workflow of using a general-purpose secret store, such as AWS Secrets Manager, to solve this problem:

These days, general-purpose secret stores are becoming more and more popular, as they keep all your secrets centralized, in a single place, rather than having little bits of ciphertext all over your codebase and infrastructure. Centralization offers a number of advantages:

Now that you’ve seen how to manage secrets that belong to your company, let’s turn our attention to how to manage secrets that belong to your customers.

To store customer secrets securely, you first have to consider what type of secret you’re storing. There are two buckets to consider: the first bucket is for user passwords and the second bucket is for everything else (e.g., financial data, health data, and so on). The first bucket, user passwords, requires special techniques, so that’s what we’ll look at in this section.

User passwords have to be handled differently than other types of customer secrets for two reasons. First, they are a very common attack vector: Forbes estimates that 46% of Americans have had their passwords stolen just in 2023, and in 2024, a user posted nearly 10 billion unique leaked passwords on a hacker forum (known as the RockYou2024 leak). Second, you do not need to store the original user password at all, encrypted or otherwise (which means all these password leaks were completely avoidable)! Instead, the way to manage customer passwords is to do the following:

There is a lot of complexity to this, so it bears repeating: don’t roll your own cryptography. Use mature, battle-tested libraries to handle this stuff for you, and try to stay up to date on the latest best practices by checking guides such as the OWASP Password Cheat Sheet.

Let’s now turn our attention to the other bucket, which is how to store all other types of secret customer data, such as financial data (e.g., credit card info) and health data (e.g., protected health information or PHI). For these use cases, you typically do need to store the original data (unlike user passwords), which means that you need to protect that data with symmetric-key encryption. This brings us to the realm of encryption at rest, which is the focus of the next section.

Most modern operating systems support full-disk encryption, where all the data stored on the hard drive is encrypted (e.g., using AES), typically using an encryption key that is derived from your login password: e.g., macOS FileVault, Windows BitLocker, Ubuntu Full Disk Encryption. There are also self-encrypting drives (SEDs) that support full-disk encryption directly in the hardware. Cloud providers also typically support full-disk encryption, but with the added option of using an encryption key from that cloud provider’s KMS: e.g., AWS EBS volumes can be encrypted with keys stored in AWS KMS and Google Cloud Compute Volumes can be encrypted with keys stored in Cloud KMS.

Full-disk encryption is a type of transparent data encryption (TDE): once you’re logged into the computer, any data you read is automatically decrypted and any data you write is automatically encrypted, without you being aware this is happening. Therefore, full-disk encryption won’t help you if an attacker gets access to a live (authenticated) operating system, but it does protect against attackers who manage to steal a physical hard drive, as without the encryption key, they won’t be able to read any of the data.

Some data stores also support TDE (sometimes via plugins), either for the entire data store, or for parts of the data store (e.g., one column in a database table), typically using an encryption key you provide when the data store is booting up: e.g., MySQL Enterprise Transparent Data Encryption (TDE) and pg_tde for PostgreSQL. Cloud providers also typically support encryption for their managed data stores, using encryption keys from that cloud provider’s KMS: e.g., AWS RDS encryption uses encryption keys from AWS KMS and Azure SQL Database encryption uses encryption keys from Azure Key Vault. Note that this applies not only to databases, but all other types of data stores, such as NoSQL data stores (e.g., DynamoDB encryption with encryption keys from AWS KMS), distributed file systems (e.g., AWS S3 encryption with encryption keys from AWS KMS), and so on.

Data store encryption provides a higher level of protection than full-disk encryption, as it’s the data store software, not the operating system, that is doing encryption. That means that you get protection not only against a malicious actor stealing a physical hard drive, but also against a malicious actor who manages to get access to the live (authenticated) operating system running the data store software, for any files the data store software writes to disk will be unreadable without the encryption key. The only thing data store encryption won’t protect against is a malicious actor who is able to authenticate to the data store software: e.g., if you have a MySQL database and a malicious actor is able to compromise a database user account and run SQL queries.

In addition to the various TDE options, you could also implement encryption in your application code, so that you encrypt your data, in-memory, before storing it in a data store or on disk. For example, when a user adds some new data in your application, you fetch an encryption key from a secret store, use AES-GCM with the encryption key to encrypt the data in memory, and then store the resulting ciphertext in a database or on disk.

This approach has several advantages. First, it provides an even higher level of protection than data store encryption, protecting not only against a hard drive being stolen and file system access on live (authenticated) operating systems, but also against a malicious actor who can authenticate to your data store software: for example, even if an attacker can compromise a database user and run SQL queries, they still won’t be able to read any of the data they get back unless they can also access the encryption key. Second, it provides granular control over the encryption, as you can use different encryption keys for different types of data (e.g., for different users, customers, tables, and so on). Third, it allows you to securely store data even in untrusted systems, or systems that aren’t as secure as they could be (e.g., systems that don’t support TDE).

This approach also has several drawbacks. First, it requires you to make nontrivial updates to your application code, whereas the TDE options are completely transparent. Second, the data you store is now opaque to your data stores, which makes it much more difficult to query the data. For example, queries that look up data in specific columns or full-text search are very difficult to do if the data is stored as unreadable ciphertext.

Generally speaking, since the TDE options are transparent, and the performance impact is small for most use cases, it’s typically a good idea to enable full-disk encryption for all company computers and servers, and to enable data store encryption for all your data stores, by default. As for application-level encryption, that’s typically reserved only for use cases where the highest level of security is necessary, or no other types of encryption are supported.

Now that you have seen the various ways to store data securely, let’s move on to discussing how to transmit data securely, which is the topic of the next section.

In this example, you’ll see how to get a TLS certificate from LetsEncrypt, a nonprofit that was formed in 2014 to make the web more secure. They were one of the first companies to offer free TLS certificates, and nowadays, they are one of the largest CAs in the world, used by more than 300 million websites.

You can get TLS certificates from LetsEncrypt using a tool called Certbot. The idiomatic way to use Certbot is to connect to a live webserver (e.g., using SSH), run Certbot directly on that server, and Certbot will automatically request the TLS certificate, validate domain ownership, and install the TLS certificate for you. This approach is great for manually-managed websites with a single user-facing server, but it’s not as good of a fit for automated deployments with multiple servers that could be replaced at any time. Therefore, in this section, you’re instead going to use Certbot in "manual" mode to get a certificate onto your own computer, and then in subsequent sections, you’ll store that certificate in AWS Secrets Manager, and then finally, run some servers that will know how to retrieve the certificate from AWS Secrets Manager.

That means you need to install Certbot on your own computer, as specified in their installation instructions. For example, an easy way to install Certbot on macOS is to run brew install certbot.

Next, create a temporary folder to store the TLS certificate:

You’ll initially have the certificate on your hard drive, which includes a private key (a secret in plaintext on disk!), but after storing it in AWS Secrets Manager, you will delete the local copy; using a temporary folder is a good practice in case you forget to delete it, as on many operating systems, temporary folders are cleaned up automatically on reboot.

In Part 7, you registered a domain name using AWS Route 53. Request a TLS certificate for that same domain name as follows:

Here’s what this command does:

When you run the preceding command, Certbot will prompt you for a few pieces of information: it’ll ask for your email address (used to remind you to renew your TLS certs), whether you accept their terms of service, and if you want to subscribe to their newsletter. Once you answer those questions, Certbot will show you instructions on how to prove that you own the domain name you specified, and it’ll pause execution to give you time to do this:

To prove that you own your domain name, you need to create a DNS TXT record with the randomly-generated value <SOME-VALUE>. Head over to the Route 53 hosted zones page in your web browser, click on the hosted zone for your domain, and click the "Create record" button. This will take you to a page where you should fill in _acme-challenge.www as the name of the record, select TXT as the type, enter the randomly-generated <SOME-VALUE> as the value, and click "Create records," as shown in Figure 98:

After you create the record, wait a minute or two, as the changes can take a little bit of time to propagate, and then head back to your terminal, and hit ENTER to let Certbot know the DNS record is ready. LetsEncrypt will validate your DNS record, and if everything worked, it’ll issue you a TLS certificate, and you’ll see a message similar to the following:

Congrats, you just got a TLS certificate signed by a CA! The certificate itself is in live/example/fullchain.pem and the private key is in live/example/privkey.pem. Feel free to take a look at the contents of these two files. TLS certificates are usually stored in .pem files, which contain some normal text and some base64-encoded text. If you decode the base64 part, you get data encoded in a format called DER (Distinguished Encoding Rules); if you decode that, you finally get the original certificate data in X.509 format. Phew. That’s a lot of encoding. The easiest way to read this data is to ask OpenSSL to parse it for you:

This will spit out a bunch of information about your certificate, such as the issuer (LetsEncrypt), the domain name it’s for (under "Subject"), the expiration date (under "Validity"), the public key, and signature. When you’re done poking around, feel free to delete the TXT record from your Route 53 hosted zone, as that record is only needed during the verification process.

Note that the private key of a TLS certificate is an infrastructure secret, so you need to store it in encrypted format, ideally in a secret store, as discussed in the next section.

AWS Secrets Manager is a general-purpose secret store that provides a way to store secrets in encrypted format, access secrets via API, CLI, or a web UI, and control access to secrets via IAM. Under the hood, the secrets are encrypted using AES and envelope encryption, with a root key stored in AWS KMS: you can either create a custom key to use in KMS, or if you don’t, it will use a default key created specifically for Secrets Manager in your AWS account.

The typical way to store secrets in AWS Secrets Manager is to format them as JSON. Let’s format the TLS certificate as JSON that looks like Example 145:

One way to create this JSON format is to use jq, which will also take care of converting special characters for you (e.g., converting new lines to \n):

This creates a variable called CERTS_JSON that contains the certificate and private key in a JSON format. Next, use the AWS CLI to store this JSON in AWS Secrets Manager as follows:

This creates a secret with id "certificate" in AWS Secrets Manager. If you head over to the AWS Secrets Manager console in your web browser, making sure to select the same region in the top right corner as you used in the preceding command (us-east-2), you should see the secret called "certificate" in the list. Click on it, and on the next page, click "Retrieve secret value," and check that the cert and key values show up correctly, as shown in Figure 99:

If everything looks OK, you should now delete the TLS certificate from your own hard drive:

Let’s now move on to deploying some servers that can use these TLS certificates to serve traffic over HTTPS.

In Part 7, you deployed several EC2 instances that ran a "Hello, World" server on port 80 (the default HTTP port), and configured a domain name for them in Route 53. Let’s extend that example to have those instances listen on port 443 (the default HTTPS port), and to use the TLS certificate from AWS Secrets Manager to encrypt traffic.

Head into the folder you’ve been using for this blog post series’s examples, and create a new subfolder for this blog post:

Next, copy over your code from Part 7 into a new folder called ec2-dns-tls:

In ec2-dns-tls/main.tf, update the EC2 instances to open up port 443 instead of 80 in the security group, as shown in Example 146:

Also in main.tf, add the code shown in Example 147 to allow the EC2 instances to read the TLS certificate data from AWS Secrets Manager:

This code does the following:

Finally, update user-data.sh as shown in Example 148:

Here is how to update the user data script to run an HTTPS Node.js server with your TLS certificate:

Deploy this code as usual, authenticating to AWS as described in Authenticating to AWS on the command line, and running init and apply:

When apply completes, you should see an output variable called domain_name that contains your domain name. Give the servers a minute or two to boot up, and then try opening up https://<DOMAIN_NAME>; in your browser. You should see the familiar "Hello, World" text, but now, it’s going over an HTTPS connection. Congrats, you’re now encrypting data in transit (communications with your web servers) using TLS, and you’re encrypting data at rest (the TLS certificate itself) using AWS Secrets Manager!

When you’re done experimenting, commit your changes to Git, and undeploy this example by running tofu destroy.

Now that you’ve seen how to transmit data securely over TLS, the last thing to discuss is how to enforce encryption everywhere, which is the topic of the next section.

This is perhaps the easiest of the three questions to answer: most E2E-encrypted software uses envelope encryption. The root key is typically derived from whatever authentication method you use to access the software: e.g., the password you use to log in to the app. This root key is used to decrypt one or more data keys, which are stored in encrypted format, either on the user’s device, or in the software provider’s servers. Once the data key is decrypted, the software typically keeps it in memory, and uses it to encrypt and decrypt data client-side.

For some types of software, the data keys are encryption keys used with symmetric-key encryption: e.g., an E2E-encrypted password manager may use AES to encrypt and decrypt your passwords. For other types of software, the data keys may be private keys for asymmetric-key encryption: e.g., an E2E-encrypted messaging app may give each user a private key that is stored on the device and used to decrypt messages, and a public key that can be shared with other users to encrypt messages.

This is a slightly trickier question, as not all data can be encrypted client-side. There is always some minimal set of data that must be visible to the software vendor, or the software won’t be able to function at all. For example, in an E2E-encrypted messaging app, at a minimum, the software vendor must be able to see the recipients of every message so that the message can be delivered to those recipients.

Beyond this minimum set of data, each software vendor has to walk a fine line. On the one hand, the more data you encrypt client-side, the more you protect your user’s privacy and security. On the other hand, encrypting more client-side comes at the cost of limiting the functionality you can provide server-side. Whether these limitations are good or bad is a question of priorities and beliefs. For example, the more you encrypt client-side, the harder it is to do server-side search and ad targeting. Is it good or bad that an ad-supported search business like Google could not exist in an E2E-encrypted world?

This is the trickiest question of all: how do you know you can trust software that claims to be E2E encrypted? Consider all the ways this trust could be broken:

There’s no perfect solution to the last problem. In fact, this problem isn’t even unique to E2E-encrypted software, or software at all. Fundamentally, this is a question of how you establish trust, and it’s something humans have been grappling with for our entire existence. Technology can help, but it’s not the full solution. At some point, you need to make a judgment call to trust something, or someone, and build from there.