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

[James Westby]

On (13/12/06 13:41), Marc Haber wrote:
> On Tue, Dec 12, 2006 at 07:23:11PM +0000, James Westby wrote:
> > On (10/12/06 19:06), Marc Haber wrote:
> > > 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
> 
> Do you want me to file a wishlist request for that functionality?

If you want it then go ahead and do it. I for one think it might be a
good addition, and could be very useful when debugging some protocols.

> > 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.
> 
> Error in handshake
> Error: A record packet with illegal version was received.

The phone doesn't support 1.1 then, that's OK.

> > Also does the problem still happen if you force SSL3.0?
> 
> no, with SSL3.0, it works:
> - Version: SSL 3.0
> - Key Exchange: RSA
> - Cipher: AES 128 CBC
> - MAC: SHA
> - Compression: NULL
> and no error message of gnutls-serv before the client eventually times
> out because no banner was received

Ok, this seems OK then, as the error happened before this point before.
It seems that at least a way to make -serv send something before waiting
to echo would be useful, but full control with the typing method would
do even better.

> >   2) Can you force on compression with --comp DEFLATE LZO? My guess is
> >      that you can't.
> 
> Error in handshake
> Error: Could not negotiate a supported compression method.

OK, It's a shame we can't find out whether compression of TLS1.1 have an
effect on the bug.

> >   3) Are any other key exchanges supported? Do they affect the bug?
> 
> --macs rmd160 md5 does not give any error message. So I'd say the
> problem is SHA-1 MAC when used on a TLS 1.0 connection.

It looks that way. As there is no way to use AES without SHA1 then that
can't be ruled out, but you have shown it to be cipher/MAC dependent,
which is very useful.

> > 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. 
> 
> I'll happily do that.

Thanks for your help so far, it's been very useful.

> 
> > 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.
> 
> Unfortunately, both exim and gnutls-serv fall back to ARCFOUR as
> cipher when I forbid SHA-1 as MAC, thus reducing security more than I
> am willing to accept for the exim package, so modifying exim is kind
> of out of the question.

That's fine, it's obviously your call, but I think it's the right one.

I fear though that for etch users of these phones are going to have to
find a workaround for the problem. Assuming that there is a bug in
GnuTLS there's no guarantee we can find it, let alone fix it, before the
release.

I think the only debugging that we can do from here is to verify the
MACs and then the plaintext/ciphertext pairs of one of the sessions.
This is going to be a bit of work, but I'll look in to setting up a
debug copy of the library soon.

There's one more thing that I have been meaning to mention wireshark
(ethereal) has some support for watching SSL handshakes. It might be
worth checking that it's idea of what is going on is the same as
GnuTLS'. It doesn't tell us what the phone thinks, but it is a quick
sanity check.

Thanks for your help,

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