On Sat, Jan 5, 2013 at 10:15 AM, Anders Rundgren <[email protected]> wrote: > On 2013-01-05 16:02, Jeffrey Walton wrote: >> On Sat, Jan 5, 2013 at 9:48 AM, Anders Rundgren >> <[email protected]> wrote: >>> On 2013-01-05 13:51, Jeffrey Walton wrote: >>>> On Sat, Jan 5, 2013 at 6:54 AM, Anders Rundgren >>>> <[email protected]> wrote: >>>>> If two-factor authentication was actually usable (i.e. <keygen> & friends >>>>> were replaced by something mere mortals could understand), these >>>>> kinds of attacks would be much less powerful. >>>> Devil's advocate: what does two factor have to do with setting up a >>>> secure channel based on a public ca hierarchy? >>> My bad, I really meant PKI (which though in my mind should be >>> complemented by a PIN). >> The problem here is conferring trust. We confer trust when we ask a >> CA, "Is this site good" (lot's of hand waiving). We also confer trust >> when we ask DNS for an IP address. We are making security decisions >> based on someone else's hearsay. >> >> Giving the user a certificate does not help with that. >> >> Taking advantage of the pre-existing relationship (apropos a shared >> secret) or using 'a priori' knowledge (the server's expected public >> key) does help with that. One way to achieve the goal is to use a >> Password Authenticated Key Exchange (PAKE), such as Thomas Wu's Secure >> Remote Password (SRP). Another is to use certificate pinning. >> Certificate pinning is similar to SSH's StrictHostKeyChecking. > > Although I'm not proposing this, a client certificate could also serve the > same > purpose without requiring a shared secret. I.e. the certificate could contain > a certificate extension holding a trust list. If you have a mobile device > that's > an easy thing to do because it doesn't require any new auth protocols. > We just have to nuke <keygen> :-) No, that's interesting (the extension). I never thought of it, but I think its a good idea. It turns two key distribution problems (distribute expected server public key, distributes user key) into to a single problem.
By the way, TurkTrust was caught issuing MitM certificates - the same crap that TrustWave issued. They are called 'interception' certificates. Dr. Matt Green has some good reading on them: http://blog.cryptographyengineering.com/2012/03/how-do-interception-proxies-fail.html. I wonder if Mozilla will elide their responsibility again. TrustWave should have been prosecuted under the CFAA. Breaking the secure channel is clearly within purview of the CFAA. It's too bad federal law is "opt-in" for US corporations. Jeff >> If we know whom we should be speaking with, it does not matter what >> the CA or DNS answers. >> >>> Unlike passwords, PKI-based client-authentication doesn't give >>> the fake site anything they could use for accessing your account >>> on the real site. "Phish-safe". >> Agreed. Never apply your secret to unvalidated systems - it does not >> matter if its a GnuPG ElGamal key or a foreign website. >> >>>>> On 2013-01-05 05:11, Jeffrey Walton wrote: >>>>>> Hi All, >>>>>> >>>>>> >From Dr. Geer on the Cryptography mailing list >>>>>> (http://lists.randombit.net/mailman/listinfo/cryptography). >>>>>> >>>>>> Its another reason to pin your certificates. Stop accepting the >>>>>> "broken" as the "norm". >>>>>> >>>>>> Not everyone is a bank who can be irresponsible and pass losses caused >>>>>> by mistakes onto share holders in pursuit of profits (re: risk >>>>>> acceptance). In some cases, people's lives depend upon it. >>>>>> >>>>>> +1 to Google and AOSP for recognizing the problem, and taking action >>>>>> early. I owe the security team a beer. >>>>>> >>>>>> Jeff >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: <[email protected]> >>>>>> Date: Fri, Jan 4, 2013 at 6:40 PM >>>>>> Subject: [cryptography] another cert failure >>>>>> To: [email protected] >>>>>> >>>>>> you may have already seen this, but >>>>>> >>>>>> http://www.bbc.co.uk/news/technology-20908546 >>>>>> >>>>>> Cyber thieves pose as Google+ social network >>>>>> >>>>>> The lapse let cyber thieves trick people into thinking they were >>>>>> on Google+ Continue reading the main story Related Stories >>>>>> Cyber-warriors join treasure hunt Insecure websites set to be named >>>>>> Warning over web security attack Web browser makers have rushed to >>>>>> fix a security lapse that cyber thieves abused to impersonate Google+ >>>>>> >>>>>> The loophole exploited ID credentials that browsers use to ensure >>>>>> a website is who it claims to be. >>>>>> >>>>>> By using the fake credentials, criminals created a website that >>>>>> purported to be part of the Google+ social media network. >>>>>> >>>>>> The fake ID credentials have been traced back to Turkish security >>>>>> firm TurkTrust which mistakenly issued them. -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
