Q: When to deploy https?
A: Always.
A: Always.
If IPv6 actually gets deployed to the extent that I can have an IPv6-only site without needing IPv4 addresses, and someone solves the SSL signing mess, I'd be happy to use it.
This is certainly no longer true. $7 for a cert from Namecheap (domain validated).
https://www.namecheap.com/ssl-certificates/geotrust-ssl-cert...
As long as you're not supporting clients running IE on WinXP or other similarly old web browsers, Server Name Indication (where the hostname is included as a part of the handshake) will work and it'll eliminate your need for more than one IP.
The only scenario where I wouldn't do it is a blog. There's probably no sensitive content there and without SSL you can use the free trier at CloudFlare to HN-proof it.
You can also get alt names on your certificates, so if you want to support IE on XP or Android 2.2 then you can put several domains on the same certificate.
I have no interest in StartSSL, just a happy customer :).
It shouldn't be hard and you should have to pay such a premium for something that should just work by default. I helped create a Front-end PaaS a little while back[2] that believed in that philosophy, we worked hard to lower the barrier of entry for most things, including SSL.
The reality is understanding SSL, Encryption and everything involved is still overwhelming for most people. This article helps but we need more services to stop gouging people for doing or trying to do the right thing.
[1] https://www.cloudflare.com/plans [2] https://blog.harp.io/posts/harp-platform-now-public
Personally I'd very much like what products I look at while shopping to be private. Some enterprising little daughter or son may be snooping the wifi during christmas shopping season trying to figure out what is being bought for them you know.
Reasons NOT to use SSL:
* Server is not powerful enough to handle the extra compute load -- SOLUTION: go buy a server made in the past decade.
* Certificate costs too much -- SOLUTION: go get a free one.
* You hope caching will reduce the load on your servers -- SOLUTION: pay for a CDN or use bittorrent for distribution. Mostly, mid-network caching doesn't happen anyway.
That leaves just one reason:
* You want 3rd world spy agencies and hackers to be able to snoop on and hack your customers just like the NSA can.
Let me give you an example from mobile app development. As many of you know, Amazon's CloudFront lets you make an in-app connection to cdn.example.com, which may be a DNS alias for something like drj6nl5tupx60.cloudfront.net. Amazon will generate a cache hit or miss and, if not cached, connect to your example.com servers.
The ideal way to do this is to generate an SSL certificate for the CloudFront distribution, but Amazon charges you $7,200 per year for that privilege: http://aws.amazon.com/cloudfront/pricing/
So if you want to load non-private images, video, etc. content via HTTPS from cdn.example.com via SSL without giving Amazon $7,200 a year, there will be an invalid certificate chain error.
Some app development environments (not pointing any fingers right now in hopes this gets fixed quickly) do not support bypassing SSL certificate checks. So in some cases the answer is not to deploy HTTPS. :(
Wouldn't it be better to be able to specify a set of accepted key fingerprints, instead of bypassing security checks altogether? Outright bypassing security checks will make MITM too easy.
Maybe using SSL as an opportunity for a premium price gouge was smart business practice in the 90s. But these days, it's wrong.
Charge for the actual cost. Even add your customary markup. But not some arbitrary $7200 fee.
It may be legal, but it's unethical. Until they change it, Jeff Bezos and Werner Vogels should be ashamed of doing this.
The problem is that it locks you into Amazon. If another company comes out with a much cheaper offering, or you want to switch to Google Cloud Storage, or (unlikely but I suppose possible) Amazon boots you for one reason or another, you're out of luck until you can get your installed base of app users to upgrade.
Option 1: negotiate with the filter maintainers to get your site whitelisted; that may require changing your content, but a site in which you have a commercial interest probably shouldn't have content on it that trips most filters (with some obvious exceptions on which the filter would be doing its job).
Option 2: inform your users that they need to opt out of the filter in question, assuming they're in a situation/regime that allows doing so. Make it clear to them exactly which content is tripping the filter, and hope their reaction is "that's absurd".
Option 3: maintain an insecure HTTP site for use from such locations, and arrange to redirect there or inform your users that they'll need to use that version due to the filter they're using.
Or really any site that doesn't involve logins, passwords, accounts, or sensitive data of any kind?
Visits to your site could be logged by IT departments, getting your users in trouble.
Also I've actually heard of places where port 80 is actually blocked by default (but 443 isn't) and you need permission on a site by site basis to get it unblocked.
That's impressive.
(more of my own writing on the topic: https://willnorris.com/tag/https)
[1] http://www.pcworld.com/article/262307/crime_attack_abuses_ss...
Sorry I didn't categorically spell this out for you earlier, I forgot some people need spoon-feeding the facts about the technology they advocate - even after you've already cited a massively dumbed down article on the subject already.
(and nasty tone of my post is a result of me getting fed up with the way how you, and everyone else it seems, feels is appropriate to talk to each other on HN. This place never used to be quite so rude)
This is untrue so please don't perpetuate this myth. If you send the `Cache-Control: public` header, the resource will be cached to disk just as it would without HTTPS.
That sentence is somewhat unnecessary as I wouldn't have posted that unless I believed it to be true. The rest of your post is valid enough (in fact extremely helpful) not to need to such a prefix.
Anyhow, I'm not out to start an argument and I genuinely am grateful you have corrected me because obviously I wasn't aware of the "public" option in the cache-control header and this is something I can actually put to use right away.
So thank you for the correction :)
You're right; sorry about that. I do get annoyed when I see bogus reasons for not deploying HTTPS. It's made all the worse by people who actually know better but spread FUD because they stand to make a profit from selling expensive HTTPS accelerator appliances. But that's clearly not the case here and doesn't excuse my comment, which, upon reflection, was too harsh.