Message-ID: <AANLkTinVQLLt-JNRvjLPSBK9mV1h3=AO15YL+sGjZ2My@mail.gmail.com>
Date: Wed, 8 Sep 2010 12:24:10 -0500
From: Andrew Auernheimer <gluttony@...il.com>
To: Tim <tim-security@...tinelchicken.org>
Cc: Full Disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: [GOATSE SECURITY] Clench: Goatse's way to say
 "screw you" to certificate authorities

Tim,

Absolutely, the risk of javascript being rewritten is highlighted
below-- which is why there needs to be something outside the reference
implementation below.

While we may be similar to other proposed ideas, our implementation is
unique and we are rapidly developing a PAM module at this moment. We
are not limited to https.

On Wed, Sep 8, 2010 at 11:59 AM, 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/

Powered by blists - more mailing lists