[37632] in Kerberos
Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted
daemon@ATHENA.MIT.EDU (Rick van Rein)
Tue Aug 23 10:25:54 2016
Message-ID: <57BC5C81.7000506@openfortress.nl>
Date: Tue, 23 Aug 2016 16:24:01 +0200
From: Rick van Rein <rick@openfortress.nl>
MIME-Version: 1.0
To: "'kerberos@mit.edu'" <kerberos@mit.edu>
In-Reply-To: <1471956864.8163.11.camel@redhat.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Hi,
> The HTTP/Negotiate protocol unfortunately does not prevent replay
> attacks, so It can be done if the other endpoint does not use a replay
> cache.
>
HTTP/Negotiate is indeed so sad that we've been working on an
alternative, that is to integrate Kerberos + Diffie-Hellman into TLS.
Then, once you get TLS going for your HTTPS, you would have established
mutual trust and perfect forward secrecy.
This is work in active progress:
- we're removing the last bugs from the GnuTLS-extension on
http://github.com/arpa2/gnutls-kdh
- we hope to integrate the KDH branch into the TLS Pool soon from
https://github.com/arpa2/tlspool/tree/tls-kdh
- we're preparing a HTTPS proxy on
https://github.com/arpa2/tlspool/blob/master/tool/https_proxy.py
- we've got a generic TLS wrapper on
https://github.com/arpa2/tlspool/blob/master/tool/tlstunnel.c
- we'll soon release a successor to
https://tools.ietf.org/html/draft-vanrein-tls-kdh-04
We also have plans for automatic realm crossover including client
identity pseudonymity.
But, alas, this is not ready to roll out yet. We're still finishing the
work as we speak.
Cheers,
Rick van Rein
for the InternetWide.org / ARPA2.net project
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
