consider unconditionally requiring pyOpenSSL (and remove UnauthenticatedTub)

Replying to warner:

As recommended in #66, there may be good reasons to have Foolscap simply require pyOpenSSL unconditionally, and remove the option of using UnauthenticatedTub. It needs some more thought, though.

Please don't do this. The IPython project is now using foolscap in its parallel computing infrastructure. In some cases:

1) Connecting processes on loopback only

2) In heavily secured contexts where the system is secured through other means

We really need to be able to use foolscap in its insecure mode. Also, we are not confident that openssl is available on some of the more exotic systems (supercomputers) we will be running on. Finally, in these contexts, we need to be able to use foolscap without SSL for performance reasons.

Summary: we are loving foolscap, but definitely prefer to have pyOpenSSL optional. I should mention though that in IPython the default mode is secure!

This is an opportunity to learn about the costs of securing foolscap.

Why is it important to bgranger to avoid the requirement on pyOpenSSL?

Possible reasons:

1. Key management makes things harder. The foolscap design should make this not be the case. If it is still the case I would love to know why. (This is a unique feature of foolscap over alternative secure RPC mechanisms -- that the object-capability paradigm makes the key management problem go away.)

2. CPU cost of SSL/AES/HMAC/SHA. I would be surprised if this were actually an issue for bgranger's deployments, but maybe it is. Is there evidence that this is a problem? (If it is, then this is useful information for the future, in the future foolscap could use a more CPU-efficient encryption and authentication scheme. I was just describing to Brian a few minutes ago how there are new improved stream ciphers out now which seem to be both faster and safer than AES, for example.)

3. Time and network utilization costs of SSL startup. Again, our measurements have shown that this is negligible. What was it -- something like 10,000 connections per second? However, bgranger's network performance characteristics might be different, and if so I would like to learn about it. (A future version of foolscap could use a crypto protocol with faster startup than SSL.)

4. Availability of OpenSSL on deployment target. This one I totally believe is an issue for bgranger. I myself have had problems configuring and installing OpenSSL on Windows, Cygwin, and Mac OS X. I wouldn't be surprised if it either doesn't port to the supercomputer at all, or if it does so only with extensive configuration tweaks. Also, even if the source code can be easily built on a deployment target, that isn't the same as it being sufficiently convenient to depend on it being there. I wouldn't be surprised if the worst problem with requiring pyOpenSSL was that there is no simple, cross-platform way to express the fact that pyOpenSSL requires OpenSSL, and have that requirement automatically resolved.

5. Other? Is there any problem with using pyOpenSSL in your environment, bgranger, other than the problems mentioned above?

Thank you very much!

Correction: Brian showed me the spot on the whiteboard where we had scribbled our notes about OpenSSL benchmarking. It was 100 connections per second, which caused a 30% CPU load. Presumably therefore it could handle 300 connections per second if it didn't need to do anything else with its CPU. This was on a typical server from a year or two ago -- 1 CPU, 1 core, about 2 or 3 GHz, Athlon64 or x86 architecture.

Also note that this isn't measuring latency incurred by the SSL connection negotiation, it is only measuring the "connection establishment throughput" -- connections established over some long time period (tens of seconds) divided by that time period.

Replying to zooko:

This is an opportunity to learn about the costs of securing foolscap. Why is it important to bgranger to avoid the requirement on pyOpenSSL? Possible reasons: 1. Key management makes things harder. The foolscap design should make this not be the case. If it is still the case I would love to know why. (This is a unique feature of foolscap over alternative secure RPC mechanisms -- that the object-capability paradigm makes the key management problem go away.)

This is a not an issue for us for the reason you mention.

2. CPU cost of SSL/AES/HMAC/SHA. I would be surprised if this were actually an issue for bgranger's deployments, but maybe it is. Is there evidence that this is a problem? (If it is, then this is useful information for the future, in the future foolscap could use a more CPU-efficient encryption and authentication scheme. I was just describing to Brian a few minutes ago how there are new improved stream ciphers out now which seem to be both faster and safer than AES, for example.)

This _could_ be a huge issue for us. Our bottleneck process maintains a large number of persistent (hundreds) connections to workers. We need extremely low latency in all of these connections and if this single process has to do a lot of CPU bound work for encryption related things, we could have a problem. I would be very interested in learning about how to use the newer ciphers.

The other performance related thing is that much of the time, we are running over loopback in a single user workstation - in this context, most users will not need security. It seems crazy to force it on them.

3. Time and network utilization costs of SSL startup. Again, our measurements have shown that this is negligible. What was it -- something like 10,000 connections per second? However, bgranger's network performance characteristics might be different, and if so I would like to learn about it. (A future version of foolscap could use a crypto protocol with faster startup than SSL.)

All of our connections are persistent, so this is not a big issue.

4. Availability of OpenSSL on deployment target. This one I totally believe is an issue for bgranger. I myself have had problems configuring and installing OpenSSL on Windows, Cygwin, and Mac OS X. I wouldn't be surprised if it either doesn't port to the supercomputer at all, or if it does so only with extensive configuration tweaks. Also, even if the source code can be easily built on a deployment target, that isn't the same as it being sufficiently convenient to depend on it being there. I wouldn't be surprised if the worst problem with requiring pyOpenSSL was that there is no simple, cross-platform way to express the fact that pyOpenSSL requires OpenSSL, and have that requirement automatically resolved.

This is a huge one for us. We _have_ to be able to run anywhere that Python+twisted runs. The more exotic platforms for us include AIX and hacked up linux versions on supercomputers. If we can't run foolscap without SSL, we will have to consider dropping foolscap and instead go with plain PB for these contexts. But I _really_ don't want to have to maintain a PB version of all of our stuff.

5. Other? Is there any problem with using pyOpenSSL in your environment, bgranger, other than the problems mentioned above? Thank you very much!