Opened 2 years ago

Closed 23 months ago

Last modified 20 months ago

#6102 defect closed wontfix (wontfix)

SSH sends sends key exchange packets too early

Reported by: crane Owned by:
Priority: normal Milestone:
Component: conch Keywords: SSH, Key Exchange, Difffie-Helmann Protocol
Cc: z3p Branch:
Author: Launchpad Bug:

Description

Normaly an SSH connection should go this way:

  1. Clients wants to connect
  2. Server returns protocol/version
  3. Clients sends a request for key exchange
  4. Server sends keys (diffie-helman protocol)

Now in Conch SSH the server sends the keys without beeing asked:

  1. Clients wants to connect
  2. Server returns protocol/version
  3. Server sends keys (diffie-helman protocol)

and now it's messed up.

Attachments (1)

twisted-0001.patch (1.4 KB) - added by crane 2 years ago.
Patch for this Bug

Download all attachments as: .zip

Change History (12)

comment:1 Changed 2 years ago by DefaultCC Plugin

  • Cc z3p added

comment:2 Changed 2 years ago by crane

  • Keywords SSH Key Exchange Difffie-Helmann Protocol added

comment:3 follow-up: Changed 2 years ago by exarkun

  • Milestone regular-releases deleted

Thanks. The regular-releases milestone is for release automation.

Also, can you please provide a link to the RFC that outlines the behavior you described? Thanks again.

Changed 2 years ago by crane

Patch for this Bug

comment:4 Changed 2 years ago by crane

I will have a look into the RFC at the weekend...
So long I added a patch to the ticket.

I tested it already in my enviroment and it works fine. :)

comment:5 Changed 2 years ago by z3p

Thanks for the patch! What's getting messed up by sending the kexInit() early?

comment:6 in reply to: ↑ 3 ; follow-up: Changed 2 years ago by crane

  • Cc twisted@… added

Replying to exarkun:

Also, can you please provide a link to the RFC that outlines the behavior you described? Thanks again.

http://www.ietf.org/rfc/rfc4419.txt
Have a look onto Part 3 of the RFC

Replying to z3p:

What's getting messed up by sending the kexInit() early?

It's not realy broken but you can determinite with a simple telnet (it's also already included by nmap and metasploit) that you're running a twisted application.

Try it on your own by just telnet'ing your ssh app. You will get after the Version String a complete list of ciphers.

comment:7 in reply to: ↑ 6 Changed 2 years ago by z3p

Replying to crane:

Replying to exarkun:

Also, can you please provide a link to the RFC that outlines the behavior you described? Thanks again.

http://www.ietf.org/rfc/rfc4419.txt
Have a look onto Part 3 of the RFC

Part 3 of that RFC specifies that the KEXINIT from the server has already been sent. The transport-layer RFC is http://tools.ietf.org/html/rfc4253, and I didn't see anything saying that the server needs to wait for the client.

Replying to z3p:

What's getting messed up by sending the kexInit() early?

It's not realy broken but you can determinite with a simple telnet (it's also already included by nmap and metasploit) that you're running a twisted application.

You can also tell because we send 'Twisted' as part of the SSHv2 version string.

comment:8 Changed 2 years ago by crane

  • Cc twisted@… removed

Hey ho,

I figured it out finally.
RFC 4253#section-5 is talking about SSHv1 and SSHv2 and the support for both.
If you have a look onto 5.1 (Old Client, New Server) you will find this:


[...]When compatibility with old clients is not needed, the server MAY send its initial key exchange data immediately after the identification string.


So this is not realy bug. It's a may condition which I did not knew. But it would be nice if Twisted is handling the key exchange like OpenSSH. :)

comment:9 Changed 2 years ago by exarkun

Thanks. It sounds like this ticket should be closed, since Conch is an SSHv2 implementation, not an SSHv1 implementation. Alternatively, perhaps there could be a setting in the implementation that can be toggled to enable this particular bit of SSHv1 compatibility - but I think it should be off by default, since it introduces additional latency into the connection setup.

comment:10 Changed 23 months ago by exarkun

  • Resolution set to wontfix
  • Status changed from new to closed

Okay, we'll go that route. Please feel free to open if any new information or perspectives surface! Thanks again.

comment:11 Changed 20 months ago by exarkun

This seems to be a duplicate of #5409.

Note: See TracTickets for help on using tickets.