OpenSSH with 'none' cipher (after reading bug #877)

Yaniv Aknin yaniv at aknin.name
Sun Mar 8 16:55:43 EST 2009


Sorry for the delayed reply. I gather the list's silence on this matter
amounts to telling me to shut up and go implement it myself on my own branch
of the source? (ah, the horror...).

Luciano, as for your suggestion of private exponent on the sniffer: this is
technically possible, but much more cumbersome, not supported by all
sniffers, requires special code to parse / decrypt / store sniffed packets
with the like of libpcap rather than just use a socket and get a plain TCP
stream, etc.

To add insult to injury, due to architectural reasons I use two and rarely
three ssh sessions, tunneled one inside the other (I can explain why, though
it isn't very interesting, honest) - if the previous description was
cumbersome, think about it done two/three levels deep.

 - Yaniv

On Thu, Feb 26, 2009 at 10:50 PM, Luciano Bello <luciano at debian.org> wrote:

> El Jue 26 Feb 2009, Yaniv Aknin escribió:
> > However, It seems that a solution I'm implementing may require cleartext
> > transport due to regulation / auditing compliance reasons. Turns out that
> > the government suits of some countries mandated that some institutions
> are
> > required to keep a cleartext copy of all communications ever sent from
> their
> > premises for a while, and I can't use my SSH based solution for these
> > customers (Please, I don't want to argue about whether it's a good or a
> bad
> > idea).
>
> What about put a copy of the sshd's private exponent in the sniffer/auditor
> machine? Whit this, the auditor can recalculate the share secret and
> decipher the communication. Of course, this broke PFS in DHE but looks like
> a better solution than just use plain text.
>
> luciano
>
> PD: I'm in favor of implement 'none' cipher but with the 'performance'
> reasons.
>


More information about the openssh-unix-dev mailing list