[xmppd-dev] Dialback to gmail.com failes: DH prime sent by server is to short

[Petr Pisar]

On Wed, Feb 25, 2009 at 03:58:04PM +0100, Matthias Wimmer wrote:
> Petr Pisar schrieb:
>> While debugging I discovered that the right reason is:
>> mio_tls.cc:1184 TLS handshake failed for fd #17: The Diffie Hellman prime 
>> sent
>> by the server is not acceptable (not long enough).
>> So I guess Google guys lowered Diffe-Hellman prime to low for my GnuTLS.
>
> Not sure yet.

I'm pretty sure I didn't changed anything regarding jabberd14 or gnutls. Now
looking deeply into logs, it hit me: Google haven't used any encryption
before. All s2s connection have been logged as unencrypted without
certificate.

Now when I'm able to connect to Google in encrypted way I see:

(s2s): connected to gmail.com (encrypted: 128 b (TLS1.0/RSA_AES_128_CBC_SHA1),
X.509 cert is invalid, auth=db, stream=XMPP1.0, compression=NULL)
(s2s): connection from gmail.com (unencrypted, no cert, auth=db,
stream=preXMPP, compression=none)

They seem to have enabled encrypted incoming connections probably. The
outgoing ones are still unencrypted.

>> I tried to adjust TLS configuration for this host using <host 
>> name="gmail.com"
>> tls="128"/> and other numbers, but it did not help. The only think which
>> helped was to switch off TLS for gmail.com completely <host 
>> name="gmail.com" tls="no"/>.
>
> Well. This setting does not affect the accepted Diffe-Hellman prime 
> accepted by GnuTLS.

So, what does it mean? Minimal RSA key length?

>
> 1. DSA+DH ("DHE_DSA")

jabber.xml(5) talks about DHE_DSS, it is accepted exactly in this form by
server.

>
>> Thus I guess I found two bugs:
>> (1) Server logs that dialback from other server timed out. But the real 
>> reason
>> is TLS negotion failed and the failed connection was not closed, thus it
>> warns about lot of opened connections.
>
> I know that this is not the optimum to log this. But the problem is, that 
> this are two things. You get the "invalid" log message for an outgoing 
> connection. But the problem TLS connection problem happens on the incoming 
> dialback connection. For the server this is just a connection it does not 
> accept, it does not know that it belongs to a outgoing connection it tries 
> to establish. I see no way to relate this two things to each other.
> To get better error messages here the foreign server (google in this case) 
> would have to pass the reason of the error back with the rejection of the 
> originating connection - but this is not specified by the XMPP protocol. 
> There is only the "invalid" it can pass back.
>
I see.

Thank you for comprehensive explanation.

-- Petr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.xmppd.org/pipermail/dev/attachments/20090225/9d33c973/attachment.pgp