Klarna users are being signed in to random accounts

Having at least authenticated sections of your site use HTTPS was standard well before 2011.

That only protects the user's password. The auth cookie will be sent in all subsequent requests in plain text.

EDIT: that's how firesheep (https://en.wikipedia.org/wiki/Firesheep) hijacked sessions for e.g.

That's not true. Cookies can have a 'secure' attribute which tells the browser to send them only over TLS

Let's Encrypt started in 2014 to address HTTP overuse.

In 2011, I (in-house corp app dev) was still stuck with HTTP services (behind a firewall, accessible only via VPN).

In 2014, public facing mobile apps using HTTP was prevalent enough to prompt name and shame campaigns. [1] My fuzzy memory suggests some banks were still using HTTP.

[1] https://arstechnica.com/information-technology/2014/08/new-w...

in 2011?

But that just makes your login not work if the rest of your site is HTTP, doesn't it?

I started doing professional web development in 2011. It was very clear at the time that not using HTTPS for any site with a login was an BAD practice that made your users less secure. There were clearly people and institution still using bad practices, but risks were clear to most web developers.

What was shifting at the time was developer views on using HTTPS for non-secure, unauthenticated portions of websites. This is where the "HTTPS Everywhere" plugin and other such movements came in.

Bank of America back in 2005 (timestamp from the annoyed email I sent them) refused to load the front page over https. I think it even redirected https attempts back to http. The form submission was over https.

The solution was to enter garbage for the first login since the "re-enter your password" page was served over https. I think they fixed it before 2011, but don't have an exact record of when.

Yes

You should not show authenticated pages without HTTPS

A secure cookie would be of no use for a site whose only secure page is the login page, which is what the parent post I replied to was talking about.

From what I remember there was a lot of pushback from infrastructure as we thought using https for the whole website would increase CPU load. Never verified if this was true... but I'm sure someone here should know.

Re 2011

Push back on what? There was pushback against HTTPS for non-authenticated pages for various reasons.

That does not mean that HTTPS for authenticated pages was not considered a standard and necessary security measure.

Only for certain domains and in certain regions.

A lot of the web was still on http, including some banks.

Even Facebook was still primarliy http when Firesheep [1] came out in 2010.

[1] https://en.wikipedia.org/wiki/Firesheep

Not sure why you are being downvoted but this is exactly correct. We had, as an industry, been so focused on PCI during this time and TLS was and continues to be the most important aspect of the protective technology. SSL/TLS had already made e-commerce viable in the 90s and its power was well known and being applied for the decade following. Being in 2011 without full ssl for authenticated access was quite bad behavior indeed. Maybe excusable for some low rent bulletin board, but perhaps that is what the commenter was operating. I have no clue.

Let’s encrypt came way way late to the party. We had been banging the drum for 20 years by then.

If the pages are only accessible via a VPN, what does HTTPS really get you?

We detached this subthread from https://news.ycombinator.com/item?id=27303744.

Not needing a VPN. rimshot

In all seriousness, better security. You are leaking whatever payload is sent right after VPN drops. An early version of the application had a defect because it did not check response payloads on an endpoint (the code handled errors, but 200 OK was all it needed on success). This is not what you want when the 200 OK is followed by the HTML of a hotel's wi-fi access page.