>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
