Hacker News Reader

Comment by GeneticGenesis | Hacker News Reader

Another big blocker is cost.

For example, one of the biggest CDNs in the world (I'm looking at you, Akamai), charge dramatically more for delivering content over HTTPS. Let's say you're delivering video content at scale, the difference between HTTP and HTTPS delivery can be many millions of dollars a year.

But why not use a different CDN, say Cloudfront which prices the same for HTTP and HTTPS?, well, simple, the same problem. Cloudfront is many times more expensive than other CDNs at scale.

Really, we need to apply pressure to all CDNs to equal out their HTTPS pricing (Its not just Akamai...)

View on HN

This isn't helped by the subset of CDN providers who use the enterprise sales models where they try to bundle services and set pricing based on your perceived ability to pay. It's always possible to negotiate a better deal but everyone has to burn the time needed to do that independently and can't publicly share the results.

BTW, Cloudfront also prices HTTPS a little bit higher than HTTP (on per request pricing, not on bandwidth).

Also Heroku's price for serving https with your own domain is absurdly high.

I basically means there is not free version of Heroku for serious projects, which is ok. But taken in isolation, the price tag looks pretty bad..

Unless you're doing a lot of large files like media or downloads, I always recommend CloudFlare. It's a great service and there are no bandwidth or request costs.

MaxCDN serves us pretty well (a few TB/mo). It has been much much cheaper than Cloudfront ever was (mostly due to not charging by number of requests).

I'd imagine HTTPS is significantly more expensive to host than plain HTTP, due to the CPU requirements of the crypto involved.

Maybe at the CDN level where there's lots of caching it's different, but for regular hosting apps are primarily IO bound so it's essentially "free" to do encryption. From http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...:

> In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.

At the time that was written, only the frontends did TLS---remember, there wasn't universal strong encryption or authentication within Google's back-end until after the Snowden leaks.

Nope. The symmetric crypto is basically free. The asymmetric crypto is cheap.

IPv4 addresses cost. Most big sites can't quite go SNI-only yet. Soon!

Customer support costs. Why would TLS involve more customer support? Because it's a technology designed only to break connections. Ideally that's only the adversarial connections---but much like the TSA, a mis-designed authentication scheme can cause great stress and drama.

I do think the world will be all-TLS before too long; the parts that aren't will probably not be HTTP over TCP (e.g., content addressable networking).

> IPv4 addresses cost. Most big sites can't quite go SNI-only yet. Soon!

Why can't they go SNI? It's not like IE6 or netscape are relevant any more, is there some other issue?

No SNI on Windows XP (IE6, IE7, IE8, Safari), nor Android 2.3 Browser, nor BlackBerry. Windows XP still has 4-5% usage share on the web, which is 1 in 20 people. Lots and lots of low-end and older Android handsets were on 2.3 because 4.0 had new hardware requirements. Combined, it's a relevant number of people for large sites.

> Windows XP still has 4-5% usage share on the web, which is 1 in 20 people.

Chrome and FF together have a market share of about 70%, so roughly speaking, only 30% of those XP users can be expected to still be using IE or safari. The percentage might be a touch higher as users left on XP might be less likely to use a different browser, but it's certainly not like all of today's XP users are on IE + Safari.

And highly dependent on the region and demographics of the visitors, so the numbers can be way higher (or way lower if you are lucky).

> nor BlackBerry

Maybe not for the old blackberries, but SNI works on BB10.

Windows XP. Python through about 2.6. Java until quite recently. Old Perl code that I shudder to think about.

Oh, and some old Android. The Android version that started supporting SNI is apparently also the version that tightened up licensing, so a number of third-world forks still use the old version. And as long as most of the web works without SNI, they don't have a huge incentive to change that.

The work that some browser vendors (Mozilla, Google) are doing to privilege imperfect-TLS over no-TLS is crucial here. Also, yes: new Web work should all be done over HTTPS.

You know how Mozilla recently had to delay the SHA1 deprecation in Firefox because it broke people behind shitty MITM "security" solutions? That crap often doesn't support any "modern" TLS features like SNI either.

See for example here: https://palant.de/2014/05/27/proxies-breaking-up-ssl-connect...

some pretty modern languages / libraries don't have SNI built in. E.g. requests under python 2.7 doesn't do it by default. As for browsers, I think the answer is that most do - it ends up being something like IE on XP and really old Android that gives you trouble.

Chromecast for example does not support SNI, which is crazy.

With AES-NI, a single modern CPU core can encrypt 10 gigabits/second and do about 50,000 public key operations per second. Cryptography is not that expensive.

AES isn't the only algorithm used in TLS handshakes.

That is why I also said 50,000 public key operations per second.

Reply on news.ycombinator.com