×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Null Character Hack Allows SSL Spoofing

timothy posted more than 4 years ago | from the cannot-anticipate-all-evil dept.

Security 280

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.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

280 comments

\0wned (4, Funny)

Hatta (162192) | more than 4 years ago | (#28885851)

\0\0ps.

Re:\0wned (5, Funny)

Lord Fury (977501) | more than 4 years ago | (#28885893)

I don't get it, you didn't post anything.

Re:\0wned (5, Funny)

LucidBeast (601749) | more than 4 years ago | (#28885983)

I just came to say Moxie Marlinspike is just about the coolest name I've ever seen...

Re:\0wned (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#28886163)

I just came in Moxie Marlinspike. Bareback ftw.

Re:\0wned (1, Informative)

Anonymous Coward | more than 4 years ago | (#28886523)

Of course, you know that Moxie is a guy....

Re:\0wned (1, Funny)

Anonymous Coward | more than 4 years ago | (#28886441)

Better than Moxie CrimeFighter (daughter of Penn Jillette)?

Or, given the subject, Robert'); DROP TABLE Students; -- (aka Little Bobby Tables [xkcd.com])...

Are CA's that stupid? (1, Interesting)

Anonymous Coward | more than 4 years ago | (#28885877)

Would a CA really grant a certificate for paypal\0.badguy.com ?

Re:Are CA's that stupid? (4, Insightful)

graphicartist82 (462767) | more than 4 years ago | (#28885913)

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.

Re:Are CA's that stupid? (5, Insightful)

OrangeTide (124937) | more than 4 years ago | (#28885923)

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.

Re:Are CA's that stupid? (0)

Anonymous Coward | more than 4 years ago | (#28885999)

By which you mean limiting all strings to 256 characters? Or needing a dedicated string API to keep the length synchronized with the actual string?

Re:Are CA's that stupid? (3, Informative)

Onymous Coward (97719) | more than 4 years ago | (#28886335)

\0 isn't a legal character in DNS protocol

Say, that's a pretty good idea. Start by limiting the input to DNS-valid characters.

Geez.

For anyone who thinks "Well, I guess there might be some bad CAs out there," please keep in mind that it only requires one of the CAs (or their delegates) that your browser recognizes to make a mistake and you're hosed. Now go look at how many CAs are listed in your browser.

Damnit, it's time to flog this again:

Every time this topic comes around I feel like I should share this thing I've run across:
  Perspectives. [cmu.edu]

Basically, "network notaries". Decentralization of (a kind of) authentication.

This is one thing that makes self-signed certs viable for a popular audience.

Re:Are CA's that stupid? (1)

bluefoxlucid (723572) | more than 4 years ago | (#28886349)

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.

It's called an asciiz string and the CPU has instructions to handle them specifically in many cases. It's a very primitive data structure.

Re:Are CA's that stupid? (1)

CarpetShark (865376) | more than 4 years ago | (#28886509)

CAs should be fixed to not allow garbage in the domain. \0 isn't a legal character in DNS protocol

If it's not allowed in DNS protocol (which wouldn't surprise me, unless punicode-escaped), then primarily, it is the client's job to defend against it. Even if all legitimate DNS information sources are checked, the client shouldn't assume that the next DNS request will go to or be replied to from a real server.

Re:Are CA's that stupid? (1)

cnettel (836611) | more than 4 years ago | (#28886837)

But this \0-terminated string is never sent to DNS. It's rather that, at some point, the actual domain of the certificate is retrieved. That is compared against the domain you think you are visiting. And behold, you can spoof any domain. However, for this to be succesful, you should poison the DNS in some way, as well.

Re:Are CA's that stupid? (4, Insightful)

Spad (470073) | more than 4 years ago | (#28885935)

Most CAs will grant you a certificate for anything if you pay them the going rate.

Re:Are CA's that stupid? (0)

Anonymous Coward | more than 4 years ago | (#28886197)

Which translates to: we shouldn't trust CAs anymore.

Re:Are CA's that stupid? (0)

Anonymous Coward | more than 4 years ago | (#28886475)

You really don't get it do you. Reread TFS.

Re:Are CA's that stupid? (1, Insightful)

CarpetShark (865376) | more than 4 years ago | (#28886473)

Would a CA really grant a certificate for paypal\0.badguy.com?

Cheap certificate services are automated, so yes.

The question is... why in hell is firefox treating strings from the net as if they're already escaped?

Re:Are CA's that stupid? (1)

Brian Gordon (987471) | more than 4 years ago | (#28886529)

I think it's the actual null character, not the string backslash-zero

Re:Are CA's that stupid? (1)

CarpetShark (865376) | more than 4 years ago | (#28886603)

Ah, yeah, I guess you're right. Misleading article :/

Re:Are CA's that stupid? (2, Insightful)

clone53421 (1310749) | more than 4 years ago | (#28886851)

Well, it did say "the null character \0". That seems pretty obvious. It's the null character, and we're calling it \0 because it's unprintable.

Is the null character valid in a domain name? (4, Interesting)

characterZer0 (138196) | more than 4 years ago | (#28885915)

If not, the CA should not have issued the cert in the first place. Which CA was it?

Re:Is the null character valid in a domain name? (1, Informative)

Anonymous Coward | more than 4 years ago | (#28886047)

The CA issued a malformed Cert. The browser (firefox) did not catch the malformation. Who is to blame? Both I would think.

When C Strings Attack! (3, Insightful)

Tyler Eaves (344284) | more than 4 years ago | (#28885941)

*sigh* Why is anyone still using null-terminated strings? It's almost a shame that Pascal didn't become dominant...many of these bugs would simply not occur.

Re:When C Strings Attack! (1)

tylersoze (789256) | more than 4 years ago | (#28886081)

Yeah and you'd have the Twitter-like limitation of all strings being no more 255 characters long. :) Of course, I'm sure they would've eventually implemented a UTF-8 style thing where you'd examine the initial bits to determine the byte size of the initial string length indicator.

Re:When C Strings Attack! (1)

QuoteMstr (55051) | more than 4 years ago | (#28886121)

If Pascal strings had become standard, we'd be dealing with 256-bytes length limits all over the place as Pascal only use eight bits to store the string length. I imagine there'd be attacks that involved making the length counter overflow. We'd still have bugs, but different bugs.

Re:When C Strings Attack! (1)

Gramie2 (411713) | more than 4 years ago | (#28886605)

Or they would have done what Delphi (Pascal-based) did, in fact, do: strings are reference-counted and copy-on-write and can contain any characters. They can also be treated as c-type strings when necessary (called a PChar, meaning a Pointer to an array of char), because assigning to a string automatically adds in a null byte at the end. But you can still get around the string handling and screw things up if you try hard enough.

Re:When C Strings Attack! (4, Funny)

Anonymous Cowar (1608865) | more than 4 years ago | (#28886245)

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."

Re:When C Strings Attack! (0)

Anonymous Coward | more than 4 years ago | (#28886311)

then we'd have the bug that you could buy a certificate for paypal\0.com.
i'm getting tired of mindless criticism of c bugs.

Re:When C Strings Attack! (-1)

CarpetShark (865376) | more than 4 years ago | (#28886541)

This is NOT a null-terminated string. This is an ESCAPE CODE terminated string. You know, like the escape codes a compiler interprets. In other words, it's treating stuff from the net as "source code" (albeit data and not instructions) to compile. Firefox is completely fucked up sometimes. Thankfully it's still not as bad as IE.

Re:When C Strings Attack! (2)

clone53421 (1310749) | more than 4 years ago | (#28886749)

Um, that's the actual null character, not the backslash character followed by the numeral zero. Your brain was supposed to unescape it. The string contains the actual null character; it was simply escaped for display purposes.

Re:When C Strings Attack! Strange replies? (1)

tuomoks (246421) | more than 4 years ago | (#28886545)

Agreed, it is a shame, the null terminated came in C very late in game when byte counting wasn't too expensive any more. I really don't get the replies of only 256 byte (octet?) max length? Pascal (PL/I, Algol, etc) strings can have up to unlimited length depending on language, computer, etc implementation. Any modern(?), intelligent language should be able to handle a continuous string of bytes (mostly octets but even NLS and other "strings") without any terminator or special API, it's so lame! And it is dangerous - my hair is gray fixing programs where the null was overwritten for some reason or where the scanning, input, whatever was depend on some such terminator instead of hardware termination based on length, signal, memory boundary, memory protection, etc.

Back to the topic, CAs are in business for money, not to make things more secure or so. That's mostly the problem in computing today, you think that security certificates, PCI, even most of other regulations, etc are there to enhance security and I have a bridge to sell. They are there to make money, sell a product, shift the blame, whatever but definitely not for security which is much, much more than just some technology.

What's the alternative? (1)

mangu (126918) | more than 4 years ago | (#28886659)

Perhaps one should use a ';' [xkcd.com] to end strings instead.

Seriously, I would say the problem is not C strings, but the CA *not* using C strings instead. If they properly recognized the null character as a string terminator, they wouldn't issue a certificate for paypal.com to badguy.com.

Dan Kaminski, would you STOP ALREADY !! (5, Funny)

Anonymous Coward | more than 4 years ago | (#28886023)

Go do something else for a while. If it were not for you we all would be safer !!

Re:Dan Kaminski, would you STOP ALREADY !! (1)

gstrickler (920733) | more than 4 years ago | (#28886857)

Are you actually suggesting we're more secure if white-hats aren't constantly checking for vulnerabilities? Security by obscurity is not secure.

So now... (5, Funny)

mhkohne (3854) | more than 4 years ago | (#28886033)

All we have to do is get the CAs to pay attention to the certs they issue, correct?

Uh-oh. We're screwed.

Re:So now... (5, Insightful)

Anonymous Coward | more than 4 years ago | (#28886087)

No, all we have to do is make CA's liable for the certs the issue.

MS BSTR and null terminated strings (1, Funny)

Anonymous Coward | more than 4 years ago | (#28886037)

It's a shame that the Microsoft BSTR didn't become the dominant form of string, then these problems wouldn't be occurring.

Re:MS BSTR and null terminated strings (1)

93 Escort Wagon (326346) | more than 4 years ago | (#28886427)

It's a shame that the Microsoft BSTR didn't become the dominant form of string, then these problems wouldn't be occurring.

Is the Microsoft BSTR anything like the Microsoft BSOD?

Re:MS BSTR and null terminated strings (1)

CarpetShark (865376) | more than 4 years ago | (#28886573)

It's a shame that the Microsoft BSTR didn't become the dominant form of string, then these problems wouldn't be occurring.

It's a shame that pearl necklaces didn't become the dominant form of string... oh, never mind.

Makes me wonder (0, Troll)

JamesP (688957) | more than 4 years ago | (#28886107)

Who's the fscking idiot who thought having \0 indicate end-of-string was a good idea??!!?

I cannot remember something that gave more _grief_ and _problems_ than that.

Re:Makes me wonder (0)

Anonymous Coward | more than 4 years ago | (#28886223)

In DOS it was $, we could go back to that if you prefer?

Re:Makes me wonder (0)

Anonymous Coward | more than 4 years ago | (#28886225)

I cannot remember something that gave more _grief_ and _problems_ than that.

Maybe you should get out more.

Re:Makes me wonder (1)

spydabyte (1032538) | more than 4 years ago | (#28886249)

And a better idea is.... \1? It's called a standard. What about any optimized language, are huge overheads really better? Or am I missing something?

Re:Makes me wonder (1)

The Moof (859402) | more than 4 years ago | (#28886285)

Well, if the CA software respected the null as the end of the string, they wouldn't have issues the certificate to badguy.com. They would've just seen badguy.com attempting to get a certificate for PayPal.com.

Re:Makes me wonder (1)

moon3 (1530265) | more than 4 years ago | (#28886295)

Who's the fscking idiot who thought having \0 indicate end-of-string..

His name should not be that fscking hard to find, if you care about that, the SSL related code is open source.

Re:Makes me wonder (1)

owlstead (636356) | more than 4 years ago | (#28886585)

That won't be someone in the SSL related code I guess. It's more like a language/library problem.

Re:Makes me wonder (0)

Anonymous Coward | more than 4 years ago | (#28886297)

how the fsck else do you propose to do it? well, i guess you could prepend the string with its length... but that's messy too, since the length of the length wouldn't be constant. crap.

Re:Makes me wonder (1)

owlstead (636356) | more than 4 years ago | (#28886567)

Meh, with the number of bytes we have lying around on the computer: just make it 64 bits. If anybody ever creates a string of 18446744073709551616 characters or higher, we'll give him a cookie. You could also use variable length encoding such as DER. In that case you can go up to a number that is much higher than 2^128 you run out of particles in the universe pretty quickly. DER uses one byte encoding up to 7Fh. After that you get 8180h, up to 81FFh, then you get 820100h up to 82FFFF up to FExx where xx is repeated 7Fh times.

Note that this is a C/C++ construct that has been - uh - deprecated by languages like pascal ages ago. Nobody says that a 00h character has to end a string, and you can do much better than that. Truly, I've seen many issues with 0 terminated strings in the last 8 years - many of them in important libraries. 0 terminated strings suck. Control characters without any textual meaning suck. Get rid of them.

Re:Makes me wonder (0)

Anonymous Coward | more than 4 years ago | (#28886299)

Go back to eating paste!

Re:Makes me wonder (1)

smellsofbikes (890263) | more than 4 years ago | (#28886313)

Who's the fscking idiot who thought having \0 indicate end-of-string was a good idea??!!?

I'm honestly curious, since I don't know enough about the problem to do more than ask questions: don't you need an end-of-string indicator of some type? Wouldn't any other end-of-string indicator do exactly the same thing? In other words, isn't this about the (bad) assumptions being made by the browser's URL parser, rather than about the inherent evil of a specific end-of-string delimiter?

Re:Makes me wonder (1)

Abcd1234 (188840) | more than 4 years ago | (#28886373)

don't you need an end-of-string indicator of some type?

Nope. The alternative would be to carry around the length at the start of the string. This would be known as a Pascal-style string (in contrast to what we're discussing here, which is a C-style string).

Re:Makes me wonder (4, Insightful)

QuoteMstr (55051) | more than 4 years ago | (#28886329)

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?

  • didn't use more than one byte of extra memory
  • worked for both static and dynamically-allocated strings
  • did the right thing when embedded in structures initialized to zero
  • allowed for easy, efficient string concatenation

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.

Re:Makes me wonder (1)

owlstead (636356) | more than 4 years ago | (#28886679)

Absolutely true. However, it does make a statement about the validness for using such a language today, especially for security related applications. How long should we keep such languages and libraries around?

Re:Makes me wonder (1)

betterunixthanunix (980855) | more than 4 years ago | (#28886737)

Yes; the PASCAL style, which have the added benefit of very efficient length checking. The only downside is that strings longer than 256 chars would have to use more than one byte for storing length; all of the other advantages are maintained.

More likely, it was chosen because of the storage saving, and because there was not a risk of hackers trying to cause strings to misbehave by passing null characters in the wrong places. C and Unix were originally used in environments where people were not trying to attack each other, and security systems were in place just to prevent common user errors from destroying others' work. The real "idiot" move was taking the same hunks of code from the age where everyone could trust each other, and trying to use it in an age where some people cannot be trusted.

Re:Makes me wonder (1)

QuoteMstr (55051) | more than 4 years ago | (#28886811)

Also, with C strings, you don't need to worry about counter overflows, and you can safely operate on a string when you don't have its beginning. (Consider strtokThe real "idiot" move was taking the same hunks of code from the age where everyone could trust each other, and trying to use it in an age where some people cannot be trusted.

Rewriting everything from scratch didn't seem to work too well for MULTICS people, the Hurd people, the Plan 9 people, and so on.

Re:Makes me wonder (1)

pushing-robot (1037830) | more than 4 years ago | (#28886375)

Somebody, a long time ago, (in a galaxy very, very close) realized that (a) you could have longer strings with less overhead and (b) sometimes you're reading streaming input and don't know ahead of time where the data will end. Having null-terminated strings was very useful when CPU cycles were expensive, registers were expensive, and buffered data was expensive.

The better question is "Who's the fscking idiot who would use a null-terminator, (on a short string, no less,) in a situation where security is paramount, and not even bother to check for poisoned nulls??!!?"

And we trust CAs *why* again? (4, Insightful)

girlintraining (1395911) | more than 4 years ago | (#28886183)

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.

Re:And we trust CAs *why* again? (2, Informative)

Hatta (162192) | more than 4 years ago | (#28886457)

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.

Really? It seems to me that with a centralized system, you have one entity controlling trust. If you want to subvert that, you have to convince that entity that you are trust worthy. If you have a decentralized system, you could have 1000 entities controlling trust. That's 9999 more chances you have to trick someone.

Decentralized systems are at first glance more appealing, but I don't think they are safer in this case. The problem in this case is that the CAs aren't incentivized to ensure trust. They make money based on the number of certificates they sell, not the trustworthiness of those certificates. CAs should be non-profit, or at least heavily penalized for issuing false certificates, if this is going to work.

Re:And we trust CAs *why* again? (2, Informative)

QuoteMstr (55051) | more than 4 years ago | (#28886593)

CAs should be non-profit, or at least heavily penalized for issuing false certificates, if this is going to work.

The problem is the same with Moody's, actually: the central issue is that the people doing the auditing are being paid by the people they're auditing. Simply having browser users pay CAs (or investors pay rating agencies) would put the economic incentives in the right place, but that idea doesn't sit well with a lot of people.

So instead, we're left with imperfect and leaky regulation. CAs really should be subject to more regular audits, and their trust bits should be removed by browser vendors when they are abused.

By the way: I remove Comodo root certificates from any browser I use. Comodo allows its affiliates to issue certificates to anyone without verification [theregister.co.uk], and therefore I do not trust Comodo.

Re:And we trust CAs *why* again? (1)

girlintraining (1395911) | more than 4 years ago | (#28886663)

If you want to subvert that, you have to convince that entity that you are trust worthy. If you have a decentralized system, you could have 1000 entities controlling trust. That's 9999 more chances you have to trick someone.

Yes, and compromising any one entity results in a 1/m damage, where m is the member count. The benefit here is that the number of compromises a person can make in a trust network before discovery (the risk) is exponential, not linear -- that is to say, two people are more than twice as likely to discover the subversion from a single source.

Re:And we trust CAs *why* again? (0)

Anonymous Coward | more than 4 years ago | (#28886691)

The other problem with a trusted computing network where 'the masses' determine whose trustworthy is, simply, the number of messages being passed back and forth every time someone deems one website trustworthy. It's akin to a room of ping pong balls sitting on mouse-traps ready to fire when the first ball is dropped. Pure chaos.

Besides, who ever said the masses know what they're doing? Next well see "Website is A++++++++++++ trustworthy" ala Ebay rating systems. (That's an exaggeration, I know, but I think I've made my point.)

Re:And we trust CAs *why* again? (1, Interesting)

Anonymous Coward | more than 4 years ago | (#28886477)

If the two major CAs were VISA and Mastercard I would be a lot happier.

They would at least have a vested interest in not putting out duff certs because they would end up paying for any money you lose to the perps.

Re:And we trust CAs *why* again? (0)

Anonymous Coward | more than 4 years ago | (#28886557)

Ever received "bad information" from a trusted friend? Or "bad information" from a friend of a trusted friend?

'Nuph said.

Re:And we trust CAs *why* again? (3, Informative)

Gramie2 (411713) | more than 4 years ago | (#28886669)

I'd rather add "Bruce Schneier" to my list of trustees, but your friend "Bruce Schneider" may be okay too.

I'm really not trying to be a smartass. I just want people to get his name right; he deserves it.

Re:And we trust CAs *why* again? (1)

ratnerstar (609443) | more than 4 years ago | (#28886675)

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.

Bruce Schneider, Chiropractor and Cranio-Sacral therapist [drbruceschneider.com]? He does seem pretty trustworthy, I guess.

Re:And we trust CAs *why* again? (0)

Anonymous Coward | more than 4 years ago | (#28886683)

I don't know.. I've heard bad things about that Bruce Schneider guy. Now, Bruce Schneier [schneier.com] on the other hand!

Pascal C: vindicated (-1, Redundant)

cpu_fusion (705735) | more than 4 years ago | (#28886189)

If you don't understand, I won't String you along, but give you 256 good reasons ...

Re:Pascal C: vindicated (0)

cpu_fusion (705735) | more than 4 years ago | (#28886205)

That was "Pascal greater than C" using the greater than sign, but apparently slashdot can't escape that properly....

it's not all bad (1)

gEvil (beta) (945888) | more than 4 years ago | (#28886227)

More significantly, an attacker can also register a wildcard domain, such as *\0.badguy.com, which would then give him a certificate that would allow him to masquerade as any site on the internet and intercept communication.

That doesn't sound that bad, does it?

Only as secure as the gate-keeper. (2, Interesting)

MaerD (954222) | more than 4 years ago | (#28886265)

This isn't really a browser issue.

The browser is going "Show me that this cert is valid for paypal.com" and the CA is going "Here it is, for paypay.com" , at least as far as the browser is concerned.
This is no more a flaw then if the CA just started letting anyone buy certs for paypal.com.

Having multiple CAs (and cheap CAs) is a good thing, but we're only ever secure with ssl as the least secure CA.

Re:Only as secure as the gate-keeper. (1)

zaajats (904507) | more than 4 years ago | (#28886653)

This isn't really a browser issue.

The browser is going "Show me that this cert is valid for paypal.com" and the CA is going "Here it is, for paypay.com" , at least as far as the browser is concerned.
  This is no more a flaw then if the CA just started letting anyone buy certs for paypal.com.

Having multiple CAs (and cheap CAs) is a good thing, but we're only ever secure with ssl as the least secure CA.

As far as I understand, it's more like:

* Browser gets cert for Paypal.com\0.badguy.com from the server

* Browser reads domain from cert, but does so invalidly, and only gets Paypal.com

* etc

Re:Only as secure as the gate-keeper. (1)

michaelhood (667393) | more than 4 years ago | (#28886681)

Having multiple CAs (and cheap CAs) is a good thing, but we're only ever secure with ssl as the least secure CA.

Sort of, but with regards to your personal security it's really just as secure as the least secure CA that is in the trusted list of the browser of your choice. Not that it makes this any better.

I think browsers should start removing CAs who aren't doing human verification..

If we were using pascal strings... (3, Insightful)

argent (18001) | more than 4 years ago | (#28886417)

Someone would just get a certificate that managed to put the ".badguy.com" part starting at byte 255 of some string.

Null is not a legal character in a domain name, even if you're using UTF strings. It shouldn't be allowed in a certificate.

Re:If we were using pascal strings... (5, Informative)

QuoteMstr (55051) | more than 4 years ago | (#28886465)

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 [wikipedia.org], 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.

Browsers should be written in a modern language (1)

gmurray (927668) | more than 4 years ago | (#28886487)

What modern language would have been open to this attack vector. Browsers are important. They should not be written in c/c++, whatever the performance gains. Lets just not do it anymore.

Re:Browsers should be written in a modern language (1)

QuoteMstr (55051) | more than 4 years ago | (#28886525)

Other languages have different vulnerabilities [slashdot.org]. There's no substitute for a brain behind the keyboard when writing software that's supposed to be secure.

Besides, Mozilla-family browsers are mostly written in Javascript, whereas Webkit is a C++ package. Yet somehow kids here consider Webkit interesting and cool, and Mozilla obsolete garbage. I happen to disagree.

Re:Browsers should be written in a modern language (1)

gmurray (927668) | more than 4 years ago | (#28886661)

While Java/.NET and other modern languages are not without security flaws, I don't see how any of their past vulnerabilities can compare to using a language where every single string operation is a chance for a lack of diligence to open an attack vector. I'm not trying to start some kind of holy war here, but it just seems like most of the time we see one of these flaws it comes down to the language providing insecure ways of handling string operations. No doubt it has libraries that allow for safe manipulation, but it requires constant vigilance by the developers to prevent security holes. Developers should be concentrating on the more sophisticated attacks that are possible against these engines, not worrying about how safely they are handling their strings.

Great summary (5, Insightful)

Bromskloss (750445) | more than 4 years ago | (#28886559)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...