[Pkg-gnutls-maint] Help with exim4 #390712, interaction with mobile phones

[Marc Haber]

On Tue, Dec 05, 2006 at 06:43:54PM +0000, James Westby wrote:
> I have had a look at what might be going on here, and I'll start by
> outlining that.
> 
> The error messages reported 
> 
>   TLS recv error on connection ...: A TLS fatal alert has been
>   received.: Bad record MAC
> 
> mean that the alert has come from the other peer, so the phone has found
> a fatal error in the transmission, and doing the only thing it can and
> abondoning the connection (well actually it could do less than that).

I see...

> gnutls (and presumably any TLS client, though I don't know the standards
> at all), will send "Bad record MAC" in two cases, when the MAC on the
> message failed (obviously), and when the decryption failed in any way.
> It does this as any distinction in the reaction to these two cases would
> give information to the attacker.
> 
> So the scenario we have is that exim via gnutls is sending something
> that the phone doesn't like and so the phone pulls the plug on the
> connection.

That sounds reasonable.

> I think it is resonable to assume that the phones all have the same client
> software/library and that is why it seems to affect some phones, but is
> not seen in other clients.

That is reasonable as well.

> There are a few possible scenarios, in no particular order,
> 
>   1) There is a bug in the gnutls encryption/mac implementations so they
>      do send bad packets. 
>   2) There is a bug in the phone software so that they incorrectly
>      decrypt/authenticate the messages.
>   3) There is an interaction between the phone and gnutls that sends one
>      or both of them off in to strange lands. As there is more than one
>      way to do a TLS session it is entirely reasonable that gnutls is
>      exercising a different part of the phone's code to the part that
>      openssl tickles. The reverse applies that the phone might be using
>      a different part of gnutls.
> 
> I guess that noone has the source of the phones' software so that we can
> see how that end works do they?

I am afraid that your guess is correct here.

> As for trying to solve the problem I can't see another way than a full
> dump of the session between the phone and server. Obviously this will
> take a bit of work and involve setting up another instance, or at least
> making sure a different key is in use to normal. At least then we can
> try and see if the packets are sound and see what end the problem is on.

The bug can be reproduced with gnutls-serv, and no client
certificates are in the game.

> However we don't need to go that far yet, as we can see whether the
> problem is related to exim at all using gnutls-serv. If someone
> experiencing the problem can dump the output of the following in to a
> file and mail it to the bug report that would be a good start.
> 
>   $ gnutls-serv -d 11 -p <port> --echo
>   $ gnutls-serv -d 11 -p <port> --http 
> 
> and then point the phone at <port> each time. You wont get a transaction
> but you'll see if the connection fails.

can I run gnutls-serv in the same way as gnutls-cli, so that I can
simply type into the connection? or is echo or http server all I can
get?

A test session is attached as gzipped text file.

>  There are plenty of other options that would be interesting to play
>  around with, see gnutls-serv -h for more details. In particular
>  requiring the client certificate if exim does and trying different
>  combinations of ciphers and macs. Please DO NOT use your real
>  certificates/key files for this as they could not be trusted if the
>  logs from this are public.

I have used a dummy cert on the server, and the phone did not have a
certificate configured.

Can you give more clear advice as which options should be used for
playing around, as I do not have too much TLS knowledge.

> It would also be interesting (but more work) to set up a second instance
> of exim, crank up the debugging output, and play around with parameters
> to disable some ciphers/macs so that we know in which combination the
> problem is.

Unfortunately, exim's GnuTLS code does not have too much TLS debugging
implemented. But since we can reproduce the image with gnutls-serv, I
feel like we don't need to debug exim.

Greetings
MArc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835
-------------- next part --------------
A non-text attachment was scrubbed...
Name: history.gz
Type: application/octet-stream
Size: 4728 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/attachments/20061210/4638bb45/history.obj