[gnutls-dev] starttls

[Andrew McDonald]

On Fri, Feb 15, 2002 at 08:29:40PM +0200, Nikos Mavroyanopoulos wrote:
> The STARTTLS mechanism is vulnerable to man in the middle attack. It's
> easy for somebody to make the client see a different IMAP hello message,
> which does not contain the starttls capability. In IMAPS the
> obvious attack is to send RSTs and make the client think that there
> is no server in this port. 
> 
> In the first case (starttls), if the client continues, without tls, and
> without asking the actual user, then the user's password is sent in the 
> clear. This does not happen in the imaps case, and since these starttls
> replaces imaps, these two methods should be equally strong.

I agree in full. The current implementation as opportunistic encryption
gives some protection against passive attackers when a server
advertises STARTTLS, but it is no way as useful as being able to insist
on a TLS connection.

I think it's time I made some comments on mutt-dev....

> > > The problem with these proprietary implementations is that we cannot
> > > easily check against. 
> > Indeed. It appears that he gets a fatal alert and that it is a problem
> > with both SSLv3 and TLSv1, but that's as much as I've found out.
> An other thing that might help here, is that DHE_RSA works with
> any server i've tried, while the most compatibility problems exist in
> RSA key exchange. The drawback is that DHE_RSA requires more 
> calculations, than plain RSA, thus many servers disable it.

Well, the mutt/gnutls patch gives:
const int kx_priority[] =
  {GNUTLS_KX_X509PKI_DHE_RSA, GNUTLS_KX_X509PKI_RSA, 0};
as the priority, is it worth suggesting he tries swapping them?

Some more info (he's using gnutls 0.3.5 AFAIK):
--X--X--
I've gdb'd a little bit through the thing today, and it seems the
server
is closing the connection quite after getting the first helo.

Activating debugging in the code I get:

mutt_gnutls_socket_setup: 0
Looking up HOSTNAME...
Connecting to HOSTNAME...
*** Keeping ciphersuite: X509PKI_DHE_RSA_3DES_EDE_CBC_SHa
*** Keeping ciphersuite: X509PKI_DHE_RSA_RIJNDAEL_128_CBC_SHA
*** Keeping ciphersuite: X509PKI_RSA_3DES_EDE_CBC_SHA
*** Keeping ciphersuite: X509PKI_RSA_RIJNDAEL_128_CBC_SHA
Handshake: CLIENT HELLO was send [52 bytes]
GNUTLS_ASSERT: gnutls_buffers.c:853
GNUTLS_ASSERT: gnutls_handshake.c:752
GNUTLS_ASSERT: gnutls_handshake.c:880
GNUTLS_ASSERT: gnutls_handshake.c:1757
GNUTLS Error: recv hello (-12)
gnutls_handshake: FATAL_ALERT_RECEIVED

The Assert seems to be just the receive-rotine, which does not like
the connection already terminated.
--X--X--

I haven't looked at the asserts in any detail.

Apparently it works ok with openssl - though it might just be openssl
working round bugs in the server.


Andrew
-- 
Andrew McDonald
E-mail: andrew at mcdonald.org.uk
http://www.mcdonald.org.uk/andrew/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: </pipermail/attachments/20020215/0c9f288e/attachment.pgp>