Using HTTPS Properly

Disclaimer: I’m a big fan of Pandora. I’ve been a listener for a decade or more, and I started paying for an annual subscription even before there was any real incentive to do so, solely because I loved the service and wanted it to succeed. This post isn’t really about Pandora, per-se, but about common anti-patterns in the industry.

On Friday, I opened Pandora.com in my browser. Unlike my normal pattern of throwing its player tab in the background, I instead decided to click around a bit (I’m testing a new Chrome extension, more on that later). I immediately noticed that the player page was delivered over unsecure HTTP and I frowned.

Then I clicked Settings:

I was disappointed to see that the page remained over HTTP, and personal information was shown in the page:

Not good. While I have mixed feelings about network snoopers knowing what I’m listening to, I definitely get uncomfortable with the idea that they can see my email address, birth year, zip code, and more. With mounting concern, I clicked down to the Billing link:

Okay, so that’s not good. My full name, zip code, eight digits of my credit card number, and its expiration are all on display in a page delivered over an unprotected channel. Any network snooper can steal this information, or prompt me for more information as if it were the legitimate site.

Perhaps even more galling is the little logo at the bottom right, assuring me that my information is secure:

Okay, so what’s going on here? I’ve encountered sites that aren’t protected with HTTPS at all before, but it’s relatively rare to see a legitimate site claim that it is using HTTPS when it’s not. And Pandora’s a public company, over a decade old, valued at over $2,500,000,000.

Maybe Fiddler will reveal something interesting. The Billing page itself comes over HTTP:

… but it doesn’t actually contain my private data. My private data is instead pulled as a JSONP response from a HTTPS URL:

So, my private data doesn’t travel over the network in cleartext. Safe, right?

No, not so fast.

The first problem here is that this is JSONP data, which means that the unsecure calling page has access to all of the data—JSONP is being used to circumvent same-origin-policy. So, while a network-based attacker can’t read my data directly off the wire, he can simply rewrite the HTTP page itself to leak the data.

Furthermore, as a user, I don’t have any way of knowing which parts of this page are trustworthy and which are not. As a consequence, attacker-injected script on this page could ask for a password, and a reasonable person would probably type it. I groaned at spending 20 minutes mocking this up, but it turned out that I don’t even have to… the original HTTP page itself can ask for the password!

There’s no way for the user to know whether this is a legitimate password prompt which will securely handle the user’s password, or a fake injected by an attacker on the network.

At this point, I’d seen enough, and decided to contact the security folks at Pandora. Unfortunately, the RFC2142-recommended email address security@pandora.com just bounces:

I also had a look at the HackerOne directory, but unfortunately there was no entry for Pandora.

March 9 Update: Pandora has enabled a security alias and registered it with the HackerOne Directory.

Okay, time for regular support channels. On Friday afternoon, I sent the following message to customer support:

SECURITY BUG

Your site needs to be using HTTPS for ALL pages. The way it’s designed today allows an attacker to steal all of the private information (credit card digits, expiration, email address, music choices, etc).

-Eric Lawrence

Around 22 hours later, I received the following response:

Hello Eric,

Thanks for writing!

Like a lot of sites these days, by default we only use SSL encryption (the actual under-the-hood technology behind an “https” connection) for the portions of our pages that accept or transmit financial data. This saves a lot of overhead, both on our end and within your own browser, by transmitting most of the page – background color, Pandora logo image and so on – via a non-secure (normal web “http”) connection.

The Verisign logo, and the “in good standing” account status we have with them (which you can see when you click the Verisign badge on our payment page), indicates that we’re really encrypting the parts of that page (like the credit-card-entry fields) that need to be encrypted.

You can see that here: https://trustsealinfo.verisign.com/splash?form_file=fdf/splash.fdf&dn=www.pandora.com&lang=en

As an added precaution, you can manually load https://pandora.com whenever you make a payment on the site or update your credit card information.

You can also upgrade using PayPal rather than entering your card information with us.

Let me know if you have any other questions about this. Thanks again for your support!

Groan. Perhaps the worst part about this response is that it’s clear that I’m not the first to complain about this.

Okay, let’s take this point-by-point:

Like a lot of sites these days, by default we only use SSL encryption (the actual under-the-hood technology behind an “https” connection) for the portions of our pages that accept or transmit financial data.

It’s true that some sites follow this insecure practice, but they’re almost all vulnerable to multiple forms of attack. Beyond the threat of an active man-in-the-middle, conducting most transactions in plaintext means that my ISP (or whoever is along the network path) can profile me (learning what artists I listen to, for instance) and sell that data to advertisers.

We needn’t rathole on the fact that that the Pandora servers thankfully don’t even support SSL anymore, allowing only TLS1 and later.

ProTip: If you think you’re clever enough to securely encrypt only part of your web application, you’re almost certainly wrong.

This saves a lot of overhead, both on our end and within your own browser, by transmitting most of the page – background color, Pandora logo image and so on – via a non-secure (normal web “http”) connection.

First off, TLS is plenty fast. Second, if a site sending an endless stream of 6mb MP3 files needs to optimize performance, it’s unlikely that the “background color” is really the problem. And if it is, using a 2.1K file which is visually identical to your 246K file is probably a good start, as is caching it for more than one day. But I digress.

The Verisign logo, and the “in good standing” account status we have with them (which you can see when you click the Verisign badge on our payment page), indicates that we’re really encrypting the parts of that page (like the credit-card-entry fields) that need to be encrypted.

You can see that here: https://trustsealinfo.verisign.com/splash?form_file=fdf/splash.fdf&dn=www.pandora.com&lang=en

The “Verisign logo” referenced here is actually a “Norton Secured, powered by Symantec” badge. I suspect that the agent had the wrong text because they’ve been copy/pasting the same incorrect information for years.

What this badge actually means is that they have a certificate, not that they’re using it properly. The Certificate Authority does not verify that you’re doing HTTPS properly. “In good standing” means only that your check cleared when you bought the certificate.

As an added precaution, you can manually load https://pandora.com whenever you make a payment on the site or update your credit card information.

Finally, we have a piece of new information—the site is available over HTTPS. Sorta.

Security shouldn’t be optional; Pandora shouldn’t require users install browser add-ons (e.g. HTTPS Everywhere) or remember to type HTTPS every time to keep their information safe.

I emailed back and indicated that the response was inaccurate and requested my ticket be escalated to Pandora’s security team.

Sorry to hear you feel that way, Eric.

Thanks for writing in and sharing your thoughts with us. We value feedback from our listeners whether it’s positive or negative. Unfortunately, I am unable to put you in touch with our security team at this time.

So, that’s a no-go.

ProTip: Unless you want your frontline user-support team triaging security vulnerability reports, get a HackerOne account and hook up a security@ alias.

Since I promised that this post isn’t just about Pandora, here are two more screenshots:

It’s 2016. Bad actors are all over the network. Certificates are free. TLS is fast. Customers deserve better.

-Eric

March 9 Update: Pandora has enabled a security alias and registered it with the HackerOne Directory. They’ve also said “our engineering department is and has been actively working on transitioning http://www.pandora.com to HTTPS only.”