[MUSIC] Sam and I wanted to put together a little bit more information about network security considerations for you. To make sure you understand the complete picture of what's happening on the network as we talk about transmitting information over HTTP, HTTPS, and we talk about the ATS settings, the app transport security settings. So at a high-level, keeping data secure requires an understanding and commitment to security first. And security doesn't just happen in one place. We're just gonna be talking about security on the network, so network security. But there are other kinds of security that are important too. For example, data security, keeping data secure while it's on a device. We'll be talking about that a little bit more when we talk about core data. And then there's other things like physical security. How do you make sure that if someone has an iOS device, it remains secure? These are all different things that security researchers and people that are concerned about security, think about. But we're gonna focus just on one aspect of it in this lecture, an aspect that we've been talking about a lot, which is network security. In fact, a lot of this was brought to life by Edward Snowden's release of top secret US information. That sort of demonstrated, not sort of, it demonstrated that there were a lot of entities that were interested in capturing information about people. That people were creating and moving across the internet. That upset a lot of people. And so some of what we're talking about, ways in which computer companies and individuals are responding in response to those revelations. So if you think about the Internet abstractly, which most people do. You should generally think about a smartphone, a device, a browser, a laptop, accessing some web server, like a web site, like maybe CNN.com or Apple.com. And you just generally think of the fact that when you make that request, when you request data or when you send data. It goes over the Internet, and the Internet is kind of this cloud. And we know it gets there somehow, and it's kinda like the telephone system, I guess. And maybe it's kinda like television, I guess. And the information goes through this cloud, ends up at the web server. And then it kinda sends it back. And there's a little bit of mystery about what's happening there. But revealing what's happening in that mystery is important for understanding why we're doing the security considerations that we are. So, a less abstract Internet looks like this. This morning I actually mapped out the path between my phone and a server at UCI. And in the center is the output of that mapping. And then this diagram shows a graphical representation of it. And what you can see is that there are at least 16 different computers that are involved in moving my data from my phone to the web server. So, those 16 servers that are involved each get to touch my data, and in some cases get to see it. So when I send data, I create some data on my phone and I pass it, and I wanna send it to the web server. I pass it off to my Internet service provider and since in this case I was working with a smartphone that was on a data network. The first place that it went to was to a computer controlled by Verizon. If you were on WiFi it would go probably to your internet service provider or if you're in sort of an organization it would go to your organization's network provider. So like a Comcast or a Cox in the US. That first step receives my data and then pushes it to another computer that's a little bit closer to my destination. And it works a little bit like the freeway system, where the first computers that you connect with are low bandwidth and way out on the edges of the Internet. And then as you get to the middle you get to these high bandwidth, freeway kind of connections. And then eventually your packet will go a long distance if it needs to, perhaps across the country or around the world. And, then it will get off an exit, if you will, and one of these smaller networks will pick it up and move it down until eventually it gets to the remote computer. So Verizon passes it off, 1, 2, 3, 4, 5, 6 different computers that are within the Verizon network. And through a number of different computers all the way to the web server on the other end. And then when the web server responds with that data, it comes back over a path that's similar. It may not be exactly the same, but it's similar to what it came across. So let's assume that it's the same coming back in this example. So the first step from that server at UCI is a UCI router or computer along the way. And then there are all these companies in the middle, and these are the actual companies. So the next company is a company called Scenic, I guess. I'm not familiar with that company, it's a backbone provider, three of those along the way. And then in the middle there's this one network router that doesn't even identify itself. It has an IP address of 198.32.251.125, but it doesn't appear to be registered publicly to anyone. It then proceeds to go through three servers owned by Zao.com. A company I am also not familiar with, a bandwidth provider. But the important thing to realize along the way is that your data is being handled by each of these computers. And many of them, you have no idea who they are. You don't know anything about their relationship with anyone else. You don't know anything about what they're doing with your data along the way. At the very minimum, you can imagine that it would be very simple for these computers to copy your data, and to keep a copy of it some way. And as, even in this simple path, this like not very exotic path to get data from one place to another. There are computers along, in the way, in the middle, that aren't revealing their identity, possibly for security on their part. And so you don't even know anything about the computers that are connecting your data from one end to another. So the data eventually will get back to us, and that's good. So as the data is moving from one end to another, there are actually several different protocols that can be used to move data from one place to another. Some of the names that you might hear associated with them are TCP or UDP. And that talks about, at a very low level, the networking protocol that's moving the bits from one server to the next server. Those are both examples of technologies that are based on sockets, or that sockets are based on those technologies. And then HTTP, HTTPS and HTTPS with perfect forward security are all built on top of sockets. What I'm referencing into is to something called the seven-layer network model. Which if you're interested in knowing more about networking, you can look up and find all the different layers that are involved in that stack. But for our purposes, I wanna focus on the fact that that data is being moved from one end to the other using one of three high level protocols in a smartphone application. There are some other protocols, but these are the dominant ones that you will experience. Particularly if you're using an API like the Instagram API we've used, or other web service APIs. Now when we work with HTTP, and we have the data that starts at one end and then moves from hop to hop along the way. One thing that's notable about HTTP, which stands for Hyper Text Transport Protocol, by the way, is that that data is completely visible. It's analogous to sending a postcard through the postal system. A post card maybe has a picture on one side, but has the words that you've written on the back. Anyone who holds that postcard, whether it's a postal carrier, someone in the post office, someone that's delivering the mail on the other end. Anyone can read what's written on that postcard, and when you use HTTP, it is the same. Any of those computers along the way can read the contents of your message as it moves from one end to the other. If you're looking at Pictures on Instagram, it might not be that big of a deal. But when you start thinking about looking at health care data or you start looking about financial data. Or you start thinking about your location data and you start thinking about who can see that sort of information. It starts to become a little bit more concerning, even far before you get to the point of state actors looking at your data. So, because HTTP is visible to every computer along the way, some more secure protocols have been developed. HTTPS is one of them. HTTPS stands for hyper text transport protocol secure. And what this protocol does is it establishes a connection from the client to the server using passwords held on both of those computers. And it encrypts the data that's in that packet so that only the originator and the destination of this packet, so the smartphone in this case, and the web server, can read that data. But I've exed out the data in this diagram to demonstrate that along the way no one is able to read that information. Now, people along the way are still able to copy that information, but what they'll be copying is a bunch of encrypted data that they really can't see, have any insight into, or they can't read at all. They do know that the data has moved from one place to another place and those places are seen. Obviously, in order to move that encrypted packet you have to know the destination. You have to know the origin in order to get it back, but the contents of the packet are encrypted. It turns out that this maybe not secure enough, and the reason why is because if you do record those packets along the way. And then sometime in the future you're able to get a password from either the web server or the smartphone through some other method. Then it would be possible to go back to that recorded capture of all the packets that went by in the past and decrypt them after the fact. And so what perfect forward security is about is about encrypting those packet in such away that even if in the future the password is compromised, if someone gets the password. It's not possible to encrypt the packets that were recorded at some point in the past. And so this is not just encryption, it still is referenced as HTTPS in a URL. But it's not just encryption, but it's encryption that can't be decrypted in the future. In order to do that, we have to use a cipher called TLS or a protocol called TLS version 1.2. So I mentioned that because in some of the utilities that I'll mention in a second, you will see reference to these TLS protocols. Different versions, and version 1.2 is the one that is currently the best practiced, best of breed for perfect forward security in an HTTPS session. Alright, so if you look at protocols in the internet by loading a browser you can see some of this. So if I go to http://www.uci.edu I will get information from UCI's public homepage and all this content, both my request and the content coming back is insecure. All of the data that moved from one end to the other end was visible by anyone that was helping me to get those packets to me and to UCI. Now this is content that is publicly available, there's nothing secret about it, so it's not really that big of a deal. If however, I request that information using the scheme https://www.uci.edu, the data that's moved from me to UCI, UCI back to me, becomes encrypted. So that no one in the middle is able to understand what it is that I'm receiving from UCI or what it is that I'm sending to UCI. Now it turns out that UCI is not using the most sophisticated certificates and ciphers in order to encrypt that data. And so currently, HTTPS at UCI gets a grade of about a C for it's security. There's no forward secrecy in the HTTPS connection. But, at the end of the day, that's not necessarily so bad. Because the information that's being transported over this channel, in this case, is really not that sensitive. Now, however, if you go to a website like the nsa.gov, and you try to connect to their website using HTTPS. Not only will that data be encrypted, but it will be encrypted at a very high security level. It does in fact use perfect forward security in the ciphers that it uses. And so the nsa.gov website receives a grade of an A for the security of its connection over the HTTPS protocol. If you're interested in checking out what the security is on a given website, what you can do is you can go to this URL here, https://www.ssllabs.com. And there's a page that will enable you to test a particular domain. So in this case I tested Google's website, the basic Google.com. And Google.com came back with a grade from SSL Labs of B. And that has to do with the level of security that they're implementing. And there are various reasons why Google might not be using a higher level of security, that have to do fundamentally with usability. But, this is a way you can validate using a GUI in a browser what different domains are doing for security. Now in iOS 9 and past that there is something called App Transport Security or ATS. And basically what this is it's a convention within the iOS app that we've talked about before. That says by default, the only way that the smartphone is going to allow a connection to occur from the phone to a web server, is if the HTTPS protocol, with perfect forward security is present. So, that means that not only do you have to be using the encrypted packets. But the web server on the other end has to be responding with a TLS version 1.2 cipher suite, cryptographic solution in order for that connection to be made. So that's the only one that's allowed by default. But you know that even in our previous lectures, we've run into web servers that don't support that high level of security. Kind of like we saw with UCI's website or Google.com's website, it may not be possible to connect to some websites with that level of security. And so in order to fix that, we did a couple things. We set our info.plist and we set one of the properties. In particular, this one was the NSExceptionRequiresForwardSecrecy. If we set that to NO, we're telling iOS that it's okay to make that connection from our smartphone to the web server using just HTTPS. It must still be secure, but it doesn't necessarily have to have perfect forward security. And so, this is sort of a compromise. It says that we're gonna have some security, we're not gonna just throw all security to the wind. But because the server doesn't support it and we'd like to use the services that that server offers, we're going to reduce our security in this app. So we set that to NO. Now we also saw in our very first course that we were accessing some services with financial conversions. In which the service on the other end didn't even support HTTPS. And so in that case, we had to set NSAllowsArbitraryLoads to YES. And that enabled us to use any kind of transit port scheme we wanted to. In particular, we wanted HTTP. And so all of our information to and from that service was completely viewable. And to do that, we would set our NSAllowsArbitraryLoads property in our info.plist file in our Xcode project equal to YES. So understanding how you're gonna make these connections It is a security decision that you as an application developer have to look into as you use these services. Now if you'd like to check security of a service that you're particularly interested in connecting with, you can use this command line option /usr/bin/nscurl --ats-diagnostics -- verbose. Space, the URL you're interested in. And what will happen is you will get back a report that your, in this case, I'm doing my laptop. I did it on a laptop. You couldn't really do this on an iOS device. But on my Mac laptop, I was able to get the report back. And it'll tell you what the settings of Info.plist need to be in order for you to successfully connect with that service. So, I did it with two different services. I did it with apple.com and I did it with the API.instagram.../recent that we worked with previously. So, in the left column you see whether or not http:// is allowed. Now you'd hope this would be allowed on these services because it's the most permissive. So what happens is the response back from the nscurl command says that if you set your Info.plist file to nsArbitraryLoads = true, the most permissive setting, then the result will be a pass. You will be able to connect to those services. On the other end, on the far right, if you leave the default settings of the out transport security settings that are present in iOS 9. If you leave them there, then you will see that apple.com's communication with pass, but your connection to the API at Instagram will fail and this is because Instagram is not supporting perfect forward security. And this is exactly why we had to put an exception into our Info.plist file because we couldn't use the level of security that we might have wanted to cuz the web server doesn't support it. So in the middle, you see the halfway point, and you can see that what this is saying is if we set NSException requires forward secrecy for that particular domain equal to false, then it will pass an Apple system, and it'll also pass an Instagram system. So what this means is that we will still be using https, but it will not be the most secure form of communication over that channel that's possible. But it's better than nothing. And so by using this command, you can see what the different options are for you as a developer for connecting to a service. And then you as a thoughtful, security concerned developer can pick the protocol that is balancing security and usability as best as possible for you and your users. Now for best practices, generally, you shouldn't disable App Transport Security entirely if at all possible. Sometimes you're gonna see people turn off ATS entirely by setting NSAllowsArbitraryLoads to true in their Info.plist file. Don't do this if you could possibly help it. Your bias as a developer should be toward security. You want the highest quality applications that you can develop. You want your users to develop trust from your system. You ultimately don't want your product to be implicated in some kind of security compromise of any sort. So just don't make it overly easy to write insecure network code. You wanna disable the bare minimum amount of ATS that you need to in order to make your service work. Now, one last thing that I wanna make you aware of. You should beware of http to https redirects. Sometimes web services, if you access them with an http scheme, will upgrade in the name of security to an https scheme. For example, if you go to http://duckduckgo.com, which is a private search engine, it will redirect you automatically to https://duckduckgo.com. As you can see in this little animation, as I type in http://duckduckgo.com and hit return, what I get back is a redirect to the https session. And from that point on, all communication with duckduckgo is secure over the https channel. Well, why isn't this good? Well, it is good. It's good for our browser, where you as a user type in something into your Chrome or your Safari or Internet Explorer or whatever you are using. But for APIs, that first request that you make over the insecure channel, for example, http://api.service.com, how's your access token on that URL? And so that first request is gonna go across on an insecure channel and that's gonna compromise the secret information that's in that URL. That secret information will be seen on that first transit across the network. And although subsequent traffic will be encrypted, your secret has been exposed along the way. And so, in other ways, that service can compromise your user. So make sure from the very beginning, you access the https version of your API, and don't rely on an upgrade, or don't use the least secure setting if you could possibly help it. Now the good news is, is that this is really difficult to do by accident when you're using an API. Unless you've disabled App Transport Security, because if you try and use http, iOS is gonna block you and not allow you to make that connection. In order to make a connection over HTTP, you have to explicitly downgrade your security. So, the answer is, don't downgrade your security. And if you do have to because the web service doesn't support a full perfect forward secrecy http ask connection, only downgrade it so that it doesn't require perfect forward security, still use https. So in summary, as we've seen and hopefully as we delve more into this lecture, Apple is now secure by default in this particular way that we're talking about a network security. Web services, however, on the other end, may not be. And in order to access these insecure web services, you need to add exceptions to Info.plist. But as a best practice, you wanna add as few exceptions as you possibly can. Thank you very much. [MUSIC]
