When Google went over to SSL for Gmail, they said "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. " http://techie-buzz.com/tech-news/google-switch-ssl-cost.html

That, coupled with the general availability of cheap and free CA signed certificates makes the claim pretty baseless.

It does completely disable ability for your ISP to have transparent proxies caching content a before it's sent to you, but the security and privacy gain is worth the trade off.

I (possibly mis-) understood the original comment to be claiming that you could cache the ciphertext, to which I just wanted to make sure I wasn't missing some huge piece of understanding.

SSL -> varnish -> backend varnish -> backend

There's work underway at the IETF to define a standard for signing pages and included resources, so that caches can do their business while still providing the same authenticity features as an HSTS-compliant site. I can't seem to find a reference to an RFC right now, though, unfortunately.

I paid $10 for an SSL cert. Isn't that low enough?

IPv6 should address the other problem - namely, that SSL certs are per-ip, not per-hostname, which makes hosting multiple sites a pain with IPv4. Or SNI could work, once Windows XP is truly abandoned.

  HTTP/1.1 GET /
  Host: mysite.com

Workarounds are to have multiple IP addresses on your box with one cert per IP, or run the server on multiple ports with one cert per port. In both cases this enables the server to know which certificate to use from the underlying connection properties, and not wait for the encoded traffic to start arriving.

SNI (Server Name Identification) is an extension to TLS (Transport Layer Security) that essentially adds the hostname into the SSL negotiation, so this cert can be selected by the server in advance. It made it into OpenSSL implementations in the mid-2000s and is reasonably widely adopted.

Legacy libraries, Internet Explorer <=7, and Windows <=XP won't support it so it's not quite ready for mainstream use. Give it 5 years or so...

I'm not an expert on DNSSEC, but the idea is that there is a chain of trust going back to the domain registrar. If a receive a signed DNS response, and everything verifies, then I know that it comes from the person who registered the domain. I can't add a signed entry for example.com, so if I received a signed DNS response for example.com, I know it ultimately originated (with possible caching like normal DNS) from whomever registered example.com.

You can then add what is essentially a TXT record to the DNS entries for a domain that is the fingerprint of an SSL cert. If you receive that as a valid dnssec response, you know it can be trusted.

Essentially the dnssec infrastructure replaces the CA infrastructure.

You can do the same thing with ssh key fingerprints too.

edit: cdjk - thank you - I have to edit-reply as there appears to be an increased time delay on replies. Maybe its me. Bought it.

http://blather.michaelwlucas.com/archives/1640

It's not out yet, but an nearly-complete draft is available on leanpub (with updates once he finishes copy editing):

https://leanpub.com/dnssecmastery

edit reply: I think the thread is nesting to far...

If I wasn't at least a little bit clever with my spending, I would have a lot more difficulty paying my rent.

Why would I want to pay if there is alternatives offering the same product at no cost?

Because free isn't necessarily a sustainable model given the current CA environment. Any server can generate its own certificate, but this does little to verify the identity of the server you are connecting to.

My point is that CA's provide a service that can't reliably be accomplished for free (yet - the CA model has many of its own issues). If you can find one for free, I would be lead to ask "what are their motives for providing this service to me?"

Let's put it another way, would you really trust that you're talking to https://www.amazon.com if it's trivial to get a cert for www.amazon.com[1] that's signed by a CA that the browsers include and trust[2]? How is it any different if the browser doesn't tell you the current cert is of dubious reputation?

[1]: It is, I could generate one right now using openssl.

[2]: It's not, that's why the system works.

It costs them nothing more than a few seconds of server time to produce a signed certificat for me.

You need SSL accelerators or pretty fast hardware to handle more than a few thousand SSL handshakes per second on a single machine. This is one of the places cost comes from.

That's not true - or rather it conflates two unrelated problems.

1) HTTPS/SSL (even with larger certificates) isn't computationally expensive:

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.[1]

2) The HTTPS initial handshake is slow. However, this isn't because of the power of the machine, or the certificates size. It's cause by round-trip overheard (See [2]). The solution for that is to reuse HTTPS connections as much as possible (which both your server and the browser should try to do for you anyway. But doing things like using the same hostname can help)

[1] http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...

[2] http://pic.dhe.ibm.com/infocenter/tivihelp/v2r1/index.jsp?to...

For web applications the overhead is much less significant. Both because you can re-use connections, and because few web applications can manage 20k+ requests per second on low end hardware.

That's precisely the point, though.

HTTPS is manageable where needed for security. Sleazy ISPs are making it necessary even where security is not a concern -- for example, viewing Apple's homepage.

http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu...

The proponents of HTTPS everywhere try to sweep the significant downsides under the rug, whilst others are spreading all kinds of unfounded FUD about HTTPS.

The bottom line is that "your mileage may vary". For some applications, SSL is trivial, and there is no excuse not to do it. For other scenarios it's a nightmare with all kinds of undocumented complications.

I'm currently working on providing SSL for a SaaS service with various client domains on AWS (i.e., with a limited number of IP-addresses). Doable, but far from trivial or inexpensive.

Also, I talked to GlobalSign recently, and they had a brand new solution that used SNI with an automatic fallback to multi-domain certificate for browsers that don't support SNI.

[1] https://code.google.com/p/chromium/issues/detail?id=43142

[2] http://en.wikipedia.org/wiki/Server_Name_Indication#Browsers...

FTFY.

  > SSL virtually requires buying certificates so
  > small/hobby sites won't use it

  > it involves multiple round-trips and latency is never
  > going to go away

  > part of what makes encryption work is that it's
  > computationally hard on today's 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.

startssl certs aren't trusted by my browser (or maybe the os?), so ssl's identity authentication for startssl is void. It's still better than no cert since ISPs can't detect what certs my browser trusts, thus wont make stupid moves, probably.

If you can use more widely recognized certificates, please do.

Which browser/OS combo are you using?

True, but the last time I tried them the UX was a nightmare.

On the other hand, they are two orders of magnitude cheaper than Symantec (nee Verisign)...

It's computationally hard to crack. To be useful, it necessarily has to be easier to use than to circumvent.