 We're we're focusing on web security and we went through that one aspect of web security is HTTPS and Normally when we're using web browsing we're using HTTPS that application layer protocol and a HTTP message like a get request is created by your web browser on the left protocol stack in the normal case that HTTP get request is sent to the TCP software in your operating system Which creates a connection to the web server? sin sin act act with TCP and then sends that HTTP request to the web server and Eventually the response comes back using TCP Now of course all of that is insecure nothing's encrypted and we don't know for sure that we're talking to the right web server What HTTPS does? it introduces the use of a Layer or a protocol between HTTP and TCP So your browser generates the same HTTP request a get request Instead of sending it direct to the TCP software in the operating system on the right picture. We see that HTTP sends it to the SSL software on your computer SSL is the secure sockets layer Also called transport layer security TLS HTTP request is sent to the secure sockets layer, which then establishes a secure connection to the server and We saw an example last lecture In wire shark that the secure cell secure sockets layer protocol has some steps of establishing a secure connection Negotiating which algorithms we're going to use to encrypt and and to authenticate and then Encrypting the data So SSL does the security functionality everything is still sent using TCP from Browser to web server, but everything inside the TCP packet once the secure cell shell secure shell secure Sockets layer connection is established everything inside the TCP packets encrypted So HTTPS is simply HTTPS using SSL HTTPS on its own is not a separate protocol. It's it just introduces SSL or Sometimes TLS is the newer version so we can encrypt our data, but one of the problems that we have is that To encrypt data We would like to use symmetric key encryption because it's generally faster than public key encryption So to encrypt data with symmetric key encryption both your web browser and Web server need to have a shared secret key So that's the challenge. How does your web browser and web server get a key that they both know So that they can encrypt the data What's the answer? How do we exchange how did it this browser and the server get some random key that they both know? Remembering we cannot send a key across the network unencrypted If I send my keys, let's say from the server chooses a key sends it to the browser unencrypted The attacker can intercept and see my key So that doesn't work So we need to encrypt the key to send it across the network Encrypt the key using what we use public key encryption to encrypt the key and Then once we've got this key at the say at both sides Then we'll use that key to use symmetric key encryption Why use a combination? Symmetric key encryption is much faster So we'll encrypt the key using public key encryption Encrypt all of our data and there's usually a lot of data using symmetric key encryption So we'll look at how that's done and we'll look at some of the problems that arise with that so When we want to provide encryption in web browsing and also authentication It's not just a key for encryption I would also like to know for sure that the other side I'm communicating with is the web server corresponding to the domain www.facebook.com It's not someone pretending to be that web server. So that's the authentication part of it. The problem is The browser and server do not have pre-shared secrets My browser doesn't have a key, which is also known by the server We need to exchange that secret So the way that we do it is we use public key cryptography to securely exchange a secret key and There are different public key cryptographic schemes Some of them are listed here RSA, Diffie-Hellman, Elliptic Curve cryptography I just list them because when we look at some real examples, you'll see their names come up So there are different ways to do it. We'll use a simple example Let's say using RSA Public key crypto is used to exchange a secret key Once both sides have a secret key Then they can use the faster symmetric key encryption to exchange data Encrypt the data with let's say AES and our shared secret key Send it to the other side which can decrypt and It's maybe tens of if not hundreds of times faster to do symmetric key encryption thousands in some cases So that's the approach But it turns out there's a problem with that approach So let's illustrate the approach and then we'll analyze the problem So I'll draw what the typical that the aim is in this case and then we'll see well, what could go wrong in that? so the idea is that we have browser and server and With public key encryption We assume let's assume that the server has its own key pair So a server has its key pair. I'll denote as the public key of S the server and the private key of S the server The browser may also have a key pair, but we don't really need it in this case We mainly use it for from the server. So we'll see how it's used So that's known at the front by the server. It has its own key pair They don't have a shared secret yet. Our aim is to get a shared secret So one approach is that we send a message from server to browser and that message Contains the public key of the server remember for confidentiality using public key cryptography we Encrypt with the other person's public key Right, so if the server has a public key P us in this case the server sends its public key to the browser Because the browser doesn't have it yet The browser is just visiting the website for the first time. It doesn't know the public key of that website so in some exchange the server would may send its public key to the browser and now The browser can generate a shared secret key choose a random number Which is going to use later for encryption and send that secret key back to the server But of course encrypted encrypted using public key crypto So the next step the browser generates a key let's say a Shared secret key K shared between the browser B and the server s and Sends back a response and the response includes the key But we can't send it in the clear so we must send it encrypted Using the public key of the server and when we encrypt with the public key of the server When the server receives this message it can decrypt because the server knows the private key of s No one else does and hence we have confidentiality for that key transfer the key exchange When the server receives that second message it decrypts and it learns KBS Now we know that this is public key encryption because I denote that the key being used is a public key but just to be clear this E here is public key encryption. We've completed the key exchange The browser and the server now have a shared secret KBS So now the data that goes between the browser and server can be encrypted with KBS And it can go in either direction using that same key So we've exchanged the secret now we have some data to send like the HTTP request and the response in both directions we may send messages and We will encrypt the messages Using the shared secret key KBS whatever data we want to send and this algorithm for encryption Is using symmetric key that's the idea with Public key encryption to exchange a key and then symmetric key encryption to encrypt the data Of course, there may be many packets going back and forth containing data all encrypted using KBS This is a common technique for exchanging keys followed by encrypting with symmetric key ciphers Any questions on how this works Can someone learn KBS? Someone other than the browser and server learn the shared secret key KBS What would you need to do as an attacker to learn this KBS? impersonate who if we could impersonate we'll see the server then maybe we can so of course if we Intercept these three messages if I'm the attacker I intercept The first one I learned the public key of the server who cares. It's public anyway. That doesn't help me If I intercept the second one, I can't decrypt it because I don't have the private key of the server So that's no help to me as an attacker And if I intercept the third message or any of the encrypted data again, I can't decrypt because I don't know KBS Because KBS was exchanged using the public key encryption So it just intercepting these messages doesn't help the attacker But there is an attack that involves the attacker impersonating the others and it's referred to as a man in the middle attack what the attacker will do is Be in the middle of the the path between browser and server intercept messages Before they get to the destination modify them and forward them on And the idea is that the attacker the man in the middle between browser and server will impersonate the server from the perspective of the browser and impersonate the browser from the the perspective of the the server Let's see how it works And then we'll look at what we need to do to overcome that So right that was what we're trying to draw and now we're going to try and draw Well, what can go wrong in that exchange a man in the middle attack Start again, but we'll introduce the third entity we have browser server and The man in the middle or a woman in the middle is the attacker and in the middle it means that they can Intercept messages between browser and server. So maybe somewhere on the path in the internet and They can modify those messages as well not just intercept but also modify So what the browser and server do they follow the steps from the previous diagram those same three steps But the attacker will make some changes along the way so again what's known up front the server has a public key and A private key and the server The browser doesn't know the public key of the server So the server sends its public key to the browser. That's the first step But it's going to be intercepted by the attacker. So the normal message sent PUS is sent from server to browser but the attacker intercepts that and Then forwards a message on to the Browser with a modified public key. Can the attacker read this value? Can the attacker read PUS? Yes, it's not encrypted. It's just sent in the plain text. So they see a public key. All right They know it's from the server. It's a public key of the server What the attacker does is changes the value to their own public key Because it's not encrypted and in this case we have no authentication techniques The attacker can make a change without anyone knowing it changes the public key in this message and changes to its own the public key of the attacker and Just to be clear, we should have said that the attacker also has its own key pair Anyone can have their own key pair So it's a message that was intercepted Maybe the from is still from the server the destination is still the browser But the contents has been changed to be the public key of the attacker Any questions on the first attack step? What are you going to do next? question Yeah Right the when I say the attacker intercepts and modifies when the browser receives PUA they still think it's from the server with respect to HTTP then the browser has made a TCP connection to the the The server already so when it receives the message it thinks based on the IP address Maybe it's a fake IP address. It still thinks it's from the server Has no way of knowing whether it is indeed the correct public key or it's the public key of a Because you just receive a message from the server public key. It must be the server's public key What happens next what does the browser do? It follows the normal steps it chooses a secret key encrypts So the browser thinks everything's okay. They generate a secret KBS and They send the response back to the server and the response is Using the public key we just received Thinking it's the public key of the server, but in fact it's public key of a encrypting KBS Send that back to the server Again our attacker intercepts before it gets to the server we as the attacker receive this message Can the attacker decrypt? Encrypted with PUA the attacker knows PRA therefore. Yes, the attacker can decrypt and the attacker learns KBS So we have a problem, but our attacks not finished yet. The attacker has learned this secret key KBS But for the attacker to be successful they must Make the browser and server think that they've set up a secure connection so we continue we Forward a message on to the server Because it's the server is expecting a response. It said it's public key. It's expecting an encrypted Shared secret to come back so the attacker encrypts Using PUS KBS The attacker knows KBS. They know PUS is a public key of the server. They received in the first message They encrypt that and send it back to the server and the server receives what it expects The server sent its public key To the browser the server receives a response Encrypted using its public key of some secret They decrypt because they know PRS and they learn KBS The server now has KBS and the key exchange is finished the key exchange was send the public key receive an encrypted shared secret key KBS and Neither the server nor the browser know that something's gone wrong The server sent a public key received a valid response the browser received a public key sent a valid response What happens next To finish this attack. How does the attacker take advantage of it? What does the Browser do now? Let's say now the browser and server have exchanged a secret so they start sending data to each other The browser sends data to the server and also on the other direction Let's consider from First the direction of it doesn't matter which direction. Let's say the data Is sent from browser to server. Maybe the HTTP get request. We're using symmetric key encryption. We encrypt Using the shared secret key KBS Some data The browser sends that to the server, but again our attacker intercepts Can the attacker decrypt? Yes encrypted with KBS the attacker knows KBS. So the attacker learns the data They learn the data and to make the browser and server think that everything is okay. They send it on to the server The same encrypted data or they can modify the data if that's their aim server gets the data The browser has sent the data But unfortunately the attacker also gets the data So everything sent between browser and server and similar in the other direction Is intercepted by the attacker and they can decrypt all of that data So this is our man in the middle attack The man in the middle the attacker has pretended to be the browser and server and In doing so learn the shared secret key KBS and Therefore can decrypt all the data They can decrypt data. They can modify data and it go undetected because they know the keys now This is a problem any questions about the man in the middle attack How to conduct it, okay What went wrong? Why why was the attack successful? What's the the problem with what the browser and server did? they Used the same key all right, but what what was what led to the problem that the attacker learned KBS What was the step here that was? The the the floor in this this protocol for exchanging a secret Which one do you think is the problem? public key of The public key of the server Was sent in that very first message the server sent its public key to the browser the problem was the attacker Intercepted that and changed it to another one Without the browser knowing That's the problem The browser receives a public key saying this is the public key of the server But it's in fact the public key of the attacker and When the browser encrypts something using this public key It's not aware that the attack is going to be able to decrypt it So the real problem problem here is receiving a public key without having to Without being able to verify that it is indeed the public key of the server We need a way so that the server can send its public key to the Browser when the browser gets it the browser can check and confirm for sure That this public key is that of the server. It's not one of the attacker How can we do that? How could we send some value the public key in this case? Such that the receiver can confirm for sure that it is indeed from this server a Signature We need the server to sign the message Or someone to sign the message just to confirm this is indeed the public key of the server Now the server signing the message won't help if the server signed the message with its private key Then the browser would need the public key of the server to verify But our problem is that the browser doesn't have the public key of the server If the browser knew the public key of the server, we wouldn't have no problem So what we do because when you open your browser you visit a new website You don't have the public key of that website. You've never been there before their public key May change on a regular basis So we need some way to distribute that public key But we need it to be signed So what we do is we get someone else to sign it We get someone else to sign the public key of the server saying this is the public key of the server When the browser gets that signed public key the browser verifies Using that someone else's public key that it is indeed the the real public key of the server So the signed public key Will see is a certificate We'll see the steps for signing it in a moment, but we'll introduce the little bit more detailed terminology and Notation so the man in the middle attack is the problem here It allows us the attacker to discover and decrypt all the data So for web security, we need something more than what we did in our protocol. We need some signature and The the signed public keys will refer to as certificates with digital certificates so the step the server Creates a key pair PUS PRS like in our initial step. We needed a public key pair But then What the server does is the server contacts some other Entity will call a certificate authority CA for short and This certificate authority will sign The public key of the server The idea is that the authority confirms this is the public key of the server When the browser receives this signed certificate, it can verify. It's the correct public key How do we sign something? So the approach is that we're going to sign the public key of the server. How do we sign a value? Write an equation for signing the public key of the server hash Hash of what remember how we do a digital signature. What do we do? We covered it in the previous lecture hash of the data and then encrypt the hash value with Private key of the signer. Okay, so we we hash the public Public key in fact here what we want to do is not just hash the public key What we want to do is include the identity of the server something that IDs or unique uniquely identifies the server So the concept we will see is that we hash We have the make some more space The concept of signing We'll see a little bit more detail for a certificate, but the concept is that we have The identity of the server How can we identify a web server? What thing do we commonly use to identify a web server? If I wanted you to tell me about the Facebook web server, what address would you tell me is that of the Facebook web server? Tell me louder What's what's the name of the Facebook web server? Not Facebook. There's a bit little bit more precise Facebook.com Okay, or A domain name all right web servers are identified by domain names So when I say the ID of the server in practice, we'll see it's a domain name So the ID of the server is combined with the public key of the server This just means concatenate or combine them together join them together So we have a domain name for example and a public key of the server we want to sign that and Remember to sign something we calculate the hash of that and then We encrypt the hash value with a private key example of the ID the example of the public key are not right, but It could be a you've generated in one of your homework say a 2048 bit RSA key One of your homeworks you generate your your public private key pair So that's what would be included here the public key of the Facebook web server Now we will add one more item to what we sign with a public key They may change over time So a public key has a lifetime So I may generate a public key today and maybe it has a lifetime for one year and One year later. I'll need to generate a new public key so We will say that we'll include another piece of information a timestamp or some time information about I'll just denote it as t here the timestamp For example, it may include the start date and The end date of this key in other words this public key This 2048 bit RSA key belongs to Facebook or more precisely www.fb.com in my example and this key is valid from this start date and Up until this end date Don't trust it before the start date. Don't trust it after the end date. So we have a period of That it's valid for so I just denote that in short as the timestamp T So that's the main information that we need to sign This would be generated by the web server. It knows its own domain name. It generates its own public key It knows it sets a start and end date We calculate the hash of all that information and then Encrypt that with a private key Who's private key when we want to sign something We use the sign as public key who's going to sign let's consider what if the server signs This public key So if the server signed their own public key Then we've got two problems one is that The browser doesn't know the public key of the server to verify That was our problem the browser doesn't yet know the public key of the server if something is signed by the private key of the server We will need the public key of the server to verify that but we don't have that so we can't verify it and In fact if it was signed by the private key of the server There's nothing to stop to someone else to create this signature maybe Steve comes along says the ID of My idea is www.facebook.com. I generate my own public key It's definitely not Facebook's and I sign it myself Then there's no way to For the receiver to be sure that it came from Facebook or me So we can't self sign here. We need to sign by someone else So we signed by what we call an authority Or a certificate authority to be precise Someone else signs this I'll denote the private key of the CA the certificate authority maybe it's also a This is this is also maybe a 2048 bit RSA key The private key but of a certificate authority. That's the general name and In fact, we'll see that later. There are different companies and organizations that act as certificate authorities One of them you may see that comes up Verisign is one Komodo many others We'll talk about them later So that idea here is that The server is going to send its public key to the browser that was the very first step that we needed The server sends its public key to the browser But with the man in the middle attack the attacker can modify it to anything it likes. That's the problem To overcome that problem The server is not going to send the public key on its own. It's going to Include its ID its timestamp and get that public key signed by someone else This someone else is called a certificate authority and the idea will be When we send this signed value to the browser the browser will be able to verify that it came from It is that of the server As long as it has the public key of the authority this part is the signature I'll just to know the signature component is here and Normally we don't just send a signature We send the real data with the signature attached questions on how we generate this signature when you access a game when you're Using line or Facebook on a mobile app if they're using HTTPS they are obtaining this signature all the time Because your browser or your application doesn't know whether you're communicating with the right server or not Any questions on how to generate the signature? The signature here is the ID of the server the public here the server some time values or timestamps Signed by someone else so we need to talk about who that someone else is in a moment But let's call them the certificate authority what we do This signed value which I just wrote down is this component here Timestamp public key of the server ID of the server hashed Encrypted with the private key of the CA that's the signature component and We of course attached the signature to the data The data was the ID the public here in the timestamp all together See there are four parts ID public key timestamp signature All together what is that called? What do we call it? What do we call CS? CS what is it? Very important part in web security when you set up your own website. You must generate this CS is what we call the certificate of server s It contains the server's identity like their domain name their public key some timestamps saying how long this certificate is valid for and This part at the end is the signature of all of those three data elements This certificate of the server is signed by who? Who signed this the certificate who signed CS? Have a look it's in there somewhere who signed it who signed CS Have a look on the equation there Don't say server. It's wrong. What's a signature mean encrypt with Encrypt the hash with which key? Private key of the signer So who signed CS? CA the certificate authority So be careful here. It's the public key of the server Signed by the authority the certificate authority in lawn It's like you coming to me and saying here is my public key and I sign it as the authority Confirming yes, this is your public key and now you have a certificate and you can go to other people Those other people that trust me They see my signature Know it's your public key and that's how we'll use it in web security So we say that the Certificate of the server is issued by the authority the certificate authority. This is the concept There's a more detailed Specification of the format of such certificates the the standard for what to include here It's more than just these values and it has a particular structure is referred to as x509 We will show you some real certificates later, but And we'll see they're in x509 format, but the concept is captured by this one. Let's see how it works With respect to our browser and server We have our browser server We will not show the attacker yet to start the server has a certificate and it's a To note it as we'll write it in full CS ID of s You don't have to write down the full one. It's on your slide the public key of s timestamp and Encrypted with the private key of CA The hash of what what's here these three values I'll not squeeze them in there We take the ID the public key and the timestamp We hash them Encrypt with the private key of the authority And this is the signature component. This is the data component That's what the server starts with and the concept is that we instead of sending the public key on its own to the browser We send the certificate instead What does the browser do when it receives the certificate? The server has just sent its certificate to the browser. What would the browser do? Remember our aim is like the previous protocol exchanges a key KBS But now we're using a certificate the certificate contains P us That's what we want to learn the purpose here is for the browser to learn the public key of the server It's included here Is the browser sure that this certificate is indeed the certificate of the server and not an attacker Well the way that we try to check if We have a signed value we verify the signature How do we verify the signature? Remember back to the basic concepts of the signature if we sign it with a private key of a user to verify We decrypt using the public key of that user So we try to verify the signature So the steps we take at the browser we receive the certificate and then to verify We decrypt Using some public key The signed component I'll just write the signature Because I can't fit it all in the signature is this component Be careful the encrypted part is the signature. This is the data component So we take the signature we decrypt which with which key how do I verify the signature who signed it Signed by CA therefore we should verify with a public key of CA and Here's an important point of the how certificates are used in web security The server sends its certificate to the browser to verify the browser Decrypts the signature part with the public key of the authority But we have a problem We meet need to have the public key of the authority to do this verification Where do we get the public key of the authority from remember our Original problem when the server sends its public key to the browser the browser is not sure if it is the public key of The browser or the attacker So we're using a certificate To verify that certificate we decrypt with the public key of the authority Therefore we need the public key of the authority. Where do we get the public key of the authority from? We ask the CA to give for the CA to give us its public key and How do we send public keys now? Instead of sending a public key on its own what we're going to do is send a certificate Really a certificate is a signed public key The certificate is the public key with some other information Confirming by someone else that it's the public key of the server So in fact, where do we get the public key of the authority from? We need to get the certificate of the authority the public key of the authority would say it comes from the certificate of the CA Where do we get the certificate of the CA from? Where do you think it's going to come from? From the CA what do we do? We send a message to the CA and say please send us your certificate They send the certificate of the CA who signed the certificate of the CA The CA signed its own certificate the problem with signing your own certificate is that You need the public key To verify it How do you know someone else didn't generate that certificate? We still have the same problem If we ask the CA for their certificate Then we need the public key of the signer to verify it. We want to verify everything we receive So we have this recursive problem To verify The certificate of the server. I need the certificate of the authority To verify the certificate of the authority. I need the certificate of someone else But to verify their certificate. I need the certificate of someone else So we have this recursive problem to stop that at some point we must trust a certificate and not verify it and In practice what that means? Normally your browser has the certificate of the authority loaded into the browser When you install your browser on your computer the creator of the browser loaded in some pre-existing certificates of authorities and We say that they are trusted So in this case It's trusted or known in advance The server sends its certificate to the browser To verify we need the public key of the authority or we need the certificate of the authority Instead of asking the authority for that The simple approach is we'll assume that the browser already has it When you installed your browser it was programmed into it to include some certificates of authorities In other words, we must implicitly trust this certificate if we do trust it Then we can verify and we verify we find that it it works and Now we learn the public key of the server and Then we can continue with our other steps of sending the response or the generating KBS This is the second state of step of our protocol and as before We select a KBS and we encrypt that Using the public here of the server When the authority receives that message it can decrypt and learn KBS and Then subsequent data can be encrypted using KBS Let's recap and see what What we've done and why we did it. So let's go back to the attack from the start The normal idea was the server sends its public key to the browser The browser generates a shared secret key KBS and Encrypts that using the public key of the server sends it back to the server. So they both now know KBS That was our our approach But we had a problem We were subject to a man in the middle attack if the server sent its public key to the browser, but the attacker intercepted We had no way for the browser to know if the public key was modified along the way So the browser may receive a different public key and if they do Then the attacker can then learn KBS So the man in the middle attack the problem was that the received public key was not verified So the solution we're using We don't send the public key on its own We send the signed public key and the signed public key is referred to as a digital certificate The public key as well as the identity of the server the time stamp to say how long it's valid for is Signed and a signature is simply hash Encrypt with a private key We say the public is signed by an authority It's the authority confirming this is the true public key of the server The server therefore sends its certificate to the browser CS It includes the public key but before the browser uses that certificate the public key it verifies and the verification approach involves using the public key of the authority and At this point we assume that the browser knows the public key of the authority It was maybe programmed in the browser such that they can verify Once they verify they know it's the real public key of the server and then can send KBS back Encrypted with the public key of the server and that's the general approach we use in HTTPS web security We issue certificates to servers and they send the certificate to the browser Those steps are summarized here the certificate of the server The server sends the digital certificate to the browser The browser verifies the signature Using the public key of the CA, but there's a little bit of a problem there To get the public key of the CA we must have the certificate of the CA But that needs to be signed by someone If it's signed by someone else then we have this recursive problem at some point there will be a self-signed certificate See the certificate of the CA contains the public key of the CA Signed with the private key of the CA this allows the browser to verify and The browser to get the certificate