This is great stuff. Thanks for sharing!
Yaron
On 08/06/2014 11:55 PM, Will Sargent wrote:
Following the specific text example...
I recently had to put together a web services client using JSSE (Java's
TLS implementation), and wrote down the experience. Hostname
verification was a significant piece of it, but even more significant
was just the work needed to find out which signature algorithms and
cipher suites could be considered "good":
http://tersesystems.com/2014/01/13/fixing-the-most-dangerous-code-in-the-world/
http://tersesystems.com/2014/03/20/fixing-x509-certificates/
http://tersesystems.com/2014/03/22/fixing-certificate-revocation/
http://tersesystems.com/2014/03/23/fixing-hostname-verification/
http://tersesystems.com/2014/03/31/testing-hostname-verification/
http://tersesystems.com/2014/07/07/play-tls-example-with-client-authentication/
I hope this gives some feedback on what it's like to try and do TLS
"right" from an end implementer's perspective.
Will Sargent
Consultant, Professional Services
Typesafe <http://typesafe.com>, the company behind Play Framework
<http://www.playframework.com>, Akka <http://akka.io> and Scala
<http://www.scala-lang.org/>
On Tue, Aug 5, 2014 at 9:43 PM, Ilari Liusvaara
<[email protected] <mailto:[email protected]>> wrote:
On Mon, Aug 04, 2014 at 09:50:35AM +0200, Leif Johansson wrote:
> On 2014-08-01 15:43, Ilari Liusvaara wrote:
> > Here are some attacks that don't seem to be covered (maybe because
> > these aren't relevant):
> >
> > - Not properly checking certificates.
> >
> > - Relying on broken channel binding
> >
> > - Triple Hanshake
> >
> > Regarding DTLS, DTLS 1.0 should behave like TLS 1.1 w.r.t. attacks,
> > except that RC4 attacks aren't applicable because the whole
algorithm
> > is disallowed.
>
>
> Can you suggest specific text for these? This helps the WG judge the
> merit of your proposal.
>
Some quickly written text (I hope I got the references right):
I put the broken channel binding together with triple handshake, as
those
are closely related.
Missing or incomplete certificate validation
As shown in [MOST-DANGEROUS-CODE], Many non-browser clients either
completely omit certificate validation or do incomplete validation
(e.g. not validating server hostname or not validating the trust
anchor), leading to those clients being vulernable to Man-in-the-Middle
attacks.
[MOST-DANGEROUS-CODE] M. Georgiev, S. Iyengar, S. Jana, R. Anubhai,
D. Boneh, and V. Shmatikov,
"The most dangerous code in the world: validating SSL certificates
in non-browser software",
In proceedings of ACM CCS '12, pp. 38-49, 2012
Triple Handshake
The triple handshake [TRIPLE-HS] enables attacker to cause two TLS
connections to share keying material. This enables multitude of attacks,
E.g. Man-in-the-Middle, breaking safe renegotiation and breaking channel
binding via TLS-EXPORTER [RFC5705] or TLS-UNIQUE [RFC5929].
[TRIPLE-HS] Bhargavan, K., Delignat-Lavaud, A., Fournet, C.,
Pironti, A., and P. Strub,
"Triple Handshakes and Cookie Cutters: Breaking and Fixing
Authentication over TLS",
IEEE Symposium on Security and Privacy, to appear , 2014.
-Ilari
_______________________________________________
Uta mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
