network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 4 months |
| seen | Feb 13 at 14:24 | |
| stats | profile views | 2 |
|
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. |
|
Jan 25 |
comment |
SSH: reusing public keys and known-man-in-the-middle Yes, only PC1 is able to solve (or read, what's the difference?)the challenge. But why S1 is unable to tunnel the challenge received from S2 to S1 ? S1 don't have to read it, just tunnel it. I can't find any statement like "challenge is signed with S2_id_rsa and THEN encrypted with P1_id_rsa.pub" (in this case, S1 won't be able to modify the signature) anywhere. In fact, I haven't found anything at all about the challenge being signed and/or encrypted.... They all say,server is authenticated on DH key exchange step, why do double authentication? |
|
Jan 23 |
comment |
SSH: reusing public keys and known-man-in-the-middle as far as I understood, the challenge could only be SOLVED by P1, because he's the only one with P1's private key. Anyone could receive the challenge, but only the one with an appropriate private key can solve it. That's the idea of the challenge,isn't it? The thing is, after receiving the challenge from S2, S1 may just pass it to P1 , for P1 to solve it. At least, I don't understand, why he's unable to do so. This is the main idea of the whole question... |
