[gnutls-dev] starttls

[Andrew McDonald]

--ghzN8eJ9Qlbqn3iT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.=20
>=20
> 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=
=20
> 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.=20
> > 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=20
> calculations, than plain RSA, thus many servers disable it.

Well, the mutt/gnutls patch gives:
const int kx_priority[] =3D
  {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
--=20
Andrew McDonald
E-mail: andrew@mcdonald.org.uk
http://www.mcdonald.org.uk/andrew/

--ghzN8eJ9Qlbqn3iT
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8bV4u/LupyPLe7TYRAqrmAJ9WASBQBaz67AlkdUg5oVCY2fqOSQCdEbcn
yZN0AQUFoaEnKGaPWV5NAYA=
=pwv1
-----END PGP SIGNATURE-----

--ghzN8eJ9Qlbqn3iT--