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

This is a discussion on Re: Clear-Text Patch? was: Re: OpenSSH 5.1: call for testing - openssh ; On Tue, 8 Jul 2008, Curt, WE7U wrote: > On Mon, 7 Jul 2008, Damien Miller wrote: > > > OpenSSH 5.1 is almost ready for release, so we would appreciate testing > > on as many platforms and systems ...

+ Reply to Thread
Results 1 to 9 of 9

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

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

    On Tue, 8 Jul 2008, Curt, WE7U wrote:

    > On Mon, 7 Jul 2008, Damien Miller wrote:
    >
    > > OpenSSH 5.1 is almost ready for release, so we would appreciate testing
    > > on as many platforms and systems as possible. This release is one of
    > > the biggest in recent years, with two hackathons' worth of improvements
    > > and fixes for some of our most recalcitrant bugs.

    >
    > Does this version have the clear-text-after-authentication patch in
    > it?


    No - we have said repeatedly that we are not interested in adding support
    for the "none" cipher.

    > The amateur radio people still need this tweak in order to use
    > OpenSSH over ham radio data links. The FCC does not allow
    > encryption of data on our frequencies, but does allow encryption for
    > authentication purposes.


    I'm sorry about your government's stupid laws, but I think that there
    is much potential for users to harm themselves if we were to add the
    null cipher.

    -d

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


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

    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 , +353-51-302938
    Telecommunications Software & Systems Group, http://www.tssg.org



    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  3. sftp pipelined requests was: Re: Clear-Text Patch? was: Re: OpenSSH

    On Wed, 9 Jul 2008, rapier wrote:

    > The main question I have is if they've increase the number of
    > outstanding requests in SFTP to match the increased receive window size
    > introduced in 4.7.


    It has now:

    /* Number of concurrent outstanding requests */
    -size_t num_requests = 16;
    +size_t num_requests = 64;


    -d
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  4. Re: sftp pipelined requests was: Re: Clear-Text Patch? was: Re:

    Quoting Damien Miller :

    > On Wed, 9 Jul 2008, rapier wrote:
    >
    > > The main question I have is if they've increase the number of
    > > outstanding requests in SFTP to match the increased receive window

    > size
    > > introduced in 4.7.

    >
    > It has now:
    >
    > /* Number of concurrent outstanding requests */
    > -size_t num_requests = 16;
    > +size_t num_requests = 64;


    Rock.
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  5. Re: sftp pipelined requests was: Re: Clear-Text Patch? was: Re:

    On Mon, Jul 14, 2008 at 08:16:55 +1000, Damien Miller wrote:
    > On Wed, 9 Jul 2008, rapier wrote:
    >
    > > The main question I have is if they've increase the number of
    > > outstanding requests in SFTP to match the increased receive window size
    > > introduced in 4.7.

    >
    > It has now:
    >
    > /* Number of concurrent outstanding requests */
    > -size_t num_requests = 16;
    > +size_t num_requests = 64;
    >
    >
    > -d


    Don't forget to update sftp(1). :-)

    --
    Iain Morgan
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  6. Re: sftp pipelined requests was: Re: Clear-Text Patch? was: Re:

    oops, fixed

    On Mon, 14 Jul 2008, Iain Morgan wrote:

    > On Mon, Jul 14, 2008 at 08:16:55 +1000, Damien Miller wrote:
    > > On Wed, 9 Jul 2008, rapier wrote:
    > >
    > > > The main question I have is if they've increase the number of
    > > > outstanding requests in SFTP to match the increased receive window size
    > > > introduced in 4.7.

    > >
    > > It has now:
    > >
    > > /* Number of concurrent outstanding requests */
    > > -size_t num_requests = 16;
    > > +size_t num_requests = 64;
    > >
    > >
    > > -d

    >
    > Don't forget to update sftp(1). :-)
    >
    > --
    > Iain Morgan
    >

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


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

    rapier writes:
    > Dag-Erling Smørgrav writes:
    > > Last I checked, it's still there; you just need to add "none" to the
    > > list of accepted ciphers in myproposal.h.

    > The problem is that just adding 'none' back pushes all interaction into
    > the clear [...]


    No, adding "none" to the list makes it available, but not the default -
    unless you add it to the front of the list.

    DES
    --
    Dag-Erling Smørgrav - des@des.no
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev

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


    Dag-Erling Smrgrav wrote:
    > rapier writes:
    >> Dag-Erling Smrgrav writes:
    >>> Last I checked, it's still there; you just need to add "none" to the
    >>> list of accepted ciphers in myproposal.h.

    >> The problem is that just adding 'none' back pushes all interaction into
    >> the clear [...]

    >
    > No, adding "none" to the list makes it available, but not the default -
    > unless you add it to the front of the list.


    My apologies for not being clear. Let me try again.

    If you simply add 'none' to the list and both sides of the connection
    agree to use none then all transactions for that connection, including
    authentication, happen in the clear. This is obviously unacceptable.
    This is why we developed the cipher switching patch. This allows for
    cipher used to be change midstream - which allows for encrypted
    authentication and unencrypted bulk data transport.





    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


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

    rapier writes:
    > If you simply add 'none' to the list and both sides of the connection
    > agree to use none then all transactions for that connection, including
    > authentication, happen in the clear. This is obviously
    > unacceptable.


    Depends on the context. I rarely use the "none" cipher, and haven't in
    a while, but it has always been on a trusted network, between two
    servers connected to the same switch. I would never use the "none"
    cipher over an untrusted link, even if only for "bulk data transport".

    DES
    --
    Dag-Erling Smørgrav - des@des.no
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev

+ Reply to Thread