Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to implement HTTPS in an insufficient manner

troyhunt.com

Post reply on HN
Print view View original

31–40 of 68 posts

Re: How to implement HTTPS in an insufficient manner

#31

Post by lucb1e »

troyhunt wrote: post #26
lucb1e wrote: post #10

Https article served over http. Lovely. Edit: Besides that problem #1 is offtopic since it has nothing to do with https and that 3/4 other points are captain obvious, #4 is actually a good one. It's so obscure that many will forget to enable it ("all pages are secured anyway"), but whenever a user visits any http page, an attacker can inject a small frame loading the http version of my website, and even if I redirect…

If there was something worth protecting on a personal blog site, it might be a different story. 1 is very on-topic - there's no way that data should be sent in the clear. HSTS is good, but unfortunately only partially supported. Agree on the secure cookie, but of course you need to drop the dependency on accessing it over HTTP before you do that.

> If there was something worth protecting on a personal blog site, it might be a different story.

It's not about security here, it's about privacy.

https://willnorris.com/2012/12/all-https-all-the-time

> This blog isn’t terribly controversial. But if only the "controversial" stuff is private, then privacy is itself suspicious. Thus, privacy should be on by default.

Re: How to implement HTTPS in an insufficient manner

#32

Post by lucb1e »

kijin wrote: post #27
lucb1e wrote: post #19

Earlier quoted context omitted.

> all of them have to do with the fact that the website in question is not 100% HTTPS Problem number 4 is actually also relevant for HTTPS-only websites. That is, if the website doesn't use HSTS, and most don't. Also a 301 only works for one page . Consider this: You go to example.com (typed in address bar), it redirects you to https://example.com via a 301, then you load your favorite news website, I inject an ifram…

> Problem number 4 is actually also relevant for HTTPS-only websites. You're right, but I was thinking along the lines of: The reason why they don't set secure cookies is probably because they want to share state between their HTTP site and their HTTPS site. > Also a 301 only works for one page. You can make it work on every page. Even the query string will remain intact. POST requests are more complicated, but they…

Of course you can activate the 301 on all pages, I actually assumed that, but it was about the cookie that can be stolen via problem #4.

Re: How to implement HTTPS in an insufficient manner

#33

Post by WatchDog »

csmattryder wrote: post #2

This is the same guy who exposed similar flaws with Tesco's (UK supermarket chain) systems [1]. Why on Earth these companies are given free advice, but think they (or their PR folks) know better is beyond me. Take the advice! You've now got a security flaw, documented, waiting for Joe Hacker to take your customer's data and shoot a hole through your business, and its reputation. [1] http://www.troyhunt.com/2012/07/le…

These companies likely have staff that already are acutely aware of the problems. It is sometimes very difficult to change anything from the inside, sometimes you need some negative PR to actually get the ball rolling.

Re: How to implement HTTPS in an insufficient manner

#34

Post by acdha »

markhemmings wrote: post #8

I'm the guy who originally contacted Troy Hunt about this, as he mentions in the blog post. What annoys me is I'm a very young developer, and I've only really just become interested in security (12 months ago I didn't even know what hashing was!!!), yet there's developers out there with years and years of experience making huge sites for the likes of Tesco and TopCashBack for vast sums of money and they don't think a…

Businesses care about loss, not security as an intrinsic merit. They will invest it only to the extent to which problems are actively costing them sales, raising expenses like insurance or are required to comply with some sort of regulation (government, credit card processor, etc.).

Something positive like a site redesign perceived as increasing customer appeal or negative like an expensive legacy server upgrade often trumps security unless it clearly poses a future risk – this is also why many large companies tend to follow the trailing edge as the main concern is usually avoiding a lawsuit alleging that they were significantly worse than everyone else in their industry.

Re: How to implement HTTPS in an insufficient manner

#35

Post by brey »

kijin wrote: post #15

The author lists 5 problems, but all of them have to do with the fact that the website in question is not 100% HTTPS. So it's really just one problem that has many different implications. When you maintain both an HTTP site and an HTTPS site, it's nearly impossible to toss state back and forth between them without exposing yourself to at least one of these problems. Even if you do everything perfectly, people will co…

> Need more server resources? Maybe.

AWS does this for (almost) free - load balancing includes optional SSL termination. really simple to set up, all HTTPS traffic just forwards to port 80 on your instance.

Re: How to implement HTTPS in an insufficient manner

#36

Post by lmm »

JennyZ wrote: post #5
dragcdxfbv wrote: post #3

Do i have to pay or create accounts on third party services to use HTTPS (in nginx)? I never used https on my sites because there are some giant warnings ("dangerous") in browser when you go to a website that is self-signed. No warnings on plain http.

You can get a free SSL certificate at https://www.startssl.com/ , so that should not be a reason to keep you from using it. I do agree that the extreme mistrust of browsers towards self-signed certificates is an odd thing.

It's free but they charge you to revoke a certificate, which is quite unfortunate as it discourages people from revoking if they e.g. leak their private key.

Re: How to implement HTTPS in an insufficient manner

#37

Post by Tomdarkness »

lucb1e wrote: post #31
troyhunt wrote: post #26

Earlier quoted context omitted.

If there was something worth protecting on a personal blog site, it might be a different story. 1 is very on-topic - there's no way that data should be sent in the clear. HSTS is good, but unfortunately only partially supported. Agree on the secure cookie, but of course you need to drop the dependency on accessing it over HTTP before you do that.

> If there was something worth protecting on a personal blog site, it might be a different story. It's not about security here, it's about privacy. https://willnorris.com/2012/12/all-https-all-the-time > This blog isn’t terribly controversial. But if only the "controversial" stuff is private, then privacy is itself suspicious. Thus, privacy should be on by default.

HTTPS is not really that effective for privacy. An attacker can still see what site you visited (Well, the IP, but it would be fairly trivial to get the domain as well) and with a little bit of analysis could most likely make a fairly accurate educated guess about exactly which page you requested.

Re: How to implement HTTPS in an insufficient manner

#38

Post by ZoFreX »

troyhunt wrote: post #24
markhemmings wrote: post #8

I'm the guy who originally contacted Troy Hunt about this, as he mentions in the blog post. What annoys me is I'm a very young developer, and I've only really just become interested in security (12 months ago I didn't even know what hashing was!!!), yet there's developers out there with years and years of experience making huge sites for the likes of Tesco and TopCashBack for vast sums of money and they don't think a…

Years and years of experience? Often not, and that's speaking from years and years of experience! Vast sums of money? Yes, at least the outsourcing vendors who churn this sort of thing out. Unfortunately you're the exception Mark so good on you for that. Well I mean unfortunate for the greater web using population, but very fortunate for you!

To expand further on those points with a personal anecdote... I worked on a "big website" for a very big government department. I was still in university at the time, had about a year's experience with the platform, and was earning close to callcenter wages.

The government only contracts to companies on a particular whitelist, which we weren't. They paid a company something in the region of £300,000 for the website.

That company then outsourced 100% of the work to the tiny (single digits employee count) company I was at.

They paid us £40,000.

My share of that works out at about £2,000.

The fact something cost half a million dollars in no way implies any kind of quality, or that the people working on the software will know what they're doing. (Really: another horror story involved a website that only needed to work in IE6... and had been built and tested purely in Firefox)

Re: How to implement HTTPS in an insufficient manner

#39

Post by nwh »

lucb1e wrote: post #10

Https article served over http. Lovely. Edit: Besides that problem #1 is offtopic since it has nothing to do with https and that 3/4 other points are captain obvious, #4 is actually a good one. It's so obscure that many will forget to enable it ("all pages are secured anyway"), but whenever a user visits any http page, an attacker can inject a small frame loading the http version of my website, and even if I redirect…

If every blog on the internet had a static IP to serve HTTPS over, we'd have even less IP addresses available than we do now.

Re: How to implement HTTPS in an insufficient manner

#40

Post by nodata »

kijin wrote: post #15

The author lists 5 problems, but all of them have to do with the fact that the website in question is not 100% HTTPS. So it's really just one problem that has many different implications. When you maintain both an HTTP site and an HTTPS site, it's nearly impossible to toss state back and forth between them without exposing yourself to at least one of these problems. Even if you do everything perfectly, people will co…

No, please don't do this:

If a visitor goes to http://domain/some/url they should not redirect to https://domain/some/url - it makes it harder to catch pages that use the wrong protocol.

Better to redirect http://domain/some/url to https://domain

Edit: if you're logging referrers from your own domain with non https:// urls AND using secure cookies, ignore my comment!

Post reply on HN