Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing

[John Ronan]

Morning,
>
> There has certainly been some interest in users, but not any amongst
> the other developers that I'm aware of (you can get an idea of who is
> working on OpenSSH by looking at the ChangeLog file in the  
> distribution
> btw).
>
> Let me explain our rationale a little more:
>
> OpenSSH is a security tool used by lots of people of wildly varying
> technical skill and cryptographic fluency, so we want to make it as
> foolproof as possible. Part of this means that we are willing to
> deliberately exclude dangerous options even if users want them.
>
> Generally, the people who require esoteric or dangerous options also
> happen to be the people who are technical enough to patch them in
> themselves.
>
You say yourself that there has been some interest amongst users, I  
personally, since January have been using the HPN-SSH patch on three  
machines (Thanks to Michael Stevens for pointing me in the right  
direction) that I have no other access to except over radio or by  
visiting the site and visiting the site is impossible for several  
months of the year.

Obviously I use (unpatched) open-ssh every day during my normal work,  
and I'm thankful for it.

>> It's likely that your government or other nearby governments have
>> similar "stupid" laws for amateur radio.  Many do.  Radio links know
>> no political boundaries, so encryption over radio links tends to
>> make the powers-that-be nervous and they legislate against it.
>> Either that or they borrowed bits from FCC regulations which is also
>> common.
>
> Please don't read too much into my throwaway line about laws - I'm not
> opposed to adding the null cipher because of politics, it is really
> about user safety.
>
>> Why would users be so stupid as to get in trouble with something
>> like:  "--NONE_CIPHER_PLEASE_DONT_USE" or
>> "--NO_CIPHER_HAM_RADIO_ONLY" or similar?  I generally assume my
>> users are intelligent and am not often disappointed.  There are
>> obvious ways to make a NULL cipher available from the command-line
>> without letting users get into trouble with it.
>
> No. Unfortunately distributors of OpenSSH have a imperfect record of
> changing defaults and turning on options that we recommend against.
> Invariably, the support requests and blame when things go wrong come
> back to us.
>
> Also, once you are at the point of having to do a custom compile of
> OpenSSH to get the options you want then adding a small patch is
> very low additional overhead anyway.
>
Ok, I understand your concern. (Australia, I think, have recently  
relaxed this rule to allow the use of encrypted traffic on air btw)

How about printing a big ugly half page warning if the option is  
switched on and when it gets enabled at compile time?  So the user is  
under no illusion as to whats happening if the null cipher is enabled.

Don't forget that in order for it to work at all, in my case I would  
have to compile with whatever options that could be required to  
enable it on at least 4 machines.

If a distribution started enabling the none ciper by default (which I  
doubt would happen), I'll gladly chase them down and file bug reports  
with them until they desist. I reckon I'm good for another 30-50  
years ish, and I'm nothing if not persistent.

Even if someone managed to download the source and build it with  
'none-cipher' enabled on every machine they wanted to log into, AND  
use whatever command line option was required to engage it, they  
would have to go to a lot of trouble to use it.


>
[snip]
> We will help by doing our best to keep OpenSSH a high quality product,
Which, there can be no argument, that it is, and I thank you for it.
> but we are not willing to be "all things to all people".
>
Well we're not asking you to be that, just allow for the relatively  
easy enabling of a feature that allows us to stay legal.

Regards
de John
EI7IG
--
John Ronan <jronan at tssg.org>, +353-51-302938
Telecommunications Software &  Systems Group,  http://www.tssg.org