#httpshaming

Videocon d2h, a direct-to-home satellite TV provider in India, does not use HTTPS on its website. All connections go over insecure HTTP.

This is particularly concerning on the "My d2h" section of the site, which collects usernames, passwords, satellite card numbers, customer ID numbers, mobile numbers, addresses, and billing information. All of these details can be intercepted on a monitored or open wi-fi network.

d2h uses third-parties to process payment card data -- Citrus, TechProcess Solutions Ltd, or CC Avenue -- all of which appear to use HTTPS, but personal information is transmitted both before and after transactions in the clear.

Videocon d2h has managed to implement HTTPS on its login form for partners and distributors. It would be great if they cared about the security of their customers as much as the security of their own company's data.

Pandora’s registration form – which loads and POSTs over insecure HTTP – collects personal information (an email address, password, and date of birth). Even worse, subscribing to Pandora One requires the entry of credit card details over an insecure HTTP page. Chrome even refuses to auto-fill the form fields with saved credit card data, because it loads over an HTTP page.

All personally-identifiable data should be transmitted securely over HTTPS, all bank card data should most definitely transmit over HTTPS, and logged-in sessions should happen over HTTPS only as well. 

Pandora is a large and established company, and there’s no excuse for exposing user and financial data to theft and fraud.

The website for Toyota Owners to login to for scheduling service and viewing service history uses insecure HTTP on its homepage, on certain portions of the registration process, and once authenticated.

When registering for an account, your name and email address are sent in the clear. Depending on the registration flow you proceed through, your home address, username, password, and vehicle identification number (VIN) are also transmitted without encryption.

The login form is loaded over HTTP and POSTs to HTTPS, so credentials are transmitted securely for the login (but not always the registration). However, if any form is loaded over HTTP, the POST location could be changed via injection if the connection is intercepted, and other malicious JavaScript could be added to the page.

Toyota’s website should use and enforce HTTPS on every single page, and it should also make use of HSTS.

This was submitted by David, who writes: “I have tried to discuss this with Toyota’s complaint department, but they are disinterested in the issue and ignorant of what it actually means. One person told me the info on the site is ‘internal and private,’ which means nothing and is certainly not a substitute for HTTPS.”

Update: The entire WhiteHouse.gov domain is entirely HTTPS now. This is resolved!

The federal government is seeking technologists to help transform the way Americans use technology to interact with their government. It's the new United States Digital Service (USDS), and you can apply on the White House website.

I cannot contain my excitement for USDS now being a thing — this is awesome. But one problem: the application form does not use HTTPS. Everything an applicant submits is sent plaintext without encryption over regular HTTP: full name, email, phone number, ZIP code, résumé file upload, links and skills, etc. All of this data could be easily intercepted by third parties on a public wi-fi network or on an employer-monitored network, for example.

If you do try to manually change the URL from ‘http’ to ‘https’ to have encryption in transit, you get a certificate name mismatch error. If you proceed beyond the error, the site redirects you back to insecure HTTP anyway — the White House uses Akamai, which is notoriously terrible at HTTPS.

Okay, this is not the worst violation of privacy on the internet – not even close. In fact, (successful) job applications may be public government data subject to disclosure pursuant to the Freedom of Information Act anyway. 

But here's a few details to keep in mind:

Privacy is not just important as an abstract concept, it's also important in context. Even if information is legally public or not a huge risk, that doesn't mean the person sitting on the other side of the café should be able to see it while you're sitting there. It doesn't mean your employer should be able to see you're applying for a new job while on your lunch break.

Just as HTTPS provides encryption to prevent against eavesdropping, it also protects against alteration of data in transit. Crazy example: it is absolutely possible to automatically change all POST data to add in offensive material if a connection is being intercepted with, for example, a WiFi Pineapple.

HTTPS does not just ensure data in transit is encrypted, it also provides authentication. The applicant in this case could be entering all their personal information on a website pretending to be WhiteHouse.gov.

If the White House is serious about getting technologists who know what they're doing and have a passion for using technology right and with the best interests of citizens in mind, there will be potential applicants who don't want to fill out an insecure form, and shouldn't have to suffer their personal information being at risk just to do so.

Finally, President Obama cited the federal government's interest in ‘cybersecurity’ at his State of the Union address. If the website for the executive branch of the United States Government does not employ HTTPS to ensure authenticity and encryption, should we have faith in the sincerity of that interest?

Submitted by anonymous, anonymous, and aam.

WebMD's website has numerous features that transmit health information: both generic information about specific health conditions and symptoms, and personal health information linked with a user account that has identifying user details.

Anytime someone is accessing or transmitting medical content online – whether generic or linked with their user account – there's no question that the information should be secure and encrypted with HTTPS to prevent others intercepting a network connection (e.g. on a public wi-fi network at a café or airport, or your employer) from discovering your medical symptoms, conditions, and medications.

Unfortunately, WebMD does not use HTTPS most anywhere on its site except when a user actually signs up or logs into the site. And once the user is logged in, the site sends them right back to unencrypted HTTP.

Even though a user may sign up using a pseudonymous username, they are still prompted for their email address, first name, last name, a profile photo, and ZIP Code, all of which can be personally identifying to others.

Writing a post on WebMD's condition-specific forums? Well, anyone monitoring or intercepting network traffic now knows that you have the condition, along with anything you write or have written in the past:

Entering an HIV medication in WebMD's medication tracker? Well, anyone monitoring the network now knows that you're HIV Positive:

As mentioned, WebMD does use HTTPS (TLS/SSL) to encrypt the sign up, authentication (login), and account management pages. However, if a site allows a user to continue onto unencrypted HTTP pages after authenticating as WebMD does, their work is for naught: a user's session data sent over HTTP can be easily be hijacked and someone across a café or airport could now continue using WebMD's site as you, and see anything that you could see.

Even the more generic portions of WebMD's site, like informational pages about specific conditions or the WebMD Symptom Checker use insecure HTTP. Although those are not tied to a specific user account unless logged in, it's still insecurely transmitting information about your specific medical symptoms and conditions, and that's not okay.

This HTTP Shame was submitted by John, who writes in below to share his email to WebMD, and their oh-so-typical we-take-your-privacy-seriously message, which is affirmatively and provably false.

As seen in WebMD's response, they encourage users not to post identifying information, but fail to think about users that – as said previously – might be using WebMD on a public network at a café or airport, or the case where an employer may be monitoring employee internet traffic. Workplace medical discrimination does happen, and WebMD is in the wrong here.

WebMD should switch to using entirely HTTPS across their entire site with long-duration HSTS and session cookies set with the 'Secure' flag to ensure that all data in transit is encrypted, authenticated user sessions only happen over HTTPS, and that users are on the authentic WebMD site.

John's comment to WebMD Customer Care Team:

WebMD asks me (via e.g. the Symptom Checker) to transmit private health information over the internet. I’m comfortable with sharing this information with WebMD, but not with unrelated third parties such as my internet service provider or strangers connected to the same wireless network.

Most sites in this situation offer access via a secure connection (HTTPS) in order to prevent third parties from viewing sensitive information. Wikipedia is a good example of this:

https://www.wikipedia.org/

When I try to access WebMD via a secure connection, however—

https://www.webmd.com/

https://symptoms.webmd.com/

—it returns an “Error 404” or “Access Denied” error message.

How can I access WebMD privately?

Thank you,

John

Response from WebMD:

Hi John,

WebMD takes very seriously the privacy and security of our users. The information submitted by our users is used as outlined and defined in our Privacy Policy (http://www.webmd.com/about-webmd-policies/about-privacy-policy).

Further, WebMD does not rent, lease, sell or otherwise disclose Personally Identifiable Information (PII) about our users to any third party without proper notice, consent and choice.

We encourage our users not to disclose any information in a public forum (message boards, chat rooms etc.) which might allow an unauthorized third party to contact them, including email address.

Thanks for making WebMD your site of choice for all of your health and wellness information needs.

Yours in health,

WebMD Customer Care

ManageFlitter is a company that provides a Twitter account management service. You connect your Twitter account, and you can do analytics, schedule posts, and do some follower cleanup. But, the entire website (except payment transactions) is all loading over insecure HTTP.

When you give ManageFlitter access to your Twitter account, you're giving the same access to anyone who might be listening in on a public wi-fi network or between you and their servers. If ManageFlitter cares about the security of their data and their users' data, they should immediately make the entire site HTTPS to encrypt data in transit.

As an example, when you click ‘unfollow’ on the below page, the action (unfollow) and the Twitter user ID to unfollow is sent back to ManageFlitter. Since anyone has access to your session and data in transit on a public wi-fi network, anyone could perform actions like unfollowing users, tweeting on your behalf, or worse.

ManageFlitter's privacy policy is light on details on the topic of security:

“89n operates secure data networks protected by industry standard firewall and password protection systems. Our security and privacy policies are periodically reviewed and enhanced as necessary and only authorized individuals have access to the information provided by our customers.”

UPDATE: February 12, 2015 –  jsFiddle added HTTPS (an EV SHA-2 certificate too!) and it's enforced to ensure that data isn't transmitted insecurely over HTTP. Thanks jsFiddle!

––––––––

Dear Piotr and Oskar,

I absolutely love jsFiddle, can't imagine life as a developer without it, and owe enormous gratitude to you. I think the entire developer community owes you a huge thanks for advancing knowledge, encouraging experimentation, and enabling information sharing.

But I'm concerned that user registration data and logins are sent completely in the clear over HTTP. On an insecure network, an attacker could intercept personal information and passwords. And for sites that are all-HTTPS, they can't embed fiddles. Trying a manual connection over HTTPS to jsfiddle.net throws a connection error.

I get that you work very hard, you didn't expect it to get this big, it's probably screwing you over because you haven't made much (or any?) money from it, and users aren't always as appreciative as they should be.

Demand for SSL is just that — demanding — because threats are changing, wi-fi sniffing is much more prevalent, and then there's that whole NSA thing. The users above didn't seem to get a response.

This request could have been worded nicer, but I'm a bit shocked by the response:

Security is everyone's responsibility, and secure web practices are critical for an open and safe internet. I'd really like to encourage you to reconsider — it's a matter of protecting your users' personal information.

That last Twitter user offered to pay for the certificate. Of course, I realize it's not that simple when you're running at JSFiddle scale, but if it's a matter of money and time, I'm sure contributions can be organized.

I hope SSL can wind up on JSFiddle's roadmap for the near future. If not, could you please encourage users to use single-use passwords and a password manager? If there's anything the developer and information security community can do, your work makes our lives better and I'm sure many of us would love to help.

(Submitted by anonymous)

MyFitnessPal is a service that tracks your food intake, daily activity and exercise, and body measurements such as weight. Of course, one would expect MyFitnessPal to force HTTPS on every single page to protect this private health information, but they don't — none of that data is transmitted securely.

When signing up or logging into MyFitnessPal, the forms POSTs to a secure HTTPS endpoint, but the forms load over insecure HTTP. This is a terrible security practice, as malicious code could be injected into an HTTP page, which transmits the information elsewhere.

When logged into MyFitnessPal, all of the pages transmit over insecure HTTP. Everything you eat, your body measurements, your daily activity, and any activity imported from third party services are all transmitted insecurely over HTTP. If you're on a public wi-fi network, anyone can easily intercept this private health information.

Even worse, if you manually change the logged-in URL from insecure HTTP to secure HTTPS, MyFitnessPal forces you back onto insecure HTTP.

MyFitnessPal has been asked repeatedly use SSL on their login page, and even to add SSL on the entire site. MyFitnessPal's founder Mike Lee said over two years ago that the company was “planning on moving the entire site to SSL.” As of December 1, 2014, that still hasn't happened.

MyFitnessPal's privacy policy states that it has “...implemented and maintains reasonable security procedures and practices designed to protect against the unauthorized access, use, modification, destruction or disclosure of Your Personal Information...” and goes onto state that in the event that such information is “...compromised as a result of a breach of security, MyFitnessPal will promptly notify You...”

This is an outright lie. HTTPS is the most basic, primary, and significant way to protect user data in transit using encryption, and at least help ensure a user is communicating with the authentic website (for example, HTTPS with HSTS would help prevent a DNS poisoning attack where a user is served a fake website). When MyFitnessPal forces a user to go back onto insecure HTTP, it is demonstrating that it has no desire to comply with its own privacy policy. It should consider every user's data to be ‘compromised’ and take immediate steps to add HTTPS with HSTS.