 So we want to secure our data when we send it between our web browser and web server and we saw that the way to do that is to use HTTP, the web browsing protocol, but on top of SSL, the secure sockets layer, or the newer name or the newer version is called transport layer security, TLS. So combining HTTP with SSL or TLS is referred to as HTTPS and we use it on a regular basis. We'll show another example of using that today and we'll look at one aspect of how to do the authentication. We'll see that HTTPS will do the encryption and as SSL allows us to, before we send the request and the response, we encrypt it so no one can see the request to response. But before we do that, there are two things that we need to perform. We need to, first, we're going to use symmetric key encryption to encrypt so we need to exchange a key, a secret key between server and client. That is for the client, your web browser to encrypt, it needs a key to encrypt and the server must have that key so it can decrypt. So there's some key exchange. And the other aspect is the authentication, which is done in usually two parts. When you visit a website, and let's say you log into that website, there's some authentication so that the web server knows it's you that's visiting the website. And the normal way for the web server to authenticate you, the client, is using some username and password. So we use that on a daily basis, we log into websites. The other part is that when you visit a website, you often want to be sure that the website you're visiting is the real website and not someone pretending to be that website. For example, you log into your bank website, you want to be sure when you, especially when you exchange confidential information with it, you want to be sure that that is the bank's website. It's not someone doing some attack and pretending to be the website. So you want to authenticate the server. And that's what we'll focus on today, is the way that the browser authenticates the server and the concept is to use certificates, or digital certificates. But before we look at them, digital certificates, let's go through another example of HTTPS or first HTTP and then HTTPS. I've set up a virtual network which has just three nodes. And I'll draw it. That's not it. For example, I'll go through looks like this. We have node one, no need to draw this. This is just an example that you may see a similar one in some of the homework tasks. Three nodes. So this is our router. This will be our web server. And this will be the web browser. So three nodes in this simple network. And what I've done is I've already set up the nodes so that node one can contact node three. And I've set up a fake website on the web server, just some web pages that we can use to demonstrate some security issues. And I've actually set it up so that we can use HTTPS. So we use both HTTP to access the browser to the web server. And then again, we access the same website but using HTTPS and see the difference. So when I say this computer one is the web browser, I mean that computer is running the web browser. So node one runs the web browser. What's the web browser we can use? Firefox. So you know many web browsers. On our virtual nodes, when you've set up the virtual network with node one, node two, and so on, we can't use Firefox directly because there's no GUI on those virtual nodes. You only have the terminal. There's no graphical interface because it's just set up as a very simple node so that we don't need many resources. So what web browser can I use? How can I use a web browser without some graphical interface? I need some text-based web browser. That's one option. Lynx is one that we can use. We'll say a couple of other options. What I can do and what I've done, it's only to make the demo a little bit easier, I've set it up so that these are the virtual nodes and think this is my laptop. These are actually running on my laptop but we can think of four different operating systems, my laptop and then the operating systems of each of the nodes. I've set up so that I can run my browser on here and it pretends as if it's on node one. Firefox is FF, so I run my web browser, my normal web browser on my laptop. I'll show you in a moment and when I browse via that, I've set it up so that when I visit a website, the request will be sent from node one and we'll see to node three and when the response comes back it will go to node one and then to my real browser. It's just for the demo so that we can actually use Firefox as opposed to the text-based browser Lynx. The way that I set that up is to use some tunneling but that's not important for this topic. So when I access my browser, think I'm on node one. So I've got the nodes, we will not do much on them. We may capture on node two, node three is the web server. The web server is there running. Apache web server is running there. There's some web pages that we'll visit in a moment and so there's nothing to view on node three. Our node two is just the router so we may capture some packets and just see what's being sent to and from the nodes. And node one is our web browser but for the web browser, we'll view from my actual Firefox. So first let's visit the website but on node two I'll capture the packets here. Now we're a bit hard to see because many packets, I think many of you know already, we can capture packets being sent using different software. One of them we use is TCP dump and it captures packets. This long command of using TCP dump simply filters out all the packets which are unnecessary for me to show you. What it does is shows just the HTTP packets. That's all I want to look at in this case, the HTTP request and the response. The TCP port 80 means show only to port 80 and those other strange characters here mean ignore all the acts and so on. So just show the HTTP messages. We'll start that running. So it shall print out and I'll show you in detail as we go. And now I'll open my browser. It's open and I'll visit the website. And I've set up a fake website on node three. It's for a university, so HTTP. And the domain name I've set up, a fake one, myuni.edu. So it's a university website. And it's for students to access their grades. Okay, so there's the front page. I developed it myself so it's a very advanced user interface. It's for students to log in and view their grades for the different courses. Why can't you see that straight on? It can change the view. Not quite. Yes, you can try. That's close. You can try the high-tech approach. As long as we can see the side of the screen. So this is the website. It's okay. Okay, perfect. Thank you. So there's our website. We're capturing, I hope. The capture will look in detail in some of the other packets, but the capture of TCP dump shows this was the GET request. You may not see the details here. It's not so important, but this is the GET request saying, I want to get the URL which the path was slash grades. And this is the response saying the response is okay. And here is the web page in the response. Here's the actual HTML. Okay, so this is just showing that the router sees the actual URL requested and the web page that comes back. And in this system we can log in. And the login is implemented as a form. Everyone knows how to implement a login for a web page? Okay, so in this case it's just a HTML form. If you look at the source code of the web page, it may be a bit hard to see, but it's a form where the action, when we press the submit button, it would take the username and the password and submit them essentially using what we call the POST method. The POST method is a part of HTTP that we use to send data to the server, to submit data to the server. The data will be received by the server, processed, and then the web page will be sent back. So we've mainly seen a GET request in HTTP. We get a web page. POST is used for sending data to the server, and it's commonly used to submit form data. So I've got some users on here, some students and passwords. Can someone see the password? Why not? Right, it's hidden. So the user interface hides the password as you type it. Why? So no one can see and look over your shoulder or on the screen and see your password as you type. And I know many of you, some of you had troubles on Linux or on Unix-based systems, you log in and you don't even see the dots or stars. Nothing's displayed. It's just a form of hiding the password. But it may be inconvenient because you don't know what you're typing and if you've made a mistake. That's a part of the login system. And we press login. And now I'm logged in as this user with ID 5 with 9 zeros and I can view my grades. And it's... I can select the course that I've got the grades for. This is the student logged in. And I can see that this student's getting a B plus for this course. So this web-based system, we'll see it in some other... In the next topic as well, we'll see some web attacks on this website. But for now we're just using it to demonstrate HTTPS. Or first HTTP. Back to the capture. Actually I'll log out. And here we should have all of our packets which were captured by the router while I was sending those requests and response between web browser and web server. And rather than scrolling up and trying to see it, actually we may be able to quickly see it, if we scroll up. So I'm just scrolling up. The web page form. The login form. And then we send a post request. So when I press the submit button that triggered my web browser to send a request to the server and it was a post request. And this was captured by the router and the important point inside that post request is the username and password. So with the authentication of the client in this case using a form, the username and password are sent in the clear in that post request. So this is just another illustration of why not to use HTTP for sending confidential information. Because anyone on the internet can easily capture this request and has captured the password of the student. Which is in fact student in this case. So this motivates the need for HTTPS. These messages sent between the browser and server should be encrypted so that someone who intercepts and captures of them cannot see this information. They cannot see the username and password. Whenever you log into a website make sure it's using HTTPS. The form to login is not using HTTP because if it is the password sent in the clear. I'll stop the capture and start again because we'll try it with HTTPS. What port number do we use if we're using HTTPS? The web server uses a different port number 443. So my web server think there are two instances on my node 3. One is the normal HTTP web server listening on port 80 and the other is the HTTPS web server listening on port 443. So what I'm going to do on the router now is capture on port 443 and see all the messages sent between browser and server. We'll leave that running and I'll just close this and open it again and we'll open our browser again and visit the same website. We'll visit the same website but HTTPS is testing this website. The only difference is the s there and I press enter and what happens? Has anyone seen this before? What does it mean? Right, what's not trusted about it? Who's not trusting who? Right, the web browser, my client doesn't trust the server or it cannot prove or it's got no way to know whether this is the real server or if it's something pretending to be a server for myuni.edu. So what we want to do in this topic is see well, why does this come up? How do we avoid it and what the mechanism is used to prove the trust or to provide trust of the server? So what do you do here? You say I understand the risks I trust it and we'll talk about why you won't do that in the future and we'll add an exception Let's confirm. All right, now I've got my website. So we'll come back to that. What happened there? And I log in the password it logs in, I can view my grades. The point here is that this is the capture of the packets between the browser and web server. You won't be able to find the username and password in here. This is just showing it. It's all encrypted. So all we see is there are, for example, this is a packet from the web server 443 to my browser what's inside it in terms of the HTTP response I don't know. Similar the request is somewhere in there what was the username and password sent? I don't know in this case because it's encrypted. So the encryption provides the confidentiality of our data but as we saw there's an issue. When we visited the website the first time there was this warning we cannot trust the server. So we want to look at how does the browser get to trust the server? So back to here so we use HTTPS it provides the encryption for the server to trust the client that is for the server to know it's the right student they use the password. The student must enter the correct password to identify themselves. So that's one form of authentication we just use normal HTTP or a HTML form for example but for the server for the client to trust the server we use one part of SSL and we use a certificate. So let's look at certificates digital certificates before we look at digital certificates maybe you don't have it but for signatures can anyone remember digital signatures? An equation write an equation for your digital signature or think about what information do you use to sign something what keys or what information do we use for digital signatures? We need to remember we use our private key to sign something we've studied it earlier but let's just remind ourselves public key cryptography and how that's used for a digital signature remember with public key crypto we all have a key pair for example user A has a key pair the public key of user A and the private key of user A and other users have their own key pair the public can be told to anyone else the private must be kept secret so we can usually encrypt using one of the two keys in the key pair if I want confidentiality the public key of the receiver good that is I want to send a message to someone so that no one else can read that message A wants to send to B a confidential message then they will encrypt that message using the public key of the receiver so we've studied this in the first or the second topic on cryptography but just a reminder if I encrypt, if A encrypts the message with the public key of B and sends that ciphertext to B the only person who can successfully decrypt is B because only B has the private key you can only decrypt with the corresponding key in the key pair if someone intercepts this they cannot decrypt it that's confidentiality they will not be able to see the message but the other way that we use public key cryptography is for authentication or in general authentication and a specific case is a digital signature if A wants to authenticate themselves to B we use our private key the concept is that A encrypts the message with their own private key B gets that if it successfully decrypts with A's public key then that implies the message must have been encrypted with A's private key which implies it must have come from A because no one else has A's private key if it doesn't successfully decrypt with A's public key it's not from A so this is the use of public key cryptography for authentication anyone can see the message it's easy to decrypt this you just need the public key of A which by definition everyone can have but only one person can create a message that will be decrypted with a public key of A and that is A and a specific instance of that is a digital signature in practice we incorporate a hash to make it more convenient so we'll just remind ourselves of a digital signature which is also performing authentication A wants to sign a message and send it to B we think we have some message and that we want to send to B and we attach a signature I would denote as S the signature where the S is calculated what is the signature equal we encrypt using the private key of A the hash of the message so similar concept to the authentication we encrypt with the sender's private key I sign it with my private key I sign it with a thing that only I have but in practice what we do is we don't encrypt the entire message we only need to encrypt a hash of the message the properties of the hash functions means that if the message is changed then the hash value will not match when we verify it, receive a B so we can say the signature of a message is the encrypted hash value when we use the private key of this sender what B does, they receive the message they use A's public key to decrypt this hash the received message and compare to the received hash value if they match, good, if they don't match something's gone wrong, don't trust it alright, everyone remembers from before the med term, good any questions encrypt with the private key for authentication in a specific case encrypt the hash value of the message with the private key for a digital signature and we'll see how that is used in certificates for web browsing it's the similar concept we want to, as the web browser when I receive something from the web server I want to be sure first that it is the right web server so we'll use these concepts to provide that authentication, provide that proof so let's look at digital certificates so with web browsing we want to do authentication and encryption to do that we need to have some secrets shared to do the encryption we need to have secrets shared between browser and server so if I want to encrypt with AES or triple desks on both sides the browser and server need to have a shared secret key and we can use public key cryptography to exchange a secret key so how do I get a secret secretly to someone else we can take advantage of public key cryptography to do that that is the confidentiality step here if I want to send a secret from A to B what I could do is generate a random key that secret and encrypt that with B's public key and send that to B so instead of the message M here we need to send a secret key that A and B are going to use to do the encryption and the way to do that across an insecure network is to use public key cryptography in the confidentiality mode but for A to send a message to B it must know B's public key so for this part to work we must know B's public key and we need to make sure that it is public key so that's something that we haven't discussed much is that okay public key encryption we encrypt with someone else's public key how do I get someone else's public key can you tell me how would I get someone else's public key how could we distribute public keys put it on Facebook post it on Facebook it's your public key you can put it anywhere anyone can see it attach in the bottom of your email in the case publish it somehow okay so I can publish my public key now your problem then is how are you sure it's me that's publishing Steve's public key it's not some malicious user saying here is Steve's public key but it's in fact that malicious user's public key that's the challenge we have how does someone know that it is indeed that user's public key anyone how do you know so if I write a public key or I post a public key on my website and say this is Steve's public key and I say download it and use it to encrypt a message to send to me how do you know someone malicious hasn't put it there pretending to be me we could try how would you try to the way that we in certificates in general is to get someone else to confirm it is mine to someone to sign it saying yes this public key is in fact Steve's public key we'll get a trusted person to sign it and as long as the receiver trusts that third party then that scheme will work so what we could do is say okay on my website I put my public key but I also attach a signature where it's signed by Dr. Tanarak and you all trust Dr. Tanarak so when you get it and download and you verify then you know since Dr. Tanarak has signed Steve's public key this must be Steve's public key so what we need is some other party we say a third party to validate or to vouch for the fact that this is my public key so we'll see how that is used in digital certificates so we need a public key before we can encrypt data so the challenge is for example with HTTPS if a server sends the public key to the browser how does a browser know it is indeed the public key of the server and it's not someone pretending or has modified the public key of the server to be someone else and the way that we achieve that is we get what we call a trusted third party someone else to confirm that this public key is the public key of the server it's not someone pretending to be the server so let's go through the steps that are involved in doing that for web browsing and we'll introduce what do we mean by certificate and then we'll see some examples so the aim is for the server to get its public key to the browser and for the browser to be sure that it is the public key of the server it's not someone pretending to be the server that's our aim so there are two steps involved first let's assume the server whoever runs the website has created their own public key pair so PUS and PRS that's the public key of the web server private key of the web server and then the server goes to this third party and this third party we refer to as a certificate authority and they say so they may physically go to some organization we'll talk about ways that this can be achieved but they somehow go to some other third party, some trusted person and say I am this server I own www.myuni.edu I own that web site and this is my public key please certify it so the server confirms their identity I'll denote as IDS the identity of the server with the certificate authority and the certificate authority, CA for certificate authority issues what we call a digital certificate just a certificate in short and the way that it does that is it signs the public key of the web site of the web server so the notation the key information in a certificate is listed here, CS C for the certificate of the web server and we'll see that anyone can have a certificate it contains the identity of the server the public key of the server T is a timestamp we'll see in practice usually the certificate is valid for a certain period of time say for one year so some time information saying that this certificate is valid from today today's date up until this other date so that's what I mean by here T the timestamp and then the that information is signed IDS, PUST that information we calculate the hash of that combined together and then encrypt the hash value with the private key of the authority so this is the authority signing that information coming back to our digital signature just remember the digital signature we have some message that information we want to sign and we take the hash of that message and encrypt it with the the signers private key so in this case we encrypt with A's private key we have the message which is the identity of the web server the public key of the web server and a timestamp we calculate the hash of all of that and then it's encrypted with the private key of the authority and that encrypted portion is what we refer to as the signature and it's combined with the original message so the message combined with the signature and this will denote as the certificate of a of the server so we say a certificate contains the identity of the server the public key of the server a timestamp and all of that data signed by someone else and the someone else we're referring to as the certificate authority later we'll look at a specific format so when we send certificates across the internet using HTTPS they are not just this information there's some standards for the format and one of them that's commonly used is X509 so I'll show you examples of the exact format but we'll see it contains this information so a website obtains a certificate so when you set up your website in particular you want to support HTTPS you need a certificate let's say our website has the certificate then what happens when the browser contacts that website the server responds by sending its certificate to the browser so cs the certificate of our server is sent to the browser and then the browser verifies that we can try and draw that cs the certificate of the server is the identity of the server, the public key of the server the timestamp and then we take all of that those three values and take a hash of that and then encrypt with the private key of the authority so this is this equation that certificate is obtained when someone sets up the server usually just done once maybe once a year for example later and the server stores its own certificate remember the aim for HTTPS the browser needs to get the public key of the server so that it can use the public key of the server to encrypt values but he wants to know it's got the public key of the server not someone pretending to be the server so we use the certificate to do that how now when the browser contacts the server and if we remember back to last week we saw the SSL exchange and then we saw things like hello messages and there was a message coming back and there's one message that comes back that contains cs the certificate of the web server so part of SSL the secure sockets layer which is used by HTTPS before we transfer the web request and response we do some exchange between browser and server and one of those packets contains the certificate of the web server cs there are other packets as well but we're focusing on the certificate what does the browser do when it receives a certificate what do you do when you receive a signed message decrypt so we verify by decrypting we check we verify we say here's the certificate it says here's the certificate of the web server here's the public key of the web server but the browser wants to be sure is this really the certificate of the web server or maybe someone sent a fake certificate someone modified it along the way so how do we check decrypt using what decrypt using the public key of ca if something was signed with the private key of the ca to verify we need to have the public key of the ca so for this to work the browser must already have the public key of the ca so the browser must have the public key of the ca for the verification to work and think of a certificate as a way to store a public key but that public key is signed so the purpose of this ca is to really transfer the public key of the server and to allow someone to verify it's the correct public key so the browser needs to know the public key of ca for this scheme to work we'll talk about how it knows it shortly if they do know the public key of ca then they can verify and decrypt I'm not right at all but decrypt using the public key of ca the signature part that is this part here the encrypted hash value the hash value was encrypted with the private key of ca so we'll take that signature component and decrypt it with the public key of ca and then compare with the hash of the values so the verification and we've seen this before to verify something we decrypt with the public key we get some value and then compare that value with the hash of the data received the data in this case is the id public key of the server and the timestamp if they match verification is successful if they don't match it fails and if it's successful what it means from the browser it means I now have the public key of the website and I'm confident I've verified that this public key is in fact of the website it's not from someone else how do I know that because this certificate authority this other entity signed it confirming it was that of the website there are a few issues with getting that in practice but before we look at them any questions on the steps there right so there are still some issues of okay what do we say we said the server gets a certificate at the start and the way they get that is they create their own public key and the certificate authority signs it they say yes this is the public key of the server then using SSL the certificate of the server is eventually sent to the web browser and the browser uses the public key of the authority to verify so the question you're all asking is where did the public key of the authority come from how does the browser know that PUCA the public key of the authority is in fact the public key of the authority and not someone pretending to be the authority we have the same problem but how do we know that let's say the public key of the CA this was from a malicious user then that malicious user could have signed the public key of the web server the fake web server for this to work we must be sure the browser must be sure that the public key of the authority is indeed the correct public key it cannot be that of someone else pretending to be the authority because that's the same problem we're trying to solve here the problem was how does the browser know that the public key coming from the server is that of the server and we said well we get someone else to sign it we get the authority to sign it confirming it is so we can do the same with the public key of the authority get another person to sign this public key CA and confirm this is indeed the public key of the authority so we could store that public key of the authority in another certificate so we can think that the authority and I've got another the certificate of the CA is the it's on the slide is listed here the certificate of the CA is the identity just to say this is who we are combined with the public key of the authority some timestamp combined with the encrypted hash value the hash of all of that that is all those values on the slide it's written clearer but we just hash the the data here and we encrypt it with whose private key when someone signs a message they encrypt with their private key message not the server, not the client the idea is that the authority signed the server's public key they said this is the server's public key when we sign something we confirm this is valid so the authority signed the server's public key and now we're saying well the public key of the authority needs to be signed as well so that we can trust that the public key of the authority sign your own that that's what happens in many cases that is you could sign it yourself but we have a problem with that because eventually you must trust that authority another approach is to get another authority to sign you have a hierarchy for example an entity a government organization inside the country so everyone who creates a website creates their own public-private key pair they go to that government organization and the government organization signs their public key the public key of the website but the public key of the government organization may be signed by some other organization maybe a regional organization or a worldwide organization so we may have a hierarchy of authorities so there are two options here the one on the slide is it signs itself another option could be it's signed by someone else the private key I'll deny it as CA2 a different authority signs this authority's public key but then we have the same problem who signs the public key of CA2 so eventually you need to get to a point where someone will sign their own public key and that's what I've written on this slide that is the public key of the certificate authority was signed by themself so this is really saying the authority saying here's my public key and I that's for the fact that it's my public key there's no one else confirming that it's the public key of the authority so when you receive this certificate you must implicitly trust it there's no one else vouching for the authority but you could have a hierarchy but eventually you would need some what we call this is a self signed certificate it's the certificate of the CA signed by the CA they signed it themselves it's sort of like if you write a recommendation letter for yourself okay you're applying for a job you need a recommendation letter and you say I'm a good student signed by myself when you submit that for your job application maybe people will not trust it so much that's what we're doing here it's a self signed message but in this case we need to do this otherwise there's no no endpoint if we need to get someone else to sign it like we had the authority sign the service certificate then that worked but then we need someone else to sign the authority certificate we can do that but then we need someone else to sign their certificate and it's never ending so eventually there must be some self signed certificates and in practice there are many so in our case if it was signed by CA2 then CA2 would have a certificate too okay just to be the same as the slide so let's say it is a self signed certificate signed just by the CA let's look at this in practice and look at an example when we visited the website and see the certificate and see how it was signed so the certificate sent using HTTBS specifically SSL the CS follows a certain format and that format is standardized as a standard X509 and we'll look at our web browser and see the certificate that was sent and received by my browser first we'll visit a website a real one this time and in this case I'm using HTTBS let's see if it works okay so I visit the website and there was no warning in this case we'll talk about why that was the warning in the previous case there was and we see the padlock up here and if I click on the it says verified by start com limited and if I click on it I can see some more information and here I can view the certificate and it's got a summary of the information and we'll look at the detail shortly we talk about a certificate is issued to someone the owner of that certificate it's issued to them and it's signed by someone else so it's issued by someone else so it's normally in this case the certificate is issued to the website or the web server and issued by the authority so here it summarizes the information which is stored inside this certificate it's issued to www.sandylands.info so that is the address, the domain name of the web server so in the notation we use I said IDS of the web server in using certificates for HTTPS the ID is the domain name of the web server there may be some other information like the organizational unit so the company, the department so we may see other examples usually that's optional the most important thing is what's called the common name which is the domain name of the web server and it was issued by the authority and the authority in this case is a company called StartCom specifically we may see StartCom has different names or different certificates and it's the StartCom class 1 primary intermediate server, CA and the time stamp I said was something that indicates the how long this certificate is valid for so in this case it begins on the 30th of May last year and it ends next month so usually certificate in this case it's valid for one year and the signature remember we take the hash of the content and then encrypt it and this shows some of the the summary information using the hash of all the data in here so the char value the char fingerprint but let's look at the details and see the more precise fields in this certificate so the detail shows us even more so the certificate it contains a lot of information the version so this standard has gone through multiple versions the certificate has a serial number so each new certificate can get a different serial number the algorithm used remember we take a hash of the content and encrypt it what hash algorithm what encryption algorithm char256 was the hash algorithm and the encryption algorithm was RSA so we need to know that because it's not fixed it may be different algorithms used there so it's stored inside the certificate the issuer is the authority who issued who signed this certificate there's a company called startcom the validity so the dates it's not valid before this date nor after this date the subject is the server the who's certificate it is and CN is the common name which is the domain name of the web server the country and other information may be included so that's the identity and we also of course the main thing is the public key of the server so that's included here what algorithm is used for the public key RSA what is the public key if you go back to your lectures on RSA I think we didn't cover the algorithm in detail but the public key in RSA is made up of two values some modulus and some public exponent e the actual public key is listed here so if you study how RSA works you'll make sense of what that value means that is the public key so we have in the certificate the public key of the user of the web server the identity of the web server some timestamp we also have the identity of the issuer the authority some information about the the algorithms used and extensions are some optional extra fields some ID for the certificate some ID for the authority and we'll not talk about it yet but we'll see later that sometimes certificates if there's an error or something goes wrong can be revoked so some ways for revoking certificates so the optional fields so in this case in back to the summary information this is a certificate of the website signed by startcom the certificate of the server so the server in this case the identity of the server with the domain name and that certificate was signed by the authority so the identity of the CA was the company startcom and when that certificate it was sent to my browser I received it and how did it verify when my browser received the certificate how did it verify decrypts remember the certificate is the public key of the server signed with the private key of the authority so to verify you need the public key of the authority so when my browser receives the certificate to verify what do we need to verify which key the public key of the authority is needed to verify and in fact how do we store public keys we store them in certificates the role of a certificate is really to store a public key but not just the public key the public key signed by someone else so that we're sure we can prove that it is the correct public key sending us a fake public key so when I say yes we verify with the public key of the authority and with HTTBS that is represented inside the certificate of the authority so yes we verify with the PU CA which is in which is stored in CA the certificate of the authority so if I know the certificate of the authority and I trust it then I know the public key of the authority and then I use the public key of the authority to verify the certificate of the web server and if that verifies I now trust the public key of the web server and that was our aim for my browser to get the public key of the web server and trust it so where is the certificate authority. This is the certificate of the web server, signed by the authority. The authority is called StarCom, class one primary intermediate server. Where is the certificate of StarCom? My browser received this certificate. To verify it, it needs the certificate of StarCom. It may be self-signed or it may not, but where is it? Well, let's have a look. In your browser, there's a way to view the certificates that you currently have. If we go to our preferences or the settings of your browser, you'll find, usually under some advanced settings, the certificates. And you can view the certificates. And there's different information here, but we'll come back to these too. This is a certificate of ICT server and my fakemyunit.edu website. But we also have a tab for authorities. The authorities are those certificate authorities that my browser currently trusts. And you'll see there are many of them. There's not just one authority in the world that would not be convenient. So there are many different authorities that can sign web server certificates. And we were looking for StarCom. So we scroll down. The StarCom class one primary intermediate server CA. We can open that and view the certificate of this authority. So this is stored inside my browser. For some browsers, it's not stored by the browser. It's actually stored by the operating system. So your operating system may have this database of certificates. We can actually view that one and see that this certificate is issued to StarCom class one primary intermediate server and issued by another authority. Same company, but just a different name here. StarCom certification authority. So there is some hierarchy in this case. The web server certificate is signed by StarCom class one. StarCom class one certificate is signed by the StarCom CA. So there's some form of hierarchy. Where is the certificate for StarCom CA? It's also in the database there. It's this one. This certificate for StarCom CA is signed by StarCom CA and G2. I think it turns out here's another one. So StarCom CA G2. Is that there? Yes. This certificate StarCom CA G2 is signed by who? It's signed by itself. Issued to StarCom certification authority G2. Issued by StarCom certification authority G2. This is what we call a self-signed certificate. This is when you sign your own recommendation letter. So in this specific instance, there's multiple levels in the hierarchy. The web server certificate was signed by one authority, signed by another and another, and eventually the top level was this self-signed certificate. It's just within that organization StarCom that they have different levels. We'll talk about that the practical aspects later. Valid for 30 years. Okay. There are some issues with that. Certificates can be revoked. Even though it's valid for 30 years, there is a ways to revoke and say this is no longer valid, but it creates problems if that has to be done. So we talk about a hierarchy of certificates. This is the root of the hierarchy, and we will refer to it as a root certificate authority. So to finish today, we want to get a public key from web server to web browser. But the web browser wants to be sure it's the correct public key. The reason we want the public key is so then we can encrypt some secret key with that public key. To be sure it is the correct public key of the server, we get someone else to sign it confirming it is. And that someone else is referred to as an authority. There may be multiple levels of authorities, and it finishes at the root level, which is a self-signed certificate. What you should do before tomorrow, because it's hard to see on the screen, open up your browser, preferably on a laptop or PC, not on a phone, it's hard to see or it's hard to access, open up your browser and view some of the certificates. Some of the ones which are maybe listed in the servers, it may be different amongst different browsers, but there will be different types of certificates. These may be some of the websites that you've clicked on trusted. At the first case, we said, yes, I trust this. That added an entry for my uni.edu. It's just temporary. And look especially at the authorities. Essentially, all the certificates listed here means you trust these organizations to sign other people's certificates. And you'll see that there are many of them there, companies, government organizations and so on. Have a look through your web browser and see who you trust and we'll discuss the implications of that tomorrow.