Comments on: IPv6, SSL, scheduled tasks, storage discounts & bulk bandwidth

By: jdw

jdw — Sun, 13 Jan 2013 23:38:49 +0000

In reply to Pete S.. The SSL endpoint for any given site is a single point of failure for that site's HTTPS access, because our system makes the good but not perfect assumption that the site's certificate is only licensed for use on one endpoint. SSL 3.0 was dropped while we were testing TLS 1.1, not in relation to any of this. We had some test clients failing due to the number of ciphers offered, and SNI only works with TLS anyway, so it seemed pointless to negotiate connections that are doomed to fail anyway. I'm not sure there is any https-capable stack anywhere that is currently supported by its developer and can do SSL 3.0 but not TLS 1.0. -jdw

By: Pete S.

Pete S. — Sun, 13 Jan 2013 21:56:33 +0000

Heh. Sorry about causing mass confusion!

Also, it seems like the current setup is now only TLS 1.0 and didn’t have the SSL 3.0 it had a few hours ago. I assume this is intentional (pretty much any client that doesn’t support SNI won’t support TLS 1.0, so it’s not a big deal yet). Is that intentional (for example, is it required for ECDHE?) or did that accidentally get disabled? Or, potentially more likely, I’m hallucinating and didn’t see SSL 3.0 being enabled before.

Just some quick clarification: on the Submit Assistance Request page for enabling SSL, one line reads “Because certificates are typically licensed for use only on a single host, SSL has an additional single point of failure that our regular hosting does not.”

What is meant by this? Is there only one, non-load-balanced SSL endpoint for all of NFSN (or a single member site) or is it just an informational warning about the licensing of certain certs?

Is the normal reverse-proxy/load-balancing done for SSL-enabled sites or only non-SSL-enabled sites?

I totally understand that the SSL is offloaded to one or more SSL endpoints and I understand if this introduces a single-point-of-failure, but I just want to be sure that’s what it actually means.

By: jdw

jdw — Sun, 13 Jan 2013 21:29:47 +0000

In reply to Pete S.. Don't be too impressed. Before we realized what you were seeing and why, hours were spent staring dumbly at the config trying to figure out why the chain certificates were being so blatantly ignored. :-P The SSL endpoint is Apache 2.4; I believe you are correct that the DH parameters aren't adjustable. (And also that it's not the end of the world -- yet -- that they aren't.) -jdw

By: Pete S.

Pete S. — Sun, 13 Jan 2013 20:47:02 +0000

Reply to jdw’s above message.)

2. Drat. Oh well. 🙂

3. Shiny. ECDHE is a useful thing to have enabled as it’s more CPU-efficient than standard DH.

3a. You mention that your SSL endpoint is separate from the webservers themselves so it’s unlikely to be running Apache. Does it support DH parameters >1024-bit (that’s the default for Apache and they don’t let you use longer parameters but your endpoint might)? Just curious, as that’d then become the “weak point” (of course it’s unlikely that anyone would attack the crypto itself and would go for application-level attacks, but still).

4. Awesome. It still saves on one query back to the CA, so that’s a plus. 🙂

5. Aha! That would do it. I figured you guys would set things up right and was puzzled as to why it was broken in that way. I’m glad you fixed it and am impressed that you did it so quickly.

-Pete

By: jdw

jdw — Sun, 13 Jan 2013 19:33:13 +0000

In reply to Pete S..

2. We cannot currently allow people to specify ciphers on a per-site basis.

3. Yes, we were able to enable ECDHE support. TLSv1.1 eludes us, however. Renders a wide swathe of browsers unable to connect for some reason. But you should be able to get AES_256_CBC, with SHA1 for message authentication and ECDHE_RSA as the key exchange mechanism now.

4. We were also able to enable OCSP stapling, although it’s only of limited value when virtually every certificate requires a chain.

5. We are definitely providing the Thawte intermediate certificate for *.nfshost.com sites. What I did find was that if you hit the server without using SNI, you were getting that certificate as the default with no chain. That’s been corrected; thanks for pointing it out.

-jdw

By: Pete S.

Pete S. — Sun, 13 Jan 2013 13:37:43 +0000

Shiny. Thanks! The stochastic billing looks pretty awesome.

A few brief comments/suggestions, if that’s no too much trouble:

1. Thanks for adding SSL. Major bonus.

2. It would be nice if, at some point in the future, a user could configure which ciphers they’d like their site to support. (I’m not sure if you can do this on a per-site basis.)

3. I also really appreciate that you have ephemeral Diffie-Hellman key exchange enabled for SSL-enabled sites. This provides perfect forward secrecy and is a Big Deal that’s often overlooked, so thanks. You may also want to see if the current versions of the software you’re using supports Elliptic-Curve DH key exchange (Google uses this and it cuts back a bunch of resource usage on the server). If so, that’d be great if such ciphers were also available. If not, well, one can wait until the next upgrade. 🙂

4. When you upgrade eventually to Apache 2.4, it’d be nice if OCSP stapling was enabled (or an option) as it can increase performance for users of SSL-enabled sites (and doesn’t have any real penalty for the site or host itself).

5. Your *.nfshost.com certificate is not installed correctly: you do not have the appropriate Thawte intermediate/chain certificate installed. This should be fixed or it can cause errors for users of *.nfshost.com secured sites.

Thanks again!

By: jdw

jdw — Wed, 09 Jan 2013 13:25:57 +0000

In reply to turkeyphant. The UI already shows a daily average of resources used. To get an estimate of the impact of switching, you can figure out how much that would cost, then compare that to 90% of what you currently pay for storage and see which figure is larger. Many people are already moving over to the stochastic billing model. It's both fairer for everyone and cheaper for a whole lot of people, so its early popularity is neither a mystery nor a surprise. That is only likely to increase once we document it on the public site and make it a selectable option at site creation. We think everyone should switch. But we understand that some people with sites for which "fair" equals "more" may prefer not to switch as long as other members are willing to continue subsidizing their usage under the old model. And a few people may be too uncomfortable with "random" and "billing" in the same sentence to ever switch, no matter how good the math is. So we don't plan to force any changes. -jdw

By: turkeyphant

turkeyphant — Wed, 09 Jan 2013 11:20:54 +0000

Is it possible to produce a basic tool to estimate whether you’d save anything by switching a certain site over to stochastic billing? Is your aim to have many people move over to this model?

By: Aaron Mason

Aaron Mason — Thu, 03 Jan 2013 02:36:58 +0000

Thanks, that clears it up. I inferred from the wording that enabling IPv6 would disable IPv4.

By: jdw

jdw — Thu, 03 Jan 2013 01:57:27 +0000

In reply to Aaron Mason. No, your choices are IPv6+IPv4 or IPv4 only. There is no "IPv6 only" option. -jdw