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

[James Westby]

On (10/12/06 19:06), Marc Haber wrote:
> On Tue, Dec 05, 2006 at 06:43:54PM +0000, James Westby wrote:
[snip]
> > 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.

That is going to make things a lot easier, thanks.

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

It looks that way (I have only used -cli before). As we know that this
is easily reproducible with any gnutls server then we could hack
something together that gave this functionality though

> 
> A test session is attached as gzipped text file.

That's very useful. I have been able to get a few bits out of it. 

The cipher/MAC negotiated are very common, and in fact the pair
negogiated when you hook up gnutls-serv and gnutls-cli, meaning that the
phone isn't using one of less common cipher/MAC combinations.

The phone negotiates to have TLS1.0, whereas gnutls will go for TLS1.1
where possible.

The phone doesn't support compression.

I haven't gone to look at the TLS spec yet to confirm, but my guess is
that it is the last packet of the negotiation/first packet of the
session that is causing the problem, as the trace shows that the alert
is sent by the phone the very next thing after the paramters are
negotiated. This means that it is going to be the first authenticated
packet, if not also the first encrypted one, so it is falling over at
the first hurdle.

The trace shows the data that is transmitted, but I don't fancy getting
out a pen and paper and working out the corresponding plaintext. Without
a trace from the phone side I don't see that there is much else that can
be done, apart from just looking at the code. Perhaps we can rig up a
special debug version of gnutls that spits out the ciphertext/plaintext
pairs and the session key it is using and then verify them using a
different implementation.

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

OK, client certificates would make it more complicated, but as it is the
client that is disconnecting I can see how they would not get in the
way.

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

The fact that it fails with the default setup removes some of the need
for this. However some other testing could be useful. gnutls-serv allows
you to specify the version, ciphers, MACs, and compression algorith to
use, and it would be interesting to see which of these has an effect on
the outcome.

The relevant options are --ciphers, --comp, --kx, --macs and
--protocols. They each take a list of the values that you would like the
server to accept, for instance --protocols TLS1.1 will make the server
only accept TLS1.1. The accepted values for each can be seen in the
output of gnutls-cli --list.

It would be interesting to see what effect each of these options has on
the problem, especially

  1) Can you force the phone to use TLS1.1 by only specifying that? You
     might get "A record packet with illegal version was received." if it
     doesn't support newer than 1.0. Also does the problem still happen
     if you force SSL3.0?
  2) Can you force on compression with --comp DEFLATE LZO? My guess is
     that you can't.
  3) Are any other key exchanges supported? Do they affect the bug?
  4) (The longest I guess) For each member of the cross-product of mac
     and cipher will the phone establish a connection? Does it still
     trigger a bug?

I realise that this might be a lot of work, but it would really help to
narrow down the problem. My guess is that changing pretty much anything
will make it go away, but knowing will help to narrow down the places
where the bug might hide. 

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

I think you are correct here. Your investigations have convinced me that
the problem is in gnutls (or at least related to it), rather than exim,
or exim's use of gnutls. I think you can go ahead and reassign the bug
to gnutls, but it would be great if you can continue to help debug the
problem as you have access to a phone that can trigger it. 

Also my money is on the problem being on the phone's end, but I would
like to prove it somehow. One positive thing (from gnutls' point of
view, rather than the owner of one of these phones) is that openssl
s_client will connect to gnutls-serv fine when they negotiate the same
cipher/MAC/version... Even if it is at the phones end then perhaps a
workaround could be provided in exim to negotiate a different connection
by default or with an option, depending on whether investigations show
that would help. I think it's too early to be looking at that though.

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