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/
