konklone
commented
10 years ago I'll emphasize what I said in https://github.com/18F/api.data.gov/issues/34 - the benefits of SSL, for all APIs, are:
- Broader client-side compatibility. Any APIs under api.data.gov wishing to support CORS or JSONP for in-browser operation will be completely blocked on HTTPS websites, as active mixed content.
- Enhanced privacy for apps and users using APIs at api.data.gov -- HTTP headers and query string parameters (among other things) will be encrypted. For APIs accepting particularly sensitive data (like lat/long or zip), this is critical.
- The primary benefit of HTTPS: a stronger guarantee that you're speaking with the real api.data.gov.
The SSL performance penalty is vastly, vastly less than it was even 5 years ago, in part thanks to Google's investment, and in part due to browser-side investment, and protocol innovation. This is one of the main benefits of making SSL ubiquitous -- it creates a critical mass of investment that incentivizes improvements that weren't being demanded before.
Everything about hosting an API has a financial obligation - the cost of a cert is the least among them.
However, you're right about SNI, in that its adoption is frustratingly close to universal, but with some significant hangups. Our section about it lays that out, but I'm very committed to pushing the ball forward on that (and that's an active project of mine and others' here). Without SNI, the cost of SSL can be much higher if you're using a CDN in front of it that demands hundreds of static IPv4 addresses around the globe. It's probably not appropriate for api.data.gov to demand SNI right now, but it may well be appropriate for other APIs that we run.
Heartbleed burned a lot of people, but isn't an argument against SSL -- it's an argument to invest in SSL more and reduce the chances of it happening again, which is exactly what's happening.
At any rate, 18F is an all-SSL shop, and we'll have more on our website about that before long.
I don't expect to change @konklone's mind on this, but it remains true that there's a substantial performance penalty, some financial obligations, and various limitations on software flexibility imposed by requiring HTTPS. In many cases it is absolutely essential, of course. But for read-only APIs of public data where use bears no particular stigma, the case for it seems weak beyond promoting the ideology of the SSL-everywhere movement. Maybe I'm just still feeling burned by heartbleed, but I still don't see the payoff for most government APIs.
Offering it optionally is certainly desirable, though!
Advocating for SNI in government systems with its support where it currently seems to be strikes me as quite aggressive, but since this is listed as an optional item I think it amounts to an admirable display of technical leadership.