Hacker News Reader

Comment by tptacek | Hacker News Reader

This is pretty great. I guess he gave this talk at HOPE, but it's laser scoped to startups, down to the order in which he gives the advice:

* Enable HSTS

* Don't link to HTTP:// javascript resources from HTTPS pages

* Set the secure flag on cookies

Very few of the sites we test enable HSTS. But it's easy to do; it's just an extra header you set.

The only quibble I might have is the fatalism he has about mixed-security Javascript links. I'd go further than he does: when you source Javascript from a third party, you have leased your users security out to that third party. Don't like the way that sounds? Doesn't matter: it's a fact. Companies should radically scale back the number of third parties that they allow to "bug" their pages.

View on HN

All of these are good recommendations.

Another technology to start preparing for is TACK. It allows you, the server owner, to control browser pinning of your certs while maintaining CA mobility. This gives you the control over your security that Google has over Gmail via Chrome cert pinning without having to issue a new browser build every time you change CAs.

One way to think of it is like a domain transfer lock but with cryptography. You control how you unlock your pin to allow mobility to a new CA by sticking a signed file on your SSL server.

http://tack.io/

[Disclosure: one of the authors of TACK is a former co-worker.]

I see Moxie is one of the authors on the draft. Is this an outgrowth/pivot of Convergence?

Moxie Marlinspike works for Twitter now that they've acquired Whisper. TACK addresses the same problem as Convergence, but is a much more tactical and incremental feature.

The way I see the relationship between Convergence and TACK is that Convergence is trying to provide trust agility for when we need to trust third parties, while TACK is trying to reduce the amount that we even need to trust a third party at all.

I think the first problem gets considerably easier to solve once the latter is in place, and there's a lot we could do with Convergence-like systems that would make them more deployable if TACK is adopted.

In the short term, however, TACK stands on its own, and we hope it's a fairly uncontroversial proposal that will be easy to integrate into the ecosystem.

A solution going forward to contain 3rd party javascript is HTML5 sandbox iframe. This allows declaring a whitelist of permissions 3rd party code should be granted. Only about 40% of browsers support this feature [1]. For unsupported browsers, the external javascript continues working without the security guarantees, so it's no worse than the situation now.

[1] http://caniuse.com/#feat=iframe-sandbox

You can get most of the benefit now by registering a separate domain for the frames and taking advantage of the same-origin policy.

It's actually kind of a pain to enable HSTS because it makes you fix all the places where you're downgrading to HTTP. You should definitely do it if you care whether your users' sessions get hijacked, but it's not _just_ flipping a switch.

Pages with http://yoursite links work seamlessly. The browser will access those via https when you click. As long as the SSL version of your site is serving the same resources, there's no problem.

if you need an absolute URI for any assets, then just use:

//www.example.com/path/to/asset.js

this will then use the same transport as the containing page uses.

That's a great suggestion that's often overlooked.

At Quantcast we tried to use "//" without the protocol in our tags (to eliminate the need for a separate http: and https: tag), but we had a huge number of complaints about a bug in our tag (missing http:!). Users also tried to be helpful and add in the "http:" and then complained when it broke. In the end we went with two separate tags to reduce the support burden, despite the added complexity of having to explain the two tags.

"Very few of the sites we test enable HSTS. But it's easy to do; it's just an extra header you set."

Less than a year ago, you were saying HSTS wasn't worth the trouble. Ref: https://news.ycombinator.com/item?id=2909613

Glad you've changed your mind.

Using SSL properly is not particularly difficult in theory, but there are many moving pieces so that the whole thing ends up being hard. For example, it's often easy to forget a crucial step. To address this, I wrote SSL/TLS Deployment Best Practices, which contains 22 recommendations in 5 categories:

https://www.ssllabs.com/projects/best-practices/

I encourage everyone to read through it, and follow it. Once you know what to do, it's easy. Part 2, dealing with advanced topics, is coming in October.

  config.force_ssl = true

Feels good, man. If only it were that easy to enable HSTS in all web frameworks.

Reply on news.ycombinator.com