[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Decrypting data within an opened channel?


Hi Karl,

It's hard to figure out what you're doing exactly. How are you
calculating the session keys needed for the interception ? are you
redoing the diffie-hellman key exchanges with both sides to set up
different encryption keys ?
What ciphers are you negotiating ?
The problem you describe may be related to a padding problem or a desync
in the packet parsing. All ciphers will decrypt to garbage if you even
miss a single byte or flip a single bit, with the exception maybe of
stream cipher modes.
It seems like you used some small parts of libssh for your purpose, you
may have introduced some unexpected side effect. In all honesty I'm
surprised you managed to decrypt even the channel opening.

Are you aware that there is no way the public key authentication (client
to server) is going to work ? The session id (being signed by client) is
a derivative of the diffie hellman key exchange.

Regards,

Aris

Le 9/10/15 03:45, Karl Scott a écrit :
> Hey guys,
>
> Encrypted data moving from a client to a server should keep the same
> encryption key regardless of if an SSH channel has been opened or not,
> right? And by channel, I mean something created by the
> ssh_channel_new() function.
>
> To explain, I'm working on an SSH proxy of sorts, and so naturally,
> one of the things I do is:
> a. See incoming raw encrypted SSH data coming in, wrapped in TCP.
> b. Decrypt that data after stripping the TCP headers off, using
> packet_decrypt_len() or packet_decrypt() and providing the length
> manually (both of these are libssh provided functions, though not part
> of the API).
> c. Look at the raw unencrypted data, and expect it to be of the normal
> SSH binary format from here: https://tools.ietf.org/html/rfc4253#section-6
> d. Encrypt the data we were just looking at, and wrap in in the
> appropriate headers (a modified version of packet_send2 is doing this
> for me wonderfully during testing).
>
> This is all working for me, except when it comes time to transmit the
> actual exec command I am trying to use. So, I manage to successfully
> open a proxied channel, which indicates that my decryption and
> encryption logic is working properly.
> Also, disconnect messages are properly read and transmitted, where all
> sides can see the plaintext, so I am very confident of the logic in
> steps a. to d. listed above.
> As one last example, I can clearly see the decrypted ASCII text of
> certain encrypted traffic that brings us up to this problem point,
> such as "Zsession" in this decrypted hex traffic:
> 5A0000000773657373696F6E000000000020000000008000
>
> But when the client sends the encrypted packet which contains the
> command we want to exec inside of it, I cannot decrypt it -- I just
> get garbage when I try. It is as if there is some other encryption key
> I need to be using. The function I am using to decrypt is the same as
> listed in step b. The encryption function I use shouldn't matter in
> this case, since the client is encrypting the message before it
> reaches my proxy code.
>
> Again, this proxy successfully opens the channel, and successfully
> decrypts and re-encrypts custom disconnected messages.
>
> Any help or ideas would be great -- I've spent all day working on
> this, with no luck!
>
> Thank you!
>
> -Karl


Follow-Ups:
Re: Decrypting data within an opened channel?Karl Scott <karlscottbg@xxxxxxxxx>
References:
Decrypting data within an opened channel?Karl Scott <karlscottbg@xxxxxxxxx>
Archive administrator: postmaster@lists.cynapses.org