On 2013-11-08, Chris Angelico <ros...@gmail.com> wrote:
> On Sat, Nov 9, 2013 at 7:48 AM, Grant Edwards <invalid@invalid.invalid> wrote:
>> All I have control over is the server. I have no influence over the
>> client side of things other than what I can do in the HTTP server.
>
> Hmm. Then the only way I can think of is a reverse proxy that can
> queue, handle security, or whatever else is necessary. Good luck. It's
> not going to be easy, I think. In fact, easiest is probably going to
> be beefing up the hardware.
>
> Oooh.... crazy thought just struck me. What's your source of entropy?
> Is it actually the mathematical overhead of cryptography that's taking
> 2-3 seconds,
Yes. AFAICT, it is. Some of the key-exchange options are pretty
taxing. I can speed things up by about a factor of 4 by disabling the
key-exchange algorithms that have the highest overhead, but those are
the algorithms that the SSL clients seem to prefer. I'm reluctant to
force them further down their preference list, lest I end up not being
able to support some clients.
> or are your connections blocking for lack of entropy?
Nope. The cyrpto libraries we're using don't do that. I'm not
entirely happy with the entropy generation used. I wish I had more
sources of "real" randomness, but at least they don't block.
> You might be able to add another source of random bits, or possibly
> reduce security a bit by allowing less-secure randomness from
> /dev/urandom.
It's not Unix-like OS, but that's more or less what's happening.
--
Grant Edwards grant.b.edwards Yow! I'm sitting on my
at SPEED QUEEN ... To me,
gmail.com it's ENJOYABLE ... I'm WARM
... I'm VIBRATORY ...
--
https://mail.python.org/mailman/listinfo/python-list
