Truth Collective

All I need are 200 PS3′s and I can read every piece of data that goes between your browser and any site you visit. Yes, even if it’s “secure.” December 30, 2008, this paper was released detailing a method of forging certificates [wikipedia.com] websites use to establish encrypted communications between themselves and their users. Creating fake certificates has never been much of a difficulty, but forging certificates that are purported to be from trusted organizations [wikipedia.com] has never quite been accomplished with such a capacity. I can explain to you the details involved to some extent, but if you really want the technical details, click on that first link for the paper mentioned above. This paper really marks one of the more significant coups against contemporary methods of trust and security. So, read on, informed reader, read on…

You know that little lock icon that shows up in the bottom right of your browser that you probably never really pay attention to that supposedly indicates you are securely communicating with a website? Other things happen too, depending on your browser, like maybe the area where the URL is changes color or something–I love things that change colors–but whatever happens when your browser’s communicating over an encrypted channel with a website, it’s supposed to make you feel like the data being transferred is secure, right? You’re supposed to trust that your login name, your password, that pin number you typed, your account number, your credit card numbers, that extra three-digit security code, your social security number, and all those other bits that identify you, your money, and any other pieces of information you’d like to consider personal are all somehow only being seen by the computers on the other end of your communication, and possibly the eyes of a few humans who may be processing whatever you submitted, like that deliciously low price of ~$200 you charged for customized M&Ms for your sweetypuss. [Aside: Customized M&Ms are awesome and all, but $200? Really? Buy a bag of M&Ms from the grocery store and draw on them with that wonderfully colored street chalk you can buy at your local hobby store. She won't even notice, I promise.] Anyway, I’m sure you’re shaking your head, having listened to conspiracies and other negative sentiments, thinking your data isn’t really secure. No, you don’t really put all your faith into that secure stuff, right? But you still use it, don’t you? I guess convenience simply outweighs the likelihood you or the company you trust with your information will be targetted. In general, that’s how we operate with most things in our day-to-day lives, but what is the real impact of what I’m talking about?

From the paper linked to above:

As a result of this successful attack, we are currently in possession of a rogue Certification Authority certificate. This certificate will be accepted as valid and trusted by all common browsers, because it appears to be signed by one of the root CAs that browsers trust by default. In turn, any website certificate signed by our rogue CA will be trusted as well. If an unsuspecting user is a victim of a man-in-the-middle attack using such a certificate, they will be assured that the connection is secure through all common security indicators: a “https://” url in the address bar, a closed padlock and messages such as “This certificate is OK” if they chose to inspect the certificate.

This successful proof of concept shows that the certificate validation performed by browsers can be subverted and malicious attackers might be able to monitor or tamper with data sent to secure websites. Banking and e-commerce sites are particularly at risk because of the high value of the information secured with HTTPS on those sites. With a rogue CA certificate, attackers would be able to execute practically undetectable phishing attacks against such sites.

The infrastructure of Certification Authorities is meant to prevent exactly this type of attack. Our work shows that known weaknesses in the MD5 hash function can be exploited in realistic attack, due to the fact that even after years of warnings about the lack of security of MD5, some root CAs are still using this broken hash function.

This is serious stuff. There literally have been years of warnings. But it’s like the 8-year-old who thinks he can fly and jumps off the roof against his mother’s warnings that he cannot, in fact, levitate–I swear, I thought I could…

What’s this HTTP stuff?

But if you really want to know what’s going on and you’re not familiar with this technology, let me take you down to the depths of this security labyrinth to tell you what’s going on. This will get only a little technical, but I’ll keep it completely understandable, I promise. When your browser vomits forth that lock icon, it’s because it’s communicating with a website using a method of communication (i.e. a “standard” or a “protocol”) known as HTTPS. You don’t need to know what it stands for, but just know that you’re typically connecting to websites using HTTP (without the ‘S’), and in HTTP everything sent between your computer and that website is completely unencrypted. That’s not so good, because if I were “listening” to the data being sent out from your computer, I could read every piece of information between you and those websites you’re browsing (and that’s easy, there are several programs that do that for you in Windows; nothing complicated about them; check out Wireshark). The ‘S’ in HTTPS, however, basically means “secure” since it can represent either SSL (Secure Socket Layer) or TLS (Transport Layer Security) which are two ways of “securing” your data by varying forms of encryption. So what do these “secure layer” things do? They differ slightly, but I’ll give you the most fundamental breakdown.

Everything you didn’t want to know about certificates

First, the website sends your computer a certificate, and certificates are basically the most important thing in all of this, so pay close attention to this! What’s the certificate supposed to do? It’s supposed to say to your browser that the website (owned and run by some company) is who the website says it is AND that that website has been verified by a “respected” and/or “well-known” authority. That “well-known” authority is another organization, and this is where the shit gets heavy. There’s a few “authorities” around the world (i.e. multinational corporations) that have been recognized as grantors of certificates (they are called, with such originality, “Certificate Authorities” or CAs)–VeriSign is probably one of the most well-known of these corporations. In order for a website to “properly” enable the use of SSL or TLS, it must purchase its certificate from one of those authorities. That costs money =( (at least in most cases), but the idea is that the company running the website is paying to say they’re able to be trusted by all you fun users out in the world, and that’s very important for this whole thing.

So, what’s in the certificate? A bunch of things, such as the name of the authority (e.g. “VeriSign”), the name of the website receiving the certificate, etc., but that’s not entirely important right now. What is important is that the bits of this stuff (literally, the 0′s and 1′s), are thrown into a “hashing” algorithm (that has nothing to do with marijuana), that condenses it all to a very unique value that is always the same length no matter the input. There are two hashing algorithms commonly employed today: MD5 and SHA-1. SHA-1 is only marginally more secure than MD5 due to the length of its output (SHA-1 produces a 160 bit output whereas MD5 produces 128 bits–to put this into perspective, a computer typically represents a letter, such as the letters that form these words you’re reading, with 8 bits, so SHA-1 produces an ouput 20 letters long and MD5 produces one that is 16 letters long). Hash outputs are often times represented using hexadecimal, which is like decimal (the system we use to count), only with “hexa” prepended–hahahaha… hah.. okay, there’s more to it, but there’s no need to get into here. Here’s more of a visual example taken from Wikipedia for MD5 [link]:

MD5(“The quick brown fox jumps over the lazy dog”)
 = 9e107d9d372bb6826bd81d3542a419d6

Even a small change in the message will (with overwhelming probability) result in a completely different hash, due to the avalanche effect. For example, adding a period to the end of the sentence:

MD5(“The quick brown fox jumps over the lazy dog.”)
 = e4d909c290d0fb1ca068ffaddf22cbd0

And for SHA-1 [link]:

SHA1(“The quick brown fox jumps over the lazy dog”)
 = 2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12

Even a small change in the message will, with overwhelming probability, result in a completely different hash due to the avalanche effect. For example, changing “dog” to “cog”:

SHA1(“The quick brown fox jumps over the lazy cog”)
 = de9f2c7f d25e1b3a fad3e85a 0bd17d9b 100db4b3

Verifying you are who you say you is

You can see the difference in length between the two (excluding the spaces) as well as how each type of input causes a unique output. This is VERY important! Its the uniqueness of the output of a hashing algorithm that makes hashing so important, and this hashing technology is used ALL OVER the Internet. In short, if I write something and send it to you, but first I create a hash of what I wrote (and tell you the hashing algorithm I used, e.g. SHA-1 or MD5) and send the output of that hash along with the message to you, you should be able to take my message, apply the hashing algorithm yourself, and get an output that matches the output I attached to the message I sent you. If those outputs are the same, then you can assume that the message you received has not been corrupted due to electromagnetic interference produced by your amazingly powerful brain–relax, you should only be using 10% of it, anyway, right? Now, let’s apply this knowledge back to those certificates!

As mentioned earlier, the info included in a certificate has a hashing algorithm applied to it, using either MD5 or SHA-1, and a unique output is produced (that output is referred to as a “message digest,” but you don’t have to remember that). That hash output is then encrypted using various other forms of encryption I don’t need to get into (but if you’re curious, it’s called “public key infrastructure” or PKI and/or “assymetric encryption”) and that encrypted hash output is written to the certificate along with all the other information. What is important about the encryption applied to the hash output is that it’s supposed to be encrypted by the authority (e.g. VeriSign) using a super-secret key (like one Tom Cruise would have to penetrate high-security vaults to discover) that only that authority knows! This encrypted hash made with the use of that super-secret key is called a digital signature. What’s the use of that? Well, that encryption method I mentioned I didn’t need to get into is pretty complex, but suffice to say that that now-encrypted hash output (the digital signature) can be decrypted, but only with another key that is like the fraternal twin (that’s the non-identical kind of twins [I had to look it up]) of the super-secret key and everybody is allowed to know who this fraternal twin is–knowing the fraternal twin doesn’t allow you to know the super-secret key, though… complex math stuff I don’t completely understand myself. So, if you can use the publicly known key (the fraternal twin), then you should be able to read that hash output that was encrypted and written to the certificate. Then, you could take all the other info in the certificate, apply the appropriate hashing algorithm to it, and hopefully, get an output that matches that hash output you just decrypted. If everything checks out, then that means that certificate actually came from a trusted authority.

Here’s a complicated yet simple image from http://docs.sun.com/source/816-6154-10/contents.htm#1047358:

If you get it, skip this paragraph, otherwise, here’s a recap: an authority, “VeriSign,” grants a company, “ABC Co.,” a certificate, “ABC Cert.” VeriSign writes out all the proper info on ABC Cert, applies a hashing algorithm to get some crazy hexadecimal value, “crazy-hexadecimal-hash-output,” encrypts that using a complex algorithm and a super-secret key, “Jessica Biel owns Megan Fox,” to get an encrypted output “encrypted-crazy-hexadecimal-hash-output,” and writes that to ABC Cert with the other info. You go to ABC’s site, www.a-whole-lot-of-wonderful-abcs.com, and it sends your browser ABC Cert. Your browser sees ABC Cert was granted to ABC Co. by VeriSign. Your browser already knows who VeriSign is (because almost all browsers come with a pre-packaged list of “trusted” authorities and VeriSign is one of them), so it trusts VeriSign, finds its public key (that whore of a fraternal twin) by looking in its pre-packaged authority list (in most cases), and uses it to decrypt the encrypted hash, “encrypted-crazy-hexadecimal-hash-output.” Your browser then takes a moment to go back and examine the other information in ABC Cert and applies a hashing algorithm to it to get its own hash output. It takes its own hash output and matches it to the just-decrypted “crazy-hexadecimal-hash-output” and finds they’re equal. This means ABC Cert is real, because VeriSign “signed” it, and communications between your browser and ABC Co.’s website www.a-whole-lot-of-wonderful-abcs.com can be trusted. “Great!” you exclaim wildly, so what’s all this about?

Enter Evil Hacker

Say I’m a malicious, evil hacker who wants to read the data going between your computer and www.a-whole-log-of-wonderful-abcs.com (that’s called a “man-in-the-middle” attack; it’s like monkey in the middle, except the monkey touches the ball everytime you throw it and you don’t know it because he’s a cheeky monkey).

image from
http://blog.trendmicro.com/network-security-101-learn-from-the-past/

Well, fortunately for you, after your browser has verified that the certificate, ABC Cert, is valid and trusted, various other things take place that ultimately winds up causing all data sent between your browser and www.a-whole-lot-of-wonderful-abcs.com to be encrypted. Another item included in ABC Cert is actually yet another public key (remember that fraternal twin key thing from earlier?). Only this public key doesn’t belong to VeriSign, rather this key is ABC Co.’s public key. What can you do with that? Well, if you encrypt a message with ABC Co.’s public key, then only ABC Co. can decrypt it, because only ABC Co. knows the key that is the super-secret fraternal twin of the public key. Know what I mean? It’s just like what happened before, when VeriSign encrypted that hash output with its own private key and then your browser decrypted it with a publicly known key, except now its in reverse, which means that only the person who is meant to receive the message is able to decrypt it. Think about that a moment. Now, let’s continue. Your browser can create a special password or passphrase, something like “Jeff likes pancakes,” randomly generated for this one time, and encrypt it using ABC Co.’s public key. If I were a hacker watching communications between your computer and ABC Co.’s website, there’s no way I could decrypt that special passphrase. I don’t know ABC Co.’s super-secret private key! So, when ABC Co. receives that encrypted message, naturally, it will decrypt it and see “Jeff likes pancakes,” which it can use to encrypt all future messages between itself and your computer. And at this point, both your browser and ABC Co. would use that secret passphrase for encryption and decryption, because it’s a lot faster than using those fraternal twin hoodlums.

So, where’s the insecurity? What if I could forge a certificate from VeriSign? “How could you do that? You don’t know VeriSign’s super-secret, private key used to ‘sign’ the hashed output of the certificate’s information, so you can’t modify that hash value and resign it! I would know because I have VeriSign’s public key stored in my computer and that’s what my browser would use to decrypt that hashed output and verify that it’s signed by VeriSign! The only way you could do that is to somehow hack my computer and replace the public key belonging to VeriSign in my browser with your own public key so you could pretend to be VeriSign!” You might say. Then I’d say you shouldn’t get all uppity, because it’s bad for your blood pressure and that causes heart attacks and nobody likes heart attacks–unless you’re the president of some nation that nobody likes and everybody is just hoping you’ll die or something, but people can be such assholes, I swear! Anyway, I won’t have to hack your computer to do this. You see, the flaw in hashing algorithms, at least algorithms like SHA-1 and MD5, is that there is, in fact, more than one input that produces the same output! It’s just that it’s REALLY hard to find another input that produces the same output. We’re talking billions, even trillions, of calculations! But it’s possible. All I need are about 200 Playstation 3s and I can totally hack your Gibson (seriously). If I can “create” a certificate that has the name of an authority your browser trusts on it, like VeriSign, with a hash value encrypted using VeriSign’s super-secret, private key (which I don’t have to know), and the rest of the certificate has the right information embedded in it to allow it to be hashed to the same output that’s encrypted in that encrypted portion (with VeriSign’s private key), then I can pretend to be any website I want. And with today’s technology, the speed of modern day CPUs, the networking capabilities, it’s all very possible and truthfully, not so horribly difficult to manage such a thing, even if I don’t currently have access to so many computers (at the moment).

More so, in the coming years, these hashing algorithms will very likely be even more susceptible as the speed of computers increases, and what would take me 200 PS3s today will likely take me less than half that many in a very short time. So, put on your tinfoil hats… they can read our minds.

But I’m not the one you should look out for. You can trust me! (And Mel Gibson.)

Tags: ps3, security, SSL Share on Facebook