Re: [GOATSE SECURITY] Clench: Goatse's way to say "screw you" to certificate authorities

[Andrew Auernheimer <gluttony () gmail com>]

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 () doxpara 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 () gmail 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 () gmail 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 () sentinelchicken 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/