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

[Christian Sciberras <uuf6429 () gmail com>]

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/