Living with HTTPS

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:<p>* Enable HSTS<p>* Don't link to HTTP:// javascript resources from HTTPS pages<p>* Set the secure flag on cookies<p>Very few of the sites we test enable HSTS. But it's easy to do; it's just an extra header you set.<p>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.

&#62; There's a second collarary to this: attackers can set your HTTPS cookies too.<p>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.)

The author seems to gloss over the importance of browser built-in HSTS lists. If you're just relying on a response header to tell the browser to use HTTPS, aren't you still vulnerable? Isn't that the same fundamental problem with redirecting to HTTPS via Location headers?<p>In other words, a MITM could downgrade any HTTPS traffic and simply remove that STS header. The browser would be none the wiser.

Please for the love of god, if you're working at google and read this: Add a deeply set option to <i>FORCIBLY</i> enable that button in all situations where it might appear. We sometimes have certificate issues with our proxy server at my workplace and it makes Chrome practically unusable when they happen.<p>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.

Moxie published a tool called SSLstrip <a href="http://www.thoughtcrime.org/software/sslstrip/" rel="nofollow">http://www.thoughtcrime.org/software/sslstrip/</a> here's a simple video demonstration <a href="https://www.youtube.com/watch?v=PmtkJKHFX5Q" rel="nofollow">https://www.youtube.com/watch?v=PmtkJKHFX5Q</a>

For users, HTTPS Everywhere is a must: <a href="https://www.eff.org/https-everywhere" rel="nofollow">https://www.eff.org/https-everywhere</a><p>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.<p>[1] <a href="https://duckduckgo.com/" rel="nofollow">https://duckduckgo.com/</a><p>[2] <a href="http://www.gabrielweinberg.com/blog/2010/09/duckduckgo-implements-https-everywhere.html" rel="nofollow">http://www.gabrielweinberg.com/blog/2010/09/duckduckgo-imple...</a>

Honest question, for those who have done it: what are the <i>downsides</i> of allowing your whole site to be accessed via SSL?<p>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?

It mentions the free StartSSL certificates, as does their page. But what isn't clear is if the certificates are free to renew after a year (ie this is just a teaser).<p>I currently use a self signed cert and certificate patrol, but apps (in particular Thunderbird) are becoming increasingly hostile to that.

HTTPSEverywhere is a firefox/chrome browser plugin, that will ensure connections that can be HTTPS are. It also does a good job preventing ssl stripping.<p><a href="https://www.eff.org/https-everywhere/" rel="nofollow">https://www.eff.org/https-everywhere/</a>

This was by a wide margin my favorite talk at HOPE this year.<p>(and a great advertisement for using Chrome in secure settings where you need a web browser)<p>The irony of Google being one of the main http-only JS resources for a long time was kind of amusing, though.

I'm wondering if there could be an equivalent DNS entry that might help signal a site should only be accessed via SSL? Then you could possibly protect against initial access as well as returning users.

What I take out of this, beside things I knew of already (and most others as well) is:<p>* Chrome wants to FORCE you to buy an SSL certificate.<p>* 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.<p>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.<p>Til then, no dice.

SSL/TLS &#38; Perfect Forward Secrecy - <a href="http://hackerne.ws/item?id=4267767" rel="nofollow">http://hackerne.ws/item?id=4267767</a>

Obligatory Django link: <a href="https://github.com/carljm/django-secure" rel="nofollow">https://github.com/carljm/django-secure</a>.

Somewhat related question: It's fairly common for sites to have static files (images/css) served on a different (sub)domain. What are you supposed to do when the html content is being served on HTTPS? Should the static files be on HTTPS as well? If so, wouldn't it need a different certificate? Certificates are only valid for a single domain, after all.

honest question: why can't banks when customers open a new account, give them a card with 1. the bank's ip addresses (in each region) and 2. their printed public key (ssl or ssh format). and why doesn't the bank ask for a public key from each customer? in-person key exchange.<p>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).<p>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.<p>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.<p>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.<p>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?<p>is javascript needed for security of a connect or to accomplish a financial transaction? because that's all i need from the bank website.<p>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".<p>what we need is simplicity, reliability and security.

Does anyone have any recommendations for search terms I could use to put together a list of news stories / posts about known man-in-the-middle attacks that have occurred?

If includeSubDomains is set for HSTS, does that mean that a cert for <a href="https://foo.com/" rel="nofollow">https://foo.com/</a> is required instead of <a href="https://www.foo.com/" rel="nofollow">https://www.foo.com/</a> in order to protect cookies set for foo.com and under?<p>It's not clear to me from what docs that I have been able to find.

Google Cache mirror if anyone needs it: <a href="http://webcache.googleusercontent.com/search?q=cache:http%3A//www.imperialviolet.org/2012/07/19/hope9talk.html" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:http%3A...</a>

Any experience with CORS and https?<p>Does it work properly?<p>If i have www.mydomain.com with certificate A, and api.mydomain.com with a certificate B, can i make CORS call with javascript?<p>(i know that if you try it with self signed cert, it will just drop the request)

I have a rails 3.2 site, and I hadn't thought about this much aside from setting force_ssl to true. Turns out that automatically enables HSTS and secure cookies - cool!

For what is worth Libya owned a trusted CA (maybe still does), which means that MITM would happily work, because they can transfer all the certs to their own authority. I don't personally see how this is more secure than my self-signed certificate, which generates a warning that's these days very hard to avoid (even if I <i>do</i> know that the cert is fine)

I learned a lot about internet security here. Thanks a lot!