Public Key Infrastructure (PKI) Explained (Bare Metal Cloud Security Series)

Let's say you want to create a web page. First, you'll need a web server. Then, you'll need a domain name to reach that server. In my case, I'll use heavy metalcloud.local. But we have an issue. Hackers sitting in the middle can view all the traffic in clear text. So, we need a way to secure the communication, and that's the topic of today's video called public key infrastructure or PKI. First, let's talk about the components required to secure the connection. As the name implies, public key infrastructure contains a public key. And this key is embedded in a certificate which is installed on the web server and is used for encryption. The server also has a private key. Again, as the name implies, this key should be kept secret and is used to decrypt data coming from the client. Unlike the public key, the private key is not embedded in a certificate. When a browser makes a request, the certificate is sent over. The browser can then use the public key to encrypt the traffic and the server will use its private key to decrypt the traffic. Using a public and private key is called asymmetric cryptography or asymmetric encryption which I covered in my last video. So you might be thinking that all traffic is encrypted using public and private keys, but that's not the case. You see, asymmetric encryption has some limits and it isn't very efficient. What really happens is the public key encrypts another key called a symmetric key. Once that key is decrypted by the server, then the whole encryption process converts from asymmetric encryption to symmetric encryption where symmetric encryption uses a single key to encrypt and decrypt. Symmetric encryption will be used for the duration of the session and once that session expires, the whole process starts over again. So, this is great, but there is one problem. It's possible that a hacker sitting in the middle could send their own certificate that's been forged. And at that point, you would still be encrypting the traffic, but it would be going to the hacker instead of your server. The hacker would use their own private key to decrypt the traffic. And this is called a man-in-the-middle attack. So, how can you protect yourself from this type of attack? To solve this problem, we'll need a trusted third party to sign off on the certificate that we're receiving. And this third party is called a certificate authority or a CA. Going back to our hacker example, let's see where the certificate authority comes into play. Let's replay what just happened. The hacker was performing a man-in-the-middle attack and they appeared as the legitimate website. We then made a request to the web server, but the hacker intercepted the request and sends a forge certificate. Your browser will then open up the certificate and inspect the contents, including the issuer. Since the issuer isn't recognized by the browser, the certificate is flagged as potentially compromised and rejected. So, how does a browser know if it can trust a certificate authority? Each operating system has something called a key store or a trust store. This is a list of certificates that are trusted by the operating system. The certificate authority that the hacker used with their fake certificate was not in the list and that's why the browser rejected it. You might be wondering where these certificates come from and the answer is that major operating systems and browsers maintain their own list of trusted certificate authorities and have them loaded by default. Next, let me walk you through the flow of creating a certificate. I'll use an example with a chain of trust that contains three certificates. Number one, a self-signed certificate authority. And this is also called a root certificate. Number two, an intermediate, also called a subordinate. And number three, a leaf certificate. Each of these certificates will also have their own private keys for decryption. So let me explain the order. The root certificate is at the top of the trust hierarchy. It's used as a starting point to sign the other certificates. Now, if we're creating our own root certificate, it's really important that we load it in the operating systems trust store, which we just talked about in the previous section. Otherwise, our browser will think we're accessing a compromised web page. The intermediate or subordinate allows us to create the leaferts while keeping the root CARert offline and safe. So, why is this important? You see, if the CAERT is compromised in any way, you have to revoke all theerts that are underneath it. You also have to issue a new CAert. And that means that all the operating systems and browsers in the world would have to update their trust stores with a newert. So, it's very important to keep thoseerts safe. Finally, the leafert will contain the domain name that we want to protect. For example, heavy metal cloud data local. The leaf ser can contain one or more domains and these domains are called subjects and they're listed in a section of the certificate called a subject alternative names or sand. You can also allow subdomains using a star and this is called a wildcard. And this wraps up my security series. We covered hashing, symmetric encryption and asymmetric encryption. In the next video, we'll use our understanding of public key infrastructure to create some certificates that I'll use in my bare metal cloud. Thanks for stopping by and I'll see you in the next video.

This video dives deep into the world of Public Key Infrastructure (PKI), explaining how it secures communication between your browser and a web server. We start with the basics of setting up a website and quickly move to the issue of hacker interception and the need for secure communication. What you will learn: - The difference between a public key (for encryption) and a private key (for decryption). - How asymmetric encryption and a symmetric key work together to secure a session efficiently. - What a man-in-the-middle attack is and how a Certificate Authority (CA) prevents it. - The purpose of a Trust Store and why operating systems trust certain CAs. - The Chain of Trust flow: Root Certificate, Intermediate Certificate, and Leaf Certificate. - The use of Subject Alternative Name (SAN) and wildcard certs for domain protection. If you are setting up a secure website or want to understand foundational internet security, this video is for you! 0:00:00 - Intro 0:01:04 - Switching from Asymmetric to Symmetric Encryption 0:01:54 - Man-in-the-Middle Attacks 0:02:58 - The Trust Store 0:03:41 - The Chain of Trust 0:04:47 - Subject Alternative Names (SAN) Amazon Affiliate Links - My recording Studio: - Cameras https://amzn.to/4msYu7v https://amzn.to/3JtfThX - Lenses https://amzn.to/4oOsrQX https://amzn.to/41iodr0 - Audio https://amzn.to/48PkdTb https://amzn.to/463UWmp https://amzn.to/4lDJ7bb - Lighting https://amzn.to/3HRiB09 https://amzn.to/4lMxxe2 https://amzn.to/3VdqgZM https://amzn.to/4mZ10T4 - Tripods, etc. https://amzn.to/3Jo6isO https://amzn.to/3Jsu1bj https://amzn.to/3JyvQDn https://amzn.to/4mQQJbk https://amzn.to/41lFMXb