Re: Idea to secure ssh
Michael Stone <mstone@debian.org> writes:
> On Wed, Mar 15, 2006 at 02:35:53PM +0100, Goswin von Brederlow wrote:
>>Michael Stone <mstone@debian.org> writes:
>>> No, anyone can generate encrypted parts. IMHO, there's not much chance
>>> that the decryption routines in your magic udp parser are going to be
>>> less vulnerable than those in openssh itself. Having "two layers of
>>> Having "two layers of encryption" in this context is fairly pointless.
>>
>>Those two layers are totaly standard. You have to use two keypairs in
>>parallel to ensure that only one person can read the text and only one
>>person can have send it.
>
> Either that paragraph doesn't parse or it doesn't address what I
> said. This gets back to "what are you trying to defend against". If
> you're trying to defend against brute force attacks, then the ssh
> public key auth should be sufficient. If it's not (if your adversary
> can somehow crack or brute force arbitrary RSA keys) than adding a
> *second* key isn't going to help. If you're trying to defend against
> attacks on the crypto routines themselves (e.g., a buffer overflow
> against the RSA code in openssh) then I don't see why this other
> parser is going to be more secure. What problem is this frankenstein
> trying to solve?
He trying to solve that a tcp connect to port 22 establishes a
connection and thereby reveals that the server is running an sshd and
attcking it makes sense.
His idea is to add a 100% non responsive knocking (using udp) before
the actual ssh handshake so unauthorized clients can't even determine
that sshd is running. Not that I find that usefull but thats the idea.
>>> Why not use three layers, or four? What analysis demonstrates a
>>> demonstrable return for that second layer, weighed against the cost of
>>> this kooky mechanism? If you really need multiple encryption layers,
>>> do it right and use an existing standard like ipsec rather than
>>> inventing a convoluted "secret method".
>>
>>The analysis is simple:
>>
>>Encrypting with the server public key ensures that only the server
>>private key can decrypt the data.
>>
>>Encrypting with the client private key ensures that only the client
>>can have send the package. Decryptng with the clients public key
>>ensures that.
>
> Dude, openssh *already does that*.
Obviously. Anything less and you can jjst use telnet.
> Mike Stone
MfG
Goswin
Reply to: