 So, let's talk about some general mechanisms that we have available to secure communications across the Internet. So, we've talked about web security, all right, which is a specific instance of Internet security. But let's sort of go back and talk about how can we secure our communications across a network, some different ways. And we'll look at some protocols or applications that we can use and just through a set of examples. So, in fact, we've talked a lot about HTTP, HTTPS already. So, one form of securing our Internet applications is if we're using web browsing, using HTTPS. So, that will be one example we come up with here. We'll see a few other examples as well. When the Internet was designed, so the protocols that are common the Internet, TCP, IP, e-mail protocols, SMTP, HTTP and so on, they were designed under the assumption that the network itself was secure, that there weren't malicious users. Remember, the Internet was created by really academic institutions trying to share network services, share computers amongst different universities, and then connecting the universities together. So they developed protocols to communicate under the assumption that the people communicating are trustworthy. So, they designed a set of protocols to allow communications across the Internet with no built-in security mechanisms. There wasn't encryption built into any of these protocols. Which was a fair assumption at that point to assume trustworthy networks and users, but of course now, today, when the Internet has grown to be used everywhere, there are of course some untrustworthy users. So, to support secure communications in the Internet, many of the existing protocols have had extensions added to them to support encryption, to support authentication. And we'll talk about some of them just via a set of examples. So, for example, IP is used for sending across a network, IP datagrams. It has no encryption of those IP datagrams. There's an extension referred to as IPsec, which is an optional extra that you can use if you want to use encryption of your IP datagrams. TCP has no encryption. TLS adds this extra feature of encrypting our data. So there's some extensions that you may use if you want secure communications. We'll look at some of them. We'll see that to communicate securely across the Internet, we can do it in different ways. So there are different choices for communicating securely, and we can roughly break them into layers. We can have application layer security, encrypt at the applications, transport layer security, encryption at the transport layer, at the network layer, or across each link, so across the link layer. So we'll go through really just four examples of how could we encrypt our data when we're communicating across the Internet. There are many different security protocols. We're just going to select some common examples. So to get started, here's our example network, and let me draw a little bit different. Here's our example network. The idea we're going to use in this example is that we have, let's say, host A is a laptop, some laptop, wireless LAN. So we have, say, an access point on the wall, so my laptop is host A. I connect wirelessly to the access point, which is this device in the middle here, so some access point. That's wireless communications there. And then that access point has a link. You can see the LAN cable goes up to the wall, and eventually that LAN cable, the Ethernet cable, goes to some router in SIT. And this is our router X, and that router has a LAN cable or a cable going to some other router and another router, and that actually is our Internet here, just showing this topology. So there may be many routers in the Internet in here. Eventually we get to some other router, which in this example then connects to, say, some server, some other computer. That's what we're going to use as our example. Laptop to wireless access point, connect via LAN to some local router, let's say, inside SIT, which connects outside to the next ISP and so on. And there are many ISPs in this cloud. This is the Internet and eventually some destination computer that we want to communicate with. And what this diagram shows is the protocol stacks or simplified protocol stacks of each of these devices. The laptop, the two hosts, the laptop and the, say, the server, A and B. We'll look a little bit about the wireless access point using Wi-Fi here and the two routers. And of course, I'm not going to show them, but there may be many other devices in between here across our Internet. We want to communicate between A and B and we want secure communications. What does that mean? In a simple way we can say we want to make sure that the data we send between A and B no one else can read, so confidential communications, and that we also would like authentication so that when A and B communicate with each other, they are sure that, well, B is sure that the message is coming from A, not someone pretending to be A. We're going to focus mainly on the confidentiality aspect of how do we make sure that when we send data that someone in between A and B cannot see the contents of that data. How do we do that? What's the general form? The solution is to do what? Encrypt. Okay? Easy. So we need to encrypt our data and then send it. But what we're going to look at is, well, where do we encrypt? And there are different choices. That's what we'll go through. The aspect of authentication is important as well. How do we make sure that when we receive something, it actually came from A and not someone pretending to be A. How do we make sure it wasn't modified? We need to cover mechanisms for that as well. But in these examples, I will not mention authentication, just the encryption part of it. So that's our example network. What's our stacks? What do our stacks show? I've tried to roughly divide the stacks into five layers. Physical layer, PHY is just sure for the physical layer. That deals with sending signals. So the physical layer at the laptop and access point would be able to transmit and receive Wi-Fi signals, wireless signals. We're not too concerned with that. We just assume that we can send some signal and it will be received. And same across the ethernet LAN. But DEL is data link, data link layer, which is dealing with getting data across that individual link. So make sure that we can efficiently get data from laptop on host A to the access point here. And because we have a different link between access point and router X, we may have a different data link layer and physical layer. So I haven't specified what they are, but just to say that the data link and physical layers. To communicate across a network, the network layer is used and specifically the internet protocol, IP. And the way that it's used is that our hosts use IP and our routers use IP. So we have an IP datagram. If we want to send it to B, we construct the datagram at A. We send it to the next router. So we use our routing table to say, OK, to reach B, I need to send to X. X would receive it, use its routing table to realize I need to send it to another router. It eventually get to router Y and that would send it onto B. So that's just IP forwarding and routing. The transport layer is on the hosts only. It's what we call end to end protocol or host to host. Only the hosts are involved in using the transport layer. TTP is the common protocol. It's used for making sure we can efficiently transfer data between hosts. UDP is another common one, but doesn't do much other than creates datagrams. And then at the top, we have a protocol specific to our application. HTTP, SMTP for email, whatever application we're using, we may have our specific protocol at the top. I know you all know that, so that's clear to everyone, because we've seen it in many other lectures. Maybe about the access point. What's an access point? What's that thing on the wall? Really, that just connects our Wi-Fi to our Wired LAN. It's often called a bridge. I've written bridge here. It's not involved with IP in this example. It just receives something on the wireless LAN and sends it on the ethernet to the next of us. So you're malicious. I'm on A, communicating with B. What can you do to read my data going between A and B? Capture where? Specific, but physically, where in this network are you going to capture? Where are you going to sit and capture? Let's say you don't have my laptop. You're not sitting in my laptop. That would be insecure. I've got my laptop. You can't physically access the server. I've been in a locked room somewhere with a cable going into it. So what can you do as an attacker to try and intercept the data? Capture where? Anywhere, almost. Anywhere between the hosts. So there are many possible ways. So in practice, capture across the wireless link, that's relatively easy. Because of the nature of wireless communications, when my laptop transmits a signal to that access point, it actually transmits it so that anyone nearby also receives that signal. So it's very easy to set up your laptop as a malicious user to record all the signals that my laptop sends to the access point. Therefore, capture all the packets my laptop sends to the access point. So to intercept those packets across the wireless link is easy. And I think everyone's done it in an assignment task in the past. You could intercept across this link. How? So there's a cable going up there into a router on the third floor. What could you do to intercept across that link? Tap, okay? Let's say what you did was that you snuck into this room when Noam was here and you unplugged the cable from there and plugged into the enclosure there, your own little mini computer. And the LAN cable goes into your own computer, records all the packets, saves them with TCP dump, and then there's another LAN cable that continues on down to the router. So effectively tap into this link somewhere. A little bit harder than doing it with Wi-Fi. You need some physical access to the link. But possible in some cases. But you do need that physical access. With Wi-Fi, you just need to be nearby, maybe even outside the room. Same with all of the links between hosts. With a wired link, you need to be able to physically access that link. If it's a wireless link, it's a little bit easier as a malicious user because you just need to be within the wireless range of the transmitted signal to capture. Of course, assuming no encryption at the moment, assuming everything's sent in the clear. So capture on the links. What else? And the next thing you do as a malicious user, if you couldn't capture across the wireless link, let's say you, almost the same as before, you get access to this wireless access point and you install your own software on the access point to record everything that is sent. That is, get access to the devices in the network. If you have physical access to those devices, then in theory, you can set them up so that all the packets that go through them are recorded and therefore you've intercepted the data. So capture on the links or somehow get access to the devices anywhere between A and B. Some parts are easier than others in practice. But assuming someone can, therefore, if A wants to talk to B, assuming someone can capture anywhere between A and B, what we need to do is encrypt our data. First approach, application level security. I have an application running on my laptop, host A, communicating with an app on host B, the server. Without encryption, I think you can see if my application sends data anywhere across our links, someone could intercept and get the data. So what we could do is one option is to encrypt the data inside my application. So if my application was a web browser, one option is to implement my web browser such that before it sends the request, it encrypts it. Or if I create my own application, I'm writing my own client application that talks to my own server. For example, my client application is a game and the server is a game server and we need to communicate and we want to encrypt the data. Then I can program my application to encrypt the data before it sends it. So I've tried to illustrate that here by saying we've got this extra part of the application that implements this application-specific security. That is, you write the code such that when you have data to send, before you send it, you encrypt it. With respect to our stacks, the flow of the data is that normally the application sends it to the transport layer inside our computer and go back. The application sends it to the transport layer. If the application is using TCP, it sends it to TCP, which then sends it to IP, sends it down through the network interface card, the data link layer and physical to the access point, which then sends it across the next link, which then the router sends it to the next one and eventually it arrives at router Y and then on to the host B, receives the data, sends it up to TCP and then on to the receiving application. That's the normal data flow. So what we do is inside the application, before we send it to the transport layer, encrypt the data such that when we send it to the transport layer from the transport layer's perspective, the data cannot be viewed. It's encrypted. It sends it to IP, keeps going down and when it goes across our wireless link, it's encrypted. Even if you sit here with your laptop and capture the packets on your wireless link, you can capture them still, but when you look at them in Wireshark, you'll just see random bits in there, random data because it's all encrypted. You will not be able to see the original contents. And as that data passes through the access point, if you had somehow compromised this access point to record everything that goes through it, again, you could record the packets going through, but you would not be able to see the data because it's encrypted. And across all the links and all the devices, the data's encrypted until it arrives at the receiving application which decrypts and gets the original data. So there, we've solved our problem. By encrypting in the applications, no one in the path and any of the links or any of the intermediate devices, no one can read our original data for this to work, we need to make sure our application supports encryption. That is, if you're writing the application, you're creating it, you need to program in this feature to encrypt the data first. And you need to make sure the server application also supports encryption and so it can decrypt and send back an encrypted response, depending upon your application as to whether this is supported or not. So some examples where application level security is used, secure shell, everyone's used. You log into other computers, you remotely connect. Everything's encrypted by the application before it's sent. And the server application decrypts and sends back responses encrypted. Email encryption uses application level security. You can enable your email clients so that you write an email, before your email client sends it, it encrypts the email and then sends it and the email goes across the internet and when the person receives the email and they open it up in their email client, their email client decrypts and they get to see the original message. We'll see some ways for doing that in email later. So that different applications use application level security. In all cases, the application itself implements the security mechanisms. There's a DNS for domain name system, secure version that is application level. We'll see there are other approaches. So why use application level security? Well, first thing, a good thing, it's host to host encryption. That means from host A, the data is encrypted, all the way through to host B, it stays encrypted. Doesn't matter where you intercept, you cannot get the original plain text. We'll see some other alternatives do not encrypt all the way across the network. So they may not be host to host. Sorry, wrong way. Independent of the operating system, where is the operating system in our picture? And remember, where's the OS roughly? Look at host A. Roughly approximately the split between say the OS, the application and let's say the network interface card, the LAN card or Wi-Fi card is, I'll write that the network interface card is at these layers. The application layer is implemented by the application that you install. When you install a web browser, Firefox, it implements the application layer protocol. Your operating system implements usually the network layer and transport layer, TCP, UDP, IP. So when you install your OS, it comes with support for these protocols. The data link layer and physical layer roughly the split is implemented by your LAN card or the drivers for your LAN card or wireless LAN card. So I say the network interface card. It's not always a split, but roughly that. So as the end user of your computer, you normally don't have, if you install an app, you can install any application but you normally do not modify the operating system. So you normally have a greater level of control over what applications you can use. You don't have much control over what the OS does. You can configure it and change things, but most users don't change the operating system. The advantage of application level security is that the security mechanisms come with the application. It doesn't depend upon what the OS does. So it doesn't matter if your operating system supports encryption or not. As long as the application implements it, then we can provide end to end or host to host encryption. So if I install my, I download an application to talk to, say an instant messaging application, to send instant messages to some other destination, whether it's a server or another user. Then if that application includes its own encryption and the server version of that application also includes encryption, then we can securely communicate. So that security mechanisms are inside the app itself. It doesn't matter what operating system and what features it has, we still have that security problem. So that's an advantage because we don't depend on the operating system, but it's also a problem because it means everyone who implements an application, they must implement their own security mechanisms. You start your company when you graduate to have a new instant messaging application or an application that communicates between mobile phones. And if you want to use application level security inside your application, you must code the security mechanisms, right? You may use a library of existing functions, but you must implement it and make sure it's implemented correctly so that there are no flaws. And if someone else develops another application, they must implement it as well. That's a disadvantage we'll see compared to some of the other approaches. So application level security is used in some cases. An alternative is to shift the security mechanisms into the operating system so that it's not needed in the individual applications, but the OS will do the encryption for us. And that's common with transport layer security. So one example of this transport layer security is TLS, transport layer security, or the older version is Secure Socket Slayer, SSL. And we saw this with HTTP. HTTPS is simply the application HTTP using TLS or SSL. We use the same acronym to mean the same protocol, although there are slight differences. And that's implemented in the OS. I will not draw it again, but remember our OS, the split really application, and then the transport and network layer inside the operating system. So what happens? You run your normal application. Let's say your instant messaging application creates a message to send to B. It doesn't encrypt the message. All the application does is takes the message and sends it to the operating system. How does it send to the operating system? Well, usually the OS provides an API for programming for network communications, the Sockets interface, for example. But your application calls a function to say send data to B. And the operating system in this case, if we're using TCP as the transport protocol, instead of saying send data with TCP, your application calls the function send data securely with TCP. So the data is sent to this TLS, this secure protocol encrypts the data which then uses the normal TCP to send it across the internet to B. So the encryption happens in the transport layer and very close, there's not much difference here. In the application versus the transport layer, but the difference is where the split is between the OS and the app. In application level security, it's in the application. In transport layer, it's in the OS, the operating system. We encrypt, it's still host to host encryption. Data is encrypted on host A, decrypted on host B. Anywhere in between, they cannot read the plaintext because it's encrypted. So we've still got the same host to host or end to end encryption, which is good. The advantage we have compared to application level security is that our application doesn't need to implement the encryption. It's done by the OS. So it's much easier to write your app. So you create your new application and you program it just to create data. And instead of writing code to do encryption of that data, all you do is you call an operating system function to send using TLS. And the OS does the encryption for your app. Doesn't matter which application you're using, doesn't matter what security features it supports. If it's going to use TCP, then it can securely communicate with a server application by simply just using the extended TLS, Transport Layer Security. So some examples. And TLS, the older version, SSL, is for TCP-based applications only. Only applications that use TCP normally can use this secure version. And you know HTTPS is simply the normal HTTP using TLS. But there are many others as well. IMAP is for you to access your email on a server. There's a secure form, IMAP-S. FTP is for transferring files. There's a secure form, FTP-S. SMTP for sending email between servers. You can encrypt the email transfer using SMTP-S and others. And they all use this approach of, it's just the normal application protocol. HTTP, IMAP, FTP, SMTP. But they all use TLS as the Transport Layer Security. Don't worry about these other. There are others for other transport protocols, for non-TCP transport protocols. Same with application level security, we still have host to host encryption. Encrypt at host A, decrypt at host B. But the advantage is that we have much simpler applications. The person who writes the application doesn't need to consider the security mechanisms. They just use the inbuilt security mechanisms of the OS. Much simpler applications and much less chance of someone making a mistake in implementing the wrong security functions. That is, if I ask you to encrypt, no, ask you to implement in your application some encryption algorithm, AES, that's a lot of work. To get it implemented correctly and perform well is hard work. So rather than get everyone who creates applications to implement it themselves, just use the existing implementation inside your OS. The problems with using Transport Layer Security is usually it's only for specific transport protocols. So TLS is very common, but it only works for applications using TCP. Anyone know applications that don't use TCP? Web browsing does, email does, many instant messaging clients do. Anyone know some applications that don't use TCP? Video, some video streaming applications do not use TCP. Some do, some don't. Because they usually use UDP, which can perform much better for streaming. It's much faster, less delay. Others, so video and sometimes voice transfer with streaming especially, they use UDP. Others, online games, games between the game client and the game server often uses UDP again because with a networked game you need fast communications between client and server. So usually they use the much lower overhead UDP. So those applications cannot use TLS. TLS only supports TCP applications. There's the problem. There are some protocols that work for UDP and others, but they're much, much less common. And I don't know if the most recent versions of most operating systems implement these DTLS and others. They may not be supported by your OS. So two options so far. Implement in the application or use the existing operating system features in the transport layer. You've used both. You've used SSH before. Some of you may have even used encrypted email. We'll see an example of that later. And you've used also, of course, HTTPS, which uses transport layer encryption. Questions. So when you go and start your own business and you're going to develop your new application and try and sell it for $16 billion, what are you going to use? Application level or transport level security? Both. Why both? You could use both. Potentially more secure, but what's the problem of adding encryption? Slow performance. Every time we need to encrypt something, it takes some time. So it's much worse in terms of performance. So what are you going to use? TCP or transport layer. Why is that easier for you? Let's say your app uses TCP. Why do you want to use transport layer security? Let's say your app uses TCP. Fine. You've got the option of this one or application level security. Which one are you going to choose? I'm not saying there's one best answer. I just want to know what one you're going to choose when you create your new app. The transport layer security. Why? Again, why? If you're using TCP, which approach application or transport layer security if using TCP? Application. Why? There's one. Use application. If you don't trust the OS to implement it or maybe more practically, you're not sure if the operating system supports the level of security that your application desires. You want to make your application independent of what the operating system provides. Then yeah, do it in your application. What's the disadvantage? Someone's going to do a different approach and sell their company before yours. Why? What's the advantage of using transport layer instead of application? It's common and it's easier for you. When you implement your application you don't need to do the encryption. So if you use application level security you need to write the code that encrypts. But using transport layer security you just write the code that generates the data. You don't deal with any encryption. You use the encryption features of the OS to do that. Much easier, much faster to write your application in that way. So use an existing OS provider feature. So there's no one best way to choose. It depends upon what your requirements are. We will see a few other approaches on Thursday. But the first two are the most common.