 So, we've reached our final topic for the course, and this topic titled Internet Security is really a couple of examples that show some of the cryptographic mechanisms being used in practice, so in securing Internet communications, which we use on a regular basis, I'll go through really two examples, one securing web traffic, and one using secure shell if we get time just at the end, to demonstrate some of the communication protocols used, so HTTBS will use as an example, which we all use, we want to see how it works, and also when we go through and see how the protocols work, we'll see the algorithms coming into play, the public key algorithms like RSA and Diffie-Hulman, the symmetric key algorithms and Macs will come up and others, so we'll finish with these examples, and we'll focus on web security, but first, all right, some general issues with web security, so, and when I say web security, I mean browsing websites, but in fact some of these comments still apply to any type of Internet application, maybe email security, security of instant messaging applications, line and so on, so similar issues arise, so with applications that we use in the Internet, the Internet has been around for 40 plus years, and the protocols that are used to communicate between computers, and which the main one being IP, the Internet protocol, and another main one being TCP, the transmission control protocol, they were designed many years ago, 30 or 40 years ago, and they were designed assuming that the network that the users were using had no malicious users, okay, so the protocols that we use in the Internet today, which were designed a long time ago, were designed with no security in mind, they assumed that there was no one malicious, and in those days there was no one malicious, the only users of the Internet were the academics and the researchers that were using the network, NOM was maliciously intercepting traffic, there were no commercial transactions, so the design was appropriate for those days, but those protocols, IP, TCP, for web browsing, HTTP and many others, most of them were designed with no security mechanism built in, but of course as the Internet grew and the number of users and the different usage applications grew, then some security issues started to rise and malicious users started to be more prevalent, so many threats arise from people using these applications, and unfortunately the protocols we were using didn't support security, so the security issues in the Internet really, if we think about the three locations where they arise, the computers which are communicating, which we refer to normally as the client and server, can we keep the client computer secure, the disk, the memory, can we keep the server computer secure, and also what's sent between the client and the server, so imagine your phone with a web browser talking to a computer with a web server, the security issues that arise relate to securing your phone, the client, securing the server and securing the traffic between your client and server, and there are many different techniques that are tried to secure those three, we're going to focus on the traffic between client and server, not how to make sure that no one can log into your phone, but to look at the techniques to ensure that if someone sends data from client to server, that someone in the middle cannot intercept and see the data or modify the data without it being detected. There are different techniques to secure the traffic, and those techniques primarily are add-ons, add-ons to the original protocols, so the original protocols being IP, TCP, HTTP, which had no security features, people have created optional extras that you can use with IP, TCP, and HTTP to add security, and we'll look at several of them, not all, but for example to add security to the internet protocol there's an extension called IPsec, it allows you to encrypt your IP datagrams. To add security to your TCP traffic, there's an extension or an extra protocol called secure sockets layer or the transport layer security SSL or TLS, and also there are different protocols for specific applications like log-ins and email. This table shows some of the problems that can arise with internet security, and we will not go through all of them, I think some are almost obvious. Returning back to one of our first lectures, remember we talked about CIA, confidentiality, integrity, and the A was availability, and availability relates to denial of service. The fourth row in this table, authentication, we sometimes combine with integrity, so this table is showing if we want to keep our data confidential what are potential things that can go wrong? What are the threats? For example someone can listen in on the network and see our data, eavesdropping on the net. If someone does that, what are the consequences? Well I may lose information, that is others can access that information or I lose privacy. What are the things that we use to stop those consequences from arising? What are the countermeasures? Well we encrypt our data, we know in general if you want to send data across a network it should be encrypted. For privacy there are other techniques like web proxies. For integrity, how do we ensure integrity? We use check sums. Well check sums, what are they? Message authentication codes, hash functions, the techniques we have looked at. To provide authentication, well we have got different cryptographic techniques. What is the one we looked at most recently? How do we provide authentication in web browsing? How do we authenticate the server? Certificates, so the previous topic we finished looking at digital certificates where a server has a certificate which includes its public key and it is signed by some trusted authority. So the browser when it gets that certificate can authenticate and check that it is communicating with the right server. So that is one of the cryptographic techniques used for authentication. So check sums, message authentication codes we have covered in the topic, used for integrity, hash functions, used for integrity, similar and digital certificates used for authentication, encryption, mainly symmetric key encryption but sometimes public key encryption used for confidentiality. To deal with denial of service attacks, well we do not have any simple cryptographic techniques that we can rely on. It is something slightly different from what we have talked about in this course. Denial of service attacks are meaning our computer system is no longer available for its intended purpose. It is overloaded. The network is overloaded. The server is overloaded by an attacker. That is hard to prevent. So there is a different area of study to look at how to stop and deal with denial of service attacks which we do not cover in this course. So those are some of the general threats that arise in internet or web security and some of the countermeasures that we can use. We are going to look mainly at one example and if time this week or even next week one small example of an application level security. This topic requires some of your background knowledge on the internet because we are looking at how internet security works and some of the protocols we use in the internet. When we look at the protocols used for communications in the internet we organise them in a layered stack or a layered architecture. We think about what do the applications use to communicate. For example, a web browser application uses what protocol? Web browser uses which protocol? HTTP. Web browser uses HTTP. Your email client? SMTP is used. You may have heard of others like POP and IMAP. Maybe when you configure your device you need to choose POP or IMAP to connect to the email server. So they are some protocols used by email applications. Remote login applications for me to remotely connect to another server or computer? What protocols are used? And you have probably done it in some of your homework tasks. You connect into another computer like the ICT server. SSH is an application layer protocol to remotely connect to another computer. An older one was Telnet. So the many different applications we have in the internet often have their own protocols for communicating called the application layer protocols. But many of those protocols, so in this first picture, HTTP for example, for web browsing, SMTP for email, FTP for file transfer, downloading large files normally, and many others sit up here. Many of them require the same functionality. And one of those functions that they require is reliability. I send a piece of data across the internet. I want to make sure it gets there correctly. It's not lost. And in the internet the main protocol used to provide reliability is TCP. TCP allows us to set up a connection from client to server and ensures that our data will be delivered correctly. TCP is a transport layer protocol. Another one which is less commonly used is UDP as a transport layer protocol. But TCP is used by your web browser, your email client, your remote login software, your database client, and many other applications. And everything is sent across the internet using the internet protocol, IP. And that provides the addressing, IP addresses, and the basic format of the packet to be forwarded through the internet. So a quick summary that we have application layer protocols, specific applications. We have transport layer protocols, TCP and UDP are the main ones. And then we have a network layer protocol called IP, which is used by all of the others. So then the question arises, I want to securely communicate between applications, client to server, where do I add the security mechanisms? And there are three options shown in these diagrams. Three examples. The first one which we call network layer security or network level security. We take the IP datagram and secure that. That is, my web browser generates a HTTP message. It's sent using TCP and IP. Then that IP datagram is encrypted. So we add a feature to IP to provide security of those IP packets. And that feature is referred as IP sec. It's an optional extra. We don't need it, but it's available. It provides a general solution for securing internet traffic. That is, every application irrespective of what protocol they're using or what transport protocol, because they all use IP, if IP sec is enabled, all of that data can be secured. The problem with IP sec in practice is it's not widely used. That is, well, why is it not widely used? It usually requires some configuration from the end user's perspective. You and I, when we want to secure our web browsing traffic, if we want to use IP sec, we may need to set up our computers in advance and set up the server in advance. And most normal users don't have the ability to do that or don't want to have to spend the time to doing some manual configuration. So we see for applications IP sec is not so commonly used. It is used for things like virtual private networks. You want to connect securely from your phone into the SIT network. Then you can use IP sec to do that, and that's a bit more common. So network layer security secures all of the IP packets using IP sec. Another option is transport level security, where we secure just the TCP packets. It only applies in the case we're looking at to TCP. Every application that uses TCP, which is many, web browsing, email, databases, many applications use TCP, what we do is we encrypt the TCP packets and provide some other security mechanisms. And again, there's an optional extra protocol that does that for us, and the old name was secure sockets layer SSL. The newer version is called transport layer security or TLS. We'll list in one slide later those in a bit more depth, but in this lecture you'll see sometimes I'll use either of those SSL or TLS to mean the same thing. There are slight differences between them, but at one point in time they were identical. SSL was the old name, TLS is the newer version. The idea is that it doesn't matter what application you're using, as long as it uses TCP as a transport protocol, we can secure that traffic between client and server. And that usually doesn't require anything from the user to set up. You don't need to configure your computer beforehand to use SSL. It's done automatically. And that means it's widely used today. So we use that as a major example in this topic. The third approach is application level security. For a specific application, we add some extensions to that application protocol to secure the traffic. An example in this picture is for email. Email traffic, when we send packets for email, is using a protocol called SMTP. And normally the email messages sent between email servers are not encrypted. There's an extension to SMTP or an add-on called SMIME, which allows us to encrypt the email messages. This is only for email. SMIME is not used for other applications, just for email. So here's an example where we add security extensions to specific applications. Any questions? So we've got three alternatives. The application-specific techniques are only relevant for an individual application. It means that we need to add, upgrade each application if we want to use them. The transport-level techniques are only relevant for TCP-based applications. But it turns out that many applications use TCP, so that is a widely used solution. The IPsec security works for all applications, but because it requires some configuration from the user's perspective, it's not so widely used. We will focus on the transport-level security as an example. TLS, SSL. And as a specific example of TLS and SSL, we'll use web browsing as the application, because that's widely used as well. So how do we support secure web browsing? What protocol do we use? Secure web browsing. HTTBS. I think you know when you use your browser, you see that HTTBS and the padlock. That is the protocol used for secure web browsing, as opposed to just normal HTTP. So we'll look at that as the example. It turns out that HTTBS is simply normal HTTP, but using SSL and TLS. So we will focus on SSL and TLS. The naming of the history. Originally, the Netscape web browser, one of the early widely used web browsers, implemented the extensions for securing web traffic. And it was called Secure Sockets Layer, SSL. So it was only implemented in Netscape, but it became popular in other web browsers, like Internet Explorer, started to add the features. And it went through multiple versions, SSL version one, version two and so on. And at some point, a standards organization called ITF said let's make it a standard so everyone uses it. And they named that standard transport layer security, TLS. At that point in time, SSL and TLS were the same, or essentially the same. So just two different names for the same technique. So SSL version three and TLS are about the same. TLS has gone through different versions, version one, 1.1, 1.2. So as TLS is changing, now SSL is no longer being updated. But in reality, we'll use, well, in reality, people use SSL and TLS to mean about the same thing. And in this course, when I say SSL or TLS, I mean the same thing. We will not look at the differences between them. Both are still widely used as the name. I will probably use SSL when I speak. What does SSL do? It allows applications that use TCP to use some additional security services. Security services, what do I mean by that? Encrypt is one. An application normally sends data to the TCP software. Before we send that data to TCP, we encrypt it so that if someone intercepts the data, they cannot see the original content. So encryption is one service. But we know to encrypt, we need a key. And if we need a key, we need to do some key exchange up front. So SSL also provides the ability to do a key exchange. And we also know with key exchanges, we need to be sure we're communicating with the right entity. We need to authenticate. So SSL provides ability to do authentication as well. SSL is quite complex. There are many different components to it. So we'll see in some of the next slides some of the details and that it actually consists of multiple sub protocols. So there's not just one communication protocol. It's made up of different parts. What we will do in this lecture is rather briefly present some of the overview of SSL. You will not be required to remember all the details, but then we'll go through an example of SSL and you'll see some of the details arise. So the overview of SSL is shown in this picture. Normally your application in this example, the web browser, your application uses an application level protocol like HTTP. Without SSL, the HTTP message is sent using TCP, which in turn uses IP to send the data across the Internet. That's without SSL. With SSL, we have an additional protocol called the record protocol that does the encryption of the data. So instead of sending the HTTP message directly using TCP, we send the HTTP message using the SSL record protocol, which will encrypt it, add a checksum or add a message authentication code for integrity. So that's the role of the record protocol to encrypt our data and to add max for our data. But to set that up so that both endpoints know which encryption algorithms to use, they know which keys to use, there are some other techniques. So there's a handshake protocol for SSL. Before we send any data, we must agree between client and server what algorithms to use, what parameters to use. Do we use AES to encrypt? Do we use RSA for public key certificates or some other algorithm? And that's the role of the handshake protocol to exchange those initial parameters and set up the secure connection. Then we can encrypt with the record protocol. So that are the main ones we'll look at. Also it turns out what we do with SSL is we use one algorithm for encryption for some steps and then we may change the cipher to another one. For example, for the key exchange we may use Diffie-Hellman and then for the data exchange we may use AES. So we may change the cipher during the connection, so there's a protocol for changing the cipher to say to the other side, let's change the other one now. And the last one, if something goes wrong or there are warning messages, for example, the client sends a message to the server, the server cannot decrypt it or the message authentication fails, then there's an alert message or an alert protocol for the server to send back a message to the client, if something went wrong, warning or error message. Sometimes it's just for notification, it's not an error, it's just to inform the other side about some event. So the main one is the record protocol and to support that we need to go through the handshake to agree upon the algorithms. Before we look into more details of that, let's look at an example of using web browsing. So we'll use that as our example throughout our study of SSL. And we access a website, for example, I access the index.html page on the ICT server using normal HTTP. I've done it before and if I record the messages being sent, for example, I capture the packets which were sent from my web browser to the web server, we can look at those messages to see how the communications took place. When we're using web browsing, the application level protocol is HTTP and the transport level protocol is TCP. I've got a record of the packets from a past class where I recorded what was sent between my browser and server, so we'll look at them just to remind us how web browsing works. And it's a slightly different example, it's a bit old but I think you'll see the idea here. This is, and those that have taken the lab or my course last semester will know this is the software called Wireshark which shows us the list of packets sent between some computers. And in this example, so we've got the first two columns identifying the source computer and the destination computer. In this particular example, the source computer was my laptop or office computer, I can't remember, it was done a couple of years ago, and the destination computer was I think the ICT server, ICT or IT again I can't remember, not so relevant. So the source computer of 10.10.99.251 was my computer, the destination of 203.131.209.72 was the IP address of the server at that point in time. So what I did is I accessed the website and these were the messages that were sent between browser and server. There were seven recorded. If we look at just the HTTP messages, we see how HTTP as an application layer protocol works. The source browser computer sent to the server a HTTP message and we call this a HTTP get request. It is the browser telling the server I want to get the page slash IT.html. At that time I accessed a page called IT.html. I send a request for that page and the second message we see is the server sending the response back. The server, the address starting with 203, sending a response to my browser computer and the response says everything is okay, 200 okay. What is inside this response message? When I open up the response message what am I going to see? When I open the response I'll see the reply but what's inside that? What's the main thing in the response? It says okay, meaning the status of this request was okay but there's a thing we want in there. The data, what is the data? It's the web page. With web browsing I send a request to the server I want IT.html, the server sends back a response inside that response. There are many things but the one thing that is of importance to the user, if I look at that response in detail, the contents of that include the web page, the HTML that was in the file IT.html. That's the normal operation for HTTP, send a request for a web page, get the web page in response. What port number does our web server use? Port 80, so port numbers are used to identify applications and server applications use a fixed port number, a web server by default uses port 80. Here we see the application layer protocol is HTTP, the transport layer protocol is TCP and the network layer protocol is IP, the other ones of interest to us. There's no security here, not yet. Here these two messages are HTTP messages but in fact there are some other things that happened as well. What are these three messages? Some of you are taking a class with Dr. Comet and I'm sure in his exam in the next couple of weeks you'll ask about this. What are the first three messages shown in this list of packets? The handshake, it's called a TCP three-way handshake. So this is the first part of my browser, remember, 10.10.99.251, connecting to the server. Before we transfer any data, we actually set up a connection and the normal way to set up a connection, we're using the protocol TCP, we send a special message to the server saying I want to synchronize you with you, a SIN message. The server sends back a response saying I acknowledge that you want to synchronize with me and I also want to synchronize with you and the third message is the browser sends back to the server I acknowledge that SIN message you sent to me. SIN, SINAK, that's the three-way handshake with TCP, we always see that before we transfer data. This is to set them, to let them know that they're about to communicate. Why do we need this handshake? TCP, the protocol TCP has several main services. One thing that TCP does for us is when I send data, say from my browser to the server, I don't know if I got there. Maybe something went wrong in the internet, so I don't know if data got there, so what we'll normally do is we'll expect an acknowledgement to come back to say your data got there. If it doesn't, we may have to resend that data. The other thing TCP does is if the client sends data too fast for the server, it may overflow the server. So there are some mechanisms for the data transfer that require some initialization of parameters at the client and server. And that's the role of the connection set up, to synchronize some initial values so that they are aware we're about to transfer data. So every application that uses TCP will use this to set up. Once we've set up, then our browser sends data to the server. The data in this case is the HTTP message, even though the protocol listed here says it's HTTP, that message is actually a TCP message, but the data inside that is the HTTP request for that web page. This one, coming from server to browser is just a TCP act saying thank you for your data. Browser sends data to the server, server sends back an acknowledgement saying thank you, everything was okay. The next message is data going from server to browser. The data is our web page, the IT.html page. And the last one shown here is an act coming from browser to server saying thank you for that data. The point being is that from the application's perspective, HTTP, if we filter just for those messages, it's a request and a response. But to support that, there's actually a TCP connection set up at the start and for each data message there's also some acts. So sometimes we'll hide the TCP messages, sometimes we'll show them. To be clear, let's just draw that so everyone remembers the structure. When we're using HTTP, we have our browser talking to the server and the exchange of messages we see, we see there's a three-way handshake at the start, SIN, SINAC and ACK. Over the three messages, I'll just summarize them as the SIN message, the TCP SIN, the SINAC that comes back from the server and the final third message in that handshake called an ACK. This is to set up the TCP connection before we transfer any data. Then we send some data and the data when we're using web browsing is the request for the web page and I'll just list that as the HTTP request or the, in our case, the HTTP get message. Meaning I want to get a particular web page. Most of you know this already, your experts on HTTP. There's an acknowledgement that comes back saying thank you for that data and then eventually the server sends back the web page. I'll denote as the HTTP response and there was a final act that we saw there saying thank you for that data and I say most of you know this and if you don't you'll have trouble in your exam this time. Any questions on HTTP so far? No security yet. But what we want to look at is when we use web browsing how do we secure the communications? We have a request for a page we get the response but to support that we need to set up a connection at the start and we sometimes have some acts coming back. What we want to do is from a security perspective ensure all the data sent using TCP in our case the HTTP get and the HTTP response we want that to be secure. By secure I mean encrypted and authenticated that is make sure that when we receive it it hasn't been modified along the way. So that's the role of SSL in this case. With SSL we do some extra steps to ensure that we can encrypt this TCP data the HTTP get and response. So with SSL the HTTP get and response will be encrypted with the record protocol but before we use that we must do an additional handshake another set up to say let's agree upon some security parameters. The TCP handshake is to agree upon just the TCP parameters but in addition we'll need a SSL handshake to agree upon the security algorithms and the keys to use. So we'll see that come up soon. Just some terminology that we may see in the example that comes up. We saw when a client connects to the server we create a TCP connection. We set up that connection with that first three-way handshake. We send some data. What I didn't show in the example is that when we finish sending data we may close the connection. We skipped over that there's also a concept of an SSL connection which directly corresponds to a TCP connection. So we can say that we have a TCP connection from browser to server and we can also have an SSL connection from browser to server. But in SSL there's another level as well. There's called SSL session. In an SSL session again between client and server we would do a handshake. We'll agree upon the parameters to use. The algorithms, the keys that will be part of setting up the session. And once we set up a session then we can have multiple connections associated with that one session. The idea is I set up my secure session between my browser on my computer and the web server. And then I transfer some data securely and maybe a little bit later I have another TCP connection using the same session parameters, the same session. So we can have multiple SSL or TCP connections associated with a single session. We don't have to set up the secure session every time we want to create a TCP connection. There's an overhead of setting up the secure session so we want to avoid that and we can do that with sessions and connections. So we'll see that come up in one of the examples. So at the start of a session we'll perform a handshake, agree upon some parameters. Once we perform the handshake both the client and server will record information about this session. Some of the information they'll record is there'll be an ID of the session, something that uniquely identifies it. When there are certificates used they'll be saved in memory at the client and server. The algorithms used for compression although not part of security will often compress the data. The cipher spec will list the set of ciphers that we use. For example, the symmetric key cipher, the MAC algorithm, the public key cipher will be listed and recorded and the secrets will be stored. There'll be a master secret but there'll be also some other secret keys. So these are the keys. These will be stored for the session and for each connection a session may contain multiple connections the specific keys will be stored. So what we'll do, we'll have one master key actually there may be two master keys we'll see and they'll be used to generate session keys. It's confusing the session keys here referred as encrypt keys and MAC secrets. And there may be sequence numbers to keep track of the messages we've sent give them in order. Initialization vectors we remember from the modes of operation CBC and other modes we often had an initial value that value will be stored and often we will need some random values say for nonces set up the initial session so they'll be stored at the client and server. So the idea we establish a secure session using a handshake protocol store this information at both client and server then the data that we send between client and server will be encrypted and authenticated using a MAC. Let's see some of the steps involved there. First how do we encrypt the data? And this summarizes the operation of the record protocol. What we're talking about with the record protocol is after we've set up a secure session after some handshake we have data to send for example our HTTP get message is considered data. I want to send it from my browser to the server but I want to send it securely. So the record protocol is that data that entire HTTP get message and does this with it. So if we consider we start with the application data say the HTTP get message we go through these steps. The data may be different sizes in different applications. So first we fragment it we split it into equally sized fragments and the size will be defined for the session it's usually I think we'll see maybe 128 bytes of that similar to 128 bytes. We split the application into equal sized fragments. If my application data was a thousand bytes then we'd get our eight fragments. If it was 10,000 bytes we'd have more fragments. For each fragment of data we then apply the following operations. It's shown the first fragment but these operations apply to each fragment. We compress the fragment. It provides no security but it may improve the performance of the data transfer because if the fragment can be compressed we can save some space or the amount that we need to transfer. Compression is actually optional. We may compress with what's called the null algorithm but we'll see that we have the option to compress. We take that compressed data and calculate a message authentication code. Remember the purpose of a MAC is so that the receiver can verify the integrity of the data. If a MAC is attached then the receiver gets this compressed fragment and the MAC and the receiver checks does the MAC of the compressed fragment match the MAC received. We've covered that concept in the topic on message authentication codes. What does a MAC take as input? What does a MAC use as input? Here it uses the compressed fragment and importantly a MAC takes two things as input. If you go back to your slides on MACs you'll see the MAC function takes a key, a secret. For authentication MACs use a secret key and the data. When we looked at hash functions they just apply on data but MAC functions also have a secret key. So there is a MAC secret that is needed to perform this operation. So when the client has its compressed fragment the data it calculates a MAC using that data and a secret key and that secret key of course must also be known by the server. So that will be one parameter stored and known and agreed upon from the handshake. So it's referred to the MAC secrets here. We take that compressed fragment with the MAC attached at the end and then encrypt all of it. What's an encrypt function take as input? What's an encrypt function take? A key and a key and the data. So that what do we encrypt? We encrypt this component and we use a key to encrypt that and we're using symmetric key encryption to encrypt here. For example AES may be used but others may be used. So there's also an encrypt key or an encrypt secret. So in fact there are two secret keys here one that's used for MACs and another that is used for encrypting the data. And they're usually different and random values. So we have two keys that both the client and server needs to know here. One for a MAC, one for an encrypt and to add some more complexity for the direction from client to server we use one set of keys and from server back to client we'll use a different set. So in fact there are four keys now. MAC for one direction, client to server a MAC key from server back to client and also encrypt key for client to server and encrypt key for server back to client. How do we get these keys? Anyone want to guess? How do we generate our MAC secrets or our encrypt keys? Random. So with symmetric key encryption and they should be random values. So if our client generates a random value, how does a server know it? We may need some key exchange to send the value to the server. Well we don't do that for each of those four values. We don't do it for the encrypt keys and MAC secrets. We'll actually have a master key. So we'll say generate a master secret key perform a key exchange of that master secret we'll see an example using Diffie-Hulman and then once both the client and server have that master secret key they will use a known algorithm to generate encrypt keys and MAC secrets. So we'll use the master generate the other sub keys and the algorithm they use is usually applying a hash of some known values. So the encrypt keys and MAC secrets are generated from the master key. The master key is the important one there. How do we get the master key at both sides? We'll see that in the handshake protocol. So we've encrypted our authenticated compressed fragment. The last thing we do is we add a small header to the front indicating the fragment order this is fragment number one the next fragment and so on and to indicate that this is using SSL it's called append the record header. Fragmentation there are some limits on the size. Compression you may have an algorithm or it may be a null algorithm that is no compression. It's lossless compression we can't compress data and throw parts away it's not lossy. The MAC is normally we use HMAC and there's a secret used in the MAC encrypt we have a secret as well a separate secret in the MAC one and the SSL record header includes a few fields like the version of SSL we're using what content type is included in here and the length of that message the compressed length shown in sort of summary version there the entire SSL message there contains the plain text optionally compressed then the MAC is attached and then all of that is encrypted and then we add some header fields at the start that will be sent across the network instead of the original HTTP get message that was for the record protocol for when we send data there's also some additional structure of the messages for the handshake the change cipher protocol and the alert protocol which are listed here but not relevant to what we want to the detail that we need to discuss yes so where does this occur so the application data comes from your application so your web browser for example your web browser you click on a link your web browser generates this HTTP get request that is what we list as the application data here normally that is then sent to your operating system to your OS and your OS uses the TCP software to set up a connection and to send the data what we do with SSL there's something else inserted between your application and the operating system and that something else it may be implemented in the application or more commonly nowadays it's a separate library or a separate piece of software on your computer that your application sends the data sends to this library that implements SSL that library software on your computer fragments compresses adds the MAC encrypts generates this SSL fragment sends that to your operating system so the application data comes from your application the end result of all of this goes to the operating system and is then sent using TCP so these steps are done by the SSL software on your computer what SSL software what's the name of some SSL software a library that you use OpenSSL you've used on the command line is actually intended for this purpose it's built to originally to provide a library to insert between an application and your operating system to do all of these steps on the command line but it's more commonly used automatically by applications so to visualize that that was the exchange with HTTP let's draw a different perspective from the client's perspective with HTTP we start with our application so our browser generates some HTTP get request this is our application data and it sends that to our operating system I'll draw it down here so we can compare and the operating system then sends a TCP message TCP data that's the normal approach browser generates application data HTTP get request for example it's sent to the operating system which generates a TCP data message actually before it generates the TCP data it does the TCP connection and then generates data and sent what about with HTTPS well our browser does the same there's nothing different generates the HTTP get that's the application data but then we have the SSL software in the middle the SSL library and that sends the I'll say the encrypted fragments encrypted to the operating system so the operating system or the TCP part of the operating system receives these encrypted fragments and it just treats it as data and sends as TCP data but the data is of course encrypted and authenticated it's not the unencrypted or plain text from the application so SSL we insert this extra component or layer between application and operating system the SSL software maybe it comes with your browser so maybe it's provided by your browser or maybe it's a separate piece of software on your computer a library a standalone library depends upon your system so the question why do we use port 443 so you're jumping ahead see the slides we'll come back to the handshake later we're talking about SSL in general but the example SSL we're using and it's the widely used one is HTTPS so HTTPS is an example of an application using SSL HTTPS all it is send your HTTPS messages using SSL so what's the difference well I think you know from the URL perspective your URLs start with HTTPS as opposed to simply HTTP that tells your browser whether to use normal HTTPS or the secure HTTPS that is if you if the URL includes HTTPS your browser knows send this HTTPS get request to the SSL software don't send it direct to TCP in the operating system when your web server again the web server may receive requests using the normal HTTP and be processed and sent back or it may be receive requests using HTTPS and the way that the web server distinguishes between them is using a port number so when the browser sends the first message to the web server a web server normally receives on what's called port 80 with HTTP but a separate port number port 443 for a secure web server HTTPS why do we have two different ports what's the answer you ask the question why need two different ports what the port numbers use for to be not ambiguous between applications that is we now have two different applications on the web server really the one that handles normal they are treated separately so we actually have two different port numbers there so that's some of the details of the implementation of the web server while we're here what else we will see when we use SSL to send our HTTP get request and to receive the response back everything is encrypted what does everything include the URL remember in the get message it says get but that is encrypted so if someone intercepts that they don't know the specific page you're accessing they don't know if you're accessing it.html or abc.html so that component is encrypted the file is encrypted someone still knows the server you're accessing you cannot hide the server you're accessing because that's identified by the IP address but you hide the the rest of the part of the the URL the contents of the web page are of course encrypted so when someone sends back it.html all of that is encrypted so someone cannot see the contents of the web page you're accessing when you access a website and it has a form you fill in the form and press submit all of that data which is submitted with the form would be encrypted so no one can see the data when you type in your username and password and press login that is implemented with a form that would be encrypted websites often use cookies so that the website can track your recent communications keep track of your communications with this website those cookies are sent using HTTP so they are also encrypted and the HTTP messages contain headers and sometimes that gives revealing information that is all encrypted so if someone intercepts using HTTPS they cannot see any of this information but if you're using HTTP if someone intercepts your communications they can see all of this let's go back we'll see what we got to and set up for the handshake our picture HTTP using a browser directly operating system HTTPS we have SSL software in the middle this is an example if I wrote my own game application I want to create a new game I write the game client and the game server not using HTTP but they communicate using my own protocol then I could have the communications between the game client and server secure using SSL I would have my game software my game client that generates messages to be sent to the game server instead of me encrypting those messages inside my game client software I simply send those messages to the SSL software which sets up the secure connection and crypts them for me so that's one of the benefits of transport layer security the application doesn't have to implement that security and the application developer doesn't have to implement that security you leave it to an existing library which is well being well tested and is shown to be secure in as many cases as possible so when you develop your own application you can use SSL to provide security across the network before we can do any encryption and when we're applying the MAC we must decree upon parameters and that's the role of the handshake protocol so we'll briefly summarize the steps and then after a break we'll go through an example but let's just summarize the steps first what's the purpose of the handshake protocol two main things we want to perform authentication we would like to be allow the client to be sure it's talking with the correct server and also sometimes for the server to be sure it's talking to the correct client so the authentication of both sides is supported with SSL and it's done in the handshake protocol and we often need to negotiate or agree upon algorithms we're going to use and keys we're going to use and as well as other parameters so that's the other purpose of the handshake agree upon what algorithm we'll use for key exchange for example RSA or Diffie-Helman what algorithm are we going to use for the MAC and the two common ones that we use HMAC with either SHA or MD5 and what are we going to use for encryption and you can choose from many different ciphers to encrypt symmetric key encryption so there are some messages that happen in the handshake protocols that both client and server will agree upon these values and the handshake protocol goes through four general phases first we establish the capabilities of each other the client proposes algorithms to the server the server chooses one that is the client will say I can support RSA and Diffie-Helman for key exchange I can support HMAC with MD5 and I can support RC4 DES and AES for encryption the client will send that information to the server the server will choose one of those which of course it also supports so the server may support multiple it will choose the highest one as preferred by the client and send back a response saying let's use this set so it's not one algorithm it's a set of algorithms for key exchange MAC and encryption also compression so they agree upon algorithms authentication of the server the client wants to be sure it's talking with the correct server how do we do that commonly certificates the server can send it certificate to my client and the client can verify the certificate we'll see that's common with web browsing and key exchange what key are we going to use for encrypt so we'll actually exchange a master key usually and then use that to generate other keys so step 3 we may and this is not used for HTTPS but it's possible that the server can authenticate the client that is the client sends its certificate to the server and the server verifies that it's talking with the correct client so that's also supported we don't normally use this step 3 for web browsing because to authenticate a client with web browsing we usually use forms so we don't use certificates but it's supported by SSL then we do some final exchange to say we've set up the connection and after that we apply the record protocol and encrypt all of our data so with HTTPS we're going to see an example where we see the step phase 1 phase 2 there will not be client authentication and finally we'll finish setting up the connection there are many different message types sent let's just list them this summarizes the main exchange in those 4 phases the client and server establish capabilities sending hello messages client says hello server says hello back the server authentication the server sends a certificate and then some messages to perform a key exchange and then it's eventually done and if there's client authentication it's not necessary but if there is the server may request a certificate the client sends a certificate and there's a key exchange and a final verification usually we will see there's only one message here the key exchange the certificate is not sent then at the end to finish up they say let's change from this previous cycle we've used and now let's start encrypting our data with AES or the encrypt cipher chosen and they both do that they say let's change the cipher to the new one I've finished the set up of the session after phase 4 now we send our encrypted data this is easier to see with a more detailed example and we'll use the example of web browsing to see this exchange and we'll look at a capture of web browsing