 We've spent some time on key management of how to get secrets between entities. So we know the basics now for most For applying cryptography to secure communications and secure data for example from the start of the semester we've gone through Different approaches for encryption So really we've seen symmetric key encryption and some different algorithms. So both sides use the same key then we went to Public key encryption where we have a public and a private key in a key pair and we can use it in two ways We encrypt with a public key of the receiver for confidentiality We encrypt with a private key of the sender for authentication to sign something and The topic on the previous topic on key distribution was about well How do we get keys to do this encryption and we saw some different approaches? So the challenge is really get a secret key to the other side in Practice we usually use symmetric key encryption to encrypt data Because it's much faster than public key encryption but we can use public key encryption to Encrypt just a small amount and to sign things so encrypting a small amount may be encrypting a secret key that we then use for symmetric key encryption and We arrived at digital certificates is a common way in internet-based systems to to distribute public keys. I Need to know someone's public key if someone just sends it to me I don't trust if it's from them or someone else The way that we do that is we get someone else to to sign that public key as long as I trust them Then that follows that I entrust I trust the public key I receive We'll see some more examples of digital Certificates when we look at web security, which is what we lead to here transport level security Or more generally some really this is a topic. It's some examples of using Some of the cryptographic techniques for internet-based security Transport level means that the transport layer in in our network stack. So the transport layer will see that We use some security mechanisms to encrypt application traffic and one example will spend some time on is web-based Applications, so web security issues and we'll see that to the main way to encrypt web traffic is using something called TLS or SSL. So we'll go through that today In fact HTTPS is really just normal HTTPS using those two previous protocols TLS or SSL and Maybe next week we'll look at secure shell Not for web browsing but to remotely access in computers because you use it a lot or you've used it in labs and Other tasks will see how it works that how it encrypts data But generally about web security or even internet security Most of the protocols which were developed for the internet were developed in the day when everyone trusted everyone That is that was just a few universities and organizations connecting networks together They knew each other. There was no need for security mechanisms. There was no need to encrypt and authenticate Therefore a lot of the internet protocols that we still use were developed with no security in mind There's no encryption inside TCP or IP Even HTTPS has no security mechanisms built in but as of course as the internet grew and people used it for for Commercial transactions different things. There's a need for security so Really extensions were developed of the existing protocols to support the security mechanisms So things to allow us to Authenticate clients and servers to make sure we're talking with the right entity and to encrypt our traffic across the internet there are different approaches for doing it and Essentially the approaches for providing encryption or security You can choose between the different layers in the stack as to where to implement that security and People have come up with different solutions At the network layer We have IP and there's an extension to IP called IP sec IP security That allows for encrypting the IP packets and providing authentication. It's not widely used By end users it's sometimes used in VPNs virtual private networks for transport layer That is TCP especially to encrypt TCP traffic. There was an extension called secure sockets layer SSL and eventually it was Replaced or renamed to be transport layer security TLS. So we'll talk about them But if you don't use IP sec or SSL you may implement the security mechanisms in your own application Maybe you create your own application from remote log in So implement the encryption with that and for example secure shell is one example there Email has its own security mechanisms built in or not built in but that you can add on So you can either do security in the internet at the application layer at the transport layer or at the network layer We will go through at the transport layer mainly With maybe a short example about the application layer with secure shell at the end in the web-based communications and Generally in the internet there are many threats many things that can go wrong and the reasons why we need security mechanisms people can Modify our data they can listen to what we're we're sending they can intercept our packets where they can issue or Make our servers fail. So denial of service attacks They can impersonate other people or forge data the other threats and there are many consequences of those threats The countermeasures the mechanisms we have to try and stop those threats turning into attacks include things like What we say here cryptographic checksums hash functions Mac functions encryption For confidentiality proxies tunnels VPNs tour for confidentiality or anonymous browsing Denial of service Hard to prevent denial of service attacks. So that it's difficult there to have cryptographic mechanisms to prevent them Authentication using the techniques we've talked about public key cryptography digital certificates So again, there are different ways to implement security in the internet really we can differentiate between the network layer security user IP sec It encrypts or secures IP datagrams transport layer security SSL it provides security for TCP packets or application-specific security at the application layer it's only for individual applications that we implement security so We'll only go through mainly secure transport layer security, but the advantages or the differences really are The lower the layer that we implement that security mechanism the more widely it can be applied to all of our data For example application-specific security is only for that individual application Email for example the email security mechanisms. Of course, don't protect our web browsing Transport layer security usually applies just to TCP So it only works for TCP based applications non TCP applications Cannot use SSL or TLS. There are them other mechanisms In practice, it's turned out that the most widely used other the last two transport layer security and application-specific mechanisms IP sec is is used, but maybe not as widely as as the others So we'll focus on them. So let's look at transport layer security and we'll look at it from the perspective of web browsing But in fact transport layer security can be used for other applications It can be used for any application that uses TCP Email uses TCP web browsing uses TCP secure shell does or remote login Database applications use TCP many applications use TCP Normally when they send data across the internet, it's unencrypted SSL adds that encryption to the data sent using TCP IP sec adds even more, but for the IP packet Okay, so we can combine them We can encrypt the TCP segments and then encrypt again the IP datagrams It has the disadvantage of that extra level of encryption of the performance But if we use IP sec it works for you UDP and TCP Doesn't matter if your application is sending UDP packets or TCP packets IP sec applies to both So there's the advantage of IP sec There are some other differences in terms of the how widely available they are and how easy to use they are IP sec generally requires it Some set up by the administrator or by the user of the computer Whereas SSL it's it's transparent to the user the user doesn't have to do much to use it. It's automatic That's why maybe SSL has become more widely used You've used open SSL as a piece of software Open SSL is really was implemented as a library to implement Secure sockets there SSL, so we'll see that as we go through So what is it SSL and TLS? so When there was a strong need for security in web-based communications the normal way that your application uses TCP is a concept called sockets you write your program and and Because TCP is in the operating system what the application developed developer does is they use an API to call TCP to send packets and set up a connection and that API is called the sockets API and Netscape the organization that or that the web browser and the people who developed it Wanted to add some encryption for communications between the web browser and web servers so What they did is they developed a A layer that goes between TCP and your application That does the encryption for you So it still uses TCP and still uses the normal application But it introduces the the security mechanism so it was referred as the secure sockets layer Before that we just use sockets, but if you want a secure connection you use secure sockets SSL SSL went through different versions so version one version two SSL version three is Was Developed by Netscape the organization, but then the standards organization ITF Created an equivalent standard which was called transport layer security the more general name TLS So SSL version three and I think TLS version one effectively the same So that's why sometimes and especially in this course will use both names to refer to the same thing SSL or TLS Commonly used to refer to the same thing So we'll we'll use the old name sometimes sometimes we use the new name But there are different versions So SSL version one is different than TLS version 1.2 So it becomes more complex when you look at the individual versions But for this course when I say SSL, I also mean TLS and vice versa what it does is it provides security services to the application layer that uses TCP and Maybe we've before we look at the more detailed picture will draw our own Normally our applications say a web browser a web browser when it creates a packet The web browser implements the application layer protocol HTTP and the normal operation is that When a HTTP request is created it's sent to TCP Which is then sent to IP and IP datagram is created and then the network interface card sends it across the the network That's the flow of the packet This is your application the browser and HTTP. This is your operating system in your computer and this is the hardware The network interface card. So a simple view of what happens when your web browser creates a request for a web page The graphical user interface allows you to click on the link the browser implements HTTP It creates the get request That is sent to the operating system in particular TCP inside the operating system takes the get request sets up a TCP connection using IP and and so it creates in the TCP segment an IP datagram and Sends it using the network interface card across the network eventually it's received by the web server and and replies come back So that's the layering for example for web browsing this the the API The programming interface that the person who develops a web browser uses to talk to the operating system is refers to as sockets Have you learned sockets? Maybe with dr. Conwood. Maybe not you may see it in some If you develop network-based applications, you will need to use sockets Just the terminology that we're coming across Now nothing's encrypted here So the idea of using TLS is that we'd like to use introducing encryption of our application data, so We have our browser HTTP and then We have this intermediate layer called I'll call it SSL and then TCP IP and The network interface card So the layering When we use SSL We still have our operating system our network hardware and the application here But the application normally uses just HTTP But then it uses the secure sockets layer and the sec secure sockets layer may be Implemented in your in your browser or a library provided by your your operating system an Example here an example implementation that you know of is open SSL Open SSL provides a set of C functions That you can call from your application that does the encryption it implements AS it implements RSA and all the other cryptographic mechanisms so from a layering perspective SSL we introduce a layer between application and transport and What happens is that when you create the HTTP get request Before it's sent to TCP. It's encrypted using SSL and Then the encrypted Information is sent to TCP and sent across the internet and not only encrypts. It also provides the authentication techniques So what we're going to do is look at What SSL does and how it's structured anyone know any other libraries apart from open SSL Does anyone done any development on other systems? I don't know No, there are there are others windows has Yeah, I don't remember the name either windows has one it's called Not PowerShell The the windows sockets layer was called winsock the security layer. I forget the name now secure Something it was Secure something I'll look up the name for windows, but it's equivalent to what open SSL does it allows you the application Programmer to call their implementation of the encryption operations Mac users open SSL in some cases Netscape or Firefox has a separate library. I think generally referred as NSS And there are a couple of other libraries that applications may use So rather than the application developer No, PGP is different not so commonly here, but there is a Couple of variations, but not really a replacement So the idea of these libraries is that they implement a yes RSA and all the encryption mechanisms mechanisms We need you as the application developer don't need to implement them. You just use the library You develop your application that makes use of that library We may return to them after we go through some examples and I'll look up the name of the windows one so SSL is actually broken up into two sub layers so We have IP and TCP This is these two layers a part of SSL and above that not shown in this diagram is the application layer We will use HTTP as the example of the application, but other applications can be used as well It's it's not dependent upon the application Or HTTP is here. Okay, so there are four parts of SSL There's what's called the SSL record protocol This is the thing that encrypts the data and provides message integrity message integrity is checking so the receiver checking that nothing's being modified for example, it uses a Mac function When we send data the record protocol will encrypt that data before it sent and attach a Mac So that the receiver can verify that nothing's being modified. So that's the record protocol But before we can encrypt data we must exchange keys We must Communicate with the other side exchange keys and agree upon parameters. So there's a handshake protocol to do that so Before we send any encrypted data between client and server we do a handshake between client and server We exchange some messages and agree upon how we're going to encrypt So there's the handshake protocol to do that and Negotiates the algorithms to use the keys to use and other parameters that are necessary SSL allows you to use different ciphers to use different algorithms to encrypt and During the initial stage it uses usually some public key algorithms But then to encrypt the data it uses a symmetric key algorithm And in fact during the connection you can change ciphers So there's a way or there's a simple mechanism, which is called the change cipher spec Which says okay, we were using that cipher now. Let's change to the new one and we'll see that in in some of the examples The fourth part is an alert protocol We sit away for the two entities to send special messages to each other Maybe about the status any warnings or errors that have happened For example, I receive a packet that doesn't pass the integrity check the Mac fails Then the alert protocol can be used to send a message back to the client saying I just received a packet and there was an error with that Do something about it? status updates warnings and errors used with the alert protocol We will we will use an example for web browsing to illustrate those protocols in in operation, but before we get to that let's mention some concepts SSL has a concept of a connection and a session TCP has connections only How do we set up a TCP connection? What's the process we use to set up a TCP connection? What's the name three-way handshake sometimes we call it the sin synac act a TCP connection remember with TCP We do that exchange of three messages and then we send data when we finish we finish the connection with a fin message So TCP has a concept of a connection So does SSL and they match so you can think every TCP connection corresponds to an SSL connection but in addition SSL has sessions and We can think a session may contain multiple connections The idea is that between a Client and a server we establish an SSL session agreeing upon some algorithms and some parameters and Maybe we use that for the next five minutes and For every TCP connection that we create between that same browser or same application client and server We may do so within that session and we use the same algorithms and the same parameters So the idea is we negotiate a session at the start Then we may have multiple connections within that session. The idea is that Setting up a session takes some effort. We don't want to do it too often It involves sending multiple packets and it requires some time So the idea is you create one session between client and server and that can contain multiple connections So we'll see that in process through our example Both the client and server store information about those sessions and connections when they're in progress We'll see some examples for example the session may store the certificate being used the secrets and For a connection, maybe we have some random values some nonces some different keys to encrypt and some max and so on We'll see some examples of mention them when we see a specific case the record protocol is the thing that encrypts the data and The process in general is that the application creates data for example a HTTP get request SSL then breaks it into fragments So if our get requests or our data is 5,000 bytes SSL may break that into smaller fragments and that will define some limits on the size of those fragments each fragment May be optionally compressed. We don't have to but we may compress it to save communication costs We attach a Mac Remember a message authentication code is calculated on the data and using a key Remember a Mac function the Mac using some secret key of the data return some short Mac value or tag. It's the similar purpose as a hash function We'll use it at the receiver to verify that the data hasn't been modified. So we calculate a Mac and attach that Then we encrypt all of that Use our encryption algorithm Then we attach a header called the record header and that fragment is sent using TCP across the internet and We do that for each fragment that comes from the application data. So let's have a look an example and We'll see some of those packets and then we'll go through not just the record protocol, but the the Handshake that happens before we can encrypt any data and the example we'll use is for Secure web browsing HTTPS So normally when we access a website For example in the URL HTTP This will use HTTP as the application layer protocol and TCP as the transport protocol Sends a request to the server and the server gets the web page in response There's no security mechanisms used there to use secure sockets layer Rather than HTTP. We use what HTTPS Okay, I think you use this on a regular basis or you've seen it That tells my browser Don't just use HTTP, but use HTTP combined with the secure sockets layer That's what the secure version of HTTP is HTTPS is not really another protocol is just say use the normal HTTP a get request receive the response but use the secure sockets layer to encrypt everything and we get the same web page back and If we observe the packets which are sent in this case We'll see that SSL is used or or more precisely TLS is used to exchange those packets. So I have I have captured this I've actually captured it before and we'll see those packets and see what happens from when I press enter Until I get the web page come back when I use normal HTTP no s How would we draw the packets that are sent? Let's quickly draw what would be sent with normal HTTP without looking at the capture with normal HTTP we To connect to a web server we first establish a connection with TCP This is the TCP connection establishment procedure since in act that connects from our browser to server and Then we send the HTTP get request There may be a TCP act that comes back that depends on the scenario and Eventually the the response in a simple case Maybe a final act or not draw up, but we may later close the connection with TCP using the fin messages So this is just a reminder what you already know of when we use TCP we set up a connection with sin sin act With TCP data It's can be sent after the act. So here the green packet is Actually TCP data. What is the data? It's a HTTP get request It's received by the web server and TCP may send an act saying thank you for the data and eventually the web server sends some data back The data in this case is the response say the web page there may be a final TCP act saying thank you for the data and Later, we may close the connection the closing is usually a fin and an act that comes back from both directions That's from the TCP perspective So that's using HTTP with a browser to server. We want to see what happens when we use HTTPS More precisely using HTTP over SSL Any questions on the TCP operation or on normal HTTP because you need to be aware of that to see what happens with HTTPS You know all this from from your other courses. This is not about the security aspect HTTP So now let's look and I'll look at the capture of what happened when I accessed ICT server using HTTPS and we'll learn the packets being sent and this is this the sequence of packets When we use HTTPS, I'll zoom in a moment and look at some Selected packets, but first I'll describe the setup So what I did is I visited the ICT website using HTTPS in in the URL and That triggered my browser and my the IP address of my browser computer is this 192.168.1.7 address It triggered to contact the ICT server And the ICT server internally inside SIT has the address 10, 10, 10, 6 Okay, so those two addresses dot 7 is Browser dot 6 the 10 address is the server the ICT server specifically The first thing we see Actually, we can hide the time for a moment this Before I hide the time this took About 116 Milliseconds from the start until the end in fact most likely to get the data to get the web page maybe slightly left maybe 76 milliseconds for from when I pressed Enter to visit the link it triggered the first sin message to be sent and eventually I get the web page back We'll see where and it takes about 75 76 Milliseconds in that case, but that's locally inside SIT so hide the time and Zoom in a bit so The first three messages are the normal TCP connections set up sin Synac act So there's nothing new here. That's the same as what happens in every TCP connection Browser sends a TCP sin server sends back sin act and then the final act any questions on this the three-way handshake for TCP in fact So that happened we'll draw it shortly One thing before we hide these messages what port numbers are used and I'll Make it easier for you What port numbers are used? 443 is the port number of the server we know with HTTP the port number of the server is 80 But here when we use HTTPS The port number used by a web server is different. It's 443 so we see up here the destination port of that first packet It's sent from some random or dynamic port on my web browser 3 3 5 3 6 but going to HTTPS Server 443 so that's one difference between Secure web servers and normal HTTP web servers. They listen on different port numbers The result is that one computer Usually will run both We'll run a web server that can listen up for normal HTTP, but also for HTTPS The protocol used for So we see TCP. This was actually using TLS version one So one I think or maybe one point something but TLS version 1.2 Okay, so there are different versions of SSL and TLS. This is using specifically TLS version 1.2 But I may just refer to it as the old name of SSL. So let's Filter out these TCP packets the sins. These are just TCP acts This message is TCP data. We'll look at the content shortly, but from TCP perspective Set up a connection Send some data Get an act send some data get an act and so on So I'm going to hide these acts because I just had the the transport layer level. They're not part of SSL So filter and display just SSL packets and we left with these packets So these are the SSL messages which are sent between client and server So we want to look at what happens here and and see how SSL works Who sends the first packet browser or server? Okay, be aware the 1.9.2 address is the browser the 10.10 address is the server So the browser contacts the server the browser is the client so a client and server and the first message is hello I'm a client. I want to talk to you. So it's called a client. Hello message. This is part of the initial handshake This SSL handshake not the TCP handshake. So once the connection is set up. They must Tell each other they want to communicate or the client must contact the server and then agree upon some parameters So the first thing is a client. Hello message Some of this sequence. It won't be exactly the same But on the lecture notes and we'll draw it as well, but If we go through we'll see more general sequences shown on this slide the hello and so on but the example We will see is slightly different. It's a specific case What's inside this client? Hello message if we expand here? What do we see? It's a hello message and We'll not look at every field, but the Important things first it contains some random bytes They're going to be useful later. So the client says hello to the server and inside this message It sends some random data and It's going to use those random bytes those those numbers In some of the steps later, it's like a nonce value in some of the protocols We've talked about we said a nonce and one and two. This is like a nonce value being sent from client to server It's actually 28 bytes. It's generated. The other important thing is This list of ciphers and there's 11 in the list This is the client saying to the server For our secure connection I propose that we use one of these 11 sets of ciphers Sets of algorithms because with a secure connection. We don't don't just use one algorithm to encrypt everything We will generally use some algorithms to do key exchange and authentication and then different algorithms to do the data encryption and What the client is saying I propose to use This one this combination will go through it in a moment or if you don't want that. This is my second preference my third preference and my 11th preference so the client indicates what algorithms it prefers to use We'll see when the server responds. It will select one of them What are all these characters mean in the first case? actually We'll choose one which Maybe it's easier to explain first and we'll come back to the others. This one is saying that All right TLS is being used RSA. So for public key encryption We'll use RSA and we'll use an RSA public key and a certificate using RSA to encrypt a secret value Remember the general approach to exchange a secret encrypt with public key encryption and to authenticate use Public certificate with public keys and certificates. So the public key algorithm in this case would be RSA For data encryption use a symmetric key algorithm which algorithm? AES AES supports different key lengths. So AES with 128 bit key and the mode of operation CBC and The third algorithm we use some hash functions in some of the steps which hash function in this case char So that's the way to interpret this. It's really three Three sets of algorithms The public key algorithm RSA The data encryption symmetric key AES 128 with CBC and the hash algorithm Char, but there are some variations. For example, this one allows for AES with 256 bit key This one still uses char AES, but it combines RSA with Diffie-Hellman Remember Diffie-Hellman? We have those global public parameters alpha and q and it's about solving discrete logarithms So this Diffie-Hellman's also a public key algorithm The way that we use this is that We'll use Diffie-Hellman to exchange a secret Both sides know a secret. We'll use RSA for the Certificate for the public key to authenticate the server. I Think in the example, we'll see this one gets chosen Of the 11 that one gets chosen DH is for Diffie-Hellman E for FM. I can't say it will show it show it shortly The other ones are a slight variance This one's Diffie-Hellman with RSA with AES, but EC is a variant of Diffie-Hellman We studied Diffie-Hellman where it was about solving discrete logarithms It was What? A to the power of x mod mod n There's a variation of that which uses slightly different problems of about curves and finding points on the curve It's called elliptic curve cryptography and EC refers to elliptic curve Diffie-Hellman a variation of the algorithm. We haven't talked about elliptic curve cryptography But just think of it as a a different way to exchange secrets so different combinations proposed by the client The client can also choose to use compression. Which compression methods do you think it would choose? It chooses one Anyone want to guess before I show you? Compression methods, do you know any? Zip is one algorithm. So there are different compression algorithms The default is none or null. Okay, so here says don't use compression If we wanted to use compression we'd add in the list and say zip or gzip or some other algorithm that would would like to compress with And there are some other information Some of these suggested algorithms require different parameters and they are listed in these extended values But at this stage not important for us Client says hello Server receives a hello and sends back a hello message from the server so let's look at that and In some of these packets there are in fact two messages included again Here we'll see that From SSL's perspective this one packet contains two messages the server. Hello and the certificate So we'll treat them separately Explain them separately the server. Hello if we find it Is this part? hitting also includes some random numbers that the server chose and Importantly it selects one of those 11 that the client Preferred it would normally choose the the highest one in the list that the server also supports So in this case the server has chosen Diffie helman with RSA with a yes with Shah of Those 11 it chooses one If the server doesn't support any of them it will will will not allow a connection So the server and client must support some common combinations there and The rest I think is not so important just yet. We may return So let's make note of what's happened so far and and and list these algorithms that we're going to use Diffie helman RSA AES and Shah This is the same as the previous TCP connection setup nothing changed But then we send a clock client. Hello message and Two things that we've seen in that hello message from the client the browser is the client is that it contains many things But the two things that we'll see later is it contains some random bytes So it's a random value and the preferred ciphers a list of preferred ciphers that it will use When the server gets that there's in fact a TCP act that comes back I'm not going to draw that but there is a TCP act Involved just to save space. We'll just draw the next message that comes back is a hello message from the server It also contains some random bytes and the selected cipher or or Combination of ciphers I say that the selected cipher set. It's not just a single algorithm It's a set of algorithms and let's just list that algorithm that was selected and explain How it's going to be used? It was Diffie Helman RSA AES and Shah Diffie Helman ephemerion Diffie Helman we know it's the algorithm for sharing a secret remember we Have a public alpha and Q we choose some X Calculate Y send Y to the other side. They choose X Calculator Y Send it back and from that we both get the same key K. That was Diffie Helman ever mario here simply means Temporary there's a different version which is fixed which means that so the purpose Here is that we'll use Diffie Helman to exchange a secret and We'll only use that secret temporarily for a short time. We will not continue to use it later if we want to Communicate communicate again will exchange and get a new secret So the idea here is that we only use the secret key for a short period There is a variant called Diffie Helman fixed which will use the same secret for a longer period the purpose of this is Secret key exchange That's why we use Diffie Helman here other algorithm RSA we know what that means the purpose of RSA is Authentication of the server in this case if we remember back to Diffie Helman We went through a case of a man in the middle attack is possible. I Don't have it But if you look back through your notes when we did Diffie Helman We saw that if there was some of them in the middle with the normal Diffie Helman they could Pretend to be both entities the the receiver and the sender and trick The two entities into believing they have a secret when the man in the middle also knows that secret It's the same type of attack. We saw on RSA. So a man in the middle attack. We saw in key distribution. It's possible so the problem with them or the reason because of them the reason for the man in the middle attack is because the Receiver doesn't know that the public values it got are correct The Way to avoid the man in the middle attack is to use a certificate to have someone sign those public values and That's what we use RSA here. We use RSA for the certificate the authentication of those values We'll see an RSA certificate certificate. So what will happen is that a Certificate is sent from server to client and That will allow the client to verify the public values that it got for the Diffie Helman to be sure There's no man in the middle attack Both Diffie Helman and RSA are public key algorithms We're using one for secret key exchange and the other one to authenticate that step When we also use this certificate to so that's to make sure that we are communicating with the correct server The other algorithms that we listed was it a yes One two eight CBC Purpose so we know the algorithm the boat of operation the key length and a yes Data encryption all the data once we've set up a connection is encrypted using a yes The key that we use is Obtained based upon the key we exchange with Diffie Helman So we'll use Diffie Helman get a secret we'll use RSA to verify that that worked correctly then we'll use that secret to Do the encryption The last thing some of those steps require a hash function or a Mac function in particular we use char a Hash algorithm and that is used That's actually used with HMAC for data integrity That is we for our Mac function HMAC takes a hash function char and turns it into a Mac function So they all use HMAC and we specify which hash function Remember the difference between a Mac and a hash hash takes just some data a Mac takes a key and data in SSL we use a Mac On everything we we going to send we take some data and we use a key What algorithm do we use for the Mac? We it's HMAC combined with char so that's what we'll use for the different security mechanisms in this HTTPS Web browsing exchange So in fact it's combining everything we've learned across the semester symmetric key encryption Public key key exchange and and authentication or data integrity This second message this second message in the exchange the one from server to client actually contains two Handshake messages. We're still in the handshake phase before we can encrypt data The server saying hello and saying what algorithms will use and since we've chosen the algorithms that will use RSA for a certificate It includes the certificate here What do we expect to see here in this 1,100 bytes? the certificate of who of the web server of ICT It's included in this message and you could see and look through all the fields the signed certificate So this is a x509 certificate. We've looked at them in the previous topic. We have the issuer And you can expand and see all the data the subject The the timestamp of how long it's valid for and so on. So this is the actual certificate included in the message And it's an RSA public key is included the public key info there's the subjects public key which would be some modulus n and some public value e that's the RSA key and signed and in this case signed by who ICT web server the science certificate is signed by who it's actually a self-signed certificate ICT it's issued to the ICT web server The common name is that of the the domain name of the server and it's issued by that actually the same person It's a self-signed certificate I updated it today just for this demo You expired two weeks ago Okay So now we have the certificate Let's see what comes next The next message is in fact also from server to client. No, this is from server to client server key exchange Remember, we're going to use Diffie helman now to exchange a secret. How do we do Diffie helman? Well, the server chooses some public values Calculates its Value of why and sends it to the other side and it's sent in this message The server key exchange It's not so interesting to look at because it's all signed it's actually 500 bytes of important information in here it includes the Diffie helman public values alpha and q and the Y value of the server all Signed with the RSA key, so let's draw that to finish today the next message Certificate they were actually included in the same packet, but from the SSL perspective that two different messages that was the certificate of the web server and Then we had the key exchange server key exchange it was called Inside that for Diffie helman the parameters There's an alpha Some modulus q and some public value Y of the server the server also has its private value xs It sends that to the client When the client gets it From those public values it can calculate Which choose its x value and calculate its x its y for the client and send it back Then they find a calculated shared secret key using Diffie helman importantly that information So that we can't have a man in the middle attack that information in the Diffie helman Especially the Y value is signed using the public key of the server the RSA public key which was Included in the certificate. So sorry It's not signed with a public key. It's signed with the private key Private key of the server the server signs it and that means that the client can verify that these are the right values They did in fact come from the server the way that it verifies is because it knows the public key in the certificate and It knows it has the right public key because that certificate is signed by an authority that the browser trusts In this case It's self-signed. So we actually have to click on that warning message to confirm that we accept it That clock is wrong. So don't worry. We have five more minutes. No, we're finished today. We'll continue that on Tuesday Make sure you do the quiz Which covers those aspects of key management including certificates and we'll finish this exchange on Tuesday And then I think Friday next week a little bit about secure shell and that should finish us for the semester