Imagine an application running on a server or cloud provider. When the application connects to a database, data doesn't simply teleport from one place to another. It travels across the Internet through multiple routers and networks. When your application needs to read or write data to MongoDB, it transmits packets of information that must reach the database server securely. This journey can occur through the public Internet infrastructure or private networks. This setup results in several security concerns. For example, the data might be visible to others while in transit through the public web. Without proper protections, malicious actors might try to intercept or manipulate the data as it moves across the network. Even when using private networks, a zero trust security model applies, meaning no connection is inherently trusted based solely on its network origin. A widely adopted strategy to prevent this vulnerability is transport layer security or TLS. In this video, we'll discuss TLS and its important in secure communications. Next, we'll explore the different types of certificates involved in implementing TLS and examine how they can work together to ensure secure communication. Finally, we'll discuss how to use TLS within MongoDB. Let's get started. TLS is a cryptographic protocol that ensures communication over the network is secure. Oftentimes, you'll hear secured sockets layer or SSL mentioned along with TLS. This is because TLS is an evolution of the legacy SSL protocol. It's likely that you've heard of TLS before since it's widely used across the Internet. For example, HTTPS, which appears in front of web addresses, signifies that the website you're visiting is using TLS to secure its web traffic. So how does TLS work? TLS protects your online communications through several parts working together in a step by step process. When you connect to a secure website, your device and the website server start a handshake to set up security. First, the server shows a digital certificate, basically an ID card that contains the server's public key or one half of a key pair, and proves who they are. This certificate comes from a certificate authority or CA, which is like a trusted official who verifies identities online. Your device checks if this certificate is real by making sure it's signed with a trusted CA. This prevents you from connecting to fake websites. The key pairs used in TLS have two parts, a public key which can be shared and the private key that stays secret. These keys work together. What one locks, the other can unlock. This system helps your device and the server create temporary session keys that will encrypt the actual conversation. Both sides also agree on which security methods, called a cipher suite, they'll use to protect your data. Think of this as choosing which locks and alarms to use on your house. After setting everything up, all messages travel encrypted with session keys. This means that anyone listening in would only see scrambled data. To make sure messages aren't changed during delivery, TLS uses message authentication codes or MACs, like tamper evident seals that break if someone messes with your data. If the MACs don't match when the message arrives, your device knows something went wrong. This whole system keeps your information private, confirms who you're talking to, and ensures your messages arrive exactly as sent. As you can see, TLS does quite a bit to keep our data safe. And we can use TLS to enhance MongoDB security by encrypting client server communication, securing replica sets and sharded clusters, and protecting sensitive data during transmission. For example, let's say we want to enable TLS to secure the internal communications between the nodes and the three member replica set. The first step in securing communication is to verify the identity of the peers. To do this, we use a digital certificate for each member of the replica set. In our example, the certificates are omitted by a certificate authority or CA. Because anyone can create their own certificates, a certificate must be signed by a trusted CA to be considered authentic. The CA verifies the identity of the certificate owner and ensures its legitimacy. This process establishes trust between the communicating parties. Next, to initiate a secure connection and encrypt messages, each node needs a pair of keys, a public key and a private key. The public key is part of a node's digital certificate, serving as the node's digital identity. It is used during the key exchange process to establish a secure session. Data encrypted with the public key can only be decrypted using the corresponding private key, which remains confidential to the node. The node's private key, on the other hand, is used to decrypt data that was encrypted with the node's corresponding public key. The private key can also be used to create digital signatures, which verify the node's identity, ensure the integrity of the message, and confirm that communication is with the intended node. In summary, the public key is used for encrypting initial connection data and verifying digital signatures, and it's publicly available. The private key is used for decrypting initial connection data and creating digital signatures, and it's kept confidential. Together, they enable secure, authenticated, and encrypted communication over the network. With a trusted digital certificate issued by a trusted certificate authority and cryptographic keys, our replica set members can securely connect to each other using the certificates, encrypt all communication between members, and ensure that data integrity is maintained, preventing unauthorized access or tampering during replication. Setting up network encryption might seem complex, but Atlas simplifies the process by enabling and configuring network encryption by default, a feature that cannot be disabled. However, we also provide the flexibility to customize your cluster security further by allowing you to select stronger ciphers when configuring your Atlas cluster. Awesome work. We covered a lot in this session, so let's take a moment to recap. First, we learned that transport layer security or TLS is a cryptographic protocol that helps ensure secure communication over the network. After that, we learned that in order to use TLS, we need to have a trusted certificate authority that will issue signed certificates that can be verified. Next, we learned that each replica set member needs a pair of cryptographic keys, a public and private key. The public key is used for encryption and signature verification and is widely distributed. The private key is used for decryption and creating digital signatures and is kept confidential.