 Let's finish on certificates and this aspect of web security, so next week we can move on to a different aspect of web security. We got to, yes, on Tuesday this case saying, we want to use public keys to encrypt secret keys. So the browser and the server need to secure their communications, and to do that we're going to encrypt our data with symmetric key cryptography. So browser A, server B, in order to encrypt the data, first we need to both have the same secret key, and in this example, so this is similar to the diagram we come up with at the end of Tuesday, and Tuesdays may even be better. The idea was that A and B both need to have a shared secret key, K, A, B. They both need to know that. So the approach is that A chooses this value, say a random key, and to get it to B, A encrypts using public key and cryptography. So the idea, although I've written C here and read, the idea is that A would encrypt with B's public key, PUB, and therefore send that ciphertext to B, and if it was encrypted with B's public key, only B could decrypt and get that secret value. That's the idea. But there's a flaw with that approach. If some malicious user C here, if they can get A to think that B's public key is some other value, in particular the public key that C knows, the malicious user, so if this malicious user can trick A into thinking, here's the public key of B, here's the value, but in fact it's the public key of C. So what A does is they encrypt this secret value that I've chosen with the public key of C, they send it to B across the Internet. But somewhere in between computer of A and B, C intercepts that packet or those packets before they go on to B, they intercept them, because it was encrypted with the public key of C, the malicious user can decrypt and get this secret KAB. So the malicious user learns the secret value that A chose, and then what the malicious user does is they encrypt that same secret value with the original, the true public key of B, and forward that message on to B. So this is what's sent to B, encrypt of KAB with PUB, B receives this message thinking it's from A, decrypts, because they have the private key of B, they get KAB, so B has just received a message, they think this comes from A, when I communicate now with A, I'm going to use the secret key KAB. And similar, when A receives data encrypted from B, it's going to use a secret key KAB. So they think they're going to communicate securely using this secret key, but what the malicious user is going to do is whenever A and B send data from now on, the malicious user, if they can intercept that data, they can decrypt it, because they know also KAB. So that's the attack that if we use public keys, there's this scenario which under two conditions, under the condition that the malicious user can fool A into using the wrong public key, that's the first thing for this attack to work. So here's the public key of Steve, you use it to encrypt data to send to me, but in fact it's not my public key, it's another student's public key, but you don't know that. So if someone can fool you into using the wrong public key, and if that malicious user can intercept the communications, because that's required here. So if they can do that, then this attack is successful, and our encryption is not secure, our communications are not secure. Is it easy to do this? Well, to intercept is generally easy in the internet, because in the internet between your computer and web servers, there are many different locations where someone could intercept over the Wi-Fi network. If the packet's going from your laptop up to the access point, inside SIT, anyone could intercept and get copies of that, modifying is harder. But if you had access to the devices in the internet service provider, anywhere in the world that the packets go through, then someone could intercept and do this. So if you want secure communications, you don't want to rely on the fact that internet service providers are trustworthy. Assume that there may be people there that would do this. So it's generally easy to do this. Now how easy it is to fool A into using the wrong key, again, not so hard, unless we have other mechanisms to make sure that when A uses a key, that they're confident that it is B's key, it's not someone else's. And that leads to certificates, questions, before we go to certificates. He is in the internet, or she is in the internet. So they need to be somewhere between, so A is a computer on the internet, B is a computer on the internet, and they're sending packets to each other. The malicious user needs to be somewhere where those packets flow via. And they need to be able to intercept those packets and take a copy and send new packets in their place. Where can you do that? At access points, if you have physical access to network devices, switches and routers, maybe a wire, a LAN cable, if a malicious user can, okay, they know all the traffic going from here to Runxit via some cables. If they can go to one of those cables, dig a hole, cut that cable, and insert a device that would take the packets, modify them, and send on new ones, then they can do this attack. So anywhere between the source and destination, they need to be able to access those packets. They can't go in many ways. They can't be anywhere in the internet, they need to be on the path between A and B. So can I say, from the employee to the ISP, and another is from the ISP to another employee? The packets take a path through the internet, okay? So you need to be, the attacker needs to be on that path. Okay, same as if you drive into Bangkok along one particular path, you need to be on that particular path to intercept. So if our packets go from Bangkok to Tokyo, across the Pacific to California, and then to a web server, those specific links and those specific devices that the packets go via, to do this attack, the attacker needs to have access to them. They cannot be in Europe to do the attack, they need to have access to those particular links that those packets go via. If they're not, yeah, they cannot do the attack. But getting access to those links, well, we cannot assume that they are always secure. So assume that it is possible to get access. Of course, sometimes it's going to be harder than others, but assume someone can. So they need to be on the path that those packets go via. That's the condition there. So we need a way so that A, when it has a public key, it knows for sure it is B's public key. How do we do that? How does A know for sure this is B's public key? Trust someone, trust who, trust, yeah, you need to trust someone, trust some other organisation to do what, and what do that other organisation do? Verify, yeah, you need some other organisation that you do trust to confirm that this is the correct public key. So you need some other entity to say, when you're using this public key, this indeed is the public key of B. So we need some other organisation to do that, or some other entity. We get a trusted third party to confirm it is, in this case in web browsing, to confirm it's the server's public key. So when your browser has a public key, and it says it's from the publickeyforfacebook.com, then we need some other entity to confirm. This is the public key of Facebook, it's not the public key of someone pretending to be Facebook. So this trusted third party we say is another entity in the system that we trust, we in this case the browser trusts. The concept is implemented using digital certificates. So there are two steps on these two slides, we'll briefly mention and then draw some diagrams to capture them. So we assume that the server, the web server, or the owner of that server, creates their key pair. You know it's PURPUSPRS, that is the key pair of the web server. They create their own, and then they go to some trusted third party that we'll call the certificate authority, CA, some organisation, some entity, they go to them and say I own this server, they show them their ID, so we denote that as identity of the server, IDS, and that certificate authority, once it can confirm that this server owner, the identity matches that of the server and that this is the public key, then they issue a certificate saying this public key is in fact belonging to this identity. So this is what a digital certificate does, it confirms that a public key belongs to a particular user and they issue a certificate and the way the certificate is structured is that it contains the identity of the server, say a domain name, www.facebook.com, it contains the public key of the server that the server chose, the server owner, maybe a time stamp to say that this certificate is valid from today for another year, so that we can expire the certificate if needed. And then a form for the authority being able to prove to others that it has confirmed that this identity and public key are related. So it signs those values, so we use a digital signature. Remember a signature is you encrypt the data using your private key. Well practically we encrypt the hash of the data using the private key. So we see here the CA uses their private key to encrypt the hash of this information. That is the ID of the server, the public key of the server and some time stamp T, that's the concept. So this certificate is saying here is the public key of this entity and I as the CA confirm that and later we'll see that others can check, validate or verify that public key by decrypting with the public key of the CA and comparing, so validate the signature. So this is the certificate of a particular server S, say of Facebook.com. It contains the public key, the identity of the server, a time stamp and this part here is the signature, this data encrypted and signed by the CA. So we use a time stamp for example to say how long this is valid for so that after one year or six months you need to get a new certificate. So it's not valid forever. Now this is the general concept, there are specific formats for these certificates and X509 is the standard that specifies the common format used for certificates. We'll see some examples of that. So when we say the identity and public key, what actual information is stored there for web servers? We'll see a particular format for that shortly. So that's the first step. You think of every web server obtains a certificate and usually that's done, I would say manually, it's not done automatically across the network. It involves some user, the owner of the server, somehow confirming that they do own this website. So if I go to some certificate authority and say please give me a certificate for www.facebook.com the authority should say no unless I can prove that I own that domain they should not issue me a certificate. They should have some way to verify that this person asking for the certificate and this public key is in fact the owner of that domain. So step one, servers obtain certificates. Step two, now when a browser accesses a website, so back to our case, browser A accesses the website B. Well, we need, the browser needs to find the public key of B. So to do that, the browser initiates communications with this server, the server sends its certificate to the browser. So it sends CS to the browser. So the browser now has CS. And let's just go back. So the browser receives this information and it includes the identity of the website, the domain name, the public key of the server. But how do we know this is the public key of this server and not someone pretending to be this server? Well, we know because this information is signed by someone we trust. So we as the browser trust the certificate authority because this information is signed by the certificate authority, we trust this information. How do we confirm that? Well, if it's signed by the, using the private key of the authority, then to verify this is correct, we decrypt that signature using the public key of the authority. So my browser, when it receives a certificate, it verifies that certificate by decrypting this component with the public key of the authority. For that to work, the browser must have the public key of the authority. And that's where we say the certificate authority is a trusted third party in that we know the public key of the authority and we know for sure that's the correct one. Once the browser can verify this is the correct certificate signed by a trusted authority, then it has the public key and we can continue and do these steps correctly. That is, instead of using the wrong key, we can make sure that we have the correct public key and avoiding the attack. So this assumes the browser already knows the public key of the authority and trusts it. That's where we say the authority is a trusted third party. The browser knows for sure this is the correct public key. If not, we have problems. Let's see how that works as an example. We have our browser and some server with some domain, fb.com. That's the identity of the server, the domain is. So the browser visits the website. So someone types or clicks on a link to the URL. We're using HTTPS with that domain and maybe some path, but we focus on the domain. So the browser wants to access fb.com securely, therefore it needs to encrypt the data. So to do so we need the public key of fb.com. So this is when we use Secure Socket Slayer SSL to do some hello exchange and the server will send its certificate to the browser. So the server has a certificate already. Let's denote it as CFB. That is the certificate of fb.com, which includes the values that the public key, so it includes the identity, say the domain name, the public key, a timestamp, and that information is also signed. So the certificate is those three values plus the signature, where the signature is the private key, that's not CA. I'm going to run out of space of the hash of all of the above information, all of these values. That is the certificate contains identity, public key, a timestamp, and then all of that is hashed and encrypted with the private key of an authority, and that's the signature. So the certificate is all of these four values, the signature plus these three values, in the same structure as on the slide. That certificate is sent by the server to the browser. So after the browser contacts the server, they eventually send back the certificate. And now the browser verifies the certificate. That's important that we don't just trust the certificate that we've received, we must verify that it's correct. How do we verify? How does the browser verify the received certificate? Again, how does the browser verify this? So they just received a certificate, how do they verify that it's correct? Use the something. Use the public key of CA to do what? What do they do with the public key of CA? Decrypt S. So remember the certificate contains think of these four values. So they decrypt the signature part. In the slide, the signature is S is this part. It's these three values hashed and encrypted with the private key. So this is S, the signature part in my picture. So yes, they decrypt that using the public key of CA. I'll just denote S here, which is this value. If nothing's been changed, if everything's correct, then they should get, when they decrypt, they'll get a hash value as the output. But as the input was a hash value, so when they decrypt, they'll get a hash value as output. And they'll compare that hash value with the hash of these three values that they have. And this is just the normal signature, that if the hash of those received values matches the decrypted hash value, everything's assumed to be correct. So once they get the hash value here, they hash those three values and compare. We can write that. So the output of decryption will be some hash value, let's say H, and then they take the hash of the received values of ID, the public key, and the timestamp, and they compare these two values. Let's say this is H1, this is H2. If they match, everything's trusted. If they don't match, don't trust. So this is the normal approach that we've considered with signatures. And if they match, then we now know that this public key, the public key of FB, belongs to FB. Why do we know that? Because it was signed by someone we trust. We trust this certificate authority to issue certificates only to the people who can identify that they are the owner of a particular public key. So as long as we trust CA, we trust now the public key of FB. And now we can encrypt a secret and send it to the server and set up our secure communications. Questions so far? So we receive a certificate. Verify that certificate. To verify, we need to know the public key of CA. Where did that come from? So that's an assumption in this process that the browser already has the public key of the certificate authority. And normally the public key of a certificate authority is stored as a certificate itself. The public key of CA is stored as a self-signed certificate. So it's the identity of CA, the name of the authority, the public key of the authority, some timestamp saying how long it's valid for. And all of that is signed, so the hash of those values encrypted with a private key of the authority. Note this is self-signed. Who signed these values? Whose private key did we use? We used our own in this case. That is, the authority is signing this public key of itself. So we call this a special case of a self-signed certificate. Whereas a normal certificate, the public key and other information is signed by someone else. CA signed this information. But a self-signed certificate, you sign your own information. We can do that because, again, we've assumed that the browser trusts the authority. So if they issue a self-signed certificate, we'll trust that. We must trust someone. So how did we get the public key of the CA? Usually the browser has pre-programmed into it, pre-loaded a set of self-signed certificates of authorities. And in the real world, we don't just have one authority, we have many different authorities. And the browsers are configured such that they have these self-signed certificates of many different authorities. So whenever your browser receives a certificate from a server, it uses these certificates of authorities to verify the server certificates. So P-P-U-C-A come from the self-signed certificate that the browser already has. Any questions before we look at some more examples and some issues? So understand the structure of a digital certificate. Importantly, it contains a public key and an identity signed by someone else, an authority. The signature is what we've covered in previous topics, is just encrypted hash using a private key. That's the signature. If the CA that we trust is hacked, that is someone else gets that private key, then we should not trust them. So when we say the CA is trusted, in theory it assumes that they will not do anything malicious and no one can force them to do anything malicious, like signed certificates of people who don't own those servers. But in practice, yes, if the CA is compromised in some way, then the security of this scheme fails or may fail. So it all depends upon that the CA is trustworthy. But if something goes wrong with the CA, then something can go wrong with this scheme. So if someone can access the authority and do malicious things, then our certificate scheme will not be secure. We can have a hierarchy. Let's go to an example and see in a browser some certificates and we'll see the generals will see some real certificates. So here is the concept. We say the certificate contains an ID, a public key and so on. But in practice, the structure of the certificate is defined by a standard. So we'll see some real certificates. It's X509 format. And we'll see that there's a hierarchy of certificates. Let's go... So let's open up a website. So I go to some URL. In my browser, I'm going to visit. So it's hard to see. So HTTPS and then some domains. So I want to visit some website. And I want the communications to be secure. Therefore my browser will need to get the certificate of this web server and verify the certificate. And of course it should all happen in the background that is not from the user's perspective. And how's it performed? HTTPS does this. We'll see a capture shortly. But the exchanges of obtaining the certificate is done via HTTPS, the protocol using SSL. So we access some website. There's my internet access work. Maybe not. Here we go. Just access a website. Okay. And now let's see information about the certificate. And you can often in different browsers you see a lock here indicating this is secured and trusted. And we can see some more information. And if we look at this security feature we see that it says this website, the domain www.eff.org is verified by some other organization, startcom.limited. Okay. Let's look at the actual certificate. So what's happened when I access that website, HTTPS uses SSL to do an exchange between browser and server. And one of those exchanges is that the server sends its certificate to my browser. And my browser then verifies that certificate. So let's view the certificate that my browser received. Can we zoom? This is a summary of the certificate. I think we can zoom a little bit. So with the certificate we talk about who's the subject, who is the certificate issued to, that is who's the identity and the public key, and who is the authority that issued the certificate, who was it issued by. So in this case, this certificate was issued to a particular domain, anything.eff.org. In websites, certificates are to domains. And some name, all right, the name of the organization that owns that, some serial number to identify the certificate, so some unique value. Who is the authority? Who issued the certificate? Again, some other name, startcom class 2 primary intermediate CA, I think if you read on that. The organization is the authority in this case. And the time stamp information. This certificate was issued on this date, 11th of November, and expires in two years from when it was issued. So there may be different time frames for when the certificate is valid. Meaning, after this date, your browser, if it receives the certificate, should not trust it, because it's expired. What should happen is that the server should get a new certificate every two years in this case, for example. So that's a summary information. Remember, a certificate contains a signature. What's a signature? It's the hash of those values encrypted with a private key. The fingerprint is just some summary information about that certificate. You'll see the details. So we look at the details, and it's not a great way to view, but if we expand, I'm going to look at the details of this one certificate, and the format is this X509 format. So it defines all the fields that we must include in the certificate. There's a version of the certificate, version 3 of X509. The certificate has a serial number. So some unique value. The algorithms used. Remember, we use a public key algorithm to encrypt the hash value. But what hash algorithm do we use, and what public key algorithm? Well, we're using SHA-1 as the hash algorithm, and RSA as the encryption algorithm. So it says what algorithm is used. There's different algorithms. The issuer is who issued this certificate. Who is the authority? There's a common name. So some string that identifies. Startcom is just a company. Class 2, primary, intermediate, I think server is down there. And some organizational unit. So some department and some short name. And the country code. So this is the authority identifier. The timestamps. So it's not valid before this date. It's not valid after that date. The subject is whose certificate it is. Issued 2. And we see the information about EFF.org. So the common name is the domain name plus some other identifying information of the server. So this is the web server information. And the country, for example. And then if we scroll down, okay, remember inside a certificate we have an identity and a public key. So here is the public key information. The algorithm used for the public key, RSA, and the actual public key. And we haven't looked at the RSA algorithm, but a public key is in two values. A modulus and some value E. So this is the actual key. And then we have some extensions. We will not go through extensions. Some extra information that may be useful in practice. The signature algorithm. Again. To sign we take the hash using SHA1 and encrypt using RSA. And the actual signature. So this part is in my diagram the value of S. So if we take the hash of all the other values we encrypt with RSA using the private key of StarCom, the issuer. We get this 2048 bit value. That's the signature. So the format is slightly different from in our slides but the information is included there. So really the issuer is the authority. The subject is the server. The subject public key information is the public key of the server and the signature is that last value, the hashed values encrypted with a private key. Now, my browser received this. How did it verify? How did my browser verify this certificate that it received? So the certificate is owned by EFF. EFF.org is the domain, the website. The issuer is the StarCom Class 2 Primary Intermediate Server CA, CA Certificate Authority. This is the person who or the organization that issued the certificate and signed it. How does my browser verify this certificate? What did my browser do? What information did my browser need to know to verify? How do we verify a certificate? We receive a certificate. What do we do to verify it? Back to our lecture notes. When you receive this certificate, how do you verify? It's signed by the private key of the CA, therefore to verify you use the public key of the CA to decrypt the signature and compare the hashed values. So you need to know the public key of the CA to verify. In this case, the CA is the StarCom Class 2 Primary Intermediate Server. So my browser needs to know the public key of this CA to verify this certificate. And the public keys are stored also in certificates. And in fact, here we see a hierarchy. We're viewing the certificate from the web server. This next one is the certificate of this authority, the StarCom Class 2 Primary Intermediate CA. So let's note what we've got. In our example, we can say we had... My browser received a certificate of... What was it? EFF.org. And that certificate was signed in step one. CS is the certificate of the server. To do the verification... No, we verified this certificate. Okay. How do we verify this certificate? What do we need? Public key of CA. Where is that? Well, we store the public key of the CA. That's what this is. This is the public key of the CA. But we don't just store the public key of the CA. We usually store it as a certificate. Because a certificate stores a public key. So this is the certificate of the CA, which includes the public key of CA. In this case, it was signed by itself. So a self-signed certificate can easily be verified. Because how do we verify the signature? We've got the public key. Not necessarily, no. Let's see in our specific example and see how my browser got the public key. In this example, we said that there was a public key. The subject was EFF.org. The issuer was this StarCom Class 2 primary intermediate server CA. So let's note that. That's the certificate. Issued by StarCom Class 2 and the rest. So that's the authority. Therefore, to verify the certificate of EFF.org, we need the certificate of StarCom Class 2. My browser needs that. Does it have it? Yes. And it's shown here. The StarCom Class 2 certificate is shown here. We see the subject. StarCom Class 2 is the subject. So it's their certificate. Their public key is there. So the public key of StarCom Class 2 and who issued this certificate? Someone else. Similar name but different. StarCom CA. The other one was StarCom Class 2 CA. This one's just, let's call it just StarCom. So let's note that. So the second certificate that my browser has is issued by someone else. And let's just call it StarCom. Similar name, it's the same company but they're different certificates. So in fact, to verify the certificate of EFF.org, we need the public key of StarCom Class 2. The public key of StarCom Class 2 is in the certificate of StarCom Class 2, which my browser has. We just saw it. But to verify that certificate, we would need to have the public key of this StarCom. Because how do we trust the certificate of StarCom Class 2? Well, it was issued by another authority. So we can have this hierarchy of authorities. So we need the certificate of StarCom. Because inside there is the public key that we can use to verify the certificate of StarCom Class 2, which contains the public key that we can use to verify the certificate of EFF.org. Who issued the certificate of StarCom? Let's have a look in our browser and it will tell us. This is a self-signed certificate in my browser. The subject, StarCom certification authority. Let's just call it StarCom. The issuer, same. StarCom certification authority. This is a self-signed certificate. StarCom has issued their own certificate in this case. So note that this one is self-signed. So my browser has all three. We need to verify the certificate of EFF. To do so, we use the public key of StarCom Class 2, which was stored in the certificate of StarCom Class 2. But to verify that public key, we needed to use the public key of StarCom, which was stored in the certificate of StarCom. But to verify that, well, this is a self-signed certificate. So that means we must trust this. Because it's verified by itself. And we can think of in this hierarchy, this is the root authority. If we trust the root authority in this case, then we can verify the certificate of StarCom Class 2, because we trust StarCom. And if we verify this certificate, then it means we trust StarCom Class 2, and therefore we can verify the certificate of EFF.org. So we have this hierarchy of trust. In this one example, there was two authorities. One verified for EFF, or signed for EFF, and the other signed for the mid-level authority. In other cases, there may be just one authority, or more, more than two. Still, we have a question. Where did my browser get these certificates? Let's have a look. I have a capture that I captured this morning. And when I accessed this website before, in Wireshark, I accessed that website. And I'm showing the SSL messages. Remember, we're using HTTPS. HTTPS is just normal HTTP, but first we set up this SSL secure connection. And these are the SSL, or TLS, is the new name. Packets. We don't worry too much about the details. The browser sending the server some hello message, some server sends back hello, agreeing upon some parameters. Then the server, 69.50 so on, sends to the browser its certificate. So this packet contains the certificate of the server. Let's look at the details. We expand, and we in fact see that there are two certificates in here. It's hard to see, but we recognize some information to scroll a bit. We'll get there. So there are two certificates included in this packet. The first one is the subject. It's hard to see. The subject is iff.org. And the issuer is this startcom class 2 primary CA. So that's the first certificate which was received from the server. In this case the server also sends a second certificate at the same time. And if we scroll down we see the second certificate is the subject is startcom class 2 and the issuer is startcom. So these are those two top certificates in our diagram. This one and this one. They were sent by the web server to my browser. So for my browser to verify, my browser now needs to know the certificate of startcom. That was not sent. Where is it? It was pre-programmed into my browser when I installed my browser. So the way that it works in practice is that when the browser developer, the people who release the browser, they pre-configure the browser with a list of certificates of what they say are trusted authorities. Organizations that they trust. I'll show you shortly that we'll see inside Firefox there is a certificate for startcom. It's already in there in the browser. Therefore when I contacted this iff.org web server, the web server sent me these two certificates. My browser used the pre-loaded certificate of startcom to verify startcom class 2 and it then used that to verify the certificate of iff.org and now it knows and trusts the public here at iff.org. So we have this hierarchy of certificates. So the self-signed ones are the ones from the trusted authorities and usually pre-loaded in your browser. And it's in practice there are many authorities, one startcom is just one company. There are many companies and government organizations which act as authorities. Let's go back just to finish. We look at in my browser preferences you can view the certificates and there are different sets and one of them is the set of certificates of authorities and you'll see the ones listed as built-in object token and they are the pre-loaded ones. So many different organizations have their authority certificate, usually a self-signed certificate loaded into the browser when you install the browser. We scrolled so many different companies and government organizations. Here we have the startcom certificate authority in here. In fact there are different startcom ones. There's a top level one that can verify that. So there's, again, a hierarchy of certificates from different authorities. So as long as your browser has the certificate of one of the authorities that has issued the certificate of the web server, you can verify it. But if you receive a certificate from a web server that is issued by someone else who's not in this list, what happens? What's your browser do? It cannot verify the certificate of the web server in that case. What does the browser do in practice? It usually gives a warning saying this is untrusted. And you would have seen that when you've accessed some of the internal SIT websites, the ICT server registration, when you first access the browser presents a warning saying this is an untrusted connection. Do you really want to continue? The browser cannot verify the certificate because it has a certificate which is either invalid, expired, signed by someone who's not in this list, like signed by themselves. So that's your browser's way of saying I cannot trust this. You need to decide for yourself whether you want to trust this website. It could be someone performing an attack. So that's how certificates are used for websites. The 509 is the format we saw. You see in your browser you should have a look at the examples, but you see there's a version, some serial number, the algorithms used, the issuer, the timestamp information, the subject, and the public key information, and then follow it at the end by the signature. It's not just ID, PU and T, it's more detailed than that. There are more details. Certificates may be revoked before they expire. If there's something goes wrong and we no longer trust that certificate, there's a way to revoke them and there's revocation lists. So to finish in the last couple of minutes, in practice, you own a website, you're setting up a web server and you want to obtain a certificate. How do you do it? Well, you need to go to a company or an organization that offers or acts as an authority. And you need to prove your identity to them. The proving of identity may be somehow to prove that you own that domain. So when you set up your website, migratecompany.com, then you need to somehow prove to that authority that you own that domain. And it's not so hard to do that. There are some extended validations where they'll actually prove that you're the owner of a company. So looking at IDs and company documents. Those are both free and commercial. There are free services that will do that for you. But you can, some services cost money, especially if you want extended validation. How do you see a browser obtain the CA certificate? At least the top level one. Well, it's preloaded into browsers. So when you install Firefox, it's configured with a set of certificates. You can add them, you can manipulate them yourself. You can delete some, add new ones. But normally most users do not. We saw that there's a hierarchy of certificates. So one authority signs for another authority which signs for another authority which signs for a website. What if your authority's certificate is not in the browser, then usually you get a warning to the user saying, I don't trust this. Do you trust this website? That's what the browser says to you. What are the problems? Well, the authorities need some way to make sure that they can identify that you do own that server. And if they don't have good procedures to verify that, then this system may fail. The authority's private key, of course, must be kept private because the authority's private key is used to sign certificates. If someone malicious finds the private key of startcom, then that malicious user could sign any certificate and sign fake certificates. So the private key of the authority needs to be, of course, kept secret. And authorities must have policies and methods to keep them secret. If they're compromised, then many certificates will be compromised. In practice, we trust the browser to give preloaded certificates. Has anyone looked at their list of preloaded certificates? Probably not. So you trust your browser to load accurate or correct certificates. If it loads certificates of untrusted authorities, then someone may do attacks by your browser. Of course, what does a user do when they get this warning message? This connection is not trusted. I'm sure all of you have seen that message and you say, ah, let's trust it anyway. But that message may be an indicator that you're being subject to an attack, a men-in-the-middle attack. The algorithms used in the certificates, the hash and the encryption algorithm, must be strong, but that's usually not an issue. So that brings us to the end of digital certificates. What you should do is maybe just have a look at your browser and follow as you visit a few websites, secure websites. Just make sure you can follow and understand what's happening. Where are these certificates coming from? What information do they include? And how is that used to verify the public key of the server? That's the main point.