http://www.itwire.com/business-it-news/open-source/62641-crypto-freebsd-playing-catch-up-says-de-raadt
________________________\QUOTE__________ Well, what you are pointing out is that a CA is a single point of failure -- Something actual security conscious engineers avoid like the plague. What you may not realize is that collectively the entire CA system is compromised by ANY ONE of those single points of failure because any CA can create a cert for ANY domain without the domain owner's permission. See also: The Diginotar Debacle. [wikipedia.org] The thing is, nobody actually checks the the cert chain, AND there's really no way to do so. How do I know if my email provider switched from Verisign to DigiCert? I don't, and there's no way to find out that's not susceptible to the same MITM attack. So, let's take a step back for a second. Symmetric stream ciphers need a key. If you have a password as the key then you need to transmit that key back and forth without anyone knowing what it is. You have to transmit the secret, and that's where Public Key Crypto comes in, however it doesn't authenticate the identity of the endpoints, that's what the CA system is supposed to do. Don't you see? All this CA PKI system is just moving the problem of sharing a secret from being the password, to being which cert the endpoint is using -- That becomes the essential "secret" you need to know, and it's far less entropy than a passphrase! At this time I would like to point out that if we ONLY used public key crypto between an client and server to establish a shared secret upon account creation, then we could use a minor tweak to the existing HTTP Auth Hashed Message Authentication Code (HMAC) proof of knowledge protocol (whereby one endpoint provides a nonce, then the nonce is HMAC'd with the passphrase and the unique-per-session resultant hash provides proof that the endpoints know the same secret without revealing it) to secure all the connections quite simply: Server and client exchange Nonces & available protocols for negotiation, the nonces are concatenated and HMAC'd with the shared secret stored at both ends, then fed to your key-stretching / key expansion system AND THAT KEYS THE SYMMETRIC STREAM CIPHER SIMULTANEOUSLY AT BOTH ENDS so the connection proceeds immediately with the efficient symmetric encryption without any PKI CA system required. PKI doesn't really authenticate the endpoint, it just obfuscates the fact that it doesn't by going through the motions and pretending to do so. It's a security theater. SSL/TLS and PKI are essentially the Emperor's New Secure Clothes. At least with the shared secret model I mention above, there's just that one-time small window of PK crypto for secret exchange at worst (failing to intercept account creation means no MITM) and at best you would actually have the CHANCE to go exchange your secret key out of band -- Visit your bank in person and exchange the passphrase, etc. then NO MITM could intercept the data. HTTP Auth asks for the password in a native browser dialog BEFORE showing you any page to login (and it could remember the PW in a list, or even generate them via hashing the domain name with a master PW and some salt so you could have one password for the entire Internet). That's how ALL security should work, it ALL relies on a shared secret, so you want the MOST entropic keyspace not the least entropic selection (which CA did they use). If you're typing a password into a form field on a web page, it's ALREADY game over. Do this: Check the root certs in your browser. For Firefox > Preferences > Advanced > Certificates > View. See that CNNIC one? What about the Hong Kong Post? Those are Known bad actors that your country is probably at cyber war with, and THEY ARE TRUSTED ROOTS IN YOUR FUCKING BROWSER?! Not to mention all the other Russian ones or Turkish, etc. ones that are on the USA's official "enemy" list. Now, ANY of those can pretend to be whatever domain's CA they want, and if your traffic bounces through their neck of the woods they can MITM you and you'll be none the wiser. Very few people if anyone will even inspect the cert chain which will show the big green bar, and even if they do they really can't know whether the domain has a cert from these trusted CAs just to comply with that country's laws or whatever. So, I would put it to you this whole "Heartbleed" business is totally overblown. If you're NOT operating under the assumption that the entire TLS/SSL Certificate Authority / Public Key Infrastructure isn't purposefully defective by design and that all your keys are bogus as soon as they are created, then you're just an ignorant fool. Heartbleed doesn't change jack shit for me. My custom VPN uses the HMAC key expansion protocol mentioned above. I don't do ANYTHING online that I wouldn't do on the back of a post-card, because that's the current level of security we have. I would STRONGLY encourage you to NOT TRUST the IETF or ANY security researchers who think the SSL/TLS system was ever a secure design. It was not ever secure, and this has been abundantly clear to everyone who is not a complete and utter moron. Assuming that the entire web security field isn't completely bogus is bat-shit insane. _______________________________\UNQUOTE_________________ Best A. Mani A. Mani [Last_Name. First_Name Format] CU, ASL, AMS, ISRS, CLC, CMS HomePage: http://www.logicamani.in Blog: http://logicamani.blogspot.in/ -- -- Mailing list guidelines and other related articles: http://lug-iitd.org/Footer --- You received this message because you are subscribed to the Google Groups "Linux User Group @ IIT Delhi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
