 So, given these five, four security requirements, of course, we want technologies to provide these security requirements, but we'd also like those technologies to be cheap or free. That is, it doesn't involve the user having to spend much money to have it set up. We'd like it to be easy to use. I don't want to have to go through a day of configuring my computer, servers and so on just to access a website securely. I want to preferably just to open my browser and access it, maybe with a couple of options. And I want it to perform well in that when I access that website using a security technique, the performance should be about the same as if I didn't use a security technique. That is, when I access a website normally, maybe the response time is less than one second, I click on the link, I get the web page in a second. If I use a security technique, we'd like about the same response time. If it's much worse, then maybe we won't use that security technique. So given the requirements, we'll go through a few different options. And the first option is with no security, and it's just browsing with HTTP. If you try to access the server using normal HTTP, nothing special. And if the firewall is turned on, then you won't be able to access the server. Because you'll send a packet, your source address is you, the destination is the server. The packet gets to the firewall. The firewall has a rule saying anything going to destination S, don't allow it through. So we can't even access the server, let alone keep our data secure. So that's the first case with HTTP, a firewall can block it. What if the firewall was turned off? What if there was no firewall there? There was not a rule to block access to that server, but we still use HTTP. So we send our IP datagram and it goes from you to the server S. It will go through the firewall because the firewall doesn't have a rule blocking it. Nothing is encrypted. So let's say we're concerned about the owner or the operator of the firewall, maybe your ISP or your government or your employer. What can they see? Well, they can see the data, it's not encrypted. So the firewall can read the data or the operator of the firewall can read the data. They can see that it's you communicating with the server S, so they can identify who is communicating. What about others beyond the firewall? That is maybe other people in the internet or other organizations that want to observe what you're doing, what can they see? Still, because the data is not encrypted, others can read the data. Let's say the others access the packets on one of these routers and others can see who you're communicating with. So there's no confidentiality of data and there's no confidentiality of who is communicating if we use HTTP. And the last one, the server receives a packet, the source addresses you. So the server knows it's you contacting it. So there's no confidentiality with respect to the server. Normal HTTP provides none of the security requirements that we're looking for. So that's the baseline. What we're going to consider is three or four options. What if we add a security technique? How does it improve upon this case? And the first one is to use HTTPS, which we know we've studied in some depth of how it works. Where we encrypt the data between browser and server. We use certificates to assist in the distribution of keys. So what happens if we use HTTPS? Two options. First option, firewall enabled. There is a firewall. The firewall has a rule saying block anything going to destination S. We use HTTPS and I simplified the packet saying the IP source is still you. The destination is still S. The data inside is encrypted using SSL. We send that packet, it gets to the firewall, the firewall blocks it. Because the destination is S, the firewall has a rule block anything to S so the packet doesn't get through. In other words, using HTTPS does not bypass our firewall block. The firewall can still see who you're communicating with. So that, we can't even communicate in that case. What if there is no firewall? What if it's disabled? Then we send our packet, it goes through your local ISP, out to the internet and eventually gets to the server. What can, when I say what can the firewall see, I really mean what can the operator of the firewall see? For example, your internet service provider. What can they see? Well, the firewall observes this packet. They still know it's you talking to the server. So they can identify who is communicating. But they cannot read the data. We know with HTTPS, the HTTP request message is encrypted. The firewall will intercept that packet, but just see Cypher text there and therefore not be able to read what the original request was. So that's the first security service that we offer with HTTPS. If someone else out on the internet, another internet service provider, a government or another user intercepts your packet, one of these routers between the firewall and S, then they also cannot read the data because it's encrypted. And they can see who you're communicating with, because they can see the source and destination address. When the server gets the packet, the source address is you, so the server knows it is you contacting it. There's no privacy there. In summary, when we use HTTPS, we have confidentiality of the data. No one can see the data between you and the server, but we don't hide who is communicating. We don't have confidentiality of our behavior. And that may be useful for someone to observe. Even if they can't see the data, observe that you're actually accessing a particular website. So that's the basics. HTTPS, no security. HTTPS, confidentiality of the data, but nothing else. So how can we go better? What's another option? I want to hide who is communicating and even hide myself from the server, but still access that server. What can you do? Anyone tried it before? Access a website without people knowing which website you're accessing? Anyone heard of techniques that may be used to do that? Again? Using a proxy. Using a proxy, okay? So you may have heard, some of you may have even tried. You can use something called a proxy. What's a proxy in general? Someone who acts on your behalf. That is, normally when we contact a server, we send the request direct to the server. The concept of using a proxy, send the request to someone else who then sends it onto the server on your behalf, the proxy. And there are different styles of proxies, but we'll look at the case of a web proxy. And we'll show an example first and then we'll see how it works. Let's make sure I have some internet access. Let's open access a website. I'm just using the normal network connection within SIT. What website can we go to? I want to read some news, maybe I want to read some news in the UK. So I go to a website of a newspaper, dailymail.co.uk. Just a newspaper in the UK. Whoa, that's not the website of the Daily Mail, what's happened? So I've sent, my browser has tried to send a request to what I typed in, www.dailymail.co.uk. And then something in between me and the server, say some firewall, has received that request and like blocked it, in that it sees the destination address and then realizes, ah, you're not allowed to access that and not only does it block my traffic, it also redirects me to some other website. So the response that comes back says the warning message or error message. So let's use a web proxy to access the same website. And there are different web proxies available, basically they are websites. Some are free, some you pay to use, most of them are free nowadays. And you go there, VPN book is one of them, it's a free one. It's a bit slow, okay. You go there and instead of typing the destination URL in your address bar, you type it into their form, www.dailymail.co.uk. And what's going to happen is using this form, my browser sends a request to the VPN book web proxy somewhere. We'll see where in a moment. And then that VPN book web proxy is going to send a request to the Daily Mail website. Let's hope it works. It chooses a random proxy, they may have proxies in different countries. It's actually contacting the UK proxy, so some web server in the UK. And eventually, and you still in the address bar, it's still the website of VPN book. But what they're going to show on their website is the Daily Mail website. Some of the, it's slow to load all the style sheets, but you see it's simply a news website. So here's one way that we can effectively bypass a firewall using a web proxy. How's the performance compared to normal web access? How's the performance of using VPN book in this case? It's slower, you can see it's still loading the web page. So that's one of the issues. We want good performance, but often with a web proxy and some of the other techniques, the performance is quite slow, quite poor. Eventually it loads the web page, it's loading all the images. Okay, I can read my news. How does it work? Well, there's slight variations, but basically the general approach is that you go to the proxy website, you type in a URL that you want to visit. That sends a web request to the proxy website. And then when that proxy website receives it, it creates a new web request to the actual one you want to visit. So the destination server gets the request from the proxy web server. That one we looked at, VPN book was free. You'll find others which will display some ads so that they can make some money from you using their service. Because they must pay money to operate the server or maybe you pay per month. So this is the exchange of messages that may occur when you use a proxy. We know when we use HTTP, we send a HTTP request to the server and it sends back a response. Well, with a proxy, we have this node in the middle that acts on our behalf. So this is a simplified version of what happens. Here's you, when you visit the proxy website and type in the URL, you visit that form, we go back. When we visit this form, we type the URL and we press go. That triggers my browser to send a HTTP message to the proxy web server. It commonly, when you use forms, uses a post method with HTTP as opposed to a get. It sends that URL in a HTTP message. So that's this packet. The IP source is you, it's coming from your computer. The destination though is the proxy P in this case. And the HTTP message is usually a post message. And inside that HTTP message will be the URL of the one that you want to visit. www.s.com if we talk about accessing our example server or dailymail.co.uk. That would be in the HTTP message that's sent from you to the proxy. The proxy receives that message, realises that you really want to access this URL. So now the proxy creates its own get request, and sends it to the real destination server, S. So the next packet that comes out from proxy to the server. It's a HTTP get request saying get the file that I want on the server, abc.html in this example. Or get the index page of the daily mail. So that's a normal request to the website. The web server receives that, sends back a normal response. Sends back the web page in the response. From the server S to the proxy P. Because the server received the request from P, it sends the response back to P. The proxy server receives this web page. It doesn't show it on someone's screen. What it does is puts the contents of that web page in a HTTP response and sends it back to you. Maybe with some ads added in. So that they can display some ads on your screen and make some money from the advertising. That's one option. So the response from the real website is included in the response that eventually comes back to you in this fourth packet here. Where the source address is the proxy and the destination is you. Maybe it includes an advertisement plus the original requested web page. There are slight variations of how that operates, but that's a summary of using a web proxy. Any questions on how the web proxy works, okay? It's like a proxy does something on your behalf. So normally you send a request to the web server. What's happening? You send a request to the proxy server, the proxy web server. Then the proxy web server becomes a browser. It's like a browser now. And now it sends a request to the real web server. So if you think of the proxy here, it's acting as a web server with respect to you. It receives a request, sends back a reply. But the proxy with respect to the real web server is acting as a client or browser, it sends a request and gets a reply. So it's forwarding the request on your behalf. And using normal HTTP, the addresses are, the source is who sends it. And the destination is the server that we want to send it to. It's not just changing the address. It's creating a new request on your behalf, yes. Why does the get request not include the URL? Because I couldn't fit in it on the picture. Normally, okay? Good question. So it's not so important in this case. But normally with HTTP, when you send a get request, there's a field inside the header that says the host. And it would indicate www.s.com. Now, I didn't show it here because it's not really used in this case. What's important though, one of the fields inside the post going from you to the proxy must indicate the website that you want to access. That's the thing of importance there. When I click Go here, my browser creates a HTTP post message and there will be a field in that post message that says the URL is the Daily Mail URL. And that's important so that the proxy knows which website you really want to access. So I don't include all fields, just squeeze it into this picture. Any other questions? Let's see how this offers some security. So back to our case where we're using a proxy now, we've got our P somewhere out on the internet and we're using just normal HTTP to access it. The next case we'll consider HTTPS with the proxy. So you send a request to the proxy. Destination is P. The request contains of importance, something in that request contains the address of the real server you want to access. I include plus S here. For example, in the post message, the address of the server is included. So in this message sent, I indicate plus S, meaning the address of the server is somewhere included inside this message. It needs to be so the proxy knows who you want to access. The firewall is enabled. The firewall says anything that's going to destination S, block it. But this packet is going to destination P, so therefore it's not blocked. This packet gets through the firewall and it will go to the proxy server P. Now, from the perspective of the operator of the firewall, like your internet service provider, what can they do? They can read the data, nothing is encrypted when we just use HTTP. So they can still see the data. They cannot easily see the server that you're communicating with. Why do I say that? Can they really find out who the server is? Let's say you operate that firewall and you want to find, did that user access this particular website S? What would the firewall need to do? If it wants to know if you accessed website S, how would the firewall find that out? Is it possible? What do you think? Can the... Observe the data, the data plus S. So yes, the firewall can see that you're accessing the website. Why? Because this packet, unencrypted, even though the destination is P, inside the data something identifies the server S. In our previous picture, we saw the URL identified the server S. So if the firewall inspects the contents of the data, it may see inside there, there's a URL field saying, someone's accessing server S and may take some action, may try to block or may take a record that they're accessing server S. So they can see, but I say it's not easy for them to see, because to do that, first the firewall needs to inspect the data. And if we recall back to firewall's topic, we said packet filtering firewalls normally do not inspect the data, they just look at the header fields, because it's much, much faster to do so. It's easy to look at the source and destination of the millions of packets coming through the firewall, but it's hard to look at the contents of every packet and try and scan through the contents and find, is there some string that matches the one that's blocked? That's very, very time-consuming, and it's hard to try and detect the address of the server. So commonly firewalls don't inspect the contents. They could, but it's not so common. So that's why I say the firewall cannot easily see, they could, but we provide some extra security in that commonly we can bypass the firewall in this case. So that's a good thing from the security perspective. We can get through the firewall, and we saw that when we accessed with VPN Book, although I think that used HTVS. What else can happen? The request goes to the proxy. The proxy creates a new request from proxy to server to the original destination server. The server gets it and sends back a response as we saw in the previous slide. If someone here in this router intercepts the packets, what do they see? They see the data is not encrypted, so others can read the data. Do they know it's you contacting the server? No. They either see source address P, destination S, they think it's the proxy accessing the server, or if they intercept it here, they think it's you accessing the proxy. So the source addresses do not connect you to the server. So that's, we say others cannot see who you're communicating with. Unless they inspect this packet and look at the address, which is hard to do. The server doesn't know it's you. The service receives a request, source is P. So we actually have hidden ourselves from the server. We access a website. That website doesn't know it was you that accesses that website. So that's another security feature. So we've improved in that we now have some privacy. What's a problem? A problem is we must trust this proxy. The proxy server knows the data, okay, everyone can see my data, but the proxy server also knows it's me contacting the server, because they can keep track and see, you sent the request to this server, therefore they could keep a log or keep a record of who accessed which particular server. So with a proxy and HTTP, we do not have confidentiality of data. Others can see the data, but we do have some privacy of who's communicating, except from the proxy. You must trust the proxy in this case. Do you trust VPN book? Do you trust some random website to monitor what websites you're accessing? Well, maybe, depending on what you want to do. But there is a potential that they, the operator of the proxy, can use that information for their benefit or against you. So that's the problem with web proxies in this case. You must trust the proxy, because they know who you're accessing. We don't have confidentiality of data. We'll use HTTPS. Now we have an S up here. The data is encrypted. So now the firewall cannot read the data. Others cannot read the data. So we've got better security in this case. Still, the addresses, the firewall cannot easily see it's you, and others cannot easily see it's you. In fact, the firewall may not be able to at all, because the address is encrypted. The server cannot identify you. But for a proxy to work, even if we use encryption, the proxy must be able to decrypt and see the data. Why is that? Why does the proxy have to be able to decrypt the data? Because the proxy must know the destination server S. You encrypt the data, which includes the address of the server you want to access. You send it to the proxy. If the proxy doesn't know the server you want to access, they cannot forward the request for you. So somehow the proxy must be able to decrypt this, find the value of S, and then send, maybe re-encrypt the data and send a request to the real web server. As a result, the proxy can decrypt and then encrypt the data, so the proxy can still read your data and still knows it's you contacting the server S. We still must trust the proxy. So that's the limitation here. So generally with a web proxy, if you use HTTBS, the proxy can still see your data. So there's some trust necessary there. I think with the VPN book it defaults to a secure option where at least the connection from you to the proxy uses HTTBS, but not necessarily from the proxy to the web server. But we still trust the proxy in this case. So security perspective, it's good except we must trust the proxy. Convenience, it's quite easy to do. We just go to our website, type in the URL. Well, we have to do a... It could be maybe easier. We'd like to not have to go to someone else's website to visit the one we want. Performance, it wasn't so good, at least in the example we saw because we send to some proxy somewhere else in the internet, which then sends to the server. But other proxy servers may be faster. This one was free to use. So there are free proxies, so that's good. But most of them will need to make money somehow because the proxy server costs money. They make money by either you paying or showing ads. Can we improve? Well, let's look at another option. Before we look at VPNs, any questions?