Message-ID: <AANLkTi=2cFuFg_Qyy6V_7yTntP-L2LOR82Hz_PS7+=OP@mail.gmail.com>
Date: Wed, 8 Sep 2010 15:52:07 -0400
From: Dan Kaminsky <dan@...para.com>
To: Andrew Auernheimer <gluttony@...il.com>
Cc: Full Disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: [GOATSE SECURITY] Clench: Goatse's way to say
 "screw you" to certificate authorities

Ah, a new password-authenticated DH.  At first glance, this is similar to
SRP (http://srp.stanford.edu/), but the server stores a plaintext password.


Initial thinking -- I'm not convinced that an offline brute force attack
won't work -- the nonce may break rainbow tabling, but it is transmitted via
unauthenticated DH (meaning, an attacker can see it with a mildly active
attack).

Thus the questions:

a) Can an attacker, able to see multiple instances of a client's g2b, g3b,
Pb and Qb, offline-brute-force them to verify the plaintext password?
b) Can an attacker, able to see multiple instances of a server's Pa, Qa and
Ra, offline-brute-force them to verify the plaintext password of an
arbitrary user?

Neither is possible in the present form-based HTTPS system, or SRP.

I'm not saying the above attacks will work.  There are a decent amount of
randomizers in here (both r and s are randomly selected, and never sent).
But the fact that you're saying "even if x-y could be extrapolated..." is
worrisome.

First, x==y, no?  So isn't x-y always 0?
Second, a MITM can clearly control the nonce (remember, at this point the
server pubkey isn't authenticated yet, and the server entirely controls the
nonce), so your statement that "a new nonce is built for every
authentication attempt, and  potentially meaningful data from (x – y) cannot
be generated without multiple attempts on the same shared secret value."
isn't accurate.

Also, multiple attempts on the same shared secret value...what's hard about
that?

Finally, this entire approach needs to stay out of the DOM.  It's not just a
client authentication protocol, it's a server authentication protocol,
meaning you can't trust the foreign UI until the password has authenticated
the content coming in.



On Wed, Sep 8, 2010 at 1:22 PM, Andrew Auernheimer <gluttony@...il.com>wrote:

> Chris,
>
> The cryptographic primitives are long-standing and strong, and the
> source is open! Feel free to pick apart our proposed protocol
> specification!
>
> On Wed, Sep 8, 2010 at 12:15 PM, Christian Sciberras <uuf6429@...il.com>
> wrote:
> > You're expecting us to trust YOU over the Government X?
> >
> > How do we know you're not working for the French Government (seeing
> > how you didn't list it in your conspiracy list)?
> >
> > I love jokes, but this is a bit too late for April's Fool.
> >
> > Cheers,
> > Chris.
> >
> >
> >
> > On Wed, Sep 8, 2010 at 6:59 PM, Tim <tim-security@...tinelchicken.org>
> wrote:
> >>
> >> Hello Andrew,
> >>
> >>> un-tl;dr abstract: SSL is broken. Certificate authorities only exist
> >>> to let the US, Chinese, Turkish, Brazilian etc etc government or
> >>> Russian mob spy on you (whichever is interested first). Well, I guess
> >>> they also exist to line the pockets of assholes who want $10-50 for
> >>> pushing a button. Luckily, we’ve remedied this! We’ve established a
> >>> way that a client, using only standard password authentication, can
> >>> validate a server’s public key and ensure that no third party is
> >>> listening (without the use of a trusted third party such as a
> >>> certificate authority or manual fingerprint verification). Read on for
> >>> a wonderfully simple hack and proof of concept code!
> >>>
> >>> Biggest problem we solve: “Trusted” third parties can’t be trusted and
> >>> criminals or hostile governments are free to launch man in the middle
> >>> attacks. Extensive research in this area has been done by by
> >>> Marlinspike, Dan Kaminsky and Mike Zusman which you really should
> >>> read.
> >> ...
> >>> The whole PKI architecture is broken and cannot be safely relied upon.
> >>> Any system of authentication which relies on a “trusted” third party
> >>> that you have no dominion over is flawed. DNSSEC is only an
> >>> incremental improvement with the same underlying flaw– I may trust the
> >>> ICANN, ISC, NIST, NTIA, the Department of Homeland Security, or
> >>> VeriSign more than the combined ineptitude and maliciousness of every
> >>> current SSL CA, but I still don’t trust them. The whole idea of a
> >>> trust anchor is fallacious.
> >>
> >> I agree with you, the currently used SSL/TLS PKI is fragile and
> >> subvertible.  SSL/TLS itself isn't so bad (less a renegotiation flaw).
> >>
> >>
> >>> We set out to solve this problem in a way that can reconcile three
> >>> realities of security:
> >>>
> >>>     * Users cannot effectively comprehend anything but password
> >>> authentication. They don’t understand key management, and the task of
> >>> getting hundreds of thousands or millions of users to install a client
> >>> certificate or generate a keypair (and not accidentally reveal the
> >>> private key) is a Herculean task that few IT departments want to
> >>> try.
> >>>
> >>>     * Users cannot be trusted to manually verify fingerprints.
> >>> Seriously, they just won’t. Even the ones that perceive themselves as
> >>> sophisticated and security-conscious.
> >>
> >> Ok, maybe.  Let's assume for now that these two assertions are correct.
> >>
> >>
> >>>     * The network is now many times more hostile and open to attack
> >>> than the server.
> >>
> >> Really?  Now compared to when?
> >>
> >>
> >>> HERE'S HOW CLENCH WORKS:
> >>>
> >>>    1. Client connects to server and sends hello.
> >>>    2. Server sends hello back, along with its cert.
> >>>    3. Standard Diffie-Helman key exchange happens in SSL/TLS/SSH
> >>> fashion. Initial handshake is finished, cypher spec is changed, now
> >>> here comes the magic:
> >>>    4. Server sends client the nonce value [ Ticks since unix epoch +
> >>> 16 bytes of random data ]
> >>>    5. Client sends userid/username to server.
> >>>    6. Client types in password, but password is not sent to server.
> >>> Both sides generate a hash.
> >>>       Client generates y, a hash of  [ client password + server's
> >>> public key, as client sees it + nonce from step 4 ]
> >>>       Server generates x, a hash of [ client password + server's own
> >>> public key + nonce from step 4 ]
> >>>    7. Client and server use a symmetric and fair zero-knowledge proof
> >>> to verify that we both have the same hash without revealing the value
> >>> of the hash to one another. Imagine a two pan scale, and a secret of a
> >>> given weight of marbles in a bag. If we both place our bag of marbles
> >>> on the pans at the same time, if they come to an equilibrium we will
> >>> have verified our shared secret without revealing it to one another.
> >>>       For more information on this step please see the excellent paper
> >>> “A Fair and Efficient Solution to the Socialist Millionaires’
> >>> Problem“.
> >>>    8. Upon successful completion of the proof, the server allows the
> >>> session to proceed.
> >>
> >>
> >> This seems awfully similar in concept to the proposed Mutual
> >> Authentication protocol for HTTP.  See:
> >>
> >>  http://www.rcis.aist.go.jp/special/MutualAuth/
> >>
> >> Note that it also uses a shared secret to provide the mutual
> >> authentication and incorporates server (SSL/TLS) certificates into the
> >> hashing process.  I'm not sure on how the details differ, but if you
> >> haven't looked at it yet, you should.  They already have a solid draft
> >> RFC.
> >>
> >>
> >>> THE ROADMAP FROM HERE:
> >>>
> >>> There’s some barriers to implementation on this for HTTPS. Firstly,
> >>> there needs to be a javascript function that returns the current
> >>> public key (or at least the fingerprint) of the https server called to
> >>> load the page in the current DOM.
> >>
> >> You're kidding right?  You plan on relying on JavaScript to implement
> >> the crypto and password checking process?  If you assume someone is
> >> already MitM-ing your SSL/TLS connection, then how do you know the
> >> JavaScript sent to you isn't malicious (backdoored Clench
> >> implementation) to begin with?
> >>
> >>
> >>> There also needs to be some
> >>> mechanism in the GUI of the browser that can’t be mimicked by an
> >>> attacker to inform the client that the current login form implements a
> >>> Clench-like authentication mechanism. Because obviously an attacker
> >>> can just rewrite the form if they’re MitMing and trick the user into
> >>> sending plaintext.
> >>
> >> Yeah, these kinds of protocols must be baked into the browser.
> >> Whether that be through an add-on or native, it needs to be
> >> distributed "a priori".  Don't bother with JavaScript.
> >>
> >> tim
> >>
> >> _______________________________________________
> >> Full-Disclosure - We believe in it.
> >> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> >> Hosted and sponsored by Secunia - http://secunia.com/
> >
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists