- Hi, everyone, it's
David Bombal back with a very special guest, Ed. Tell me about yourself, man, and welcome. - Happy to be here. I run a YouTube channel,
practical networking.net. I do network engineering training, network security training. And today we're gonna be talking deep about the SSL handshake,
and the TLS handshake and all the intricacies that goes on in the first few milliseconds between what your computer is doing when you browse to a website and what the server's
doing on the other side. - Really looking forward to this. And I'll say this to
everyone who's watching. Ed came highly, highly recommended
by my discord moderators. So Ed, you've gotta perform today because you've been put on this pedestal. So Ed I'm kidding. I really appreciate you
taking the time to come and show us this, I I'd like to say this. Ed's got a course, which I'll link below where he goes into this stuff
in even more crazy detail. (jazz music playing) Now, just before we begin the video, Ed went into a lot of detail on this slide and a bunch of other stuff. Ed, we didn't cover everything didn't we? So we perhaps have another one, which we might call de deep TLS. This is a topic a lot of
people have asked me about, let's go deep Ed, so
I'll give it over to you. Take it away, Let's go deep into the keys and the exchange, et cetera. - Oh, for sure okay. Well let's, do it. What you're looking at is a lot, there's a lot going on on this slide, but what this slide is showing you is the entire SSL handshake
between a client and a server. And what we're gonna do is go through this kinda line by line
slowly one step at a time, and we're gonna outline, everything they send to each
other kind of in the middle. But also, and this is the interesting part is everything that they each know inside these boxes on the left and the right as they share information with another sometimes they'll be making
calculations on those, in that those pieces of information. And I'm gonna outline
both the calculations and what piece of information, both the client and the
server have in these boxes on the left and right respectively. The end goal will be to get
down to these session keys. Now these session keys
at the bottom, those are, what's actually going to secure the data in an SSL communication. And we're gonna talk through
how those session keys are actually derived. So that's the end goal. And we're gonna step through this slowly. Won't be as chaotic as you
see here on the screen. - So like a normal person who
doesn't understand this stuff, they just open up their browser. They go to Google or
Facebook or whatever website, and they get that little padlock. And this is what's going
on in the background to give us that padlock, is run. - Yeah, absolutely. This happens every time you go
to a new website over HTTPS, every time if you're using an SSL VPN, the same thing happens in the
background on the wire there. - Great. - Now, before we can
really unpack all of this, we kind have to start
with a few pre-requisites just to make sure we're
kind of look well setting and starting from the same page. Now, all of this, we can go
into much more detail on again, if you would like, but as as long as we at least understand this part, we should be well suited to
actually cover the handshake in great detail. So the pre-requisites are
first SSL/TLS have three goals. That's confidentiality,
integrity and authentication. Each of those is a, is something that is done to data in order to do what's called protecting it right. When we say we wanna
protect data or secure data, those are the three
things that we want to do. So confidentiality is the
idea of what I put on the wire I only want the other side, the intended party to be able to extract what I put on the wire, integrity
is what I put on the wire. I don't want anybody to be able to change or modify or tamper with, or at least if it does get modified, I want the other side to
know that something happened to those packets and to discard those. And then finally authentications. I wanna make sure I know who the side is. That's commonly referred to as you know, the CIA of security. It's like the three most important things anytime you're talking about a secure communication protocol. And TLS has that as a goal, but also, so does IPsec so does SSH any
secure communication protocol is gonna require those three things, cool. So each of those are provided by different cryptographic tools. Confidentiality is provided
via symmetric encryption. That's the idea of, I take
something, a piece of data. I encrypt it with a particular algorithm and a particular key. And the only way to undo that is if you have the same
algorithm and the same key. So that's the idea behind
symmetric encryption. - Same key on both sides. - Same key on both sides, absolutely. And we're gonna talk about how those keys are derived shortly. We mentioned making sure data
isn't changed in transit. That's provided via hashing,
but technically via, what's known as a M.A.C
message authentication code. And the simple definition of this is, is hashing in combination
with a secret key. We can't just use simple hashing 'cause anybody can do hashing, but if I hash data in combination
with a particular key, then I know only the other
person who has that same key can redo that hash or verify that hash. - So like symmetric would
be like DES or something, sorry to interrupt.
- Absolutely. - And then like hashing
would be MD5 or SHA. Is that right? - Absolutely correct, so absolutely. So symmetric encryption,
AES, DES, RC4, ChaCha20, all those are symmetric
encryption algorithms and then hashing would
be MD5, SHA, SHA-256 SHA-304, POLY1305,
another hashing algorithm. - And anyone who's worried about what you're saying now you you're gonna talk about what that is later, yeah. - Sure, absolutely. And we can actually go
back and look at these in a more detail. Actually, I think that would be useful. So let me actually go to that. So real quick, I wanted to pause and talk about integrity and specifically why hashing by itself
isn't necessarily enough. And this is often an overlooked point but I think it's worth picking out. So integrity is the idea of making sure what is put on the wire can't be changed. And that's done via hashing,
but not just hashing. So the basic premise of
hashing would be somebody will put together some data, something on the wire
and then run that data through some sort of hashing algorithm that's gonna result in a digest. Now I have more videos
on hashing on my channel. If you guys wanna unpack
that in more detail, but idea hashing is you put something into it
and it spits out a digest, which is a representation
of the original input. So if I have a message and I run it through a hashing algorithm, it's going to spit out
a particular digest. Now, most people think what you do is then you then send the message and the digest across the wire. And the idea is the other
side can recalculate the same digest, rather
recalculate the hashing algorithm on the message and make
sure that the digest match. That's how most people
think that it works. But there is a problem with
that, actually David see if you could tell me what you think the problem might be if that's what we actually did on the
wire with SSL and TLS. - So my understanding
of hashing is like MD5, you take a piece of data, whatever it is, you run it through MD5, it
comes up with 128 it value, if any of the data is
changed, the hash changes. So yeah, whole idea is like, if you and I want to check
that we've got the same data, we check that the hashes are the same. The problem here is what happens if a hacker changes the data
and puts a new hash on the data and then sends it to the receiving party, they will do take the
manipulated data hash it and the hashes will be the same. So yeah, the hashes just
injected trash, yeah. - Yeah, a hundred percent. So you nailed it, right? So if somebody captures
the data on the wire, changes the data and recalculates a digest on the modified data and then forwards that along at the end of the day, the receiving entity can
calculate a hash again on the modified data. And the modified data is
digest is going to match the modified hash that
was sent with the hacker. So you called it out exactly. - For people who are not sure the important thing with hashing is any part of the original, if any part of the original
data changes the hash changes. - Absolutely, yeah. So the way we kind of solve
this in the security world is by doing, what's known as a message out authentication code. So that's what I'm about to show you the way it works is both parties need to have a secret key. Now we'll talk about how that
secret keys is established in a minute, but for now, just understand a secret key
magically exists on both sides and only the intended
recipients of the conversation have that key. Then the sender is going to
calculate a hashing algorithm, rather put through the hashing algorithm, both the key and the message. So this digest is a result
of combining this key and this message. Then what is sent across the wire is both the message and the
digest, again, not the key. The key is never sent across the wire. The other side already has
the same key and can combine the key and the message
to calculate own digest and to make sure that the same digest, rather to make sure that the message hasn't been changed in transit. The benefit there is the
only person that could create either of these digest
is whoever has this key. So if the person in the
middle captures the message and changes the message, that
person doesn't have the key, and won't be able to create a
digest based upon the modified message that the green user
over here is going to accept. This is known as a message
authentication code and a message authentication provides both integrity and authentication, meaning I know nothing
was changed in transit. And I know the only person that
could have sent this message is whoever had the secret key, meaning the blue user over here. This concept of combining the key, plus the message is known as a message authentication code or a MAC. So there's a specific way of doing a MAC known as the HMAC and that's
the kind of industry strand for how they combine a
message with the key. So the reason we kind
of went into integrity is just to there's many
different layers to all of this. It's easy to be, to say like, oh, we'll use hashing to do integrity or use symmetrical encryption
to do confidentiality, but it actually goes so
much deeper than that. And hopefully we can unpack a lot of that depth in this video. So that's integrity. - If we didn't go deep
enough, let us know. Ed's been very kind to say
that he'll go as we want. We'll see how far we get in this video. And if we don't get deep enough, they let us know we'll go even deeper. And Ed said can even take
us into the algorithms and other craziness. So please put in the
comments below how deep you want us to go if this
is not deep enough, sorry, Ed carry on. - Oh, no. By all means yeah, absolutely. A lot of those content is from a, a full eight hour course. We can go as deep as you
guys are willing to go on this content right here that
we just like looked at the whole first two modules
of the course is actually on my YouTube channel for free. So feel free to check that
if you wanna go deeper on the crypto side of thing. But for us, we're gonna
jump back to the handshake. That's the goal of this video. So back to where we were before, we kind of took a detour to talk about message authentication codes and explain why hashing
alone wasn't enough. We told you that using a MAC
will provide both integrity on, in authentication on the
data that you're securing. These two things require
a key exchange because we need to get the same secret key on both sides of the wire. And a key exchange can be done
using asymmetric encryption. You can use Diffie-Hellman
or RSA to do that, but the problem is anybody can use RSA and Diffie-Hellman
for a key exchange. Anybody with a Linux terminal
can generate asymmetric keys. In fact, it only takes two
commands on a Linux terminal. OpenSL, genrsa, and
I've just now generated a set of asymmetric keys, a set of RSA asymmetric keys. I can do it again as many times as I want. I can continually generate
new asymmetric keys. - What's RSA. - Great question. So RSA is one of the premier, one of the most common
asymmetric encryption algorithms. It's kind of the asymmetric
encryption algorithm that everybody explains when they explain asymmetric encryption. But there's actually a lot
more to asymmetric encryption than just RSA. But it's an algorithm that you can use to create a set of what
they call community of keys. So I can create a public
key and a private key. And what I encrypt with one
can be decrypted or the other, what I encrypt or the other
can be decrypted or the first. So you can go kind of in either direction. - So it is an important,
and can you explain like, just briefly, what is private
keys, public keys, and I know you've got a lot of
content on your channel. And so if anyone one doesn't
understand it, you know, with this quick demo, they can go look at your YouTube channel,
but what is a public key? What is a private key and why do we care. - A second ago, we made reference
to symmetric encryption. We said that to do confidentiality, you can use symmetric encryption, which is where I encrypt
something with one key and you decrypted with the other key. A very simplistic example
of symmetric encryption would be honestly just
multiplication. Right? So if I start out with a value five and I use multiplication
with a secret value of say three, so five times three, that's gonna give me 15. 15 is like the encrypted
version of the five. And for you to undo that you would use the reverse algorithm. So division and the same secret key three. So if you did 15 divided by three, you would get back to five. But the crucial point. Yeah, the, the crucial point there is, was we're both using three to both encrypt and decrypt the content. - So the threes are key, yeah. - Yeah. And three would be the key. And that would be an example
of symmetric encryption. Asymmetric encryption is a little different in the
sense that you can't actually, you can't undo the work
using the original key. So explain asymmetric encryption. I'm gonna use this analogy. Now what we have here is
the outfit A through Z and for simplicity's sake, we're gonna assume that only know the lower case alphabet, no symbols, no numbers, no nothing,
it's just the alphabet. So with symmetric encryption, I can take a word and I
can use a particular key. And in this case, the algorithm is gonna be
moving the letters forward this amount of times, the secret key amount of
times in this case three, if I start at H and I
go forward three times, that would end up at K and
then to undo that I would start at K and go backwards three times, I would end up back at H but
notice three to go forward and three to go backwards, symmetric key. It's the same key on both sides. Now, asymmetric is a little different. With asymmetric encryption I'm still going to use an encryption key, but I can only use go forward. So for instance, if I start at H and I'm using
an encryption key of five, I go forward five times that would put me on M that would be the encrypted version of the letter H and I could do this with the rest of the letters
in the word as well. The difference is with
asymmetric encryption, this math involves what's
called trap doors functions, which means it's it's functions that can only go in one direction. So even if I know five was
used to go this direction, I can't simply go back. Now a simple example of that is the remainder function
or the modulars operation. For instance, David, if I ask
you, what's the remainder, when you divide 12 by five. - I'll let you talk two yeah. - Two, right absolutely. Let ask you another one. What's the remainder, if I divide- - Don't ask me maths, I'm bad at math. Go on. - What if I do 17 by five,
what's the remainder? When you divide 17 by five. - What's a two again, isn't it. - Two, absolutely. What if I said 22 what's the
remainder you do 22 by five. - Two, yeah.
- Two, right. So if you know that I'm doing
something divided by five and the result is two, is there a way for you to know explicitly what I started with? - No, that's a great analogy, I like that. So in other words, right. I know what the remainder is, but I don't know what the
original, like the 22 by five it gives me four yeah. Four times five. - Absolutely, right. And so it's like, there's
no way to really undo it. Like you could know the results
and even what I divided by if you will, but the, an infinite amount of possibilities
exist on the front end. So there's not a way to undo the do the the reverse of it if you will. So if I encrypted with five now I'm left with having to decrypt it. But in this case, I'm
gonna use a different key. I'm gonna use a key of 21. Now the key of 21, especially to chosen, it's actually somewhat
mathematically linked to this key because we're using the alphabet as our numerical possible
values, we'll call it. So the idea is if I want to decrypt N I'm gonna use the decryption
key of 21, but again, I can't go backwards 'cause
of asymmetric encryption. So instead I'm actually
going to go forward 21 spaces and you'll see what that'll do is that'll have me loop back to the beginning and then
I'll end up back at H you can actually count out a`nd that's 21 space to send me back at H. And of course I could do that for all the other letters as well. In all cases, I'll end up back at the original starting
message, if you will. So that's an example of
asymmetric encryption. Now what RSA does in particular
is it creates these two mathematically linked keys, but they're commutative in the
sense that they can be used in either direction. I could easily have
done encryption with 21 and decryption with five. Since there's 26 letters, in our example, any two values that
add up to 26 would work for this particular example. Now, every time I mention this, and of course some student
always points out like, oh, what about 13? All right, I get it. You can break the analogy
if you take it far enough. And so what RSA does is it takes, this is actually showing it to you. Cool. What RSA does is it takes one
of these keys and it calls it your public key and it takes the other key and calls it your private key. And what you do with RSA
specifically is you never share your private key, but you
give anybody your public key. And the idea is they
can take that public key and encrypt something. But you're the only one
that has the private key that can simply decrypt it. Now in the real world,
it isn't as simple as, do they add up to 26, of course, 'cause then if you knew one key, you could extract the
other one right away, but that's a simplistic rundown
of asymmetric encryption in what you can do with your RSA. Here, I have two characters, Pam and Jim and, and what they're gonna do
is they're gonna demonstrate how to use public and private keys for the purpose of encrypting. So sending something with
confidentiality across the wire. Now, since these are two different users, they each have to have their
own asymmetric key pair. So Jim has these red keys and then Pam has these purple keys over here. And then all my slides, all the public keys are solid colors. And then all the correlating, private keys are the same colors, but l they're kinda (indistinct)
out in internally, whatever. So a little darker. So if Jim wants to send
something securely to Pam, what Jim will do is it'll create a message take Pam's public key, and then encrypt that message
with Pam's public key. Now the only key in the
world that can decrypt this, that can turn this back into
the original message is whoever has the private key, which
in theory is only Pam. So we're safe to put that on the wire, knowing that only Pam has the private key and only Pam can actually
undo that operation to extract the original message. So this is how the public and
private keys are used for what they call confidentiality
making or that no one else only the intended recipient can
see what was put on the wire. - So dumb question. How did she get those keys? Is that command that you
typed in that Lenux terminal? Is that right?
- Absolutely. - She types that command, she generates a public and private key and they somehow linked see
some crazy maths or something. - Yeah, absolutely.
- Okay, great. - And we can actually,
we can even do them. I have a video where I show the math and we're welcome to do
that together if you wanna- - I think I'm a good,
scared of math, but like, let's ask if you wanna
see the actual math, if you're American or maths
(indistinct) from the UK, have you got a link, sorry video Ed is that we can link it below yeah. - I'll put a link in the description. I'll make sure in there, but you can actually see the math of both RSA and Diffie-Hellman. This is doing encryption
with public and private keys, but there's actually
something else you can do with public and private keys. And that actually I'll show it to you, then I'll tell you what it is. So here's the something else. Let's say, Pam now has a message that she wants to send to Jim. But let's just say for
the sake of this message, Pam doesn't care who can read the message, but she does care that no
one can change the message. She wants to make sure
that no one can change this message that only that, that Jim knows who's
definitely Pam that sent it and no one can change it. What Pam can do is what she
can do is encrypt that message with her private key. Now the only key in the world
that can decrypt this message into the original value is
the public key, which Jim has. But of course, so does
everybody else in the world, everybody has her public key. If Jim is able to decrypt
something with Pam's public key to extract something that
looks like a message, and isn't just random garbled
data or whatever the case, this proves to Jim, that Pam, or rather only whoever had the private key could have encrypted that message. And therefore the message
was definitely sent from Pam that gives us authentication and it wasn't modified in transit and that gives us integrity. - So just to summarize, I wanna send something to
you that only you can read, I would encrypt it with
your public key, right? If you wanna send something
to me that only I can read, you would encrypt it with my public key. You know my public key because
it's public, that's the name everyone has that, so you have that key. So you would encrypt
it with my public key. And I'm the only one with my private key. So I'm the only one that
can decrypt it, yeah. - Correct. Absolutely. - You let's say you wanna, you wanna send me something
and I need to know that it came from you and not someone
else you would encrypt it with your private key. And I would it with your public key, 'cause I once again have
your public key, but you, the only one who has your private key. So I know it has to
come have come from you. - Absolutely, and that process, what we just outlined and
what you just reviewed is what's known as signatures. Now I'll do a quick little caveat. It doesn't work exactly
as we just described it because of the way asymmetric can work, asymmetric encryption works, you can't asymmetrically
encrypt any content. So what you first do is a
actually hash the content to kind of make it smaller, easier to work with and in
something in a repeatable, more consistent size. But for now in so far as
just defining signatures, that's probably sufficient as an analogy. Okay, so where we've kind of picked up the slide that kind of started SSL/TLS has three goals, confidentiality, integrity, authentication. We need symmetric and and
MAC for these two things. And to get the secret key
that is required for those two things, we need to do a key exchange. And what authentication does
it proves that we're doing a key exchange with a person
we mean to be doing the key exchange with. In fact, what a certificate
is, it really all does, is it ties a particular
set of asymmetric keys to an identity that that's
all a certificate is. It's some sort of certificate
authority saying, hey, whoever owns this certificate is really, you know, blue.com or eddie.com or DavidBombal.com or whatever the case. These are all concepts, but there are specific protocols
you can use to actually do each of those things. So we mentioned some
of them confidentiality could be triple DES, AES, DES RC4 integrity or specific. Hashing algorithms could be
MD5, SHA1, et cetera, et cetera. And authentication is
done via certificates and the key exchange can be
done with RSA or Diffie-Hellman. What Cipher Suite is and
what a client and a server, when they're doing SSL with each other, they have to decide upon using
a particular Cipher Suite. And a Cipher Suite is an explicit
definition of the protocol we're gonna use for key exchange, for instance, Diffie-Hellman. And the protocol we're gonna
use for authentication, for instance, RSA, and the protocol we're
gonna use for encryption, for instance, AES and
hashing, et cetera, et cetera. So the Cipher Suite is actually how the client and server are gonna choose the specific protocols
that are gonna do all these other concepts
with kind of highlighted. And with that in mind, we can now get into the
actual SSL handshake. So I'm excited, let's do this. So let me set the scene if you will. So here we have a client
I'm gonna refer to this as the client, but it
isn't necessarily the user. It it's the software that's
actually making the SSL request. Most of the time, this is gonna be the actual web browser so Chrome, Firefox, Safari, Internet Explorer, et cetera, et cetera. If you use an SSL VPN, then it's gonna be whatever
you use as your SSL VPN client, whether it's Cisco AnyConnect or like NordVPNor any of those SSL that's all contained in
a category of the client. On the other side, we have the server. And I think in my slides,
I call the server blue.com. So if you hear me say blue.com, that's just the server that
is hosting the website, blue.com. The server has a certificate
proving the identity of blue.com. This certificate actually says, hey, whoever owns this blue key, or really the private key that
correlates to this public key is really blue.com. That's the purpose of the certificate. And the certificate is signed
by a certificate authority, which we haven't talked
about, but that's , the entity that gives out
certificates, just like, your state or your government
gives you a driver's license or identification card, same thing. The CA gives out these certificates. Now for these two to
do SSL with each other, they're going to have to keep
track of a lot of information and exchange a lot of information. And I'm gonna outline all the
information they have and know in these green and blue
boxes on your screen, we are gonna step through it. And at the end, the goal is for us to have created the session keys, which is the actual keys that
are going to be encrypting and protecting the data on the wire. So those are essentially the of keys. If I were trying to brute
force a particular connection, it's the session keys that
I'm trying to brute force. So those are the keys that are actually protecting everything. To begin before anything
was ever sent on the wire. A server already has some
pieces of information. It has its certificate,
it has its public key, which is actually inside the certificate. And of course it has its private key. So this happened before
the client ever showed up, the server already has
acquired its certificate. Now, the first thing that
happens is the client is going to send a Client Hello. This is the first
message in a TLS session. It's essentially how
we start a TLS session. Inside this Client Hello
are a few important pieces of information that
we're going to highlight. First, you have the version number, in the version number field
SSL is going to tell you, or rather the Client is going to indicate the highest version of SSL
that the client supports. So as you know there have
been many different versions of SSL throughout the years. You've got TLS version 1.0, 1.1, 1.2 and the most modern 1.3. In this field of the Client Hello, the Client is saying, hey, the highest version I support
is let's just say TLS 1.2. Then the Client also
includes a random number. This random number is
32 bytes of random data. Some implementations will
actually include the, a timestamp in the first four
bytes, but that's optional it doesn't have to be that way. We can just simply consider
this as 32 bytes of random data. This random number will actually
be used in the calculation. That'll create the session keys
later when we'll get there. Then the Client sends a session ID. We don't really need to go into that. Now the session IDs involved
in session resumption for now just assume this is a field. What this is going to be used is a value used to identify a
particular set of session keys. And then finally the Cipher Suite list. So in this field, the Client
is providing a list of all the different snipers
that the Client supports. The intent is for the server
to pick from this list. This way, they're both doing
what they're willing to do. The Client's like, hey, I can do all this and
the server's like, cool I want this one. - So that would be like
Triple DES or something as an example.
- Yep, absolutely. - Okay.
- Absolutely. And I'll show you we'll jump on a packet capture minute and actually show you each of these fields, cool. And then there's also some extensions. What we're gonna be going through is what I'll call like the basic kind of default version of SSL. There's lots of extensions
that have been added to SSL over the years, but we're not gonna go into
'em in this set of slides. The Client sends the Client Hello, which includes these piece of information. In response, the server is
going to send the Server Hello, and the Server Hello actually
has the same five fields. It's it's got a few more
than that, but for now, we'll just leave it to these five fields. In the version number from the server, it's the server's highest version of SSL. So if the client was like, hey, the highest I can do is TLS 1.2. And the server's like,
hey, I can do TLS 1.3. They now both know that the
highest mutually accepted version is TLS 1.2 and they'll
continue with that version. It's the negotiation for always doing the most secure version that they can. Then the server sends a random number, and again, it's same thing, 32 bytes random number
generated by the server. The server sends a session ID. Again, we're not gonna
talk too much about that. That has to do with session resumption. And then the Cipher Suites, the server picks from the
list sent by the Client, which Cipher that it wants to do. And finally, also
includes some extensions. Those are the first two
messages of the SSL handshake. And this happens every time
you browse to a website that, you're browsing to with HTPs or whatever they do this Client
Hello and Server Hello. At the end of the Client and Server Hello, both the client and the
server have acquired new pieces of information. First they've both acquired
the highest mutually supported of SSL that they both support. Then they've both acquired
both random numbers, right? So it's two different random numbers. One generated by the Client, one generated by the Server
and both at this point, have these random numbers. Now for the record, all of
this is sent in clear text. So if there was a bad guy
on the wire listening in, they would also know everything
that was sent at this point, everything is sent in clear text. The Client and Server also know that, know the session ID they're
gonna use for this session. And then they also have
a selected Cipher Suite. So that's the results of the first two messages
in an SSL handshake. What I'm going to do now
is jump onto Wireshark and actually show these to you. This way it isn't just me
telling you these things. So what you're looking at
here is a particular packet capture of an SSL negotiation that I did at some point in the past. In previous videos, actually, you've done some fun Wireshark food with Chris Greer, of packet pioneers. And those are some really fun videos. If you guys haven't checked
those out, definitely do. So what I'm gonna do to
start is simply type in the TLS filter into the filter box, and that's just going to
limit the packet capture to only showing me the TLS packets. I could also type SSL,
it also would've worked, but that's the deprecated version of TLS. In any case, what you
see here is essentially the first two messages, the Client and Server Hello, and then all the other
messages that we haven't gone to yet in the slides
but we will, I promise. What I want to draw your attention to is the Client and the Server Hello. And so if we come down here, we've got the layer two header
layer, three header layer, four header, right? This conversation is happening over TCP. And then in here is the actual SSL header, the TLS center in this case. And if we expand that, we can see that this was
indeed a Client Hello. And then inside this Client Hello is all the pieces of information
that we talked about. So there are five fields that we unpacked in the Client Hello. The first one is right here, the highest version
supported by the Client. The Client is telling us
that it can do a TLS 1.2. Then we have the random number. This is the actual random
number sent by the Client. And this is going to be used to generate Session Keys later on. Then you have the session ID, which we kind of briefly looked over. Here we have the Cipher Suites and you'll see that 17 of them are sent. And if I expand this list, this is the actual protocols
that are gonna be doing the key exchange range and authentication and symmetric encryption, and all that. You can see AES-128 is a
common encryption AES-256, symmetric encryption SHA and SHA-256. Those are all hashing
algorithms for use in HMAC. And then you've got Diffie-Hellman and you've got RSA for key exchange and authentication over there. And then the Server's gonna
pick from this list, right? And we can actually look
at the Server Hello, in a minute to which one that it picked. And then the last thing
was the extensions. And you see down in here, these are all the extensions
included, which again, we're not gonna unpack
in detail at this point, but we could in another session. It's interesting, right because there's so much that goes on in the first, like second of you browsing to a website that it's fun to kind of go
through and recognize like, wow, there is so much more to it than just a little padlock appears in any case. This is why I'm getting all excited
and nerding out on this. So that's the Client Hello. And then the next thing sent over here by the server is the Server Hello. Now, if I go up to the
top, you'll see that this one packet actually
included a few pieces of information the Server Hello, which we're about to explore, but also the next two
things in the conversation. Now we haven't shown these
to you in the slides yet. We'll go back and show 'em to you, but you'll see that those
that is like a foreshadowing of what's coming next. In any case, the thing that's interesting
for us is the Server Hello. And if we expand this,
we can see that inside the Server Hello was
essentially the same fields. This is the highest version
supported by the server. In this case, TLS 1.2
random number generated by the server and again this is different from
the client random number. In fact, look at the
first four letters 11af. And if we go back to the Client Hello, you'll see the random numbers
completely different 8377 or whatever the case. So two different random numbers I wanna make sure we highlight that. Then you have the session ID, which again, session resumption. And then here you see
the selected Cipher Suite that the Server chose. So it's RSA for both key
exchange and authentication AES-128 for encryption,
technically AES-128 CBC for encryption, and then
SHAW-256 for passion. CBC, that stands for
Cipher Block Chaining. It's a way of doing well, again, depends how much detail
you wanna get into. - Just gives us a quick over there. - Yeah, sure. So AES is what they call a block Cipher. Now what it does is it
takes, if you have a message, it takes it and breaks it up into blocks. And it encrypts one block
based upon the Cipher text of the block prior, it essentially changes the
Ciphers from block to block. That way if there's something that changes in the message way early on, it changes all the way down. And that's intentional to avoid what's what's called
rather intentional to avoid if I send the same sentence twice in, if you just did block encryption, the same sentence twice would look the same on the wire encrypted. And you can use that to do what it takes to figure out what that
sentence might have been. But with block chaining the sentence here might be identical
to the sentence down here, but since other stuff happened
before and after either of those, they're gonna look
different on the wire. So that's one way of doing
block encryption, CBC. - So, question for the audience, as you can probably
see Ed is holding back. There's a lot more, let us know what you wanna learn more. How deep do you want Ed to go? 'Cause I'm kind of pulling
him back about not going too, too deep and scaring us all. Let's move along Ed. They can give us, audience can give us can put comments below. Let us know if we need to go deeper. - I almost hold back to some slides for CBC because you asked, but I was restrained
wisely so by David so cool. So that's the Cipher that
was selected by the Client. So if we jump back to the client, you, we can actually find this
guy in the list somewhere. So the Client sent a bunch in
the list and the Server was like, okay, of this list. This is the one that I wanna do. And let's continue using that guy. And of course the Client
sends its extensions as well. That's the on the wire version of what we just did right here. Again, this is just
the first two messages. So we have a few more mess
I think, nine total messages in the entire sequence. Any questions on this so far, you think this is. - I think it, the audience
must just put questions below. You know, if there's things
that you are not happy with it, it'd be great if you could come back and like answer a bunch of questions or perhaps go deep, deep on like certain pieces that people
are struggling with, but I'm keen to get through this. - Okay. So let's press on. The next thing that's going to be sent is gonna be sent by the server. And it's gonna be the actual certificate. Now you saw this in the packet capture, but as you can guess in
the certificate message, the server is going to be
sending the actual certificate. Now it's sending more
than just the certificate it's sending the full certificate chains. The idea there is it's the certificate plus the certificate of
whoever issued the certificate. So it's a series of certificates
that go all the way back to whoever issued the certificate. For now all we need to know is this is where the certificate was sent. - Like Verisign, sorry to interrupt. - Yeah, exactly. Verisign, Let's Encrypt, DigiCert, Comodo there's hundreds of CAS that can generate those certs absolutely. So inside this certificate
is a public key. And so after having
received the certificate from the server, the client now acquires two
new pieces of information. So the certificate itself course, and then the included
public key of the server. Again, the client doesn't have public and private keys in this case, that's just the server that has
public and private keys. So that's the certificate message. And then the next thing
sent also by the server is the Server Hello Done. The purpose of this message nothing's actually
included in this message, but there's different
versions of the handshake, which involves the server sending more piece of information. And so the client can
infer that we're not doing those different versions
because the Server Hello Done followed the certificate message. So that's kind of saying, this is all the servers meaning to send the next message is intended
to come from the client. And so to show that to you notice here in one packet on Wireshark, the server sent all three of
those what's called records. The Server Hello which we talked about the certificate record, and then of course the Server Hello Done. So this is the certificate
record right here in Wireshark. And if you look inside of it, we can expand the certificate section. And this is actually telling you two certificates were included. Remember I told you the
full chain was included. So if I expand both of those and the sign certificate section, and I look at the subject field
in both of these right here, you can see that the first, the subject of the first
certificate was blue.com. Remember I told you the
server was for, you know, fictitious server that I invented for a website for blue.com. Then the certificate
authority down in here was the orange CA which again is something fictitious that I created for the sake of this course
to kind of pick apart all the different things
happening with SSL. And then inside the Server Hello Done notice the length that
header itself is really zero. It's just the indication that, hey, that's all I'm sending for now, the next thing that needs to be sent is going to be from the Client. So that's the Server Hello Done again to indicate nothing was sent
at this time nothing more. All right, the next message and this is actually a
very important message. The next message is sent by the Client it's called the Client Key Exchange. In this message the client is gonna send a very important piece of information and that piece of information
is gonna serve two purposes. First, we're going to use
that piece of information to establish what's called
keying material or a SEED Value. And the idea there is
asymmetric Math is hard, right? It's harder than symmetric math, but we need to do asymmetric
math to do a key exchange. And the idea is we're only going
to do the key exchange once to create the SEED Value. And then from that SEED Value, we're gonna generate a
bunch of symmetric keys. The benefit at is we can
generate as many keys as we want very easily, but we only
have to do the hard work. The asymmetric math wants
to do this key exchange. That's the idea behind that. And then the other goal of
this message is to prove that the server is the true
owner of the certificate. Now, remember certificates
are public knowledge, right? If I go to google.com, I
have Google certificate. If I go to bing.com,
Microsoft.com, I have, you know, Microsoft certificates. So anybody can get anybody's certificate. I could very easily get Google
certificate and send it to you and be like, hey,
look, David, I'm Google I'm the actual Google, check it out and you'll
get Google's certificate. You'll get Google's public key, but there's something else you
need to do to make sure that I am the true owner of that certificate, which in Google's case, I'm clearly not. But that's, what's going to happen with this Client Key Exchange. Both of these things are
gonna be done with this really special value known as
the Pre Master Secret. So let's talk about how
that's put together. Now, I'll quickly throw this disclaimer, we're about to show you how
the Pre Master Secret Exchange using RSA as a key exchange. There is another type of
key exchange Diffie-Hellman which does it a little different, but it's still going
to produce this value, a value known as the Pre Master Secret, which will be used for these two things. So quick little caveat we're doing RSA. - And that tends to be the
most common, is that right? - It is for now. So TLS one, it is considered the less
secure of the two options. TLS 1.3 actually does away
with RSA as a key exchange. So it is for now probably
the most common still I'd have to actually look at the stats, but it's only a matter of time before Diffie-Hellman takes over and becomes much more common. So it is also more, more secure to do with Diffie-Hellman. And we can explore the intricacies of why after- - It gets deeper and deeper. We'll start with on, yeah. - Okay, cool. So client key exchange So the way RSA does this, Pre Master Secret is the client
is gonna randomly generate a Pre Master Secret. The Pre Master Secret is 48 total bytes. Some implementations will
encode the TLS version and the first two btyes
that's optional doesn't have to happen. So for us, we'll just say the client is going to randomly generate 48 bytes. Obviously the client knows what
it just randomly generated. So we're gonna add this
to the list of things that the client has,
but notice on the wire it's circled in red, that's an indication that
this value is actually sent encrypted and it's encrypted
with a servers public key, which the client has
because the client acquired the server certificate, which included the public
key earlier in the exchange. So as we unpacked earlier, when we did public and private keys, the only person in the world
that can take this encrypted value and extract the
unencrypted Pre Master Secret would be whoever has the
correlating private key, which luckily our server does. So our server is able to
decrypt this value using the server private key. And now both parties have the
exact same Pre Master Secret and it was shared securely. So on the wire, this is all
that you could have captured, but it doesn't mean anything to you unless you have that private key. Now that both parties
have a Pre Master Secret they're going to turn
that Pre Master Secret into the Master Secret. And that Master Secret is what's going to actually generate the session keys. And so let's talk about how that's done. First, we're gonna take
the Pre Master Secret and turn it into the Master Secret. To do that, we're gonna
take the Pre Master Secret and combine it with other value. Those other values are first, the literal string Master Secret. Like literally those
letters that's in the RFC. If you look it up, it's literally combined
it with those letters. - Someone was drinking
something good when they came up with that RFC. - Yeah, no kidding you're right. And then you'll see the
ne there's another place where the word is used again. And you'll see, it's like, oh yeah, of course that, that's what you used. And then both random
numbers that were exchange in the Client Hello and the Server Hello. And again, all four of
these are gonna be combined with something like a hashing algorithm and that's going to
create a Master Secret. So the result of combining
these creates a Master Secret. And if you look at kinda
what both parties have, both parties have the random numbers, both parties know the RFC, right? If they're implementing SSL/TLS
hopefully they know the RFC. So they know that word
and both parties have the Pre Master Secret. Therefore, both parties are able to put together the Master Secret. Only whoever had the private key is able to do this because this was the value that started it all. And the only people that
have the unencrypted version of the Pre Master Secret are
the Client and the Server. Now the Master Secret is then
what's actually turned into these session keys. And that's done by
combining the Master Secret with a few other values. Those other values are, again, literally the words, key expansion. And then again, the same Client and Server that we used before. So these four are we
combined to create four keys. First, a client symmetric, encryption key, and a client HMAC key and second, a server encryption key,
and a server HMAC key. Since both parties had
all of these information, both parties are able to
generate all four of these keys and they're the identical keys because they all started with th
exact same information. Now here's the thing that's
often overlooked with SSL I think this is super, super cool. You'll often see people say, SSL will generate a secure tunnel, but it isn't that SSL
generates a secure tunnel. SSL actually generates two secure tunnels. The way it works is the
tunnels are uni directional. Anything that the Client wants to send. And so far as application data
or HTTP content or whatever it's trying to send
through the SSL tunnel. The client is going to
use this set of keys to encrypt and verify the
integrity of that information. So essentially it's like
sending that information through this tunnel. The server who also has an
identical copy of those keys will use those keys to de encrypt
and verify the integrity of so it'll be secured with this
set of keys and then unsecured with the exact same set of keys. But these set of keys are
protecting the data from what I'll call from left to
right client to server. On the other side, if the server is sending
something to the client, the server is going to encrypt
and secure the data using this set of keys and the
client will unsecure it using the exact same set of keys. The benefit there is, let's just say that the
client and the server send the same word to each other. Let's say they send the
word apple to each other. Well, since I'm using one set of keys from client to server on the wire, that's going to look different encrypted than when the server sends
the same word encrypted with a different set of keys. So that's where the two
tunnels come into place. - The server and the client
keys are different, yeah? - Absolutely. - But if you let's say you're the server, you encrypt it with your server keys, I've got the client keys, I can
decrypt your encrypted data, even though the keys are different, yeah. - No, 'cause these are symmetric keys. So I'm glad you asked that. So if I encrypt something with these keys, these are the only keys in
the world that can decrypt it. - Okay. - But both parties have both sets of keys. - Oh, I see so you encrypt, You encrypted with a server key and then I decrypted with a server key.
- Exactly. - If you are the server
and if I send it to you, I encrypted with a client
key and you decrypted with the same client key 'cause it's symmetric encryption. - Yeah.
- Okay, great. I wasn't sure about that. - A hundred percent yeah. No, I'm so glad you asked. The idea from a security
standpoint of why that's there. If someone's trying to brute force keys, these are the keys they're
trying to brute force. And so sitting aside
the difficulty of that, if someone does actually
attain brute forcing one sets one set of keys at best, they're only going to decrypt
the content in one direction. So they're only gonna get
half the conversation. So that's and. - The encryption could
be Triple DES, sorry. And then the HMAC could be SHA that- - Absolutely. In fact, we're using kind of a, a fun little illustration for keys, but let's just say way back
in the Cipher Suite section that we decided that
we're gonna use AES-128. Well, what means is that
for this encryption key, we needed 128 bytes. And then for this encryption key, we needed another 128 bytes to create both those separate keys. And let's just say for hashing, we decided we're gonna
use SHA-256 for our HMAC which the HMAC also
requires the same key size as the hash digest. So I'll need 256 bytes for this key. And then another 256 for this key. So in total, the result of combining these four things needs to get me 128 plus 128 plus 256 plus 256. I believe that's 768 if
I did the math, right. 768 bytes worth of keys. You might ask, how does combining these same four things produce 768 bytes or however many bytes I
actually need of keys? Well, the answer is that
these aren't combined in what's with a hashing
algorithm necessarily. They're combined with something
like a hashing algorithm. I'll explain that next. So this not only creates these keys it also creates any additional
key material that might be needed or instance, CBC Ciphers need, what's known as an IV or
an initialization vector to kind of kick off the process. And we can unpack that in more detail, but this is actually the
combination of things that actually creates those IVs as well. But the reason these four
things can create any amount of bytes we need is that we're not using a hashing
algorithm for these. We're using, what's known as a PRF or a Pseudo Random Function. PRF is sort of like a hashing algorithm, except the result is not
rather, it can create as many, a digest length as long as you want. And so what happens is
the client and the server, they know how many bytes of keys they need because of the Cipher Suite, right? So they know they're
doing AES-128 and SHA-256. And what they do is they say, hey, we're gonna combine these
four things using a PRF until we have generated 768
bytes or however much they need, but just like a hashing algorithm. If you start with the exact four values, you're gonna end with the same sequence of in this case, 768 bytes. So this is how they know that
they both end up on the same keys with the same starting point. - Something I was just thinking about. So they use Master Secret key expansion, client random, server random
to come up with four pieces, four keys here. - Correct, four or more? Yeah. - Okay. - Now a few weeks ago, a few
months ago, I don't know. I'm not good at timelines, but you did a video with, with Chris where you decrypted an
SSL handshake and where you told the client to
log the session keys to a particular file or whatever. And then you used those
session keys to apply in Wireshark to decrypt the
content of the SSL handshake in the SSL conversation. Well, what that session key rather, what that logging was
doing was either logging these four or logging this
and Wireshark was doing the calculation again,
or logging this value. And a Wireshark was doing
this calculation again. One way or another, if
you have any of these, anybody can redo the calculation
to acquire the session keys that are actually going
to protect and decrypt the data on the wire. - So the Pre Master Secret is what you really want to keep secret, really. - Correct, any of these,
if you have any of these, you can extract all the keys. - That what you're saying. - We back up a quick second. This Pre Master Secret was
shared on the wire encrypted using the servers public key. And the only reason the server
was able to extract it is because the server had the private key. In the packet capture that I have it's actually one of the packet
captures we used in the lab one of the labs for my course, I actually give you
the server private key. So you can then decrypt it after the fact so that on the wire, you can
see the Pre Master Secret, not the encrypted form, but
the actual decrypted form. And then Wireshak can
redo all this math again to generate the session keys and decrypt the content after the fact. And we're actually gonna
do that in a minute, but we haven't finished
the handshake quite yet. Any questions so far, anything
I need to unpack more? - Yeah I'm barely hanging on,
but question for the audience, how you doing? If you're struggling with any
piece of this, let us know Ed, and then we'll get you
back for more detail. - For sure I'd be happy to do it. So that's where we are in the slide. So this is kind of everything
that's happened so far. Client Hello, Server Hello, Certificate Server Hello Done, client key exchange. Now to quickly show you
that in the actual Wireshark capture, if we expand this box over here, this is the client key
exchange right here. - I just need to ask you this. Do you do live training as
well on this kind of stuff? It's so someone was like really
struggling and they wanted to like have in class or remote training. Do you do that kind of thing? - I totally would. I haven't a while actually I
stopped doing live training since COVID, but I'd be
happy to pick that up, pick that back up for sure. Or do live virtual courses for sure. - Yeah, 'cause I think
some peopl well, I mean, it's question for everyone watching, if you have like a group of you that want to do live training, then yeah. Please, ask Ed about it because yes. You know, sometimes it's
nice to have an instructor, but in your class, in
your recorded course, you kind of work through
this don't you and you have , the P caps and stuff people can download. - Great.
- Yep. And the course is much
much more methodical about what I introduce when and when, where, so we start
way, way mini layers back. Such that when we get to this part, there's less kind of
side that you have to do. And I'm also I have a private
discord for my students that, that I interact with as well. - Okay, great. - This course, and really this
whole thing really started as a enterprise training effort. It was, I used to work for
a company in Texas Rackspace and they had tasked me out to teach their engineers to do SSL. And that's kinda how I
dive deep into all this and created a lot of, at least learned a lot of
the knowledge to teach them. And, then since then that
was like seven years ago or eight years ago more actually. But in any case since then, I've put together as a self-paced course that anybody can get to so. - Correct, sorry I took
you an attention again. So now we had client key exchange. - Yeah. Okay. Exactly. So we're at client key exchange. And so this is the client key change, and you'll notice inside
the client key change there's your Pre Master Secret. Now this is the encrypted
Pre Master Secret. So anybody can take this
value, this super long value, and you notice the dot, dot,
dot at the end over here. Anybody can take that in decrypted with the private the key
associated to my server to extract the actual Pre Master Secret. And we're gonna have Wireshark do this for us in a few minutes. But, first we have to
finish the handshake, the rest of the handshake. So the core of what I wanted to get to was how these session keys are derived. And at this point we've done that we've shown you the math
and all the different values that go into how those
session keys are derived. What I want to do next says
quickly finish the handshake. So I'm gonna go a little
faster for the rest just to kind of get to the end so we can go to actually
playing with decrypting, all this in Wireshark. So the rest of the handshake, is really about two things. At this point, both parties
have identical session keys, but they don't know that each
other have the same keys. Again, if I gave you Google
certificate, it was like, hey, I'm Google, I can send
you Google certificate. I can send you a Server Hello Done. And you can send this and
then do all this math. But you have no idea that I
was able to do the same thing, If I was giving you Google certificate, obviously I couldn't cause I don't have Google's private key. So at this point in the handshake, they have to prove to each other that they have identical keys. And that's what happens in the rest of the handshake essentially. And that's done using a two messages. First, the client sends the change Cipher spec message that just says, I have everything I need
to start speaking securely, everything I send going
forward is gonna be encrypted. And then the client sends
the finished record. And inside the finished record is a very special piece of information, which I'm gonna call the
encrypted verification. And the way this is put together,
I think is pretty clever. But what it's going to do is both prove that the client has the right keys, but also prove that
nothing has been messed with insofar as a negotiation. So let me show you how
that is put together. What happens is the client is
going to calculate a hash of all the handshake records seen so far. And so if we pull back down our handshake, we've got the Client Hello
1, Server Hello, 2, 3, 4, 5. 'Cause again, we're talking
about how to put together this. So this hasn't actually
been sent just yet. So there's five records
that have been sent so far and the client's gonna
take all of these five and create a hash on the content of all of those of everything was seen on the wire. Now the purpose of this,
it's actually very clever. Remember in the first
message, the Client Hello, and the Server Hello. The client and the server sent Ciphers that they like and versions of SSL that they can support. Well, let's just say, I'm a bad guy in the middle and I know I can't break TLS 1.3 or TLS 1.2, but I can break TLS 1.0. What if I just take that
Client Hello message. and I change it sand I say, hey, the highest you can support is TLS 1.0, that might trick the server into doing a worse version of SSL than they both mutually support, but doing this handshake
hash essentially validates that the client and the server saw the same client and server Hellos preventing what's called downgrade attacks on this particular session. Client puts together this hash, the server is able to put
together the exact same hash 'cause the server in theory
saw the exact same records. That hash is then combined
with a few other values Master Secret, Client
Finished and of course the handshake hash and that
creates verification data. And that verification data is
encrypted with one of the sets of keys in this case,
the client session keys. That is what's actually
sent across the wire. That's how this piece
of information is sent. And so that's sent across
the wire and in theory, as long as the server has
seen the exact same hash seen the exact same records
as the same Master Secret, which the server only has if
the server had the private key. Puts together the same verification data decrypt
this content and validates the the exact same encrypted verification. So if this checks out, this proves to the server
that the client must have had the correct client session keys. - My concern is the client still hasn't checked that the server is Google. - Bingo, a hundred percent. I'm so glad you pulled that out. So at this point we've
done it in one direction. The server knows that
the client checks out, but nothing has actually been sent from the server yet for the client. And so that's what happens next. And it's not, it's at the
exact same two messages, but this time sent from the
server and it's put together essentially the same way the
server is going to send the Change Cipher Spec saying, hey, I've got everything you
need to speak securely. The server puts together
the finished message. And then the encrypted
verification from the servers perspective is also put
together the exact same way. It's gonna calculate a hash of all the handshake records seen so far. And again, this time a few
more records are involved because at this point in the conversation we've added one more handshake record. And so we should see six
of them, Client Hello Server Hello, Certificate
Done, Server Hello Done Client Key Exchange and Finished. So all those are hashed together. Now the reason Change
Cipher Spec isn't included is those are handshake records. Records are the types of packet that SSL and TLS uses and change Ciphers Spec is not a handshake record. So it's not included in any case. The server at this point is
able to put together the hash of all this in the same way, combines that hash with a few
pieces of information known only to the client server to
create the verification data, encrypts the verification data
with the server session keys. And then if that checks
out and then again, that's sent from server to client. And if the client is able to
validate this information, this then tells the client
that the server has the correct session keys and therefore
had the Master Secret and therefore had the Pre Master Secret and therefore had the private key. And therefore is indeed the
true owner of that certificate. - That's cool. - As we pull back all the
layers and at this point, there's really nothing further
to do other than actually send application data to each other, protecting that application
data with the session keys derived for this particular session. - I'm gonna have to watch this again, Ed. Oh, no, that's great. I'll go through this again. Yeah, that that's brilliant. So that's what you started with initially. That was the first slide you said, this is what we're gonna cover and that's what we've done now yeah. - Yeah, absolutely. - But how (indistinct) in Wireshark. - Yeah. Okay, so Wireshark next. Okay, so we just walked through the handshake using the slides. And now I wanna show 'em
to you using Wireshark. And what I wanna do is show you the pieces that we talked about, but then also we'll go a step
further and actually decrypt everything because I happened
to have the private key that was used on the server for
this particular capture. So here you can again see the the records going back and forth. You've got the Client Hello here, the Server Hello sent by the server, the Certificate message,
the Server Hello Done. Just as we unpacked in the slides, then you've got the client key exchange. This is the one where we showed you where the Pre Master Secret was. And then the Change Cipher Spec and then you've got this, what's called the encrypted
handshake message. Now, if we quickly go back to my slides, I didn't call it the
encrypted handshake message. I called it the finished record. Remember I told you everything sent after the Change Cipher Spec is encrypted So Wireshark, knowing
that this is encrypted, doesn't actually know the
content of what that is. It's actually the finished message, but it's encrypted at the moment. You'll see that change when I
apply the private key shortly and then here from the server, you've got the Change
Cipher Spec and again, the encrypted handshake
message once again. You'll see that change
to the finished message once I apply the private key. All of these first four
packets was the handshake. And then in here is the actual
application data transfer. Now you'll see, it's just two packets. It's a simple get request and then a simple webpage being
served by the server. And then afterwards, this is what actually
terminates the session. If we unpack the actual application data, you'll see that you and I, or even Wireshark can't
make any sense of this. Like this is the encrypted
version of the website that is sent in this particular session. What I'm gonna do is I'm
going to give Wireshark, the private key that
correlates to the public key that was used in this handshake. Wireshark will then be able to take that private key and apply it to this Pre Master Secret this
encrypted Pre Master Secret and extract the actual Pre Master Secret from this encrypted version. And then calculate like the session keys, the same way that I just
explained what happened. So to do this, now you did something
similar with Chris earlier. And so we're gonna do
kind of the same thing. So I'm gonna go to protocol
preferences in Wireshark, and then go to the RSA keys list. There's another way you
could also go to it by going to the edit and preferences and protocols. So there's two different ways to get to the same Window. And from here, in fact,
if I remember correctly this is what you did with Chris. As you went to this Window, scrolled down to TLS down
in here and then added e, the debug file I believe over
here or possibly down here, the Pre Master Secret file name. That's one way of doing it, where you give Wireshark
directly the Pre Master Secret. What we're gonna do is
I'm gonna give Wireshark, the RSA private key. So I'm gonna go here, hit the plus button, and then I'm going to
scroll and find on my, the private key. So that right there is the
private key that is associated with this particular packet capture. And again, this would be the private key that only the server has. And since this was my server, I obviously have the private key. I'll click Open, and then
before I click, Okay, I wanna draw your
attention right over here to the right side of my screen. Notice how it says
encrypted handshake message. That's gonna change very slightly, very shortly when I actually hit okay, on either this or the next box. And then the other thing is notice this application data is
also going to change as well. So once I hit, Okay, Wireshark is gonna do the exact same math that we just talked about doing. And therefore it's going to
be able to determine that this is actually a finished message
and not what was before the encrypted handshake verification
or whatever it was called. And then come in here, you see something that looked
much like much more like data that you and I would recognize. If I click this guy over here. And then we go and actually
look at the packet bytes, which are way down in here. This is still showing you
the encrypted content. What I can do now is I can
actually tell Wireshark to follow the TLS stream And you'll see Wireshark is
able to actually extract this into, you know, something
you and I can read. You'll notice that it's a simple
get request from the client and then the actual content of the server is just the a random app. - Wow. Yeah. I mean, it's, it's great
to see the inner workings. 'Cause like you said, in the beginning, all we see as a user, as a padlock and then
we get at the session. - Yeah, and there's so much that goes into it and everything we just, we spent probably the last
hour and change discussing happens in a few milliseconds every time you browse to a website. - So there's two, just that understanding
there's two messages. And then the third message is actually encrypted straight away. So it's only like the two Clients Hello, Server Hello, and then it's
encrypted straight away. - Correct. A part will say a part of the
third message is encrypted. So this client key exchange
itself is encrypted. It includes a value that it's encrypted, but the client key exchange
itself is encrypted. But this third value, the finished record is indeed encrypted. It might be easier to see if we- - And then after that it's
it's encrypted as well. - Correct. Yeah. After that, everything's encrypted. So if I remove the private key, you'll see this finished message. And this guy right here will
go back to what it was before. Cause if I remove this guy or shark, won't know what the content
is and it's just like, hey, this is just something that is
encrypted that I can't really tell the contents of. - What's nice is Chris
did the client key side and you've done the service side. So yours, your examples is different in that you've done you took the server private key. - A lot of times in the
wild when you're operating with a security device, like an IDs or an IPS or a
web web application firewall, what they'll do is they'll
ask you to put your website's private key on the web application
firewall or on the IDS. And what the IDs will do is
exactly what we just did. Just like the server
is able to recalculate the session keys, the IDS in the middle. If it has the server private key will recalculate the
exact same session keys, and decrypt everything in line passively without knowing about it. That's only possible with
RSA as a key exchange. It changes a bit with
Diffie-Hellman but again, I don't know, we can get
into that depth in another- - Yeah, I think we'll
have to do another video. So tell Ed, on your course,
do you cover Diffie-Hellman, do you cover like a lot more
stuff than what I'm assuming the answer is yes than what
we are doing here, yeah. - Yeah, so we cover Diffie-Hellman. We cover the the interesting thing of Diffie-Hellman is what's known as forward secrecy. So we explain what that is
and really, I show it to you. I show you a packet capture, in fact, this same packet capture, but also done with a
Diffie-Hellman key exchange. And I show you how, even with a I show you how with a
Diffie-Hellman key exchange, even if I give you the
private key of the server, you still can't decrypt the content. That's because of a property
known as forward secrecy. Or if you've worked in the VPNs days, PFS, Perfect For Secrecy, those are essentially the same thing, but it's a very desirable
cryptographic property that significantly increases
the security of SSL and TLS. It's highly recommended
now in the TLS 1.2 days and required then TLS 1.3 days. - So tell me how do people follow you or get more information? Can you give us your socials? I know you've recently joined Twitter. How can they get a lot more, I mean, I know you got a lot of free
content on your website, so don't, you wanna pull that up and just tell us about about your social, where can
people interact with you? 'Cause I'm pretty sure people are gonna have a lot of questions. - So my website is probably
the easiest to get ahold of me, practicalnetworking.net. I've published a bunch of an information about network engineering,
network security. Actually, David, I feel like I need to give you some congratulations. You just won the Cisco IT Blog Awards for the video category. - And so did you.
- Congratulations. - I did for the blog yeah, I have. Congratulations, David, make sure to you, you celebrate that. Thank you, thank you. So the website practicalnetworking.net. That's that me, I just started on Twitter. I think I have like 10 followers. I literally created the
account like two weeks ago. - So can everyone please
follow Ed on Twitter? Let's get that growing, come on. - YouTube is probably where
I do most of the publishing. I kinda started doing more on YouTube about a year and a half ago. I'm in the middle of working an OSBF Deep Dive Series. So if you're interested in OSBF, but if you want more kind of
crypto and TLS related stuff, I would point you towards this
playlist, which is actually, it's the first two modules
of my course for free. If you jump on this,
it it'll unpack kind of the foundation of what
the course goes into. - Where do you get the course? - Oh yeah the course. - I'll put a link below, I mean, how much is it
and can we give them and, can we give my viewers a
special dea, is that right? - Yeah absolutely. So the, the course to get details about the it's practical.net/tls. If you enter you'll, you'll see the actual kind
of content of the course and some information about
what the course will teach. Normally the course is available for 300 bucks for $297. But for you and your followers, David, we're gonna generate a coupon to make it available for 50 bucks. That that information.
- All right, thank you. - Will be in the to description. - Brilliant. - So enjoy and definitely
come join me in the course. There's a disor that we
can talk through things. And if you have questions, I'm here for you guys as well. - So full disclosure, I will get an affiliate
fee if you do buy that. But you know, if you don't just, you don't wanna gimme affiliate fee I don't mind just go and buy
it directly from Ed's website and support him. Ed, I really thank you for sharing this kind of
knowledge, but that was brilliant. I really enjoyed it, so thanks so much. - This was a blast, I really enjoyed it. Thank you for the opportunity, David. Hopefully we'll get some
more sessions in if, if more questions come in. - Yeah, definitely. Really wanna get you back. So Ed, thanks. (jazz music playing)
