 We have talked about web security. So one of our topics was about HTTPS, where we have a secure web server and we use really HTTP and SSL protocol to establish a secure connection between the browser and server and encrypt the data. This topic will just compare more generally the different approaches that we can use to secure our communications in the internet. So HTTPS is one, but it's only for web browsing. What about other applications in the internet? So we'll look at three or four different approaches that we can use to secure communications in the internet. First, in the internet, because it was designed many years ago as really the protocols used, IP and TCP were designed for just a small set of users. It was originally built connecting a few different universities and government organizations together. Everyone trusted everyone when they were designed. There was no need for security. But as the internet grew, of course, the need for security also grew because there was less trust amongst the users. And eventually now it's used for many communications that we need some security measures to support the applications. But the protocols that the internet is built around didn't include any security mechanisms. IP, TCP, HTTP. In the original protocols, there's no encryption. There's no authentication mechanisms built in. So what's happened gradually is that extensions have been created, like add-ons have been created, to make HTTP more secure. SSL is one of them. So a lot of them we'll see, we'll mention there's IPsec, which is an optional extra for IP. If you use IP for your internet communications, which we all do, if you want security, one option is to use something called IPsec, the security features of IP. If you want transport layer security for TCP, TCP doesn't include it. If you want it, you can use TLS. If you send emails, you use protocols like SMTP. There's no encryption of your emails. Everything's sent in the clear. If you want encryption, then you can use PGP and other technologies to secure your email transfer. So there are optional extras to provide security. And there are different ones you can choose, depending upon your aims and what application you're trying to secure, what data. So we'll compare some of the options at different layers in a protocol stack. We'll look at the options at the application layer, transport, network, and link layer. Link is data link, DL in this picture. So here's an example of some devices in a network. And in each device, I've shown just a view of the layers in those devices. So for example, host A, some computer on the internet. Phi is for physical layer. DL for data link layer, or the link layer, sometimes we call it. And those two are about really getting data across a link, just a single link. For example, the technology we use in this example between the host A and this next device, let's say we use Wi-Fi, wireless LAN. The middle layer is the network layer. And the primary protocol we use there is IP, the internet protocol. That allows us to send data via routers to some destination across the internet. To support our applications, we have transport protocols that do things like set up a connection with TCP, retransmit data, flow control, error control, congestion control, especially in TCP. Or if you want some very simple transport service, UDP is another option. So the transport layer is the second to top most layer. And at the top are the protocols specific to applications. If I want to do web browsing, the application layer protocol is HTTP. If I want to send emails, it's SMTP. If I want to log into another computer, it's SSH. So the different protocols for different applications. What does this example network represent? Let's say we have a laptop host A. And it's using Wi-Fi to connect to an access point, like on the wall there. So this next device, the access point, is like the links this device on the wall. We connect wirelessly between our first host and the access point. All an access point does really is connect the wireless LAN with a wired LAN. So if you look at that access point, there's an ethernet cable plugged in, which goes to some other device in the network. And I've simplified it such that the access point has an ethernet cable connected into a router. So maybe this access point on the wall has an ethernet device going into the SIT router. And then to simplify the rest, that router has a connection out to the wider internet, say through our ISP, our internet service provider. And I don't draw the entire internet here, but we have think of this as our connection from router X, let's say the SIT router, to the external ISP, which connects to other internet service providers across the globe. And if we want to communicate with host B, then host B is connected via, say, a LAN cable, just ethernet, to a router, which eventually connects to an ISP on the internet. So we want to look at, if I want to get data from an application on A to B, how can we do that securely? What options do we have? HTTPS is one, so we know HTTPS already. What if I'm not web browsing? We want to look at that. And even if we are doing web browsing, there are some other approaches. What we generally do is we use one of those extra security protocols at one of the different layers, at the application layer, at the transport layer, and at the network layer especially. And that's what the next few slides illustrate. But first, let's say we don't use any encryption, no security mechanisms. And we're just using HTTP or email, whatever application. And we send data from A to B. Can the attacker see the data? Just HTTP, yes. And how can they observe the data? What could they do to get that data? Intercept, where? In this picture, where would they intercept? Or the access point? Anywhere else? They could intercept at the router. So in general, anywhere between the source and destination, if they can intercept at any point between host A and host B, they can see our data. In practice, what that may mean is if the attacker has physical access to this device, the access point, they can intercept. Or physical access to the router. Maybe the attacker works for SIT. They have physical access to the router. So from the perspective of the two hosts, they can see the data going through the router. So any device between host A and host B, where our data passes via, anyone who has access to those devices can, in theory, see our data. In addition to the devices, also the links. Anyone, they don't have to have access to the devices. They just need to be able to monitor the links. With wireless, that's generally easy. With Wi-Fi, to monitor what I send from laptop to the access point, you can sit in the class with your laptop open and monitor and capture those packets. You know how to do it because you've done it in the lab. Remember we monitored Wi-Fi packets? So there, it's very easy because you don't need to have physical access to a cable. You can do it from nearby. With a wired link like Ethernet or maybe an optical fiber, it's a little bit harder for the attacker to intercept. They need to get physical access to that cable, maybe cut it and insert some special device. But it's possible. So we want to protect the communications between host A and host B. And we need to protect it all the way along that path. The first approach is what we call application level security. We implement security mechanisms in the application. The security mechanisms include encryption. Of course, to keep our data confidential, we need to encrypt it. But other mechanisms like authentication to make sure that we are talking to host B, some authentication mechanisms, key exchange to encrypt something at A such that B can decrypt it, they both need a shared secret key. How do we get that? And we need some key exchange. But what we're saying here is that those security mechanisms are implemented at the application layer and they are specific to the application. That's what I mean by application level security. If we do that, we have our normal application running on host A, and then we have some security mechanisms inside that application that encrypts our data, for example. And when it encrypts that data, the data is sent through the stack inside host A via either UDP or TCP, whichever one the application uses, via IP across the wireless LAN to the access point. The access point sends it to the router, which goes across the internet to the destination router Y and eventually received by host B and sent to the application on host B and there the corresponding application decrypts the data. And the app on host B has got the original data. So what the red line shows here is for all of that path, we say the data is protected or encrypted. If anyone intercepts anywhere along that path, although they can intercept the data, they cannot see the original contents because it's encrypted. Any questions so far? An example of this, maybe you're not using web browsing. You want to create your own application to talk to a server. Maybe it's a game application. You create a game that runs on a mobile phone and that game needs to talk to a server. So host A may be the mobile phone which runs the application and it talks to the server, host B. Let's say you want that data to be secure, confidential, then inside your code you could encrypt the data. You write the code to encrypt it and when the application sends it via either UDP or TCP, it's already encrypted. So it goes across the internet encrypted, preventing anyone from seeing the original contents. That's what we want. What are some examples that use this approach? One that you know very well, secure shell. You've used secure shell as an application, SSH. You run it on your computer. That uses application-level security. It encrypts the data that you send to the secure shell server on the other computer. Some forms of email use their own encryption. So things like OpenPGP or secure MIME, technologies that allow you to encrypt your email before you send it. So usually not inside a web-based email, but if you're using an email client on your computer, then that client can encrypt the email before you send it. Then you press send and as it's sent across the internet, it's encrypted and the receiving client, the receiving email client, the person who gets it, then must have that technology to decrypt it. So there are ways to do that. So it's done inside the application and there are others as well. What's good about this? We'll see that there are alternative approaches shortly. So we'll compare the advantages and disadvantages of the different approaches. This provides what we call host to host or end-to-end encryption. The data that we're sending is encrypted at the source host and decrypted at the destination host. Or it's encrypted at one endpoint and decrypted at the other end. So host to host or end-to-end encryption. This is what we want. We will see some other approaches later. Don't provide end-to-end encryption. This one does, which is good. Non-end-to-end encryption would be let's say I encrypt at host A and then it gets to router Y which then decrypts and sends the data unencrypted to host B. That is an example of not host to host encryption. That's less secure because for some portion of the path the data is unencrypted. Someone may compromise the data there. So this does use end-to-end encryption. When we implement the security in the application then it means that we don't have to depend upon the security features of the operating system. We'll see in the next approach we use an operating system feature to implement the security. Here the security features are implemented inside the app. Whoever develops the application is responsible for the security. And that can be a good thing because they can choose whichever security mechanisms they like. It can also be a bad thing because if it's the responsibility of the application developer to implement the encryption, the key management, if they make a mistake then the security mechanism may have a flaw. So it's not easy to implement encryption protocols. If you try to implement it yourself there's a high chance you'll make a mistake and that will be less secure. But the application implements the security mechanisms in this case. The other thing, what's the problem? As a result, every application, every different type of application must implement their own mechanism. If we do this, then let's say you create a game that talks to its game server. So that application must implement its security mechanisms. And then someone creates a different game that talks to a different game server then they must implement their own application level security. So there's a lot of duplication of effort because many applications would use the same security mechanisms. It may be better to reuse some existing security mechanisms and we'll see that in the next approach. Before we see the next approach, I forgot. In terms of implementation, where is the data link layer and physical layer implemented in your computer? If you think about your computer where can we associate those two layers with? Or if you don't know them, what about IP? Where is that in your computer? Did you install something called IP when you set up your computer? No, but it has IP, where is it? In what part or in what software inside your computer implements IP? Is it included in Firefox when you download and install Firefox? No, because you need the internet to download and install Firefox. What about other web browsers? No, where is it? What part of the software is it included? Not the network interface. When you buy a computer, what does it come with? An operating system. It comes with Windows or OS X installed on it. The operating system implements IP. So in terms of implementation, roughly we distinguish between, over here it's the same on host A and host B. The transport layer protocols and the network layer, TCP, IP and others, are in the operating system. You, as the application developer, have very little control over them. You don't need to write the code for them and you may not be able to access them directly. The application level protocols, well, that's part of the application. So if you install an application, like a web browser, that will most likely implement HTTP. The code for HTTP will be inside that application. But when you install your web browser, that web browser does not implement TCP or IP. That comes with your OS. And we think of the bottom two layers as usually as part of the network interface card, NIC, the NIC, or just simply the network interface. It's not always, but think of the hardware, the LAN card implements the data link layer and physical layer. The operating system, the network and transport layer, and the application at the top. Network interface card, like your LAN card or your Wi-Fi chip that comes in your computer on the motherboard. That makes a difference about where things are implemented because if you want to install an application, you can choose which application to install, and you may choose the security mechanisms it has, but you can't generally modify the OS. The normal user doesn't modify the operating system. Once it's installed, that's what they use. So it has an impact on what security features are available. Let's look at transport level security. So we looked at, okay, if we implement our security mechanisms in the application layer, it's like this. The application implements the encryption. Another approach, a different approach, implement the security mechanisms in the transport layer. And one very common example is using secure sockets layer, SSL or it's called transport layer security, TLS. TLS, for example, goes with TCP. It's like an extension of TCP to also add on security features. And note the difference between something implemented in the application layer and in the transport layer. If it's implemented in the application layers, it's in the application that we install. If it's in the transport layer, it's part of the operating system. So it comes with the operating system usually. We usually don't need to install anything extra because most operating systems support TLS especially. So that has an impact on what's available to the users. TLS comes with the operating system. Now there may be some slight differences in practice. It may be not inside the OS kernel, it may be in a library, but effectively it's part of the OS. So even though it looks similar, if you switch between transport layer security and application layer security, there's a difference in terms of where they're implemented. One's in the application, one's in the OS. Transport level security. You write an application. When you write the application, you don't implement your own security mechanism. What you do is you write your application to call the operating system to do the security for you. Has anyone written a networked application? I'm not sure if Dr. Komort got you to do it. Did anyone write sockets applications? Yes? Not yet? Maybe next year in your senior project. So when you implement a network based application, say a client talks to a server, you usually use some API that does the networking for you. It calls the operating system to send packets. Basically it calls TCP to send data. Well, if you want to use TLS, transport layer security, you write your application to you call TLS to send packets. You don't have to implement TLS or the encryption algorithms. You just use part of the operating system to do it for you. So you create your data in your application and it sends data using TLS, which then encrypts it, sends it through the stack inside your computer across the Wi-Fi link, across to your local router, all the way across the internet, still encrypted, gets to host B and TLS in the operating system at host B decrypts and then passes it up to the corresponding application. This is HTTPS uses this model. HTTPS is simply the application of HTTP using TLS. TLS and SSL in this course, I mean the same thing. They're slightly different versions, but TLS is the name of a protocol, transport layer security, secure sockets layer is the older name, that's all. And HTTPS is simply the application layer of HTTP using the operating system support of TLS. So your application doesn't need to be too concerned with the security mechanisms internally. And every application that wants to use security mechanisms can use the same implementation of TLS. My web browsing application, my email client, my game application, I developed them and my computer has TLS included, so I just developed them to use that. So there's only one implementation of the security mechanisms, it's in the operating system. So that implementation of the security mechanisms is shared amongst multiple applications. We don't have to reimplement for every different application. Whereas with application level security, if I wanted to do it in this way, my game would need to implement encryption. My other application, maybe instant messaging client would need to implement encryption. And my third application would need to separately implement encryption in application level security, which can be a waste of resources because they in many cases will implement the same thing. Right, in this case, TLS can be used by any application that uses TCP normally. No, you don't need to implement TLS. You can think, when I get my computer, TLS is included in the operating system. All I need to do if I'm an application developer is configure or program my application to call TLS. There's an API that says send data with TLS. The implementation of the encryption algorithms and the other security mechanisms is done for you. And it's installed in TLS in the OS. But with application level security, if you develop an application, you also need to implement the encryption algorithms or use someone's library that implements them. You may not have to do it yourself. And every application does that separately. Transport level security. TLS and SSL are the most widely used implementations. They're used in secure web browsing. HTTPS is simply HTTP using TLS. There are different variants of the email protocols to use TLS, SMTP, S for secure email transfer. IMAP is a way to access your email inbox and then there's a secure version, IMAP-S. FTP for file transfer, there is an FTP-S. FTP runs on top of TLS. So you just use your existing applications of HTTP, SMTP, IMAP, and they then use TLS to do all the security work for them. It's still host to host encryption. If you look in the picture, the encryption starts on host A, finishes on host B. That's good. It means the application development is much simpler. The application developer doesn't have to worry about the security mechanisms. They use the ones provided by the OS. So there's no need to implement them. You use security mechanisms that have been implemented and used for a long time by a lot of people and are well trusted. Some problems, the security mechanisms only work for specific transport protocols. TLS is only for TTP. If you want to send data using UDP, you cannot use TLS. There are others, but they're not very widely supported. So some operating systems will not support these like DTLS for UDP and SRTP. So TLS is very widely supported, the others are not. So back to the picture, I draw TLS is only goes with TCP. If your application wants to use UDP, then it needs another mechanism here. And when you develop your application, you must write the code such that it uses the correct API provided by the OS to use the security features of the OS. But we will not say much more about that because you haven't had experience in using those APIs. So very similar these approaches, but the difference between application and the OS. The last approach which provides end to end and security, do it at the network layer. There's an extension of IP called IPsec, IP security. What it does is that our IP datagram that we create, it allows us to encrypt that and provide authentication. So our application, HTTP for example, just creates the normal HTTP message, sends it using TCP, sends it to IP, a normal IP datagram is created and then IPsec performs the security mechanisms. It encrypts it. And then that's, think of that encrypted IP datagram is sent across the internet. IPsec at the host B receives eventually decrypts and sends the original data up to the application on host B. So this is a third approach. They're all doing similar things, providing end to end encryption, end to end security. IPsec is also in the operating system, okay? So it usually comes as part of the operating system. Most operating systems today will support it. It's a feature there. It works for any transport protocol. Doesn't matter whether your application's using UDP, TCP or some other obscure transport protocol, they're all sending IP datagrams. So if you use IPsec, it still gets encrypted. So that's an advantage. It supports all applications and all transport protocols. It can be used for host to host encryption, like in the previous picture. The problem is to use it, it usually requires the human user to set up IPsec on their computer. It requires some extra configuration in most cases to get it to work. And that makes it inconvenient because to get the human user to change some parameters on your computer, is very hard to get people to make the correct changes. So in fact, we'll see that it's not so widely used for end to end encryption. I know all of you have used application level security. You've all used Secure Shell. With Secure Shell, there's hardly any setup. You install the software and it works. All of you have used HTTPS. Again, you don't need to set that up at the server you do, but the user of the web browser doesn't need to do anything special to use HTTPS. Just select, make sure the link has HTTPS in it. So there's no configuration there. But if you want to use IPsec, it may require some setup on your part in setting up your computer to use it. And that means it's not so widely used for end to end encryption. Any questions on those three? Three different approaches to how do we get our data securely from one host to another? And they have different advantages and disadvantages. In the internet today, application level security is used in some applications. Transport level security is used by others. Network level security is not so widely used for end to end or host to host encryption. But network level security, IPsec and other approaches are used in some other way. What we'll refer to as tunneling mode. And we'll just introduce and show a picture of how that can be used. Here's an example how we could use IPsec or generally network level security. Let's say I'm at home and I want to access the internal SIT servers. So we have some servers like the databases here at SIT that are only accessible to internal. So let's say host B is an internal server in SIT, has an ethernet link to an SIT router, this router Y, which connects by the internet and router X is my home router. And I have a Wi-Fi device at home and I connect from my laptop via the Wi-Fi device through my ISP eventually into the SIT router then to the server. And let's say I trust the SIT network. I know it's very hard for someone to come into SIT and intercept my data between the SIT router and the server inside SIT. They need physical access to SIT to do that. And I trust everyone in SIT, all the employees, all the students are very trustworthy, aren't you? Okay, so let's say that's the case. But I don't trust the internet of course. I don't trust all the ISPs and I know it's very easy for someone to intercept my data. So one approach is to use network level security, or IPsec from say from my computer just to this router. This router has a special role of running IPsec and when I wanna send data, IPsec on my computer communicates with the router to set up a secure connection. Everything that is sent by my computer will be sent encrypted to router Y, which will then decrypt and send it on to the server, host B. So that's another mode in which we can use IPsec. The advantage here is that host B, the computer inside SIT, doesn't need to use IPsec. It doesn't need to be configured to use IPsec. So in fact, all the normal computers inside SIT could be set up as hosts here. They don't need to be configured to use IPsec. Only the one router for SIT needs to be set up. So say the computer center sets up that router to support IPsec. I set up my computer to support it, my computer at home and that allows me to have a secure connection just to that router. It protects the data between my computer inside my network and especially across the internet all the way up to the SIT router. And that may be sufficient security. It trades off security with convenience of not having to set up all the computers inside SIT to support IPsec. So that's another mode where IPsec can be used or maybe even simpler. Between my router at home and the router SIT, they talk with IPsec. I don't set up my computer or I have multiple computers at home, phone, laptop, PC. They are just configured normally but the router at home is configured to use IPsec to the SIT router. And the data between those two points is encrypted which is really saying the data between my internal network and the SIT internal network between those two networks is protected and that may be sufficient security. So that's another way that IPsec and other technologies can be used. This is using a concept called tunneling and it's generally referred to as a virtual private network of EPN. Tomorrow we'll explain how that works and look at the trade-offs of using IPsec and other technologies as here end-to-end, encrypt all the way between the hosts versus just using it over the one segment of the path from host to a router or even simpler between two routers. We'll look at how that's achieved and then what are the trade-offs of those.