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

[Matthias Wimmer]

Hi Petr,

thank you for your interesting debugging in this topic. You concluded 
right, that it seems, that Google is using DH parameters, that are 
considered too week by GnuTLS.

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. It might also be, that GnuTLS has started to restrict 
usage of low primes. The GnuTLS project is very concerned about 
security. While I think this is a good thing and I like GnuTLS because 
of that, it sometimes is also hard for developpers and administrators to 
keep track of the requirements of GnuTLS.

> 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. A TLS handshake uses a bunch of different 
cryptographic operations. Basically in your above case there are three 
main cryptographic operations:

1. Diffy Hellman is used to agree on a private key used for operation 3
2. To authenticate the peer and to protect against man in the middle 
attacks the Diffy Hellman key exchange (operation 1 above) is signed by 
a certificate.
3. The key agreed upon in operation 1 is used to encryt/decrypt 
transfered data.

The setting you tried is for specifying the minimum length of the key 
that is agreed upon in operation 1 and used in operation 3.

The thing GnuTLS complains about is not this key (output of operation 
1), but some data used by operation 1 (input of operation 1). There is 
currently no setting for this. - It might even not be possible to 
confiure GnuTLS to accept this, and probably you should also not try to.

I think the way to go is to configure your server in a way, that it uses 
a non-Diffie-Hellman key exchange. jabberd14 + GnuTLS is able to do 
three different types of key exchanges:

1. DSA+DH ("DHE_DSA")
2. RSA+DH ("DHE_RSA")
3. RSA without DH ("RSA")

You should configure the RSA without DH keyexchange to be prefered. You 
should be able to safely disable option 2 compeltely, as option 3 should 
always be available if 2 is. But you should not disable option 1, is 
this is needed if your peer only has a DSA certificate, but no RSA 
certificate.

So you should add the following element to your configuration <kx>RSA 
DHE_DSA</kx> (add it inside the <credentials/> element inside 
jabber.xml). This will configure GnuTLS to do a RSA without DH handshake 
when ever possible (whenever the peer has a RSA certificate available) 
and to only do DSA+DH when the peer only has a DSA certificate. As well 
as you should take care, that your own server does have an RSA 
certificate instead of a DSA certificate.

> 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.

> (2) The server doesn't honor numeric host at tls value.

It does - bit the setting is for something different.



Matthias
-------------- nächster Teil --------------
Ein Dateianhang mit Bin�rdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/x-pkcs7-signature
Dateigr��e  : 3271 bytes
Beschreibung: S/MIME Cryptographic Signature
URL         : http://lists.xmppd.org/pipermail/dev/attachments/20090225/fab80054/attachment.bin