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

[James Westby]

On (05/12/06 16:16), Marc Haber wrote:
> Hi,
> 
> I have an issue with exim4 that can, IMO, clearly be traced to GnuTLS.
> Please refer to #390712 for more information.
> 
> The original reporter, Stian Jordet <stian at jordet.net>, has a
> SonyEricsson P990, and Marc Fargas <telenieko at telenieko.com> reports
> the same issue with a Nokia E60 (Software Version 2.0618.06.05
> (RM-49)).
> 
> I did some testing with Marc, and his phone was perfectly able to do
> STARTTLS with an exim compiled against OpenSSL. Both exims were build
> on the same Debian unstable system by myself, so I am reasonably sure
> that we have a GnuTLS issue here.
> 
> Marc is willing to debug with him, and I can also put you in contact
> with a close friend of mine who is plagued with the same issue with
> his new mobile phone against his exim installation.
> 
> If there is anything that I can do to help, please get in touch with
> me, and by all means keep me posted.
> 

Hi,

Thanks for the report.

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

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

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?

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.

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

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.

Thanks,

James

-- 
  James Westby   --    GPG Key ID: B577FE13    --     http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256