So, this takes us to web browsers. How is it that web browsers establish a secure connection? We've talked about men in the middle attacks, and that ones a toughy, because if someone can establish themselves in the center, they basically act as a proxy for both of sides of they're various savvy, and it's very difficult to detect that there's man in the middle. So, there's a collection of utilities and protocols, and specifications known as TLS, or the precursor was SSL. So, TLS stands for Transport Layer Security, and SSL stands for Secure Socket Layer was the predecessor, and my thinking is encompassed within TLS now if my understanding is correct. So when a connection is secured by TLS and in our case, a web browser and a server, the connection will have one or more of the following properties: the connection is private. It means, it's secure, where Eve's trying to listen in but the data-path is encrypted, so we're frustrating Eve. In this case, it's secured by symmetric encryption. We'll see how that works coming up. The identity of the communicating parties can be authenticated using public key encryption. They are who they say they are. The connection has integrity because each message exchange is protected by a MAC field. I don't think I actually included that in my upcoming slides. So, we want to bring all of these things together. We want to make sure our communication has integrity, it's not being modified while it's in flight. We want to make sure that when web browsers talking to a server, it is the server we believe it is, and we want that all those messages to be encrypted, so it's secure. So here's some examples of how web browsers tell us what the level of what's going on in terms of authentication and encryption. So, I think these two came from the Safari browser, this one might have been, Firefox. I just went to websites just to see what the icons were displayed. So, in Safari if you see this colored lock, it means the connection is encrypted and authenticated, and it's using a standard certificate. We'll get to certificates here in a minute. Okay. You see these different colored lock icon, it means it's encrypted and authenticated with extended validation certificate, which is a more robust certificate than the standard certificate. I'm not going to go into what the differences are. I just wanted to point out that there's at least two levels of validated certificates. If you see, this one that says https, s is supposed to stand for secure. And it's got this line through then an x. So it means it's encrypted but it's not authenticated. Might not be talking to the server, that we think we are. But nonetheless, the data's being encrypted back and forth between the server and the client. If it's not encrypted at all, I just went out to Matplotlib, I was working on my Machine Learning stuff at the time, and they didn't anything there. So, you don't get any icon so, that's one wide open, so there's no security, there's no authenticity, and there's no data integrity. So, here's how this works. So some company it's going to set up a website, and they want it to be secure. So, company that owns the web server creates a certificate and there's a bunch of data, and just think of a certificate like a database entry with a whole bunch of fields and a bunch of numbers and then, information that they fill out. They have created a public and a private key pair on their side at a time of so many bits in length. They prepare their certificate and embedded in the certificate is their public key. They send this certificate, to a Certificate Authority. We've companies like Verisign, and RSA security and others, there are a bunch of certificate authorities out there. So they take the certificate along that has the public key embedded in it, and they run it through a cryptographic hash function to get the digester, the MAC out of it. Okay, so they take the digest. They got the digest here. Now, the Certificate Authority has generated their own private-public key pair. They take the digest, and they take their private key and they encrypt it. This is the signature. The signature gets embedded in the certificate from the company that's requesting the signing. It's stuck in there, and is sent back to the requesting company, for their web server to hand out to web clients that are asking to communicate with the server. They also in order to make this work, has to make the Certificate Authority's public key, publicly available at someplace. In some way, and you'll see how this works when, our web browser clients want to authenticate the certificate, it needs access to this, Certificate Authority's public key. Any questions about that? So, here's what happens. Here's our client, or our laptop. Here's the web server, it's got public and private key, it's got the signed certificate, and the public key is part of their certificate, and the private key is kept private. Is like we'd seen in all of our scenarios with asymmetric encryption. So, the client makes an SSL connection request to the server, saying, "I want to talk to you securely." The server responds with the SSL certificate, and shifts it across the link to the client. So, over it goes. The client validates, authenticates, the certificate couldn't fit that all in one slide, so I have a separate slide, coming up here where we will see how the client actually validates that certificate. But, the client will go through this, our web browser will go through this process of authenticating the certificate to make sure it is legit. That it can be trusted. So that, happens in step three. Step four, the client generates a symmetric session key, and sends that key to the server. So, generates a session key. Some random number, of hopefully high quality, and the client takes the public key from the signed certificate, and uses that public key to encrypt this session key. So that when it's sent across and insecure public transport, it cannot be observed and it's received by the web server that uses the matching private key to decrypt it and establish the session key. The last step, is the SSL session key, is available now, and is used for subsequent communication in step five. So we've got this key here, could be using AES or RSA encryption, or othe- yeah probably AES, but some kind of some- sorry, not RSA, be using AES algorithm or some other symmetric encryption algorithm uses a shared common key on both ends. Okay. So, this is what happens. The reason this works and we trust it, we deem it good enough is because it involves this third party, this Certificate Authority, that's why we trust it. So, many options exist for the client and server to establish, what signing and encryption algorithms are used, as beyond the scope of this class, but there's a number. I've got a couple of certificates that I'll show you in a second, just so you can get a feel for what's in there. So, here's what the exploded view, of what happens when the client wants to authenticate the certificate. So, the client will receives the certificate with the signature and the public key, and extracts the signature, and the client goes out to the Certificate Authority where the public key is published and is made available, posing the public key, and decrypts the signature, and produces a digest. Then it takes the certificate without the signature, and runs it through the same cryptographic hash function that was used when, the company originally sent the certificate to the Certificate Authority to be signed. Runs cryptographic hash on that guy, and produces a digest and compares these two, and if the result is the same, the browser now trusts the server. Here is- I know it's a night chart. I'm just going to point out a couple of things and you can look at these slides later, to see. This one was issued by Apple. They have they call the Integration Certification Authority. These certificates have a date range, on them they can expire some time. So down here, this big long number 256 bytes, this is the RSA public key here. Here's the exponent is 65537, the key size is 2,048 bits, and the uses for this key to encrypt and verify and derived, and here's a signature. Here's it's 256 bytes as well, that's that signature that Apple generated, and is embedded in the certificate. Here's another one from Lauderbach, and I got this when I started interacting with Lauderbach and I never got signed emails before, because message pops up do you want to trust the certificate of McLeod, this is just an email. Okay. I went later and looked the signature algorithm on the Apple one is a shot 256 with RSA encryption, and then there is this version 1.20.840.1113549.1.1.11. I might think they're getting a little ridiculous with the revision numbers but anyways, that's the revision of RSA encryption. This signature algorithm was a short one with RSA encryption, in it. It's a completely different version of RSA encryption algorithm. So that's what certificates look like. So the schemes that we use for web browsers, can be used when we're deploying an IoT system, this would be a great model to copy to provide secure communication. We trust it with our banking, we trust it with our health information, so far to-date. We're not aware of severe threats to the scheme. So in summary, certificates are issued by trusted organizations of Verisign and others. Your bank requests a certificate from Verisign and includes the banks public key. Versign confirms the identity the bank, the server creates the certificate and signs it, or actually its already created, signs it and then gives it back to the bank for the bank's server to handout, and then the browser receives the certificate, and checks the certificate's authenticity, and trust is established.
