SSl challenge - it was fun!
Hi
Someone asked about the SSL challenge. Well if you're interested here is a personal view from a "client" participant.
Despite criticisms posted to this list I think it worked pretty well for a first attempt, mainly due to Piete for hacking out new code and fixing things pretty quickly when things went wrong.
There was very little time to test software initially and get problems ironed out. I couldn't get brutessl to compile without tinkering and had timeout problems with brclient due to the sometimes slow link from Austalia. Later versions of client software (that I didn't get till half way through the challenge) seemed to run without any problems and without losing ACKs. But my old client had failed to ACK quite a few of its earlier keyspaces and due to lack of a logfile I ended up writing a script to redo them and ACK them with the new version of the client software.
One problem with being in Australia was that I was asleep when new software updates were announced and tended to get them later than everyone else, and because of this an auto-update would be particularly useful to me if we do this again.
In the end it needed a bit of user intervention to get all my keyspaces ACKed but the problems were sorted out by the time the challenge was half way through and I think the next time we try this (and I hope we will) it will run much more smoothly. It was a good "learning" experience for all of us (especially Piete!) and should be regarded as what it was: an experiment that didn't run completely smoothly but was ultimately successful.
Taking part in the challenge was fun and I hope we can do another challenge sometime soon.
One gripe though - my ACKs don't appear on the credits list ;-(
Sherry
One problem with being in Australia was that I was asleep when new software updates were announced and tended to get them later than everyone else, and because of this an auto-update would be particularly useful to me if we do this again.
I would be extremely wary of this as accepting code written by someone else to automatically run on your machine is bad. I realise the non unix people are forced to use binaries and have no way of knowing what in hell is in the nice software, but Unix people have a responsibility to themselves and the others on their machines/networks to at least check that everything is ok. If they do not have the expertise, they will hear of it soon enough when others scan the offered code. Having source code to these programs is essential, from a security and snub the TLAs point of view. People need to be educated how to write systems to use crypto and they need to be able to check no trojans are included. Mark mark@lochard.com.au opinions are rumoured to be mine.
Sorry if I stuff up; I'm trying for PGP-signed and the PGP is on a different machine... -----BEGIN PGP SIGNED MESSAGE----- Hello Mark <mark@lochard.com.au> and scmayo@rschp1.anu.edu.au (Sherry Mayo) and cypherpunks@toad.com ...[asking for an auto-update]...
I would be extremely wary of this as accepting code written by someone else to automatically run on your machine is bad. ...
Why? I wouldn't say "bad". I'd say "you need to know what you are doing". ...
If they do not have the expertise, they will hear of it soon enough when others scan the offered code. ...
Perhaps there should be a mechanism whereby code offered would be signed by various parites. When sufficient signatures have collected, auto-update can proceed. Yes, no, maybe? Jiri - -- If you want an answer, please mail to <jirib@cs.monash.edu.au>. On sweeney, I may delete without reading! PGP 463A14D5 (but it's at home so it'll take a day or two) PGP EF0607F9 (but it's at uni so don't rely on it too much) -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMEFmuixV6mvvBgf5AQEkRwP/TUorbtcmElHjWVrxJ8KoTlM0D3/oK4xh Jh4+QLGaH/aNvI5ehdhPjn+tFXwL/ONS+J/pzO0b2cP9GcM3D6PvtUWxmsTwwaMh jXkctAPIuO24nb0cAXtcj7LlUe4s5DqIVvkCYi8UrdPXrYEV5DaKti4MYD7oShgC XMkzzcv55bQ= =wa8h -----END PGP SIGNATURE-----
...[asking for an auto-update]...
I would be extremely wary of this as accepting code written by someone else to automatically run on your machine is bad. ...
Why?
I wouldn't say "bad".
I'd say "you need to know what you are doing".
...
If they do not have the expertise, they will hear of it soon enough when others scan the offered code. ...
Perhaps there should be a mechanism whereby code offered would be signed by various parites. When sufficient signatures have collected, auto-update can proceed.
Yes, no, maybe?
No. Bypassing anecdotes about personal experiences with some .au cpunks, why should I trust *anyone* to certify that code is auto runnable on my machine? In secure or commercial networks, the onus is on making sure holes are not opened up in the defences. To me, having all these crypto links, digital envelopes, crypto filesystems, etc all mean zero if you start offering to run code blindly from anyone. Next. Mark mark@lochard.com.au The above opinions are rumoured to be mine.
One problem with being in Australia was that I was asleep when new software updates were announced and tended to get them later than everyone else, and because of this an auto-update would be particularly useful to me if we do this again. I would be extremely wary of this as accepting code written by someone else to automatically run on your machine is bad.
Indeed ! This is why brclient and brloop are two separate programs .. (those who don't care about security can run "brclient -Ubrutessl -tssl | sh" (for a demo, type "brclient -Ubrutessl -tsslck") BUT it means that the SKSP server could run any command on your system! ) Users should read brclient (and make me blush !) to show that there are no trapdoors. Then they should read brloop and convince themselves that whatever data is returned by brclient, no rogue command will be run. (this is why brloop is written in sh rather than perl -- I assume more people read sh than perl ... ) Note that brclient and brloop do not do any file I/O (so can be chroot'ed, etc) and apart from "pretties" (such as calling hostname / uname -n to generate an ID) brclient doesn't exec any other commands, so all you need provide are those used by brloop (I think sed and head). If anyone cares to build a "cell" in which to run it, please let me know. However, I fear that it might be somewhat machine specific. One problem is that the more recent brloop starts by asking "which servers shoudl I use" unless they are explicitly set -- this means that you either need to wire down the host to call (e.g. a local SKSP "local CPU farm" server), or allow it to make an outgoing call to *ANY* host on port 19957 (well, you might care to disable access to your local network, 127.* etc).
If they do not have the expertise, they will hear of it soon enough when others scan the offered code.
I've been waiting, but not heard any yet :-)) After my experiences of a handfull of old clients killing the server for everyone, I plan to circumvent the problem by causing rogue brloop's to exit. Sure -- auto update would be nice, but until the padded cell above is implemented
participants (4)
-
Jiri Baum -
Mark -
Piete Brooks -
Sherry Mayo