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] > 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] > https://www.ietf.org/mailman/listinfo/uta >
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
