[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SSL trouble
Piete Brooks writes:
> Let's not get implementations confused with algorithms ... We were
> using ALPHA code when we started ....
Pardon me here, as I don't mean to belittle your considerable efforts, but I
think it was a mistake to make such loud announcements (posted to sci.crypt
for instance) when the software was alpha! The software should have been
tested and stable before the general public was invited to participate and
"see how fast we can break SSL" As expected, lots of people tried to
participate and the software just couldn't handle it.
How many patched versions of the client software were distributed after the
effort had started? If you want to do it as fast as possible, you can't be
constantly updating your client software.
> With BETA clients, a hierarchy and select/poll loops, I reckon a
> server would stand a chance.
I think protocol issues are a Red Herring. If your server had been able to
handle more than one client at a time it would have stood a chance. Why
didn't it fork? Sure, forking isn't the most efficient way to handle
multiple clients, but HTTP servers (as well as SMTP and FTP) manage to handle
hundreds of thousands of requests each day that way. One client at a time
with a 30-second timeout was just plain dumb...
I would recommend thorough testing of the software on many platforms and with
realistic loads before the next public effort (there are plenty of willing
testers on the cypherpunks list). I tried to join in the effort and after
discovering that the client software was firing off multiple brutessl
processes, I decided to wait until the client stabilized. I attempted to
reject the keyspace I allocated through the WWW interface, but that didn't