The web can be a scary place - but once you get to know it a little better, it doesn't feel as scary. Liz and Geoffrey go back to 1990 to figure out how the web came to be what it is today and discuss how browsers keep us safe. Also, two very good improvements to HTTPS in today's version of Chrome, and the future of Android security just got a whole lot more complicated.
Timeline
- 0:58 - Security news: Chrome 68's new security indicator scheme
- 1:52 - Security news: Chrome 68 enforces Certificate Transparency for all HTTPS certificates
- 3:20 - Security news: European Commission fines Google for breaching EU antitrust rules with Android device manufacturer restrictions
- 7:57 - A brief history of the web
- 11:16 - What the browser security model is
- 15:00 - Limitations of the browser security model
Show notes & further reading
Sandboxes and snow boots
The term "sandbox" refers to any mechanism that gives a program a limited, controlled environment to prevent it from making unwanted changes outside the sandbox. (The analogy is to a real-world sandbox, where you can play in it and have materials to build whatever you like, but hopefully you don't damage anything outside the sandbox.) Strictly speaking, it can refer to both how web browsers restrict what a web page can do, and restrictions on the web browser's implementation itself.
The web has always had restrictions on what web pages can do - originally because web pages weren't designed to do very much. When technologies like JavaScript came along, they were restricted to changing things on the web page and otherwise only accessing resources that the web page could already access.
As the web has grown more complicated, browsers have started placing themselves inside operating-system-level sandboxes as additional defense against bugs in web features: if, say, the JavaScript implementation had a vulnerability, the web browser process should still not be able to do too much damage to the computer. This was pioneered by Internet Explorer's Protected Mode in Windows Vista, and then heavily advanced by Google Chrome's sandbox, which took advantage of Chrome's architecture to significantly restrict what each part of the browser could do. The major browsers today all sandbox at least the most sensitive parts of their code.
If you search for information on browser sandboxes, you'll generally find information on this second meaning. But it's important to remember that all browsers do intend to restrict what web pages can do; the second type of sandbox generally determines how effective this is against attacks. We used the analogy of snow boots to refer to this combined system; snow boots vary in quality, but they're all going to keep your feet drier than walking around barefoot.
Origins and isolation
The web security model is based on "origins": at a high level, different pages from the same web site are from the same origin and can freely share data, but different web sites are different origins and are isolated by default. Like most things about the web, the idea of origins rose organically, but RFC 6454 gave it a precise technical definition in 2011. The same-origin policy is the foundation of web security; Mozilla's documentation for web developers goes into detail about the same-origin policy and what exactly websites can and cannot do.
Other people's computers
If someone else untrustworty has access to install software on your computer, it's not solely your computer any more. Microsoft's Ten Immutable Laws of Security go into detail about a number of cases of this.
They also mention that if someone untrustworthy has access to run scripts or other "active content" inside a website, the website owner doesn't have complete control of the website any more - because those scripts all run as the same origin, and have complete access to everything the website can do.
In the news
There are two exciting security changes in the release notes for Chrome 68: Chrome is marking all unencrypted HTTP sites as "not secure" and enforcing certificate transparency for all websites.
The European Commission has posted a press release about its antitrust ruling against Google, which goes into detail about Google's contractual requirements and how they impacted manufacturers who wanted to ship Fire OS. There's more analysis and reporting around the web, including from Bloomberg, which notes that competing browser maker Firefox and competing search engine DuckDuckGo have both responded favorably, and from The Verge, which compares Google's tactics with those Microsoft used in the 1990s.
Transcript
Liz Denys (LD): Geoffrey, do you think you're safe when you're browsing the web?
Geoffrey Thomas (GT): What even is the web, Liz? An information superhighway? A series of tubes?
LD: Oh good point, the web is complicated, and what it is right now has to do a lot with how it, and even computers themselves, came to be.
GT: Yeah, and that's why today's episode, the first in our series about safely surfing the world wide web, starts with a brief history of the web.
LD: We'll also talk about what the web's security model is -
GT: and what it isn't.
Intro music plays.
LD: Hello and welcome to Loose Leaf Security! I'm Liz Denys,
GT: and I'm Geoffrey Thomas, and we're your hosts.
LD: Loose Leaf Security is a show about making good computer security practice for everyone. We believe you don't need to be a software engineer or security professional to understand how to keep your devices and data safe.
GT: In every episode, we tackle a typical security concern or walk you through a recent incident.
Intro music fades out.
LD: Chrome 68 comes out today, and it's going to start marking every unencrypted HTTP web page with a "Not secure" indicator in the address bar.
GT: A couple of episodes ago we talked about their plan to stop marking secure sites with the little green padlock icon. That's coming in the next version of Chrome in September - this is the step before that. Chrome will warn you that if you're on a website that isn't completely using the secure HTTPS protocol, your use of that website isn't secure.
LD: We'll definitely be talking more later in this series about how to make sure you're connected to websites securely, because that's a very important part of using the web securely. This change should make it a lot easier for Chrome users to notice when they're not.
GT: A few years ago, you'd only see HTTPS used by a small percentage of websites, usually online shopping or banking sites. Now almost everything is HTTPS, and it makes sense to identify HTTP websites as unusual. We're hopeful that other browsers will start doing the same.
LD: Also in the Chrome 68 updates, they're enforcing a standard called Certificate Transparency for all HTTPS certificates. Every time an SSL certificate is issued, it has to be logged somewhere public.
GT: Over the last several years there have been incidents with certificate authorities either getting compromised or just not being very rigorous with what they're signing, and accidentally issuing certificates to the wrong people. It's very hard to discover that this has happened, without a public log of all certificates, which is what Certificate Transparency requires.
LD: There's very little point in SSL if it says you're securely talking to one person and you're actually securely talking to an attacker, so Certificate Transparency lets website owners notice bad certificates and say, hey, we didn't authorize this certificate, we don't know where this came from, and then the browsers can look at distrusting the certificate authority if it looks like they've been compromised.
GT: Facebook has a tool which will watch the central logs and send you a message whenever it sees a new certificate for a website you're interested in. It goes through Facebook messages so it's a bit weird but it is pretty easy to set up.
LD: Also, if you're interested in cryptography and decentralized systems, the design of Certificate Transparency is really cool - we don't have time to go into the details, but there's a lot of detail on the Certificate Transparency website about how you prove that a certificate was publicly logged without really having to trust anyone in the system.
GT: Google and Mozilla have both been working heavily on this standard, so Firefox will probably start enforcing it soon. Apple will also be enforcing it later this year in their browsers.
LD: The European Commission fined Google 4.34 billion euro for breaching EU antitrust rules, specifically related to the restrictions Google has imposed on Android device manufacturers around modifying Android's base code.
GT: It sounds like one of the big complaints is regarding Amazon's Fire OS, which is based on the Android Open Source Project code. Amazon originally developed this for the Kindle Fire, which was sort of a half-e-reader half-tablet, where they wanted to support Android apps but they they wanted an Amazon login instead of a Google one, and they didn't want Google Search front-and-center and the Google Play Store built in. They later released the Fire Phone, and apparently other manufacturers wanted to build phones based on Fire OS.
LD: Google had a rule: if you want to sell official Android phones, you can't have any phones running Android forks, like Fire OS, because they wanted to prevent Android fragmentation. The European Commission says that this rule is anticompetitive and illegal.
GT: Which is interesting because Android is already pretty fragmented, at least in terms of security, as we talked about last episode.
LD: Yeah. Google's own phones are doing really well on security, but it's already the case that phones from other manufacturers are all over the place, even though they're all running something that Google has certified as official Android.
GT: So when they say "fragmentation," they're just talking about the app store, choice of search engine, and so forth.
LD: They required that manufacturers preinstall the Google Search and Chrome apps in order to have access to the Play Store, and also prevented them from selling both Google-approved Android phones and any phones at all running an Android fork.
GT: And it's usually the lower-end, cheaper Android phones that tend to differ significantly from core Android and Google's best practices, so the problem is likely a lot worse there. The European Commission is right that there isn't very much competition in this market, because iPhones are generally on the expensive side.
LD: We were hopeful, last episode, that Android's Project Treble would make it easier for manufacturers to customize phones without compromising on security. As a reminder, Project Treble splits Android into a core that can be updated by Google on all phones, and extra components from the manufacturers with some security isolation. But it's not rolled out on all phones, and it's not mandatory.
GT: The frustrating part is that Google has been using its control over Android to promote other Google products instead of setting security standards for manufacturers of Android phones.
LD: And making deals with other web browsers or search engines is one of the ways manufacturers can keep prices down on their lower-end phones. Right now, they'd need to switch to something other than Android, like Fire OS, and they probably won't get the benefits of Project Treble or any other improvements going into Android itself.
GT: It would be super cool if Google's response to this ruling were to just extend Project Treble to allowing manufacturers to install another search engine or browser, but that seems unlikely to happen, and so the lower end models are likely to run Android forks.
LD: Another thing we mentioned last episode as a plus to Android's security was that Google offers a significant bounty for bugs found in Android's core OS, but that primarily helps Google's phones and phones using Project Treble. As more forks of Android pop up, more opportunities for bugs arise, and the hunt to eliminate those bugs becomes harder due to the number of variants out there, and forks that don't have as many users running them will get particularly low attention - meaning they're highly vulnerable.
GT: So Amazon is also a very large tech company - they run Amazon Web Services, which is the largest cloud computing service - and they could have a first-class security team for Fire OS if they wanted, just like Google has for Android. But they're not quite there today, and they aren't even running a bug bounty for AWS itself. If Fire OS gets popular, maybe in a couple of years it will be on par with Android and iOS security, but for the immediate future, we'd be worried about it.
LD: One of the risks with forking a project is that if there's a security fix that's already been tested in the project you forked, you have to test it on your own project too, to make sure it doesn't break anything and to make sure it's actually fixed the bug.
GT: This is a super common problem with forks of all sorts of open source projects. It's pretty time-consuming, and also you don't know if your changes mean there's a vulnerability that affects you but not the project you forked, or if that project's fix actually fixes it in your fork too or not, or so forth.
LD: And one of the biggest issues here is that it's not going to be easy as a consumer, or honestly even as someone who thinks a lot about security, to tell which Android fork you're running or to evaluate how effective the team that's maintaining it is at delivering security updates.
GT: We don't yet know how Google, Amazon, and cell phone manufacturers are going to respond to this ruling, but it's something we're definitely going to keep an eye on. It could go very well, if competition means someone starts focusing on security for cheaper phones. But it could also go very poorly.
Interlude music plays.
LD: Now for our main segment: safely surfing the world wide web. Let's start by talking a bit about where the web came from.
GT: It's 1990, and Tim Berners-Lee is working on a system to help nuclear physics researchers share information more effectively, by writing text documents with the ability to link to other text documents.
LD: Windows 3.0 has just been released. People are connecting to America Online and CompuServe. And when you run WordStar or Lotus 1-2-3 on your computer, the only thing you're running is WordStar or Lotus 1-2-3.
GT: It's pretty remarkable that we've been in essentially a continuous progression of backwards compatibility for the last 3 or 4 decades. Windows was designed to be mostly backwards compatible with DOS. Windows 95 was mostly backwards compatible with older versions of Windows. Basically, from the first IBM PC and the first Macintosh onwards, there was never a point at which there was a fundamentally new design.
LD: In the 1980s, when you ran WordStar on DOS, it had complete access to your computer. Why wouldn't it? So ten years later, when you run WordPerfect on Windows 95, it also has complete access to your computer. Ten years later than that, when you're running Office on Windows XP, it also has complete access to your user account - it's lost access to a couple of things, like now it can't install drivers, but nothing is preventing it from getting to all your files. And it's still like that today.
GT: Meanwhile, Sir Tim - well, he's not Sir Tim yet - has built a system where you can connect to a server and get a page with some links to pages on other servers. People realize you can make a server that generates a new page every time you connect, maybe showing you the current weather or something, and that you can also send information to the server. And then a couple of years later, some people decide this would be a good way to buy and sell things online, if only it supported logins and encryption. Over time, people realize you can make interactive web pages, with animations and all the things you expect from an interactive desktop application, by adding a few more features to the system.
LD: Really, neither desktop computing nor the web had the opportunity to be designed securely. Everything was always an incremental improvement over the previous system. But the web started from something very simple, adding features and figuring out how to secure them over time, but the desktop started off granting a lot of access to a lot of things and has been slowly fighting to pare that back over time.
GT: This changed with smartphones, which had no requirement of backwards compatibility. There was nothing people expected smartphones to be compatible with, besides just supporting the standard features they'd come to expect from older cell phones. So when the first iPhone came out about a decade ago, it didn't support installing apps at all - it just had a few things built in, including a web browser, and the idea was anything else you wanted, you'd get through the web browser.
LD: In iOS 2, apps were introduced, and a very specific security framework was created to keep those apps separate from everything else on your phone and from each other.
GT: We're starting to see some of these smartphone principles of separation come over to desktop computing, such as with the Mac App Store and the Windows Store, but the overwhelming majority of applications people run are still either run in the web browser, like if you go to trello.com or twitter.com and just use that in your browser, or if they're just traditional desktop applications, like Photoshop, iTunes, Audacity, or most video games.
LD: Photoshop's been around since 1990, predating modern smartphones by about two decades, so it's not surprising that it and other large software, even ones we think of as pretty modern, still have access to everything. Despite its organic growth, the web now has a pretty coherent security model that all browsers follow. It starts by separating different websites - different origins, as they call it - because the idea is that someone who operates one website can't cause problems for another website. If a web page or a script comes from one origin, its ability to access another origin is very limited.
GT: You can do things like load pictures from another origin, which has been common since the very early days of the web, before scripts or web applications really existed. But a web page can only tell the browser to put that picture on screen - it has no idea what the picture contains.
LD: If a website wants to - let's say it's providing public data, like a mapping service - it can signal that it should be accessible by other origins. But by default, they're isolated.
GT: Origins are defined by the first part of the URL which says what the server's name is. For instance, every web page on looseleafsecurity.com is part of the same origin, looseleafsecurity.com. This turns out to be important when we look into how browsers secure their connection to web servers.
LD: Each website can also store some data privately in a few ways; the most common one is cookies. Generally, cookies are used to store things like login sessions or preferences. It's important that this data is only accessible to the same origin; otherwise, if you're logged into your bank and visit any other website, it could start transferring money out of your account.
GT: A web page can choose to use part of the screen to display another web page. Online ads often use this feature, so that the ad company can show ads on its own, a little bit isolated from the main site. The main site's cookies aren't accessible to the ad, which is good for security overall, but the ad company is its own origin, so it gets to keep the same cookies every time it shows you an ad, on any website. If the website also communicates some information to the ad web page when it loads - such as what the website is, so they can get paid - then the ad company can effectively track you with the cookie, because they know you're the same person visiting all these other websites.
LD: That's not a breach of the web's own security model, because these websites are voluntarily showing ads and telling the ad company about you. But it might be something you don't want, and there are some ways to avoid that.
GT: Overall, what we just talked about with origins and cookies, is part of your web browsers isolation of web pages from each other, which is often referred to as "sandboxing".
LD: I know the term that's usually used is "sandbox", but since we all know sand never actually stays in the sandbox at the playground, I think it's easier to think of it as a "snow boot". For each web page you visit, your web browser sort of puts a snow boot around it to keep it separate from other web pages. While you browse the web, you're walking through the snow. Just like when you put on snow boots to go outside so that snow doesn't get your feet wet, your browser protects one site you load from other sites so that they don't interfere with that site.
GT: Even though there are potential weaknesses or holes in your snow boots, it's still better to go out in the snow with snow boots instead of barefoot. So in the same way, while your web browser might have bugs, it still tries to keep web pages isolated from each other, and it tends to do a pretty good job.
LD: And in this analogy, cookies are kind of like pebbles. If they started inside your snow boots, they're still in there!
GT: But if they're outside your snow boots, because they're for a different site, they're not going to get in.
LD: In fact, the web browser not only isolates different websites from each other with these snow boots, but also isolates the environment that it runs all websites in from the rest of your computer - so web pages loaded in your browser can't get access to files on your computer or to any applications you have installed there.
GT: Now that we've gone over what the web security model does, we can talk about what it doesn't do.
LD: We'll get to that after a quick break.
Interlude music plays.
GT: So, with this nice security model, what are the cases where it doesn't help you?
LD: The big one is with other apps on your computer. Remember, your web browser itself is just another app, and every traditional desktop app has access to everything in your account.
GT: So, viruses and other sorts of malware - if your computer gets infected outside the web browser, there's very little the browser itself can do to protect you.
LD: That's why it's really important to be careful about downloads. If you're intending to download software, be very sure about what website you're getting it from, and that you got it over an HTTPS connection. If you can, see if the software is available from your desktop's app store, because software in the app store runs in its own sandbox or snow boot isolated environment.
GT: If you're intending to download a file that's being opened in a complicated program - and, to be clear, a modern word processor or PDF viewer is definitely a complicated piece of software - make sure you're getting it from a trusted source. Oftentimes, a better choice is to view it with some web-based software like your webmail client's built-in preview, because then it stays on the web and not on your computer.
LD: Along those lines, if you're using somebody else's computer, the web browser won't keep you safe from things they've installed. Probably goes without saying, but there are a couple of common times when this comes up.
GT: If someone else has the ability to install things on your computer - your employer or maybe someone you live with - then it's not solely your computer. It's fine if you trust them, or in the case of your employer it's fine if you're using the computer to do work for them. But it's very easy for someone with access to your computer to install something that completely breaks this security model and leaves no obvious signs of breaking it.
LD: There are monitoring tools and things called RATs - short for remote access tools - that let someone see everything on your screen and everything you type. There are keyloggers, and all sorts of other hidden things that can grab your password. If you have a computer for just yourself this isn't something you should really need to worry about.
GT: If you're using a shared computer, like at a public library, a hotel's business center, or a university computer lab, then that's also a computer that other people have the ability to install things on. Typically, these sorts of computers are running some software that cleans up between users and prevents things from getting installed, but it's definitely worth being cautious if you don't really trust the people who own it, or if it doesn't look like it's running anything special and is just giving you access to a normal desktop.
LD: Let's say you're at a hotel and you need to print your boarding pass - definitely something I do a lot, because I want a backup in case my phone dies and in case I get to the airport a little too late to get to the kiosk. It's a lot safer to just enter your confirmation number into the hotel's business center computer than logging in to your account with the airline. If something goes wrong - either there's a keylogger, or the business center machine isn't very good at cleaning things - people can mess with your flight in the worst case, but they don't have access to buy new flights, access to all your personal information, and so on.
GT: Whatever you do, definitely don't log into your email account from this sort of shared computer - that's a huge amount of power. If you just need to look up your boarding pass or tickets, do that on your phone or your laptop.
LD: The web security model also does not protect non-HTTPS websites from people who have access to your network connection. When you're traveling or at a coffee shop or on the free public transit wifi, this is particularly important to keep in mind.
GT: Once the sites are on your computer, your browser will protect the data and isolate the sites from each other. But it can't protect the connection, unless it's HTTPS.
LD: When it isn't HTTPS, someone on your network connection could read the unencrypted network traffic and see what your sending, including potentially sensitive information like passwords or credit card numbers. They could also give you fake responses, like if you're trying to log into your bank's web page, they might show you a malicious web page that looks just like your bank's web page, but any transactions or information you provide on that site is just going to that person snooping on your connection instead of to your bank.
GT: That could be really scary if you're moving money around or trying to pay a bill on time because the attacker could just pretend to be the same origin as your bank and bypass that whole security model. Also, we've talked about software updates many times before, but this is a good time to reiterate it - the web is incredibly complex and browsers are just difficult to get right. If you're not running the latest version, there's a serious chance you're at risk.
LD: If you could replace your snow boots for free, every season, with a new pair of snow boots where they've reinforced all the parts that used to wear down too quickly, you know, all the security holes that everyone had problems with, you would instead of wearing older snow boots with known holes in them, right? Browser updates are just like that.
GT: Fortunately, most web browsers automatically update these days. If you're running Chrome, Firefox, or Opera, just make sure you restart your browser when it prompts you - usually with a little colored marker in the menu in the corner.
LD: Apple Safari and Microsoft Edge are both shipped with the operating system, so updates come from the OS. Just make sure you're applying security updates from your OS - which is also extremely important in its own right for keeping your device secure.
GT: If you're using Internet Explorer, you should switch to something else, whether that's Edge or something not made by Microsoft. Microsoft does still update Internet Explorer, but they just keep it around for compatibility with businesses who made IE-specific websites and can't change. So a lot of what's now common security design wasn't there because it wasn't around when IE was popular, and they can't just add it now.
LD: Edge is Microsoft's new browser which was written ground-up with a secure design, and in fact, Edge itself is sandboxed with the technologies used for sandboxing Windows Store apps.
GT: That's a big gain over Internet Explorer!
LD: If you're using some other browser, you should really think about switching to one of the major ones. Writing a good, secure web browser is pretty hard. Even Opera switched in 2013 to being based on the engine from Chrome, because they were worried about being left behind on features. And even if you're basing your work on one of the major browsers, you've still got the difficulties with forks and security that we were talking about earlier, with Android forks.
GT: It's hard to respond to problem reports quickly without a well-staffed full-time security team. There are a few niche browsers that focus on being secure options, but if you're interested in using them, be sure to check out how frequently they've been releasing updates.
LD: Tor, the anonymous, decentralized private network, has a product they call the Tor Browser that's based on Firefox, but with a lot of privacy options cranked up so that nothing accidentally reveals your real identity. Despite having a number of top-notch security folks working on it, they've had trouble keeping up with integrating their customizations with updated versions of Firefox, and a couple years back, they decided to work with Mozilla on integrating their privacy improvements into Firefox and aiming to just ship Firefox with some preferences changed, instead of having a separate product.
GT: Which is good news all around - it's less work for the Tor developers, it's great for Tor users, and it's great for everyone else who uses Firefox, too, because those fixes and preferences are going to be generally available in Firefox itself.
LD: So like so many other security things, make sure you take those browser software updates.
GT: The last thing that the browser can't help you with is it can't make sure you're entering things into the right website. Which sounds a little silly, but this is essentially how phishing attacks work. The browser itself is never going to accidentally send cookies for your bank to a fake bank website: it knows that these are different origins. So phishing sites aim to trick you.
LD: The easiest way to stop phishing is to stop logging in manually and make it the browser's job. For passwords, the best way to do this is to get a password manager extension that integrates with your web browser. Your password manager not only keeps track of the passwords for you, but also where you use that password, and when you're on a site, using the integration to pull up your password means it won't provide that password to a phishing website with a different origin.
GT: For two-factor, the gold standard, especially on desktop, is to use security keys when you can. You're not typing anything in, and the U2F protocol works by sending the name of the origin to your security key. If that doesn't match the original origin, the authentication won't work, so there's no risk of accidentally giving your two factor code to a phishing website that is then going to use that information on the real website to break into your account.
LD: There are some password managers that offer two-factor authentication built in. As we mentioned in our two-factor episode, it's better than not using two-factor at all, because it gives you additional protection against leaks and keyloggers - your authenticator code is new every time. But if you're already using a separate two-factor mechanism like an app on your phone, it's probably better to keep doing that and keep your two factors separate. Your password manager extension will still verify the origin when entering the password itself, which protects you pretty well.
GT: We talked about these tradeoffs more in our previous episodes on password managers and two-factor authentication, but thinking about how these fit in with web security and keeping origins separate from each other, it's cool to see just why password managers and security keys work so well.
LD: Actually, Google just recently said that none of their employees have been a victim of phishing attacks since they started requiring that people use security keys.
GT: Very cool - but it points to how complicated the web is that we only got a highly secure method of logging in a couple years ago.
LD: The web's come a long way since Tim Berners-Lee was working on nuclear physics documentation in the 1990s. Unfortunately, we've just scratched the surface of how its security model has come to work.
GT: Next time, we'll start digging into specific risks and what you need to know to keep yourself safe.
LD: Like how cookies work!
Outro music plays.
LD: Loose Leaf Security is produced by me, Liz Denys.
GT: Our theme music, arranged by Liz, is based on excerpts of "Venus: The Bringer of Peace" from Gustav Holst's original two piano arrangement of The Planets.
LD: For a transcript of this show and links for further reading about topics covered in this episode, head on over to looseleafsecurity.com. You can also follow us on Twitter, Instagram, and Facebook at @LooseLeafSecure.
GT: If you want to support the show, we'd really appreciate it if you could head to iTunes and leave us a nice review or just tell your friends about the podcast. Those simple actions can really help us.
Outro music fades out.
GT: Oh, Liz, since the next episode starts with a discussion about cookies, are you going to make those delicious matcha cookies for us to eat while we're writing the episode?
LD: Sure!