Full Disclosure mailing list archives

Previous By Date Next
Previous By Thread Next

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

From: Andrew Auernheimer <gluttony () gmail com>
Date: Wed, 8 Sep 2010 15:02:21 -0500
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/
Previous By Date Next
Previous By Thread Next

Current thread: