Good day, everyone. Wonderful to be speaking to you today at FOSTAM. Unfortunately, again, online instead of in-person, but eventually we'll be back to Brussels.

My name is Bruce Momjian. I am one of the Postgres Core Team members and an employee of EnterpriseDB for the past 15 years. I am going to be talking to you today about TLS, more commonly referred to as SSL, if you're my age. And we're going to be talking about all aspects of TLS SSL,

including what it's trying to accomplish, how it does it, how it's configured, how browsers use it, how Postgres uses it, pretty much all the aspects in 78 slides.

This slide deck is actually part of a larger set of security slides that make up over 300 slides on my website. So if you'd like to look at these slides or the other three security presentations that I have, or any of the 54 or 55 Postgres talks that I have, please go to this URL right here

and you'll be able to review those pretty well. This is not a light talk. We're going to be a lot of complicated topics here and complicated issues to discover. About my goal is that when you're done going through this,

you'll have a better understanding of what TLS is actually accomplishing and how it is accomplishing it and how you can make it so that it accomplishes it for your project in a better way. I find that this is a kind of a complicated topic. I, about six years ago, started studying this,

read a bunch of books, wrote all 300 slides. It has some unusual concepts and it has, because it's related to security, it has to do things in certain ways to get those outcomes. And those type of processes that you see

in this type of material are really not common things that you would normally do in person, but in the digital world, you have to do this to maintain security. So it's a bit of a, it doesn't map greatly to sort of common sense sometimes or to what you can do in the real world

that you have to do differently in the digital world. Now, I'll kind of highlight that as it go through, but hopefully the material we're going to hold together. Again, there's one slide, a set of slides that's right before this one, which might be the best sort of precursor to this.

And I'll talk about it as we go forward, but be aware that there is going to be some assumed knowledge in this material. So what are we going to accomplish? First, why should we care about TLS SSL? What does it do? Okay, what does it accomplish for us?

Secondly, we're going to talk about the digital protocol that is TLS SSL. We'll talk about how it's set up, how it uses different encryption methods, how it exchanges keys and so forth, how it uses a message authentication codes. And then we'll talk about in section three, we'll talk about authentication.

This is where we introduce the idea of certificates, certificate authorities, how do certificates validated, how are they used? And I think there's a lot of confusion there sometimes. And I'll try and highlight that as we go along. Section four, how do browsers use certificates,

TLS certificates? And finally, how does Postgres as a non-browser app use it to give you an idea of how a non-browser app would use certificates? And then finally, a conclusion and of course your questions at the end. So why should you care? I'm kind of old enough to remember

a lot of the challenges in the early years of how to do communication securely without this protocol. How do you exchange keys? How do you make sure the person is who they say they are and how do you prevent inbound messages from being introduced?

These are pretty, these are now solved problems, but they weren't always solved. Obviously interactions are increasingly digital. So there is an increasing need to have this type of secure communication infrastructure available. Attackers are increasingly distant. In the old days, you only really had to secure

your location based on who could access your location. So if you're in, I'm in near Philadelphia, I don't have to worry so much about somebody who's in another continent because they're not here, right? So I don't have to worry kind of about people who, but in the digital world, somebody from another continent can easily attack my system.

So the scope of bad actors you can actually attack is obviously much, much larger in the digital world than it is in the physical world. And that requires more thought about security, I would say. Attackers are increasingly sophisticated. We do have some governments who do this,

some sort of companies or groups that do it for hire, certainly ransomware has become a big issue. I was just reading an article today about NSL, which is a Israeli company that does security tools, sells to governments, allows you to crack into a lot of mobile phones.

So again, the sophistication, and you have to keep your game up because if you don't, then these other more sophisticated people could potentially breach your security. News threats prompts new security requirements. TLS has evolved over the years, and I think it's become a lot better. And of course, security software must regularly be updated

to be effective because as new threats appear, new mitigations are required. Certainly log4j has taught us that in the past month or two, the problems that you can have there. I'm not gonna draw too much in history.

This is really talking about modern TLS. So what things is cryptography designed to accomplish? Now, again, I have a previous slide deck, which is called Fundamentals of Modern Cryptography. It's on my website that I, URL there I showed you, and there it goes into all of the pieces

that make up cryptography. But now we're gonna put them together. We're gonna put in hashing and encryption and key exchange. We're gonna say, what do we wanna accomplish here? Okay, probably three major things.

One is authenticity. How do we know that the person on the other end of our communication channel is the person we intend to communicate with? Okay, we're not talking about so much cryptography there as authenticity.

How do we know the other person is who they say they are? Secondly, how do we know or no one else can read our communications? That's encryption, okay? And then integrity, how do we know no other party can change the message or add messages into our stream of communication?

So those are the big three, and we're gonna kind of walk them through. We're gonna leave authenticity for a later section. We're gonna start really with confidentiality and integrity and then move in authentication at the end. Okay, but this talk is not enough. This is just a focus on TLS.

Of course, there's so many other ways you can be attacked. There's a video here at the bottom, which I think is really entertaining, which talks about a person who hacked into, I think it was an Xbox, and he explained how having the physical control

of the device allowed them to bypass the encryption. Anyway, the bottom line is that there's so many other ways that can be attacked that you really have to be aware of all of them to really have effective security.

So as I said, we're going to be talking about TLS today. What does that actual secure protocol involve? The first thing it involves is something called negotiating a secret session key. This is done primarily by an algorithm

called the Diffie-Hellman algorithm. It was designed, well, way back, decades back. But you'll see Diffie-Hellman if you look at some of the sort of encryption documentation, it's usually kind of shortened to DH.

So for example, in this case, we have ECDHE, which is Elliptic Curve Diffie-Hellman Exchange, which is basically, and again, my previous slide deck has this covered. It explains how two people in a communication channel

can come up with a secret key that someone observing the communication between the two individuals cannot derive the same secret key. It's very interesting. It's quite complicated, allows a lot of issue with exponents and in that case, Elliptic Curve to sort of come up with a shared secret

that is invisible to somebody looking at the exchange, which of course is a requirement. You can't be sure that your initial exchange, which somebody would not be visible because you haven't exchanged a secret yet to use encryption with, right? It's kind of the chicken and egg. How do you get that secret?

So you can then move into a method of using encryption so that your communication is secure. So that's what Diffie-Hellman is. Again, previous slide deck has a lot of details on that. Then you need to encrypt, decrypt blocks of data using a key. In this case, AES-256 is an example.

AES-128, AES-192, you see a lot of, you don't see a lot of non-AES, yes, there are some, but I'm gonna focus on AES in this talk. Most browsers and most sort of commercial communication also because of CPU enhancements, CPU acceleration,

AES is a very, very popular way of using encryption. You then need a way of handling variable-length messages. That's something called a cipher mode. We'll be talking about that later.

That is, again, covered in the previous slide deck. That's called, we're gonna, example is GCM. Verify that the message was generated by somebody who knows the key, also GCM. Identify that the other party is authentic. That cannot be done with the previous authentication methods.

That requires something like RSA or public key encryption. So we'll talk about that going forward. And then also verify that somebody in the middle is not viewing or modifying our messages. That would be also an RSA because you can't have a man in the middle. So again, you have to use multiple features

to really accomplish the goal of a secure digital protocol. And it's kind of made up into pieces. TLS version 1.3, it gets a little better with separating out those features and having all kind of pushed together, but they are separate concepts. TLS was originally named SSL, secure socket layers,

developed by Netscape in 1995. Yes, way, way, way back. It was the IETF named a protocol called TLS,

which was pretty much synonymous with SSL for many, many years. But the name TLS has been around for quite a while, 22 years at this point. And over time, SSL became kind of out of favor.

The last version of SSL was deprecated in 2015. And TLS is now sort of the go-to term. You see SSL just used because people used to SSL certificates a lot. It just kind of gets thrown around, but effectively nobody uses SSL anymore.

They're technically using TLS. In fact, the most recent version of TLS is 1.3. Versions 1.0 and 1.1 pretty much were deprecated by browsers about a year ago, but you still see them in the wild.

They're still around, particularly in software that hasn't been updated. But most modern systems are now using TLS 1.3, released in August, 2018. Again, because we now have browsers that auto-update themselves, you're seeing a lot more adoption of newer protocols, more recent versions of TLS in browsers,

which allows those browsers to make much more current. And again, I have a URL there if you want to kind of walk through how all this happens in more detail. In fact, a lot of these slides have URLs in them, so feel free to come back to the slides and really dig through them and kind of go down in individual slides

to see how these pieces work. Unfortunately, in the time allotted, we don't have enough time to go into that much detail. Some of the things have sort of fallen out of favor over time. For example, some of the early uses of encryption used RSA to encrypt the message

or even to encrypt the secret key. And that has fallen out of favor. That's no longer supported by TLS. You have a much more streamlined API for TLS now. And RSA is really now reserved for authentication

and the encryption part and the integrity part is left for a more modern and more efficient method. So RSA seems like a great way, public key encryption seems like a great way of, for example, exchanging keys. There's some reasons that that's probably not ideal.

Particularly one of the reasons that keys exchange is no longer done with RSA, something called forward secrecy. The concept is that if the private key of the certificate was to become compromised, could you go back in time and decrypt communications that had been recorded

in the past? If you use Diffie-Hellman, that is not possible if you use RSA for the key exchange it is and that's why it's not deprecated and no longer used. So basically to summarize here,

we use ephemeral Diffie-Hellman to negotiate a secret between myself and the person on the other end of the communication channel. We then use RSA, public key and cryptography to verify the authenticity of the person on the other end.

Typically what they do is they sign a hash of the actual secret key. So they take a secret, they negotiate a secret key, they private key sign the secret key.

Well, the private key sign a hash of the, I'm sorry, the hash of that exchange that made the secret key and then that proves that the other person on the other end

is literally the person who did the secret key exchange and also has the private key that goes with the public key, prevents made-in-middle-text. Client can do the same to validate their authenticity as well. You can use session tickets to allow reuse

of parameters from recent sessions. It's not sure how much that's still used. Again, as I said before, TLS 1.3 requires Diffie-Hellman and it no longer allows RSA to be used for key exchange. So you're looking at Diffie-Hellman for the key exchange.

You're looking at RSA for the authentication, authenticating users and authenticating this secret key to guarantee there's no one in the middle making changes. We have AS, which is used for confidentiality.

That's the encryption part. And then we use GCM and SHA hashes for integrity of the encrypted blocks. I'm gonna go into details of how that actually works. So let's look at an example. What we have here is an OpenSSL call. So we have an OpenSSL call in red, okay?

So we're typing, this is with OpenSSL 1.1.1k, which is a fairly modern version of OpenSSL. So OpenSSL, there is an optical S client and I'm connecting to the HTTPS interface on my web server.

And one of the lines that come out is this. It says new, meaning new connection. It says it's TLS 1.3, which is good. And then it spits out this long string here, which most people just glaze over like, oh, what's that? I don't know. What I've done here is to split out that string.

The TLS is of course the protocol. The AS is the symmetric cipher method that's being used. 256 is the cipher key length. GCM is what we call the cipher mode. And finally, we have a message authentication code hash type of SHA-384.

So we're basically combining that all together. And that's that big string. So if you wanna run this yourself, or you wanna try it on your own server, you can actually see the same string. And now you know what those sort of gobbledygook letters means. Cryptographic standards are evolving. When I originally did this talk

a couple of years, about five years ago, some systems we were using different versions of TLS, different AES versions and so forth. Now pretty much everyone's standardized. Be aware though, that you don't always get the maximum encryption. Sometimes the maximum encryption's overkill.

AES-128 is certainly fine for browsers. AES-226 typically is recommended when you're looking to avoid quantum attacks, quantum computing attacks. So that doesn't sort of apply, I guess, in a lot of cases. So for example, Firefox 96 and Chrome 97

prefer AES-128 over 256. And again, you can actually check that URL to see what your browser's preference is. I'm gonna sort of prove what I just said. What I did was I opened up Firefox onto my web server,

and I basically pulled this up and it's telling me that the connection is using exactly the similar string here, TLS, AES recryption, 128-bit key, GCM for verification, integrity,

and also SHA-256 for integrity. And it tells me that I'm using TLS 1.3. So again, that's exactly what I expected to see. If I hop over to Chrome, it gives me a similar string, TLS 1.3.

This sort of has to do with the certificate, I believe. And this is the AES-128 GCM that is being used. This is sort of a final slide just to give you a feeling for what's going on here. I'm just talking about a little bit

about the speed overhead of different versions of elliptic curve and some of the computation that's necessary. Again, I expect you to understand that. What I'm trying to get at here is that as the number of bits increases,

you start to get really heavy compute load. So again, just be aware of it. As you start to get really complicated, it can get kind of expensive to do stuff. But again, you can kind of see. But again, feel free to come back to that.

If I do the same thing with Postgres instead of a web browser, I actually see the same thing. I'm basically taking PSQL and connecting to Postgres 14.1 using SSL. And I can see right here, it tells me, yeah, I'm using TLS 1.3, and here's our same, TLS AES 2.6 GCM SHA 384.

And again, I can even use an extension called SSL info, which gives me the same information. If I wanna get fancy, I could even use some of the Postgres sort of extendable features and I can break out that string by breaking the string on the underscore and then labeling all of those pieces.

So a little geek factor there. So I talked about the key exchange, I talked about how they get a shared secret. To some extent, we talked about AES, we talked about how browsers use it, sort of how that sort of framework is set up. Now we're gonna launch into authentication,

which we're gonna pretty much cover mostly for the rest of this talk. Authentication is tricky. Again, the encryption part, pretty well understood. Key exchange, Jiffy Hellman, a little complicated. Authentication requires a lot more overhead, a lot more infrastructure

because it's trying to do something like proven identity, which is not something computers are really... Encryption, you just kind of put the number in, it comes out encrypted, that's kind of easy. But authentication kind of requires an infrastructure of identity management.

And I'm gonna explain how that then management works, kind of how it fits together with TLS, how browsers use it, how Postgres uses it, and hopefully you'll come away understanding this a lot better. So the primary mechanism used on the internet

pretty much universally to prove authentication are certificates. Why is authentication important? Well, of course, if you're sending a password to somebody or you're sending an order or something that you wanna remain confidential, you have to make sure the person on the other end

is indeed that person, because those of you who know internet protocols, it's very easy to sort of fake a packet or to intersperse a packet or intercept the packet if you understand how the traffic is flowing through the network. So you have to something beyond TCP IP to really do that type of authentication

and TLS certificates are really that solution. They got a lot easier over time. When I started, you had to find a certificate authority and you had to sort of register with them and do a lot more work. Now, most people using Let's Encrypt, we'll talk about that as we go.

That's automated a lot of this process, but I wanna walk through the process so you can actually see what's holding it together because frankly, Let's Encrypt makes it so easy. You don't really understand what's going on. Why does this work? How does it all fit together? So I'm gonna kind of walk through this here. So again, Diffie-Hellman gives us a way

of changing the secret, but it doesn't identify, it doesn't prove who you're negotiating with. Is there someone in person named this participant? Is there somebody viewing, modifying? We have to create a secure connection between the two, but we also have to prove identity. And that's done with something called

an X.509 certificate, which is the standard ISO name for these TLS certificates, which is typically sort of melded with the RSA public key, private key system to allow for both parties to trust

basically this kind of identity across the internet. So let's talk about how we create sort of our identity. And then we're gonna talk about how that identity kind of fits into the larger identity that we have out on the internet,

because it's kind of not clear sometimes what are we doing here. So what we typically do is we create an X.509 certificate that is signed by a trusted root authority. And that is what allows our certificate

to be considered to be proven identity. I mean, I could say, I'm Donald Dock or Mickey Mouse, but how do I prove that? What these certificate authorities do is to give us a framework where millions or some cases, hundreds of millions of websites

can identify themselves or individuals can identify themselves and prove who they are. So the way that typically happens is you create something called a certificate signing request or CSR by answering some questions that uniquely identify you or your website.

During that certificate signing request, you also create what's called an RSA key pair, which consists of a public key, which is you can share and is part of this certificate signing request and a private key, which you do not send outside and you keep private to yourself.

So this is again, part of the magic of public private keys. The public key is available to anyone who wants it, but the private key is something that you keep undisclosed and your knowledge of that private key is how you prove who you are. So the public part is sort of your,

I guess, half of the key and you have the other half and by showing that they fit together without divulging the private key, you prove who you are. They basically, you send your certificate to a signing authority and then they typically will sign it and send it back

and then you install it on your web server, for example, to prove that you're trusted. And again, Let's Encrypt does the exact same thing, although in an automated way. So let's kind of visualize what's going on here. You basically are creating a certificate signing request here

which has a public key in it, but a private key exists over here in the server, which you do not send. You have certificate signing information and you have a server signature. And basically what you do is you take your certificate signing information and you what we call private key sign it

and you store it into the certificate signing request. And that proves that you know the private key which matches this public key right here. That's how you prove that you're the right person to send a certificate signing request. Here's the mechanism of it. And again, I have a lot of these slides.

I don't expect that you'd understand them or even focus on them. I'm giving them to you so you have them as reference to understand how these fit together. So here we're doing an OpenSSL REQ for request, requesting a CSR, okay, certificate signing request. We'll fill in a bunch of information about ourselves,

what country we're in, our name, and that will create two files. It'll create a key, which is our public and private key, and it creates a CSR, certificate sign request. And if we run this command, we can actually output the certificate signing request. You can see I live in Newtown Square in Pennsylvania. It's for a website and here's my web address

and my email address. So it kind of fills that all in for you. You can actually dump out the entire certificate by using this command, and you can see actually the public key that's part of it and also the exponent, and then the private key is not in this file.

So you'd really only see the public key part because the private key is in that key file. So only the public key can goes out. If you want to generate a key pair on your own, here's how you would do it. I can actually dump out my key pair and here I can see my private exponent.

So here's my public part of my key in blue, and here's the private part in magenta. So the key file has both the public and private key together. I actually created a tool called RSA dump.sh, which will dump out the mathematics around your key.

I'm not gonna go into this again, previous slide explains this, but it basically will show you your exponent, your base and so forth. And this is how the exponents are computed for the RSA algorithm. And again, here it is in, just to give you an idea of how big these numbers are,

you know, one times 10 to the 300 maze. RSA and this whole certificate thing really has three files or three types of files. So you should probably be aware of what these are. The key file, you know, you hear the word key and you think, well, is that the public key or the private key?

It's actually both. So if you ever see key, it's usually the public and private key together in one file, and that's private obviously to you. If you see a file that's called pub, that is the public part of the key, doesn't contain a private part. And again, that can be shared with anyone.

CSR is the public key and the data to be signed. And the CRT is their certificate. Once the CRT has been signed, it becomes a CRT. So the certificate signing request once signed becomes a CRT or a signed certificate.

And that certificate is signed by a certificate authority, which we're gonna go into in a minute. There are some acronyms here with TLS. And again, we're gonna get into a whole bunch of details which you may glance over. Actual certificates use a standard called ASN1

which is an abstract hierarchical data structure. Defined I believe by ISO. And there are two representations for certificates. One is a DER file, which is a binary representation of typically a certificate or an ASN1,

which is a type of certificate. Or a PEM file, which you may have heard of before. A PEM file is a base 64 encoding of DER data. You'll see PEM files a lot. It's basically armored. So you can open it in an editor, like a DER file, which you can't.

Typical file extensions for these certificates are PEM, Key, PUB, CSR, CRT, CRL. Talk about what CRL is later. One problem you have, if somebody names a file with extension PEM, it's not really clear what it is. It tells you what the format is.

Doesn't tell you whether it's a certificate or a key or a public key or a private public key or a CRL, right? So I'd sort of tell them to try and avoid the name PEM, or if you wanna use the word PEM, put another extension after it to identify what it really is. PEM is a format, but is it a certificate? Is it a key?

That can get a little confusing, at least in my experience. So am I really making this up? Does this actually work? Yes, it does. What I'm gonna do in the next couple of slides, I'm gonna break apart a CSR and kind of prove how when a browser

or an SSL session receives a certificate, how does it validate? The certificate was, how does it validate that the person on the other end of the certificate knows the private key of that certificate? That's really the information.

Them having the certificate is immaterial. Everyone can have their certificate. I can download certificates of millions of websites if I want to. Having a certificate is not identity, doesn't prove identity. Having a private key that goes with it proves identity. So how does that work in practice?

Typically what happens when you get a CSR or when a CSR is created, it basically, you basically find the CSR, you find the hash method, you hash the user supplied parameters that you give like your name and your website

and so forth, the email address. And you extract that and you use the RSA public key to reverse the signature to produce a hash and then you compare it. And that's how you actually verify this certificate is valid. So let's let you walk through this.

So here I have basically my CSR, which is my certificate signing request. And you can see right here, the ASN1 notation. You can see it indented, right? So you can understand it's a hierarchical structure. You can see my website and the type of encryption we use and so forth right here.

Here's the website, here's the type of encryption we're using. So what typically happens is you take the CSR, you output it in DER form, you parse it and then you create a SHA-56 hash of that.

And then you look at the hash and you can see the hash begins with F405. So what I've taken, I've taken the CSR and I've computed it out, okay? And you can actually see it reversed. We can actually take the CSR and we can parse it directly

and then use a PKEYVERIFY to verify that the key actually would sign matches the signature. And that's exactly what we get. We get the exact same output. So here we're proving that the CSR is valid because we've used our private key to verify that it does actually allow us to sign this.

You could go in another way. Here's two versions of the same thing. Here we're taking the CSR and we're validating against the key and we're outputting the hash. Here we're taking the CSR and we're just outputting it and hashing it directly. And you can see they're exactly the same. So one, we're using the key to verify it.

The other one, we're just computing the hash directly and you can see they verify and they're exactly the same. How would I do that for a website? Here's my website certificate. You can see CMOMGEN right here. Obviously this is an expired certificate but I wanted to show you this because it has some good examples in it.

So effectively for my web server, I have a PEM file which we talked about was not a good idea but that's what it came in with the name of. Remember PEM is a format. It turns out it's a certificate.

So I take my certificate and I output the issuer of that certificate. It happens to be RapidSSL. Then I go to RapidSSL and I find the issuer of the RapidSSL certificate. Turns out it's GeoTrust Global, certificate authority.

And then if I ask to see who the signer issuer is of the GeoTrust Global, it actually is themselves. So in every case, as you walk up this certificate authority, you're eventually going to get to what we call a root certificate. And a root certificate is effectively something itself signed, right?

So here we are, we're verifying that, we're verifying that this momgen.pem can be violated against these two certificates. So rapidSSL is okay. We can here verify that RapidSSL can be verified

against the Global, GeoTrust Global, which is okay. And then we can also say GeoTrust Global is verified against itself, which is a root certificate. That's okay too. We can play with verification a little bit. If we don't supply all the certificates, we don't get verification. Again, if we supply RapidSSL and GeoTrust Global,

we can validate our PEM. But if we only supply ourselves, like I'm trying to validate myself against myself, that'll fail. If I try and validate myself against GeoTrust Global, that also won't work. So what I'm trying to do is I'm trying to validate GeoTrust Global against nothing,

but I'll get it okay because the self-signed certificate, it validates because there is no signer of that. So rules of certificate verification, I'm not gonna go into this, but again, you walk through the process, you receive your certificate,

you validate that matches the private key, that the server has a private key. Somehow they prove that. And then you walk up the chain to find a certificate that you trust that's part of that chain. And if you can't find it, then the certificate's invalid. Somebody can present a certificate,

but unless it chains up, it's signed by one or more certificate authorities that eventually you trust, you can't trust it. And that's that chain of trust is the way it works. And again, the top most is a root certificate. This is instructions on installing certificates in Apache.

Again, pretty straightforward. If you want to introspect a certificate bundle here, here I'm actually taking and I'm creating my certificate. I'm contracting with another one, which I can then dump out and validate my certificate. So I'm creating two certificates together because I need to create,

to include the intermediate certificate. With my certificates, I don't know the intermediate's gonna be on everyone's computer. So sometimes depending on who you're using for certificate authority, you may need to supply their certificates as part of your certificate so that the chain is connected. You might not have enough on its own to connect.

You might need to supply it. How do you create a certificate authority? It's pretty straightforward. You sign, and I have a blog entry here to explain it, but you basically sign your own certificate. So this is the way visually we do it.

We have up here a root certificate signed by itself. We have an intermediate certificate, which is signed by this root. And then we have what we call a leaf certificate or an end certificate, which is signed by an intermediate. The root doesn't need to sign the leaf certificate. It just needs to have a chain that we can trust going all the way down.

How do you create a root certificate authority? Very easy. You basically sign yourself, right? You just sign yourself and then you create a CSR and you sign, here I am signing my own certificate

with my own key. And you also need to create an indicator that it is indeed a certificate authority. You have to use that special extension flag when using OpenSSL to do this. Then that causes the certificate to mark as CA true, meaning that a certificate is identified

as certificate authority. Then we can create an intermediate certificate signed by my root certificate. And this is the way that would look. I'm now signing. I'm now, here is my certificate authority and I've got my server key. And I'm now using a root certificate to sign this certificate authority.

So this is a trusted certificate by this root down there. Again, using ASN1, we can actually prove this out. You can see the pieces there. We can verify the hash like we did before that they match. You see 9B7, 9B7, that is the exact hash.

We can do the same process we had before where we reversed out the two of them. We took the root, we computed the ASN1 hash on its own. And then secondly, we took the hash that they gave us and we validated against the public key

to verify that indeed that the hash was signed by somebody who knew the private key. That's how you know that that's a valid certificate. It prevents any tampering. How do you create a LEAF certificate, one at the end? Well, you basically just create a certificate signing request

and then you sign it by someone. In this case, I know the certificate intermediate key, private key, so I use that to sign it. If I didn't have that, if I didn't know the private key of the intermediate, I would have to send it to somebody and they would have to do it for me and then send it back. So that's typically the way it works.

You typically don't sign your own. You typically have to send it to somebody if they do it for you or use Let's Encrypt and that's all automated. Again, same certificate authority, the roots at the top, one or more intermediates in the middle and then the LEAFs are at the end. There's a couple of different hierarchies you can use

or structures for this. Here we have a root certificate and the root certificate is directly signing the client, the server certificate and the client certificate. I don't recommend this hierarchy. I recommend something that has an intermediate so that you can replace the intermediate occasionally

without having to rekey everything. I'll show you how that works but effectively by having intermediate, you can replace the keys much more easily than having them signed directly by a root. There's another architecture where the server certificate may be signed by the root but you decide that all the clients are gonna be signed by intermediates.

That's also possible. It's also possible to do this. We have two intermediates, an intermediate for the servers and intermediate for the clients. Either one would work fine. So how do you create your own root certificate? Why would you wanna do that? There are cases, for example, when you're using Postgres where root certificates,

your own root certificate is actually preferable. You basically sign your own key or you create an intermediate CA, you transfer the root to private key to offline storage. So your root certificate just goes off into a USB key or something sitting in a bank. And then from there on, you just use the intermediate keys to sign things.

And that way, if you wanna change your intermediate, you just need to go back to the bank, recreate a new intermediate and then take it back to the bank again then your intermediate can stay. So it gives you sort of that extra level of indirection so you can replace the intermediate a lot more easily. Again, there's a nice article there

that explains why this is important. There's also something called a certificate revocation list. I recommend you use this. It allows you to revoke certificates that either have been exposed like the private key's been exposed, an employee leaves who had access to the private key or maybe the hardware was under untrusted control.

So for whatever reason, if you wanna invalidate a key, you can do that with certificate revocation list. You probably are not gonna use it right away but I recommend you set it up so that if you ever need it, it's available. I do have a nice blog entry at the bottom talking about why that's important.

Using certificates, again, what we're now bringing to a head here, what these certificates allow us to do is for two parties communicating by TLS to have authentication. So we know we do a shared secret but what we actually do is we use the certificate

to sign the key exchange and we send that back to the other person and that verifies that the person who viewed that entire exchange knew the private key of their certificate and because we know the certificate is valid

because it goes up to a trust that we know, we can then verify that that is a valid key exchange because the key exchange was signed by the private key of the certificate that we are communicating with, okay? And that's actually how the key, that's actually how you identify

that the key exchange was done with the person that you really wanna talk to. And again, great description there at the bottom if you would like more details on that. How does this actually work in practice? Typically certificates are sent to across the network

and then what happens is effectively, as I said before, the TLS parameters and the shared secret are signed with the private key and are sent as a signature to the other end and the other end takes the public key of the certificate, decrypts the signed, I'm sorry,

takes what was sent, hashes it and then uses the public key to decrypt the hash of what was sent across the network and if the two match, they know that the person who created that special hash knew the private key of the certificate that we trust.

Very tricky. Let's look at how browsers use these. Again, here's a pop-up of a browser. You can see it's going to my website and you can see that it actually is using a certificate from RapidSSL

and that RapidSSL certificate was signed by Geotrust. Again, I currently use Let's Encrypt but again, this example shows the certificate authority is a lot clearer so we can walk through exactly how the process works and you can see that certificate actually expired so it's not valid.

Here's a little better display. You can see Geotrust is the root, RapidSSL is the intermediate and MomGen is the leaf. Here's a, you might say, well, how do systems know what's trusted? Effectively, what they do is they have a list

of trusted certificates inside their browser and you effectively can validate only against that list. So here I have RapidSSL on the list as trusted. In my example, Chrome actually doesn't have that so I had to make sure it was sent as intermediate. Some Chrome browsers don't.

If you remove a root certificate that you trust, remove a root certificate that you need, what will happen is that you will get a certificate invalid error. So if you're removing a certificate

that you need to validate a certificate, you basically get MomGen US uses an invalid security certificate. The issuer certificate is unknown because it couldn't follow the chain up to the root. Again, great URL here. Another case this happened was with Let's Encrypt. They used to have their certificate authority

used to be signed by someone else. And in September of last year that someone else's certificate expired. So all of a sudden old browsers or old devices, internet of things devices that may have been using Let's Encrypt that didn't have the Let's Encrypt root certificate,

all of a sudden we're gonna throw errors. So that was, if you remember that little excitement in September last year, that's what it was about. That the Let's Encrypt used to be signed by a certificate that was in every device. And now that Let's Encrypt is in all devices

but the older devices weren't there and therefore you would get these errors. And the only way to fix it is really to get the root certificate into the old devices. There's no really other way around it. So that's why there was some excitement there. Just to finish out, I'm just gonna show you how Postgres uses it really fast.

Here's a tool that allows you to dump out the certificate for Postgres to enable certificate authority in Postgres. And again, this is not a Postgres talk so I don't wanna go in too much detail, but effectively with Postgres you can verify the authenticity of the server or of the client using certificates.

Typically you create a root certificate in Postgres. You don't usually use public certificate authorities. You create your own private root and you effectively have the server verifying the client and the client potentially verifying the server using this certificate authority system. The ordering of the certificates is actually important

so you don't wanna just order them randomly. Postgres docs goes into that and why certain certificates are necessary. Certain requirements of you have to have a chain just like a normal web browser has to have a chain up to the root. And we also support certificate revocation lists.

Okay, so what did we conclude? Cryptography, TLS gives us authenticity, confidentiality and integrity. How does it do that? Authenticity with X.509 certificates, ASN1 and RSA,

confidentiality, Diffie-Hellman and AES, integrity, GCM and SHA. I tried to put them all together so you can kind of see how they work. So it's been wonderful presenting to you today and we're going to be taking some questions

right after this recording stops.

First, the Let's Encrypt issue which actually I was specifically asked for by the FOSTA organizers to mention, it was basically a cross signing of the Let's Encrypt certificate by another certificate authority and their own certificate was put

in the most certificate stores at the same time. So it was kind of two happening at once, they were signed in two places. What disappeared in September of 2021 was that second signing. So now they're just a root certificate store and nobody else is signing them. And obviously if you had an old certificate store,

Let's Encrypt might stop working. Fortunately, we got through that pretty easily. Older systems might not have updated certificate stores and that was the big issue. There was a question about ECDSA. At one point that was I believe the preferred method for Chrome.

Maybe that was five years ago but now it is no longer the case. So I don't know if people are moving away from DSA or if DSA was considered more secure or not before and now it's just the same as RSA, I don't know. But I don't see it as much as I did maybe five years ago. How does one become a credible, trusted,

popular certificate store? Basically, every browser, every operating system makes its own decisions of what certificate stores are gonna be in there. So the problem is that if you're one of the smaller certificate stores, you may need to supply

and you're signed by a higher certificate store, you may need to supply your own intermediate certificate when you send your leaf certificate. I kinda went into that a little bit in the talk but there are sort of the big certificate stores that are in everyone and then there's some that are only in some and some are intermediates technically

even though there are a lot of times in certificate stores so you don't need to send the intermediate but in other cases they aren't as an intermediate in the certificate store and you have to supply it. So the unevenness is certainly confusing. That's one of the reasons I use the RSA, I mean the RapidSSL certificate example

because they were a case where RapidSSL was an intermediate on Geotrust. In some certificate stores, RapidSSL was in the certificate store even though it was an intermediate of Geotrust. In other cases, it was not in the certificate store and you had to supply, the leaf had to supply the intermediate

which was then signed by the Geotrust which was in the certificate store. So again, it gets really complicated. Most cases you don't have to worry about any more, Let's Encrypt certainly is pretty much everywhere. So that kind of takes care of that. And I believe that is the end of the question. So do we have any more questions? And if not, we'll just wrap it up here.

Got a lot of clapping hands here but I think that might be it. So let's call it a day. I wanna thank you. Do you have any new questions? No, all right. Well, thanks folks.

Been a wonderful event. This is my second talk today and I've certainly enjoyed it. Not as much fun as being in person, but still enjoyable. Thank you so much. I'd request all the audience to please put up virtual round of applause for the speaker. Thank you, Bruce.