Message-ID: <AANLkTim4hD_6gS5K=2pOuRJb6pnLJO4squ8x4S7ieB8O@mail.gmail.com>
Date: Wed, 8 Sep 2010 12:22:43 -0500
From: Andrew Auernheimer <gluttony@...il.com>
To: Christian Sciberras <uuf6429@...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

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/

Powered by blists - more mailing lists