Hi.
Thanks for the reply.
Your expertise is clearly better than mine, and your help is much appreciated.
Im sorry for removing some "sensitive" information, but it is company policy.
SFTP Server is using maverick sshd library (java based).
Wireshark Output:
Following is Packet no. 264
----------------------------------------------------------------------------
SSH Protocol
SSH Version 2 (encryption:aes128-cbc mac:hmac-sha1 compression:none)
Packet Length: 148
Padding Length: 8
Key Exchange
Msg code: Diffie-Hellman Key Exchange Reply (31)
Multi Precision Integer Length: 129
DH modulus (P): 00ffffffffffffffffc90fdaa22168c234c4c6628b80dc1c...
Multi Precision Integer Length: 1
DH base (G): 02
Padding String: da7d2dba194ca285
----------------------------------------------------------------------------
No. Time Source Destination Protocol Length
Info
260 117.341377 <SERVER> <CLIENT> TCP 54
EtherNet-IP-1 > 43161 [ACK] Seq=322 Ack=838 Win=7424 Len=0
264 117.491396 <SERVER> <CLIENT> SSHv2 206 Server:
Diffie-Hellman Key Exchange Reply
265 117.509038 <CLIENT> <SERVER> TCP 60 43161 >
EtherNet-IP-1 [ACK] Seq=838 Ack=474 Win=8064 Len=0
266 117.509231 <CLIENT> <SERVER> TCP 60 43161 >
EtherNet-IP-1 [FIN, ACK] Seq=838 Ack=474 Win=8064 Len=0
267 117.509292 <SERVER> <CLIENT> TCP 54
EtherNet-IP-1 > 43161 [FIN, ACK] Seq=474 Ack=839 Win=7424 Len=0
272 117.527293 <CLIENT> <SERVER> TCP 60 43161 >
EtherNet-IP-1 [ACK] Seq=839 Ack=475 Win=8064 Len=0
Vennlig hilsen
Daniel Bjørnådal Johansen
IT Konsulent, ITO Card Services
daniel.johan...@evry.com
T +47 75 12 81 61 M +47 909 15 267
-----Opprinnelig melding-----
Fra: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
På vegne av Dave Thompson
Sendt: 26. april 2012 23:21
Til: openssl-users@openssl.org
Emne: RE: SSH/SFTP - DH_GEX group out of range
>From: owner-openssl-us...@openssl.org On Behalf Of Johansen Daniel
>Sent: Wednesday, 25 April, 2012 08:13
>Having this weird problem when connecting to a SFTP server.
>OpenSSH_5.9p1, OpenSSL 1.0.1 14 Mar 2012
<snip>
>debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
>debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP DH_GEX group out of range:
>1024 !< 1020 !< 8192 Couldn't read packet: Connection reset by peer
>As you can see in the end, the error: DH_GEX group out of range:
>1024 !< 1020 !< 8192 shows.
>When we grabbed the package and decoded it in Wireshark, we found that
>the key being sent was 1032 bit long, not 1020 as the client debug
>indicates.
It is the group modulus p being sent here; that is a parameter not a key. (The
public keys are the two y=g^x values which SSH names e and f sent in GEX_INIT
and GEX_REPLY respectively.)
What exactly is 1032 bits? A full-1024-bit p will be encoded and sent by SSH as
mpint with 4 octet length prefix plus 129 octets of value; 129 octets is 1032
bits and 133 octets is 1064 bits, though Wireshark shows (and IP/TCP
transports) only whole octets.
The seemingly 'extra' octet is because SSH (like ASN.1) encodes bignums as
signed two's-complement, even though the numbers in public-key crypto are
actually always positive.
If the client is correct that p is 1020-bits magnitude, it should have been
encoded as 4+128 = 132 octets. But if your server actually generated a
1020-bit-magnitude p, that is likely a bug, and it may be mis-encoding also.
What exactly does the encoded p look like in Wireshark, at least the length and
first 4 or so octets of value?
>And the request for terminating the session is done by the client, not
>the server.
But the client is reporting "Connection reset"? That doesn't really make sense.
What exactly is the sequence? Is the client sending FIN or RST (or both!)?
Immediately or after sending anything else, like an alternate KEX attempt, or
receiving anything else, like I can't see any candidate?
Actually, if you have a reasonably small capture of this (not containing too
much other clutter, and definitely not any sensitive data) you could post it.
>Since im not in control of the client, only the server, I can only say
>what the customer tell me.
What is the server software? You censored it from your log, which suggests it's
custom or proprietary, so if you can't tell details can you at least say how it
implements SSH e.g. using a library
or component or custom code? Does it generate DH parameters
on the fly, or have them preconfigured/stored and if so can you post them, or
are they (supposed to be) standard e.g. Oakley?
>Operating system is unix/linux but exactly which, I don't know.
>I can mention that this error only occurs with this customer, and no
>one
else.
Do other clients use the same sftp client software, and exact version? It might
be that only some client(s) or version(s), perhaps a recent or snapshot one or
patch, enforces 1024 as the minimum instead of allowing the server to
'downgrade'.
(1024 is a SHOULD in 4419 not a MUST. But the sizes <1024 that people tend to
use, like 512 and 768, are no longer secure and should not be used, so software
that prevents them is a reasonable feature.)
>And the customer claims that this error only occurs towards us, and no
>one
else.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
