Message-ID: <AANLkTinjJWtwXyV38nCLidoNU260F4WgcGJVeq0=SRwV@mail.gmail.com>
Date: Wed, 8 Sep 2010 15:02:21 -0500
From: Andrew Auernheimer <gluttony@...il.com>
To: Dan Kaminsky <dan@...para.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

Dan,

Upon examining SRP, you are correct. SRP solves the same problem in a
superior manner. lulz

On Wed, Sep 8, 2010 at 2:52 PM, Dan Kaminsky <dan@...para.com> wrote:
> 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/
>
>

_______________________________________________
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