21 reputation
6
bio website
location
age
visits member for 1 year, 9 months
seen Sep 7 at 19:45

Apr
30
awarded  Popular Question
Sep
27
awarded  Teacher
Feb
11
awarded  Scholar
Feb
11
accepted SSH: reusing public keys and known-man-in-the-middle
Feb
11
answered SSH: reusing public keys and known-man-in-the-middle
Feb
6
comment SSH: reusing public keys and known-man-in-the-middle
PS... I'm not sure, what do you mean under "credentials"..
Feb
6
comment SSH: reusing public keys and known-man-in-the-middle
Sure, P1 is not "entering the credentials" for S2 (at least, he thinks so). P1 only solves the challenge, received from S1, because he thinks, that this is required to authorize on S1. The whole attack would not be possible, if P1 would use different key pairs for S1 and S2... But, the thing is (and I've started the question with it): "Usually, people recommend to use a single private-public key pair everywhere"... That's why, in "preconditions" section, both S1 and S2 have the same "P1_id_rsa.pub".
Feb
5
comment SSH: reusing public keys and known-man-in-the-middle
sure only the one S2 has a symmetrically encrypted connection with would be able to read it, that is - only S1. So, S1 receives the challenge, and re-sends it to P1, now, P1 is unable to determine, whether this challenge was generated by S1 or someone else. So, it solves the challenge, and sends the answer to S1.
Feb
5
comment SSH: reusing public keys and known-man-in-the-middle
S1**<->**S2. Now, P1 is sure that he is connected to the server he intended to connect - to S1. And he is waiting for the challenge from S1, that he would solve to get authorized. On the other hand, S1 is not authorized as ssh client on S2, and S2 will send S1 a challenge,that only P1 is able to solve. The message structure is described in rfc I've mentioned above. I can't see any info that it's additionally encrypted or something. As far as I can tell, it is sent in quite plain format. It's only encrypted with general symmetric encryption, to make
Feb
5
comment SSH: reusing public keys and known-man-in-the-middle
...talking about. In my case, I'm playing on the authorization sequence features, not on the general concept of ssh. And the thing is - symmetric encryption is established firstly. Server would establish symmetrically encrypted channel with anyone who asks. And the identity of user is not yet verified. It would be verified during the second step. The symmetrically encrypted channel is secure, but you still don't know who you've got channel with. Only server signs his DH key part with his signature. So, on the first step 2 independent DH tunnels is established. P1**<->**S1 and
Feb
5
comment SSH: reusing public keys and known-man-in-the-middle
>>"P1 tunnels to S1 and then uses a client on S1 to talk to S2" nope, P1 is just trying to connect to S1, it doesn't want to connect to S2 either directly or through someone. Connecting to S2 is a result of the attack. >>"For P1 to talk to S2 while going through S1 <...> S1 then has no access to the actual information on the tunnel, nor can it modify it meaningfully" In this case, you treat S1 as just a regular router, somewhere between P1 and S2. This is not the case I'm ...
Feb
1
comment SSH: reusing public keys and known-man-in-the-middle
P1 knows that he is talking to S1. But it looks like P1 is unable to determine, whether challenge (received from S1) was generated by S1 or someone else.
Feb
1
comment SSH: reusing public keys and known-man-in-the-middle
Em... P1 thinks that there's a usual ssh server running on S1, and it tries to connect to it. But instead of normal ssh server, there's a specific "hack tool". P1 doesn't know that he's request would be tunneled.
Jan
29
comment SSH: reusing public keys and known-man-in-the-middle
I'm very sorry I failed to describe the whole situation in question in a manner that no misunderstanding would be possible... I've tried my best... Sorry....
Jan
29
comment SSH: reusing public keys and known-man-in-the-middle
>>"but P1 would know it was talking to S1" Indeed, P1 knows that he is talking to S1, and the thing is - this is what P1 wants.... P1 WANTS to connect to S1, and, it doesn't want to connect to S2 (this time). As far as I understood, the rest of your message seem to be based on the same idea...
Jan
27
awarded  Commentator
Jan
27
comment SSH: reusing public keys and known-man-in-the-middle
Em...But S1 is going to convince P1 to establish a DH key exchange with itself, S1. So, for DH key exchange P1<->S1 and S1<->S2.
Jan
26
comment SSH: reusing public keys and known-man-in-the-middle
(In response to 3/3) As far as I understood, the "challenge" packet to be sent to client is described here, around page 8, but I can't see any info about additional encryption for challenge, so, I assume that it's only encrypted with the same symmetric encryption, based on DH key exchange,that all data is encrypted with. But S1 is able to read the data encrypted with it, since it had established two separate channels with P1 and S2 before. How exactly is the challenge encrypted?
Jan
26
comment SSH: reusing public keys and known-man-in-the-middle
(In response to:2/3) Yep, I believe, we're talking about ssh2...
Jan
26
comment SSH: reusing public keys and known-man-in-the-middle
(IN response to:1/3) If S1 would just tunnel DH key exchange data - it won't be able to encrypt/decrypt any data in this session. But that's a separate data packet, not the same as the packet with challenge. So, S1 works differently with them. There are two different "DH channels", with symmetric encryption which S1 is able to encrypt/decrypt, but there's only one client authentication process - S1 just tunnels it.