Null Character Hack Allows SSL Spoofing
eldavojohn writes "Two researchers, Dan Kaminsky and Moxie Marlinspike, came up with exact same way to fake being a popular website with authentication from a certificate authority. Wired has the details: 'When an attacker who owns his own domain — badguy.com — requests a certificate from the CA, the CA, using contact information from Whois records, sends him an email asking to confirm his ownership of the site. But an attacker can also request a certificate for a subdomain of his site, such as Paypal.com\0.badguy.com, using the null character \0 in the URL. The CA will issue the certificate for a domain like PayPal.com\0.badguy.com because the hacker legitimately owns the root domain badguy.com. Then, due to a flaw found in the way SSL is implemented in many browsers, Firefox and others theoretically can be fooled into reading his certificate as if it were one that came from the authentic PayPal site. Basically when these vulnerable browsers check the domain name contained in the attacker's certificate, they stop reading any characters that follow the "\0 in the name.'"
\0\0ps.
Give me Classic Slashdot or give me death!
The lower-cost automated ones don't care. It's all handled by software; at no point in the process (on the CA side) is a human involved. And I'm betting that if the browsers aren't catching it, neither are the CAs.
If not, the CA should not have issued the cert in the first place. Which CA was it?
Go green: turn off your refrigerator.
CAs should be fixed to not allow garbage in the domain. \0 isn't a legal character in DNS protocol, so why should anyone be allowed to register a domain certificate with something that is not allowed.
I miss pascal strings, where the first byte was the length of the string. It had lots of cool advantages in situations like this over C's null terminated strings.
“Common sense is not so common.” — Voltaire
Most CAs will grant you a certificate for anything if you pay them the going rate.
Go do something else for a while. If it were not for you we all would be safer !!
All we have to do is get the CAs to pay attention to the certs they issue, correct?
Uh-oh. We're screwed.
A thousand pounds of wood moving at 300 feet per minute. Don't get in the way.
If you ask me, networks of trust such as PGP are far more difficult to compromise than a central authority. Anything centralized is going to have only a handful of people, who are easy to find, and being private citizens, easily compromised. On the other hand, an integrated cryptographic interface where anyone can vouch for the authenticity of a site, ie; a reputation-based evaluation schema, would be (relatively speaking) more secure.
I have a reputation amongst my friends and family of being "tech savvy". They trust my advice on technology. If that advice could be included in a database an integrated directly into the browser, then others they know that are also "tech savvy" (and trust) could inform their browsing actions much more than a single profit-orientated organization. I could, for example, add "l0pht industries" to my list of trustees, or "Bruce Schneider"... Or even "Rob Malda", and those people would become part of the trust network that my friends would then rely on. This is where the technology should go -- but because it conflicts with monied interests and in a capitalist society it is only the dollar value of a thing that makes our institutions protect it, it probably never will.
Trust is really the central issue, not cryptography. Cryptography enables us to extend our trust relationships into the digital world.
#fuckbeta #iamslashdot #dicemustdie
Two strings walk into a bar.
The first string says to the bartender, "Give me a beer." The bartender turns to the second string and says, "and what about for you?" To which the second string replies, "I would also like a beer#@a9101gb230b81;kajf3#$B89*#()*13!$%#@$"" and goes on and on spewing gibberish.
The bartender, shocked, asks the first string, "What is your buddy's problem?"
The first string answers, "Oh, you'll have to excuse him, he isn't null terminated."
Idiots? I think not. Put yourself in the shoes of programmers in the 70s. Could you have come up with a better idea that did all these?
Sure, today, C strings might seem like a poor decision today, in this age of virtual memory, C++ classes, and sophisticated optimizing compilers. But at the time, C strings were the least bad of the available alternatives.
It's actually rather amusing that people here proclaim Pascal-style strings as the solution to all our woes.
It's because certificates use ASN.1, essentially a modern-day Pascal string, that these vulnerabilities are possible. If certificates instead were encoded using C-style strings, NULLs wouldn't be an issue.
The summary really explained what it's all about, rather than sound like a newspaper who want's you to read more. This is great! Too few summaries are like this. Editors, you should make sure every story get such a good presentation on Slashdot.
Swedish plasma phys. PhD student; MSc EE; knows maths, programming, electronics; finance interest; seeks opportunities
I don't get it.
Isn't this just the same company?
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
Tim Callan, vice president of product marketing at VeriSign, responds (in more detail) to these Black Hat presentations in his new SSL blogpost: https://blogs.verisign.com/ssl-blog/2009/07/busy_day_at_black_hat.php He fills some of the holes that Marlinspike and Kaminsky dug.
Java strings!
32bit signed int, max length 2GB.
That ought to be enough for anybody. ;) If you need longer, there's special buffer classes that can go longer.
The string also chooses between ASCII and Unicode when initialized, (you can manually set char encoding, as well) so properly cleaned/trimmed ASCII strings don't waste any memory. (Except for the 3 bytes extra that go into a length int, instead of a null char - but those 3 bytes also give you an amazing speedup when you need to know the length of the string.)
I believe C# implements Strings in a similar way.