turning on none cipher for v1 and v2 server

[Dan Kaminsky]

> Put it simplity..
>
> using 'none' cipher can result in man-in-the-middle attacks against you.
> And since ssh was designed to protect against that and against information
> leakage it would break the integerity of protocol to support such a thing.
>
> I have seen people hack 'none' into the ssh client.  However, we will not
> support such things.
>
> - Ben

You're correct in terms of SSH1.  SSH1 uses its encryption function for
integrity verification, so the lack of a cipher means anyone can inject
arbitrary packets.  (Essentially, the system presumes that the only two
entities who share the symmetric key are the client and the server, meaning
all messages that weren't sent from one side and decrypt correctly had to
have been legitimately sent from the other.)

SSH2, by contrast, separates the cipher from the integrity verifier, using a
distinct HMAC for each message being exchanged between the client and the
server.  This HMAC is entirely functional even when encryption is disabled
entirely--any man in the middle will indeed be able to view the datastream
in its entirety, but it won't be able to change a thing.

This isn't an accident.  Beyond the fact that separating integrity killed
lots and lots of packet injection attacks dead, there's a good deal of
theoretical justification for the separate and independent emphasis.  Some
messages are presumed to be private, many are assumed to be public, but
*all* messages are assumed to be intact, whether or not we have a good
reason to believe so.  Integrity verifiers exist to give us that reason, but
when you read an article from http://www.nytimes.com or http://www.cnn.com,
you still *think* you're reading from an authenticated source--the pixels
tell you so.

Even I believed http://www.pacland.cc/pics/zoomzoom.jpg .

The web needs to be mass-authenticated long before it needs to be
mass-encrypted(though the masking noise would be helpful).  Unfortunately,
most of the development energy is going into systems for making it easier to
swipe your mother's maiden name every time you click on a stupid
link...*sigh*

If a user wants to safely send public-readable messages, not only is it not
dangerous, it's not surprising.  There's a highly legitimate need for
messages that are simply not changeable in transit--read only, not
read-write.  Given the weakness that's becoming apparent in web security, we
can't really deny what others have been painfully blind to.

Anyway.  Enough preaching:

This works:
$ ssh -2 -m hmac-sha1 -c arcfour user at host

This should work, but instead uses AES.  Now *that's* incorrect behavior!
We need to break if we don't recognize a cipher.
$ ssh -2 -m hmac-sha1 -c none user at host

This must fail--it doesn't(uses 3DES), and that's a problem.
$ ssh -1 -c none user at host

Since SSH2 apparently refuses to work with a null HMAC, are there any other
objections you have to might have to allowing SSH2 to exist cipherless?  And
is there any objection to making unknown ciphers fail like unknown HMACs?

Yours Truly,

    Dan Kaminsky, CISSP
    http://www.doxpara.com