* 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.
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.
[Disclosure: one of the authors of TACK is a former co-worker.]
//www.example.com/path/to/asset.js
this will then use the same transport as the containing page uses.
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.
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.
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
I know what I'm doing. I'll reset the option when the underlying issue is resolved, and overall it's a great feature for the browser, but I need to have the ability to be responsible for myself.
Then, the proxy makes its certificate available to users, you download it, and add it to your CA certs via the UI that browsers provide for that; HTTPS magically appears to work again.
HTTPS shouldn't magically appear to 'work' again, considering it is completely broken when a forced mitm is introduced.
In which case I end up shit creek without a paddle because there's no way to temporarily disable the security feature.
And I do not have control over the Proxy server because I'm not in the fucking security team.
You can disable all certificate checking with --ignore-certificate-errors but it is as bad as it sounds.
Rather, to correctly support MITM proxies you should install their CA certificate locally.
This is the problem.
> ... and it makes Chrome practically unusable when they happen
This is not the problem.
chrome://net-internals/#hsts
Are you looking for something else?
* Chrome wants to FORCE you to buy an SSL certificate.
* The guy suggest getting one from StartSSL BUT those are crap for 2 reasons: you can only have ONE domain, else you have to pay. The TOS are horrible.
So, dear imperialviolet, if you want me to use certificates that your company trusts (and by extension, your users), get up with it and make Google provide free, unlimited SSL certificates.
Til then, no dice.
It's one name per certificate (well, two: yourdomain.com and whatever.yourdomain.com) but you can order multiple certificates for multiple subdomains in the same or different domains at no charge.
And it's only one domain per cert, so your entire argument is silly.
If you have a really small website, NearlyFreeSpeech is actually nearly free.
Actually that's not the case, you can get single certificates which cover different domains, using the Subject Alternative Name field.
Edit: a downside of using separate certs is that you'll need to serve the respective sites from separate IP addresses, or rely on SNI [1] which isn't supported in older browsers. But if the use case is a separate domain for serving static files, that's probably hosted on a different server/IP address anyways, right?
'//www.your-cdn.com/image.jpg'
In other words don't specify http or https in the url, just do '//your-url.com/new.js'
In other words, a MITM could downgrade any HTTPS traffic and simply remove that STS header. The browser would be none the wiser.
You are, obviously, vulnerable on first contact to a site, in that an attacker can prevent you from ever seeing the STS header. The point of STS is that attackers don't generally get to intercept your first contact with a site.
Adam Langley, by the way, is one of Google's Chrome SSL/TLS/HTTPS people.
If clearing the browser cache/cookies does not make the browser forget about STS for each domain, then we got another way to maintain http://samy.pl/evercookie/
As an example, a rogue Apple Store employee could insert him self as a MITM between the access point and the internet connection. Anyone testing out a new laptop in the store (or logging in to their bank from a just-activated iphone) would be vulnerable, without the attacker ever having touched any of those devices.
Let's assume you have it set to 1 year. If user A visits the site in March, receives the header, uses the site for a while.
In May, the site/user's DNS/whatever is hijacked. Users are sent to a dummy site, which does not set the header. The dummy site is over HTTP.
The next day, the user tries to go to the site. Because it is not over HTTPS, the browser refuses to load the page, even though the header is no longer sent.
strict-transport-security:max-age=2592000; includeSubDomains
If I visit again tomorrow, the browser-cached version of that header will be updated with a new expiration date, and expire a month from tomorrow, not now.
1: http://www.wolframalpha.com/input/?i=2592000%20seconds
edit: I think we're agreeing.
Obviously, you need to be a bit more diligent about making asset urls protocol-relative (which can be a PITA across a large, dynamically generated site), but are there any other gotchas? Server load? Reduced cache-ability?
If you don't do SSL properly (e.g. non-SSL-terminating load-balancer can break SSL session resuming by forwarding requests to different servers which don't share tickets) then you'll have lower front-end performance.
webpagetest.org nicely shows connections including time spent on SSL negotiation, so you can use it to check your SSL overhead.
SNI would help a lot, but unfortunately it will never be a feature in the SSL client code in Windows XP (which MSIE uses) and so we're stuck with this for the foreseeable future.
(http://paulirish.com/2010/the-protocol-relative-url/)
Because they wound't be so PITAish would they?
Digressing a bit further, wouldn't you say that even if HSTS is enabled and registered in the all the browsers' built-in list, you still have the problem of unencrypted DNS lookups? (Maybe this kind of attack is orders of magnitude harder to implement. I honestly don't know.)
[1] http://www.imperialviolet.org/2011/06/16/dnssecchrome.html
Also, by using DuckDuckGo [1] over HTTPS you get the same ruleset in HTTPS Everywhere [2] even if you don't have the extension installed.
[2] http://www.gabrielweinberg.com/blog/2010/09/duckduckgo-imple...
Pages include resources from https-everywhere'd domains and for whatever reason (mostly that the ssl versions of those resource urls aren't serving the same resources, or have broken certs) those resources fail to load. Within an hour of using it I'd seen it break 3 or 4 sites, so it got disabled.
You can manually disable it for individual sites, if you recognize that it's the problem, but if some minor resource fails to load it might not be obvious.
(and a great advertisement for using Chrome in secure settings where you need a web browser)
The irony of Google being one of the main http-only JS resources for a long time was kind of amusing, though.
If your app uses session ID cookies, then another implication of this is that attackers can set a user's session ID to a value they know, wait for the user to log in, and then use the session ID to hijack the logged-in session. To prevent this make sure you regenerate session IDs when logging a user in. (This isn't the only reason to regenerate session IDs on log in but it's a very compelling one.)
Session fixation used to be a common problem. There were lots of J2EE applications which were not only fix-able, but which would allow an attacker to fix a session ID with a carefully crafted GET URL. It's much rarer now.
I currently use a self signed cert and certificate patrol, but apps (in particular Thunderbird) are becoming increasingly hostile to that.
Yes, they are. StartSSL will even send you a reminder e-mail.
Does it work properly?
If i have www.mydomain.com with certificate A, and api.mydomain.com with a certificate B, can i make CORS call with javascript?
(i know that if you try it with self signed cert, it will just drop the request)
With signed certificates, Libya can MITM (unpinned) certificate-backed TLS sessions.
With signed certificates, random people cannot MITM (any) certificate-backed TLS sessions.
With self-signed certificates, Libya can MITM any TLS session.
With self-signed certificates, random people can MITM any TLS session.
I'm not seeing the argument you're making here.
no one even pays attention to the client side of ssl. how many of you use your own ssl certificates? you basically can't under the cert authorty scheme. it's a racket and no one is going to pay for these. and do the banks even care? they use tactics like cookies and follow-up emails to verify customers (hardware).
and why does the bank have to be able to switch their ip address without telling anyone? what if the same was true for phone numbers? people would be like wtf? load balancing? c'mon. too difficult ot type? thnk about the trade-offs in security, all for the sake of not looking at a number? ipv4 is no longer than an area code and phone number. just tell people where your servers are and let them choose the one that is nearest. which incidentally, contrary to conventional wisdom, is not _always_ the one that will be the most responsive in the ever-changing state of the network.
there's nothing more annoying than being subjected to using trial and error and you are not allowed to do any of the trial when the errors start coming. out of your control.
what happened to the concept of "important numbers"? are we to believe you only need to remember "google.com" or "yourbank.com"? that's a security problem waiting to happen.
second honest question: why does bank website need to embed links to third party reources and require that customers enable their browsers to access all these indiscriminantly (user doesn't get to choose) and to enable javascript?
is javascript needed for security of a connect or to accomplish a financial transaction? because that's all i need from the bank website.
i think we're past the point where customers need to be enticed to use the web to do things like banking and shopping. they're going to be forced to. so we can forgo the silly demonstrations and gratuitous use of javascript. save for "show HN".
what we need is simplicity, reliability and security.
It's not clear to me from what docs that I have been able to find.