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 <[email protected]> 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 <[email protected]> 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/
