In the third and last episode in the series on web security, Liz and Geoffrey look at HTTPS and how it keeps your web browsing both private and secure, and they also investigate private browsing or incognito mode and what exactly that mode does for your privacy. Plus, a new version of the protocol behind HTTPS and the latest Android release are cause for celebration, while Facebook and Google's approaches to data privacy are cause for concern.

Timeline

• 1:05 - Security news: Android 9.0 features
• 3:24 - Security news: Google still tracks your location even after turning off Google's Location History feature
• 4:28 - Security news: Facebook is asking banks for users' account information
• 5:08 - Security news: TLS 1.3 improvements
• 7:13 - The history of the insecure HTTP and secure HTTPS protocols
• 10:18 - Certificates and Certificate Authorities
• 12:51 - Making sure you're getting the HTTPS versions of web pages
• 15:57 - Does every web page need HTTPS?
• 18:06 - Incognito mode and private browsing
• 21:42 - Firefox Multi-Account Containers to separate browsing
• 22:20 - "People profiles" to separate browsing
• 22:58 - Should you just use a bunch of different web browsers?

Show notes & further reading

SSL and TLS

One of the authors of the TLS 1.0 specification, Tim Dierks, wrote a post about why it was renamed from SSL. Essentially, Microsoft had a competing revision of SSL 2.0 (the first public release from Netscape) called Private Communications Technology, and was reluctant to sign onto a standardization process that looked like it was endorsing Netscape in the midst of the browser wars. So we're stuck with both names today; the protocol itself is "TLS," but you will more commonly hear people talk about "SSL certificates" than "TLS certificates."

If you're interested in more history, there's a good overview of SSL/TLS and PKI history from author and security software developer Ivan Ristić. ("PKI" is the "public key infrastructure," which consists of certificate authorities as well as browsers and other parties working to make sure that trusted certificates are available to people who should have them and not to anyone else.)

Distrusting Symantec

One common worry about certificate authorities are that they are "too big to fail" - that a browser cannot distrust a certificate authority that has issued certificates for lots of websites, because the impact of breaking those websites would be too large. So the process of removing trust in Symantec, a $19B security company, has been very slow. Symantec's certificate authority division made a number of missteps, including mistakenly issuing certificates and mistakenly delegating the power to issue certificates, over the last few years. Mozilla started keeping track of these incidents in early 2017, and Google announced that Chrome would stop showing Extended Validation certificates from Symantec - their most expensive type of certificates - as a first step towards distrust.

After months of negotiations and public discussions, with both Chrome and Firefox planning to eventually remove all trust in Symantec, competing CA DigiCert bought the certificate business from Symantec, with the intent to move all customers to the DigiCert brand (and its higher standard of operations). The plan to distrust the old Symantec CA continues, with Mozilla, Chrome, and Apple all expecting to remove Symantec from the trusted list this fall.

This is essentially the first major removal of trust in the history of the PKI; all previous ones were either small CAs or CAs that primarily served a particular country. If it goes well, it will be a good sign that no CA is too big to fail and even the largest CAs have strong incentives to continue earning the trust placed in them.

HTTP by default

Earlier this summer, there was a warning about widespread malware called VPNFilter, which infects home routers and redirects connections to malicious sites. HTTPS is supposed to protect against this sort of attack, but VPNFilter seems to also hijack the HTTP-to-HTTPS redirect. So this is another very good reason to make sure you have an up-to-date browser with an up-to-date list of preloaded HTTPS sites (Chrome, Firefox, Opera, Safari, IE 11, and Edge all have one), and potentially type https:// by hand for new sites.

In the news

The AP's article on Google storing more location history than you would expect links to a guide they've written on how to delete existing history and make sure no new history gets recorded. If you're using a Google account, we strongly recommend looking through their suggestions.

In addition to the security improvements, Android 9 "Pie" has a bunch of new features that sound like all the more reason to upgrade promptly!

The IETF's site on TLS 1.3 has some information on the major improvements: more robust cryptography and improved performance. The Register and TechRepublic have longer stories about the development of the standard and some of the tradeoffs made in the process.

Transcript

Liz Denys (LD): Today's episode closes out our series on safely surfing the world wide web.

Geoffrey Thomas (GT): If you have yet to check out the previous two episodes, don't worry, each mile of the information superhighway has its own unique sights to see.

LD: Yeah, uh, as Geoffrey was trying to say, we're covering different topics in each episode. But if you're curious about the browser security model works or about cookies, plugins, and extensions, be sure to check out the rest of our series.

GT: So what's our topic for today?

LD: We'll look at HTTPS and private browsing modes to help you stay safe while browsing the web.

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: Android 9.0 was released last week. Every Android release is named after some dessert or candy, and this one is "Pie."

GT: Android versions just keep movin' on up.

LD: There's a couple of neat security features in the new version that check off some of the boxes that previously only iOS had. In particular, Android now supports devices with a hardware security module, a physically separate CPU that handles storing encryption keys and verifying the OS, similar to Apple's Secure Enclave.

GT: Because this requires new hardware, it's not an improvement for existing phones, but it does show the direction they want to go with the platform.

LD: Android Pie also adds "lockdown mode," which temporarily disables all methods of unlocking your device other than your PIN or password. It's useful if you're worried someone might be able to use your fingerprint or face recognition to unlock your phone without your consent.

GT: It's similar to the iPhone's Emergency SOS mode, which disables Touch ID and Face ID. We talked about it in our episode on securing your phone, and it was one of the reasons we were looking forward to this version of Android being released.

LD: The last one is support for encryption keys that require the device to be unlocked. In our episode "Comparing Android and iOS security," we talked about how Android's file encryption made the files readable from when you first unlock the device to when it powers down, and one of the advantages of Apple's approach to file encryption was that it supported having files that stopped being accessible once you lock the device again. Android now supports the same thing, too.

GT: There's another interesting new feature, the ability to do indoor positioning with high accuracy using the round-trip time to nearby wifi access points. Wi-Fi RTT requires access points or other nearby devices that support high-resolution timestamps, so the phone can calculate how far it is from an access point by sending a message and seeing how long it takes to return.

LD: Google states that the access points themselves can't determine where you are - the calculation is only done on the phone. Still, any phone app that has permissions to access your location can now track you very precisely, so it's a reminder to go through your apps and disable permissions for anything that doesn't really need it.

GT: As always, there are going to be a ton of quiet and boring security improvements that are only fixed in the latest version of the software, so if your phone is offering you an upgrade to Android 9, it's worth taking some time to do the upgrade as soon as you can.

LD: And if your phone hasn't been offering you OS updates for a while, it may unfortunately be time to think about getting a new one.

GT: An Associated Press investigation has found that turning off Google's Location History feature doesn't actually prevent Google from storing your location history.

LD: In May, a Ph.D. student at Berkeley found that her Android phone was asking her to review stores she visited when location tracking was off. The AP investigated with the help of some researchers from Princeton, and found that there are multiple ways that Google records where you've been - and "Location History" is the name of just one of those features.

GT: If you use Google Maps or the Android weather app, or if you even make web searches for things Google thinks it can find locally like "chocolate chip cookies," Google will record your location along with the history of your use of that app or service. That goes into "Web and App Activity," and not "Location History."

LD: The AP has a guide on how to stop the tracking and delete existing data that we'll include in our show notes.

GT: Honestly, this is one of the reasons I use an iPhone - I use so many Google services like Maps and Hangouts that I don't want it linked with the rest of what I do with my phone. Android is Google everywhere; iOS lets me limit Google's access to when I'm using Google's apps alone.

LD: The Wall Street Journal reported that Facebook is asking banks for account information for their users, including details like balances and transactions.

GT: It looks like it isn't quite as bad as that sounds: a Facebook spokesperson said the data is only for use as part of Facebook Messenger integrations, where you can chat with your bank and ask them about your balance.

LD: They've also stated that they're not using the information for advertising or other purposes. Still, it's going over Facebook Messenger, so the data is accessible to Facebook itself, even if they promise not to look at it.

GT: Facebook says this will be all opt-in, but we essentially have to trust them - if your bank and Facebook start making deals about your data, there's very little that you can do.

LD: TLS version 1.3, the newest revision of the protocol that secures the web and most other things on the internet, finally came out last week.

GT: We'll talk more about TLS in the main part of this episode. TLS 1.3 brings some notable security improvements, including getting rid of some older, less secure cryptographic algorithms, as well as older, less secure ways of using algorithms that are otherwise safe.

LD: TLS 1.3 also brings performance improvements when establishing a secure connection with a website you've already visited - browsers can now keep track of the encryption keys used so that they can attempt to create a new connection with that same key your browser and the web page previously established as only for connections between them.

GT: This is especially helpful when you're physically far from a server or on a bad cell connection because it eliminates some of the back and forth between you and the server before that connection can actually get started. Another good change is that they've gotten rid of a few less-secure forms of key exchange, where you directly encrypt things to a server's public key.

LD: Instead, when a TLS connection starts, the two ends of the connection will generate a new, temporary encryption key, and then the server will only use its public key to verify that it's one of the ends of the connection.

GT: This is called perfect forward secrecy. If the server's private key falls into the wrong hands, existing connections can't be decrypted. They're secure going forward, no matter what happens after the connection was set up.

LD: This was an option in older versions of TLS, but it's now mandatory. The older methods made it easy for someone doing surveillance to just log a bunch of encrypted connections and hope they get their hands on the private key eventually. Perfect forward secrecy puts a stop to that, because both sides of the connection forget their temporary key once they disconnect.

GT: Chrome and Firefox have both been shipping early drafts of TLS 1.3 for about the last year, but now that it's officially released, servers and other clients are likely to adopt it very quickly.

LD: This is the best kind of security news - you don't have to do anything, and everything's more secure!

Interlude music plays.

GT: So if you want privacy on the web, the place to start is making sure that nobody can read the conversation between you and whatever website you're visiting. You might need to make sure the website is also acting in a trustworthy way - like whether Facebook and banks share information - but if your traffic to Facebook or to your bank isn't private, then there's little point in worrying about anything else.

LD: When the web first came together for Tim Berners-Lee's nuclear physics documentation in the 1990s, there wasn't any need to protect against someone reading or modifying your web traffic. The Hyper-Text Transfer Protocol, or HTTP for short, just sent the name of whatever document you wanted in plaintext, and the server would send back the document in plaintext, and no one was really worried that other people on the research network could see what you were looking for.

GT: As web made its way from being a quote unquote "world-wide" collection of research laboratories to being actually available to everyone, nobody immediately re-thought this approach. HTTP still defaults to sending requests and receiving responses in plain text, which makes it pretty easy for someone who's on the same network to see what you're doing - especially if it's a wifi network. And if you're using a network from someone you don't completely trust - maybe you're at your local coffee shop or on a hotel's wifi network, or even browsing the web at work - you might not want them to be able to see everything.

LD: And not only can people listen to your HTTP requests, they could also potentially run what's called a "man in the middle" attack and alter your responses. If they can position themselves in the network between you and the server - for instance, because they control one of the routers - then you're actually talking to them and not the server directly - and as the man in the middle, they can change what you send or what the server sends, and you'll have no way of knowing that this happened.

GT: So, if you're ordering something online over HTTP, even if your credit card number is saved and you're not entering it, an attacker could just change what's in your cart and change the shipping address. Or if you're searching for web security tips, and you see a response from what you think is a trustworthy website, an attacker might actually have changed it to give you bad advice that makes your computer less secure.

LD: When e-commerce started to get popular in the mid-1990s, Netscape introduced SSL, the Secure Sockets Layer, a somewhat hastily designed approach to add encryption and cryptographic verification on top of existing protocols. By running HTTP inside SSL, you got HTTP Secure, or simply just HTTPS.

GT: Over time, SSL was revised to fix some serious security problems and add features, including newer algorithms and performance improvements. After negotiations with other browsers, in 1999, Netscape's SSL was slightly adapted and renamed Transport Layer Security, an official internet-wide standard. You might still hear people call it SSL in casual conversation, but the protocol has been TLS since the dot-com boom.

LD: TLS makes sure that the entire conversation between your browser and an HTTPS web server is encrypted, so that nobody who's seeing the network traffic go by can actually see what you're talking about. It also adds a cryptographic signature to all the data, so that you notice if someone is trying to modify the data. So even if there's a man in the middle, they can't read anything or change anything.

GT: TLS also lets the server show a certificate to prove its identity. A cryptographic certificate is just a signed statement that a public key belongs to a certain name, usually a website name, and so if you encrypt things to that key or you see other digital signatures from that key, you know it's from whoever owns the key.

LD: This is all part of the handshake. Your web browser says, "Hi, I'd like to speak TLS, and these are the protocols I support." The server responds with "Sure, I support these protocols, and here's my certificate." The browser looks through the certificate and checks the name, and they negotiate a few more things, like a temporary encryption and verification key to use during this connection. Once that's done, your browser can send an encrypted, authenticated version of an HTTP request, and the server can reply in the same way.

GT: So that brings up the question of how you know the certificate is authentic. Who signs it? Technically, anyone could make a certificate that says they're IKEA.com, but HTTPS won't respect just anyone's certificate. Browsers have a list of known Certificate Authorities that they trust, and they accept certificates that are issued or trusted by these respected Certificate Authorities. You can modify this list if you want, but generally speaking, you probably shouldn't do this because browsers are paying closer attention than you are to which Certificate Authorities are trustworthy.

LD: In fact, many web browsers are in currently the process of distrusting Symantec, which used to be one of the biggest TLS certificate vendors, because they've been caught being repeatedly lax about their internal security. You might think that it's worth trying to distrust Symantec right now, but you'll find that there are still a lot of websites that you'll be unable to access if you do so.

GT: If you follow the major browsers' schedule, then you get to take advantage of their efforts to reach out to websites and put pressure on them to change their certificates. For most people, the best thing you can do to get a good list of certificate authorities is to make sure you're taking browser updates regularly.

LD: HTTPS wasn't initially designed to do any sort of identity verification that says that ikea.com is actually showing content on behalf of IKEA, the popular furniture company. An Extended Validation Certificate is a special type of certificate for use with the HTTPS protocol that proves the legal entity controlling a website.

GT: So, for instance, if you go to ikea.com, you might see something in the URL bar that says this is IKEA the company from this country. But browsers generally don't work by looking at which company is operating a website: as we talked about last episode, they usually look at which origin, that is which website name, a web page is coming from. And so browsers haven't been super keen on supporting Extended Validation, and there's some talk of getting rid of it.

LD: Since HTTPS was not how the web was originally built, there's an issue that if you type in just the name of a website, like just looseleafsecurity.com, it's going to default to HTTP. You'd need to check once the page loaded that you got the HTTPS version. Currently, to check whether or not a web site is using the unsecured HTTP protocol or the secured HTTPS protocol and find out more about its certificate if it's HTTPS, you can look for indicators near the address bar in popular web browsers.

GT: Web browsers are constantly changing how they convey different security indicators as their understandings of how to best convey what is and isn't secure evolves, just like how Chrome's lock icon indicator for HTTPS is changing soon. Instead of just checking whether or not a website is using HTTPS after you navigate to it, you could also take more proactive approaches.

LD: You could personally type "https colon slash slash looseleafsecurity.com", but sometimes old habits die hard and people, myself included, rarely do this. Many websites, including looseleafsecurity.com, want to make sure that you're connecting to them over a secure connection and will send you a redirect to the HTTPS version of the site. But that still gets sent to you over insecure HTTP, so there's a risk that a man in the middle attacker might send you somewhere else.

GT: Usually that redirect is cached, and sticks around for a bit, but if you're on a new browser or visiting a site you haven't used before, it might be worth manually typing out that "https colon slash slash", even though it's a bit annoying.

LD: I guess you could also do a web search for that site, because the search engine will know about the actual site instead of a redirect. But then you have to worry about accidentally clicking on an earlier search result that seems similar or getting an ad you didn't want.

GT: There's a somewhat new standard called HTTP Strict Transport Security, where a website can tell your browser, "you should always access this site over HTTPS." So if you visit looseleafsecurity.com and you get the HTTPS version of that, your browser will remember "hey, I should always visit looseleafsecurity.com over HTTPS." There's even a couple of browsers that have built-in lists of some major websites using HTTP Strict Transport Security, so you can't be easily attacked if you're using a brand new browser and you type in, say, gmail.com while on an unsecured wifi connection.

LD: Also, there's a popular extension from the EFF called HTTPS Everywhere, which has a bunch of rules saying, here's the HTTPS version of this website. It used to be more useful a few years ago, before Strict Transport Security was around, and when websites were concerned enough about HTTPS that they wouldn't put HTTPS on their normal name.

GT: Yeah, many years ago Wikipedia only supported HTTPS on a special site name, secure.wikimedia.org. They stopped doing that as HTTPS got more popular and better supported by both browsers and web server software, and now they just set the Strict Transport Security setting.

LD: A good reason to still use HTTPS Everywhere is that it has a mode where you can ask it to block all insecure HTTP connections. It turns out that most websites support HTTPS these days, so you can generally get by with this mode enabled.

GT: Actually, that brings up something we should talk about quickly - does every website need HTTPS? It sort of seems like the whole web is moving in that direction.

LD: Well, where you're sending logins or financial information, of course, you want HTTPS. And also basically anything with a cookie - a cookie is a unique identifier just for you, so if it means anything, it should be secret between you and the website. Even a random Shark Game I've been playing lately uses it!

GT: Otherwise I'd definitely have stolen all your sharks over this wifi network by now. Anything that's sending you JavaScript and has sensitive information stored locally - even if it's not using cookies - also needs to use HTTPS, because otherwise an attacker can just send you malicious JavaScript that copies the sensitive information somewhere else.

LD: For entirely static websites, like Wikipedia or news sites, it's still important because you want to make sure that you're seeing accurate information from the website as they wrote it.

GT: And even for completely random websites, there's still some threats from malicious JavaScript that's now harder to identify the source of. It's similar to the malvertising attacks we talked about last episode - it's not a huge risk, but probably any website you're intentionally going to isn't going to be as hostile as someone camping out on the local public wifi trying to see who they can hack.

LD: So if you're on a wifi network you're particularly suspicious of, and all you want to do is quickly check your email, which you know should be HTTPS, you can use HTTPS Everywhere's HTTPS-only mode to make sure that nothing is sending insecure requests in the background from some link you click or some tab you forgot about.

GT: I commonly use the option to block all HTTP connections option when I'm at a coffee shop, because enough websites support HTTPS these days that I can get my work done without using plaintext HTTP at all. If I find a website that I really need to read that only supports HTTP, I'll open up incognito mode, and then I can read it without risking the secrecy of any of my cookies or anything.

LD: That brings us to our other major topic for today - incognito mode or private browsing. Before we dive into that, let's take a quick break.

Interlude music plays.

LD Your browser's "incognito mode" or "private browsing" feature is essentially a separate, temporary set of snow boots. As we discussed in the previous episodes in this series, the web browser security model is like a snow boot for each website - it makes sure that what's inside stays inside and what's outside stays outside. In this case, they start out empty even if your regular, non-private browsing included the websites you open in the private browsing mode, and nothing is saved when you exit the session.

GT: Any cookies, local storage, cached pages, or anything else from your normal, non-private browsing windows and tabs won't be available to the private browsing session. If you want access to your Twitter or Facebook or email accounts inside private browsing sessions, you'll have to log in again inside that session.

LD: Those things are saved while private browsing is active and shared among tabs within the session, so just doing all of your web browsing in private browsing mode isn't very helpful. If you log into Twitter in private browsing mode, you will stay logged into that account until you close all your private browsing tabs, even if you haven't had a Twitter window open in quite a while. If you're doing something as a one-off action in private browsing session so it has it's own private snow boot, you need to make sure that it's a fresh private browsing session and that you completely close it when you're done.

GT: Since cookies and other session information is shared within incognito mode, you can't simply do all your browsing in incognito mode just to keep things isolated to protect yourself from trackers like we were talking about last episode. You'd need to create a fresh session before each task and close it out completely when that task is done.

LD: Some browsers, like Chrome, also disable extensions by default, to make sure extensions aren't carrying information to or from your incognito session without your awareness. That means you might start seeing ads even if you have an unwanted content blocker, but it also means you might not have access to your password manager. You lose the phishing protection provided by having your password manager check the origin of a site before it enters your password for you like we talked about in the first episode in our web series.

GT: It can be really handy that Chrome's Incognito mode disables extensions in case you've got one of the aggressive extensions to help prevent tracking that we talked about last episode that has some risk of breaking sites that are written to expect tracking is going to work.

LD: Yeah, if a website doesn't load properly when I'm using Chrome because of either the settings I have with the Privacy Badger extension or NoScript, I'll often just open it in a new incognito session without anything else to see if the whole page loads as a quick check. And depending on what it is, I'll finish whatever business I have with that page in that private, separate snow boot so that I don't have to think as carefully about what other account information or browser history I might be exposing to that web page.

GT: Unlike cookies and session information, history isn't saved within a private browsing session at all. Once you close a tab, you can't look at your history to find where you were or use a keyboard shortcut to reopen that tab. If you're usually syncing your history across browsers, your activity in private browsing isn't being added to this either.

LD: If you're worried about someone who doesn't currently have access to your computer seeing your history, private browsing is a good way to look something up and then have that history disappear. Unfortunately, if someone already has access to your computer, they could already be monitoring your history. For instance, if you're using a computer issued by your employer, neither private browsing nor HTTPS can keep your web browsing private from standard workplace monitoring software.

GT: Or if an attacker gets access to your computer, they could install a keylogger or even something like parental controls to record your entire web history, whether it's from private or regular browsing.

LD: Right, which is why you should also be skeptical of how protective using incognito mode is on any shared computer because it can't protect you from monitoring applications that are already installed in that account.

GT: If you're a Firefox user, one alternative to using incognito mode to separate different types of work is an extension that they built called Multi-Account Containers, which separates your web browsing into color-coded tabs where each color has its own isolated set of snow boots. Cookies are separated for each of these containers, so you can segment your web browsing to separate things like personal email and social media from your work accounts or even create a completely new container just for your online shopping.

LD: You still have access to your password manager and other extensions, so it's a lot easier to have websites cookies and tracking separated without losing benefits like your password manager for entering passwords for you to help avoid phishing attacks.

GT: In Chrome, you can have different "People" profiles. Every non-incognito Chrome window you have will be tied to one of those "People", so it could be a handy way to separate work and personal browsing if you're doing both of those on the same computer.

LD: It's not as granular or configurable as Firefox's Multi-Account Containers, but I guess there's nothing stopping you from creating lots of different Google People profiles if that's helpful to you.

GT: If this model makes more sense to you, Firefox also has a built-in concept of profiles that works similarly, but isn't as prominent or intuitive as Chrome's in the upper right hand corner of the browser. In Firefox, you have to type about:profiles in the address bar to find it.

LD: Another strategy that some people use to separate different sections of their web browsing is to just use multiple browsers, one per context.

GT: While this works, it's kind of clunky and may even slow down your computer since web browsers aren't exactly the leanest when it comes to memory usage. You also have to remember to install the plugins you want for all your different browsers, like if you want unwanted content blockers to happen for all your browsing.

LD: Depending on what operating system and browsers you're using, your password manager might not even have an extension for all the different browsers you need. I know we keep coming back to this, but having that integration really goes a long way for making sure you always create unique passwords and to help with phishing prevention.

GT: So that about untangles the whole world wide web!

LD: Wow, Geoffrey, that is one way to say that this wraps up our series.

GT: Just like an unsuspecting fly in a spider's trap.

LD: Staaaaaaahp. Next episode, we're going to do something a little bit different. Instead of focusing on a particular topic in depth, we're going to chat about some fun security mishaps and scares we've had over the years.

GT: Most of them, scarier than spiders!

LD: Oy with the spiders already!

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.