 Let's look at a different security technique that tries to meet our security requirements. Virtual private networks, which we've mentioned in the previous topic, virtual private network, the name comes from a private network would be one where I own the cables and the devices. So let's say SIT has a private network inside our campus, we own all the cables and devices, it's ours, we trust it, we don't use anyone else's infrastructure. If let's say a bank has a private network across the country, then they would own the cables and the devices across Thailand connecting all their branches and ATMs together, that would be a private network. Very expensive for individual organisations because they must deploy the infrastructure. So commonly today we use public networks, e.g. the internet, where other people own the infrastructure and we use it either at a cost or usually at a cost. Well a virtual private network, use the public network but use encryption and concept of tunneling such that we effectively get the service of a private network. No one can see our data, that's what we care about from a security perspective. So we saw an example of VPNs in the last topic where we saw IPsec being used. There are different VPN technologies, IPsec is one of them, it operates at the network layer, if you look in your phone at the VPN settings you'll often see that you can choose from IPsec or two from the data link layer called point to point tunneling protocol PPTP and the layer two tunneling protocol L2TP which are maybe a little bit older but more widely used. You can also use the application and transport lab protocols for VPN, I'll show a quick example where we use SSH effectively to provide a virtual private network. There's some other applications where you can install for VPN, open VPN is a popular one and that uses TLS to provide the security. But the idea is that when we use a VPN we take our original packet and usually encrypt it and put it inside another packet which goes to the VPN server, the VPN server decrypts and sends the original to the destination. So we can talk about we put one packet inside another. The original one is the inner packet and we put it inside another, say another IP packet and that's the outer packet, we'll see that in the pictures. Let's show an example, with a short amount of time I don't have examples today of open VPN or IPsec but I do have a simple one with secure shell so let's try that and we did it I think before. I go to whatismyipaddress.com, we get there, so I access this website directly and this website identifies me as being in Tamasat so it can identify me. Now what I do, I start a secure shell connection to a server which is outside, we'll see where in a moment, using secure shell but we'll use a special option with secure shell where we say we don't want to send commands to this server, we're going to say let's have this secure shell connection set up as a VPN and the option I use is minus D999, the number is a port number and it's a value I can choose so I can use another value that the number is not important in this case, it's just one I'll use for this example. What's going to happen is when I create this secure shell connection, the secure shell client software will listen from other applications on my computer and see if anyone wants to send any data. I don't want to send any commands to the server so I add the minus N option. Let's try this and then we'll explain how it works. I connect and I've already supplied the password before so it should automatically connect and here we go, all right we log in and then it gives no feedback because we're not using secure shell to send commands, we're using it to create a VPN tunnel. I want my browser to send its data via that secure shell connection, well to set up the VPN in my browser, it's actually referred to as a proxy like before. We go to the advanced network settings and I'll set up my browser to use a proxy, the idea is that when my browser sends a request to a website it will send to a proxy server. Well that proxy server is in fact my secure shell client software. The destination is localhost so my browser sends the request to my own computer, localhost represents me, but destined to port 9999, the one I chose. So really my browser is going to send the request to my secure shell client, my secure shell client is going to then send the request onto the secure shell server which will then send it to the real server. So we set that up to tell my browser to use a proxy and now hopefully it's working, I visit this website again, I don't want to share any location, and the website what is my IP address, where am I, where is my web browser, what country is my web browser in, too small, move up the front, Singapore, this what is my IP address website, of course identifies my IP address, IPv6, we'll come back to Y in a moment, but also identifies based upon that IP address, version 4 or 6, the country that the source is in, Singapore. What's happened is that my browser sends the request for this website to my secure shell client on my computer, my secure shell client sends that request to the secure shell server in Singapore, sandylands.info, and then that server sends the request onto the what is my IP address website. So the website thinks it gets the request from the sandylands.info server in Singapore, let's illustrate what happened there. What we had was my web browser, this is on my computer, or in our case you, we have my browser Firefox running, and it doesn't send a request directly across the internet, the way that I set it up to use a proxy is going to send a request to the secure shell server, the secure shell client, the secure shell client was listening on port in my example 9999, I could have used another number, that is when I run this command I start my SSH client, but I tell it to listen on port 9999, anything that's received on that port will be sent to the server sandylands.info. So my browser was configured to send all the requests to port 9999 on the local host, which was the secure shell client, so the secure shell client sends it out across the internet to a secure shell server, S for server here, I will not fit it in, and this is, the server is the address we used for the SSH client, sandylands.info in the example, there's a secure shell server running there, it receives the data via a secure shell connection, realises the data is actually a web request, and then sends that web request out to the real web server across the internet, and the real web server eventually gets it, and the web server, let's say Apache web server, and this was the server S or whatismyipaddress.com, with respect to port numbers, a real web server would be listening on port 80, secure shell server listens on what port number, 22, but my secure shell client was also acting as a server listening on port 9999, that was a special setup I used there. The protocols in use, between client and server of course we have SSH in use here, between the secure shell server and the web server, it's simply HTTP, and when I set up my proxy, when I set the preferences, if I just show you again, the proxy configuration, I'm using a special protocol to talk between my browser and my secure shell client called SOX, so the protocol to talk between these two applications is referred to as SOX, and this is internal to the computer, and we know with respect to encryption, this path is encrypted with the secure shell connection, everything is encrypted across that segment of the path. This is, we said even in the browser, it's a web set up as a proxy, but it's effectively a VPN. My secure shell server is a VPN server, but we're not using IPsec or one of those other protocols, we're using SSH as the protocol there, but we get the same service. The web server identified the secure shell server as the source, and it has actually an IPv6 address, and the sandylands.info is actually hosted in Singapore, that's why the website indicated that browser came from Singapore. With other VPN technologies, we get similar, that is we have a VPN server, and we set up the client to use the VPN client, but we use a different protocol here, not SSH, maybe it's IPsec. If it's on your phone, you go to the IPsec or the VPN settings on your phone and set up to use a particular VPN server using one of the protocols like IPsec or L2TP, and that connects from your VPN client to the VPN server, and then the data from your normal applications on your phone, like your web browser, is sent to your VPN client on your phone, which sends it to the VPN server, which then sends the data to the real server. So a similar set up. Questions on our example for a VPN. Before we look at the security implications. Anyone used a VPN before? Some people may have. Any questions? So sometimes when you use a VPN, the performance is very bad and maybe you don't even get to connect. Why is that? Well, one of the possible reasons, let's say here I am in Thailand, I want to access a website, let's say is also in Thailand. Normally when I access it, it's very fast because it's from inside the country to another server in the country. It doesn't have to go far, my packets. But if I use a VPN server outside of the country, in this case Singapore, not far away, then my data to that website go to Singapore and then back into Thailand. So the first issue is with respect to performance, the location of your VPN server is important. If the VPN server is a long way away from you and the real server, then your data needs to go there and basically come back adding delay and slowing things down. The other thing, the VPN server itself must be fast enough to receive your packets and quickly send them on to the real server. So it needs fast connections in and usually sometimes even fast software or fast computer to process the packets. If you're using a free VPN server, then maybe one of the limitations of that free VPN server, it's quite slow and they don't have fast connections slowing down your access. There could be other reasons, maybe that VPN server you're using, many other people are using it at the same time. So again, the data that you're sending into that and it's sending out is slowed down by the fact that many others data is coming through. So we rely on the performance of that VPN server and that's one reason why you may see poor performance and it's a very common reason. Let's look at the security implications of using VPN. So similar to the diagram I drew, but more general, we have you. You contact the VPN server, V, and then that sends the data onto the real server S. Now, the technology we use to talk between you and the VPN server, there's different options. But I generalize here, we're still using HTTP. What happens is that your VPN software, the VPN client, in my case the secure shell client, in your case maybe the software on your phone, creates a packet that is sent out of your computer and commonly what happens is that the original data and a header, let's say an IP header, where the source, if you can read here, the source is V and the destination is S. So you create a packet where the source will be that of the VPN server. The destination will be the final destination server, S. But that is all encrypted. And then we put an outer header saying this IP packet goes from U to V. So we'll see what happens. When we send this packet between U and V, what does the firewall see? What does the firewall see in this case, when it intercepts this packet? Can they see the data? No, the data is encrypted, so they can't see the data. What addresses does the firewall see? Which ones? Which values in that packet? Look at the ones which are not encrypted. What are they? U and V. So the packet sent by your computer through the firewall, the source is U, the destination is V. So the firewall observes you are talking to the VPN server. The firewall cannot read the data. It's encrypted. And they don't know that you are talking to server S. They think you are talking with server V. So they can't see the end server you're talking to because that address is encrypted inside the inner packet. So we have privacy of who's communicating from the firewall. That packet goes to the VPN server V. The VPN server decrypts the packet and it removes the outer header and it has the inner packet. Sources V, destination S and the data unencrypted. This is the original HTTP packet. That goes across the internet to the server. The server sees it's computer V sending to the server. So the server cannot identify you. They think it's the VPN server contacting it. We saw that on my example when I accessed that website. The server thought it was the sandylands.info contacting not my laptop. So that's one security feature. If someone intercepts the packets between the VPN server and the real server, they can read the data. The data is not encrypted. But they don't know it's you talking to the server. They only see the address of V in the server. So we have one floor here. Others can read the data. And the VPN can read the data. It's unencrypted. And they know it's you contacting the server. The VPN knows the request came from you. And it knows the destination is S. So the VPN does know who you're communicating with. How do we ensure others cannot read the data? How do we keep that data confidential? What are you going to use? Here we're using a VPN and HTTP. The HTTP request is going from V to S. But someone can see my data. Use HTTPS. Just in your browser, at your computer, visit the normal HTTPS website and the data will be encrypted. And that's this case. See the difference. At least in the data. The original packet created. The data was encrypted using HTTPS. And then it's all encrypted again, including the inner header using the VPN technology. So we really have two layers of encryption here. The data is encrypted with HTTPS. Then the data plus the inner header is encrypted with say IPsec or secure shell. Then the outer header is attached. Same as before, the firewall cannot see who's communicating. They cannot identify you and S. The firewall cannot read the data. It's encrypted. When the VPN server sends this packet, the data is still encrypted. So someone here on this router cannot see the data. So we have confidentiality from source to destination. In fact, because you're using HTTPS, the data was encrypted at your computer. It will only be decrypted at the server S. The VPN cannot read the data. But the VPN knows it is you contacting the server S. So we're almost there of providing all security features. The only limitation now is that we must trust the VPN server not to reveal who you're communicating with. Questions on VPNs. Who uses a VPN or has used in the past? Someone has. His was slow. Performance is an issue because we rely on this intermediate server. Was it free, your VPN server? You pay for it. You can pay how much? About 100 bar a month. No, 20 per amount. So you can usually get a VPN server for several US dollars a month. But there are other offers available. So reasonably cheap. It requires you to set up your client either on your phone, you do the VPN settings or maybe you install some software on your computer and it tells your client computer to contact the VPN server. And if you're using HTTPS in your browser, the VPN server cannot even read the data. Even though they know who is communicating, they cannot see the data.