Re: Draft finding - "Transitioning the Web to HTTPS"

Eric J. Bowman:
> Tim Bray wrote:
>>
>> But I really can’t take seriously the objection that cost is a serious
>> obstacle to widespread TLS deployment.
>>
> 
> I take it seriously. While your draft makes a good point or two on this
> issue, I'd like to offer a couple of counterpoints.
> 
> Broken-ness
> 
> I've certainly noticed an increase in invalid-cert warnings when using
> the Web. I'm not talking about the one-time costs associated with
> implementing SNI in a load-balanced, virtual-hosting environment, I'm
> talking about the knock-on costs to the small-business content-creator
> when third- and even fourth- party PKI implementations are bungled.
> 
> Even an expired cert on the part of, say, an ad provider or even an
> advertiser using that provider, causes a pop-up warning for users. At
> best, the site hosting those ads loses potential click-through revenue.
> At worst, naive users assume the problem lies with the site they're
> using, and stop using it. Resulting in direct loss of revenue, or
> indirect losses stemming from decreased activity on the site.
> 
> Browsing through a descriptive link using software that doesn't display
> the URL can make it non-obvious to experienced users, that the cert in
> question isn't the same domain as the site being accessed. And we all
> know that people will just move on, rather than taking a moment to
> figure that out.

The ACME specification part of Let's Encrypt (https://letsencrypt.org)
addresses this by making it much easier to renew certs:
https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.txt.
I think you can just do it via a cron job.

(Let's Encrypt is launching a new cert authority in 2015 that will
support the ACME protocol for automated cert issuance and management.)

> 
> Hosting costs
> 
> It's possible to achieve both low latency and five-nines reliability on
> a budget using HTTP, due to the lower implementation cost of redundant
> systems based on "obsolete" CPUs. Moving to HTTPS on such hardware comes
> with latency increases which may negatively impact profitability due to
> user impatience. Avoiding this latency penalty requires encryption co-
> processing, i.e. the latest-and-greatest CPUs, increasing hosting costs
> at the expense of profitability.

It's hard to evaluate these claims without numbers. What are the CPU
specs? What's the order of magnitude of latency increase? What are your
hosting costs compared to, say, AWS?

> 
> Plus the aforementioned (by me) loss of access to shared intermediary
> caching. Going to the next "tier" of bandwidth usage isn't a negligible
> cost. Alternatives either come with unacceptable tradeoffs in terms of
> control of content, or the most odious TOS I've yet seen for any Web
> service (looking at you, CloudFlare), or moving to lesser hosting and
> increasing latency/downtime. Fast, reliable, *and* inexpensive hosting
> has long been my key to profitable websites, but it's a tightrope walk.
> 
> While the overall costs of HTTPS Everywhere to the world-at-large may
> be negligible, I'm very much struggling with the cost justification for
> small businesses which care about high reliability and low latency.

Just a note: HTTPS Everywhere (https://eff.org/https-everywhere) is a
browser extension maintained by EFF and has nothing to do with the TAG
findings.

> 
> -Eric
>

Received on Wednesday, 10 December 2014 15:55:10 UTC