Null-Prefix SSL Certificate For PayPal Released 351
An anonymous reader writes "Nine weeks after Moxie Marlinspike presented at Defcon 17, null-prefix certificates that exploit the SSL certificate vulnerability are beginning to appear. Yesterday, someone posted a null-prefix certificate for www.paypal.com on the full-disclosure mailing list. In conjunction with sslsniff, this certificate can be used to intercept communication to PayPal from all clients using the Windows Crypto API, for which a patch is still not available. This includes IE, Chrome, and Safari on Windows. What's worse, because of the OCSP attack that Moxie also presented at Defcon, this certificate cannot be revoked." Update: 10/06 23:19 GMT by KD: Now it seems that PayPal has suspended Marlinspike's account.
In other news... (Score:4, Funny)
Re: (Score:3, Funny)
2010, Year of the Linux Desktop?
Re:In other news... (Score:4, Funny)
2010 is the year of the phished desktop :3
Re: (Score:3, Insightful)
Re: (Score:2)
2010, Year of Failed Dreams And Geeks Who Were Right But Nobody Cares.
Re:In other news... (Score:4, Funny)
Re: (Score:3, Funny)
Re: (Score:2)
We have flying cars already
Show me one that doesn't kill your eardrums.
Re: (Score:2)
So let me get this right... (Score:5, Insightful)
Re: (Score:3, Informative)
Actually, this attack has been known a lot longer than that.
I'm really glad the security product we developed uses OpenSSL even on Windows. The MS Crypto API was greatly desired at the time because it made the binary distribution a lot smaller. Originally everything was developed using OSSL because our stuff is cross-platform. Good thing we never found the time to switch over to CAPI on Windows.
Re: (Score:2)
Re:So let me get this right... (Score:5, Interesting)
Re: (Score:2, Interesting)
Re: (Score:3, Interesting)
Wow.
"not technically feasible" to patch at least XP 64 bit which was release after 2003 32-bit server and before 2003 server 64-bit. I thought the code base was really similar. Especially since it uses the same Service Pack (WindowsServer2003.WindowsXP-KB914961-SP2-x64-ENU.exe)
General Availability Dates from Microsoft
Windows Server 2003, Standard Edition (32-bit x86) 5/28/2003
Windows XP Professional x64 Edition 4/24/2005
Windows Server 2003, Standard x64 Edition 5/28/2005
This cannot be anything less than a
Re:So let me get this right... (Score:5, Interesting)
The people who need to make sure to get everything secure in order to for the web to function have waited longer than -9 weeks- to get something fixed? When the thing was presented at... Defcon? What else do these people have to do other than fix these -major- flaws. When something is shown at Defcon, BlackHat, HOPE or any other major security conference, the first thing for these people to do would be to fix the flaw. 9 weeks is inexcusable.
The problem is that this is not just some buffer overflow where you can replace single function call with an equivalent function call that does a safety length check. Security holes that depend on '\0' characters in strings exploit a systematic flaw in the Windows API design: the mix of two entirely different and incompatible types of strings all over the place. The 'native NT' API uses Unicode strings with an explicit length, but the Win32 API and C/C++ libraries usually use null-terminated strings. The dirty compromise is to use null-terminated strings together with an explicit length. Naively, one would think that this is now compatible with both, but it isn't - the NT API strings are a superset of the C-style API strings, because they can contain \0 characters, which the latter cannot handle.
This is a glaring flaw, has been known for many years, and will probably never get completely fixed. The SysInternals guys wrote a nice article about it once, I think, but I can't find it any more. It's lost in the mists of time. It's been exploited repeatedly too. You can create files and registry entries with \0 in them, and then none of the user-mode tools will be able to modify or delete those, including Explorer and the command-line tools. Viruses and other malware make use of this 'feature' often.
What really shits me is that Microsoft hasn't learned a thing. They talk big about security, but it's just talk. For example, the entire ASP.NET API suffers from a similar mismatch of encodings flaw: All of the data binding controls fail to properly HTML encode strings coming from a database. This makes virtually all ASP.NET applications ripe for exploits via XSS or other script injection attacks. The one time I wrote an ASP.NET app, I had to spend weeks going through and replacing all of the simple-looking bind statements with explicit calls to a method that would both bind and encode. Even in the upcoming 4.0 release, the flaw is still there. I suspect that it won't ever get fixed.
If Microsoft can sit on a related security holes for years, don't hold your breath for a patch for this one. Even if they do fix it, I suspect they'll do something half-assed, like create a patch for IE only, instead of the cryptographic subsystem as a whole.
Re:So let me get this right... (Score:5, Insightful)
To be fair, that's the kind of thing Microsoft really can't fix: plenty of people depend on outputting HTML stored in the database, and making escaping the default would break these users. We can debate the usefulness of Microsoft's compatibility-über-alles approach, but you can't fix that problem and preserve backward compatibility.
Re:So let me get this right... (Score:4, Informative)
Re: (Score:3, Informative)
True but the core Java language doesn't ship with any nice HTML widgets. I believe JSF either does escaping by default or at least has a single app-wide setting to enable it by default. The Spring MVC framework has similar options, where with one line I can enable XML and JS escaping in all content written out by UI components. Being backwards compatible is one thing but not having an option to do default escaping is just opening your developer base up to all sorts of issues.
Re: (Score:3, Insightful)
To be fair, that's the kind of thing Microsoft really can't fix: plenty of people depend on outputting HTML stored in the database, and making escaping the default would break these users. We can debate the usefulness of Microsoft's compatibility-über-alles approach, but you can't fix that problem and preserve backward compatibility.
There's no backwards compatibility, ASP.NET was a completely new framework, written from the ground up. It should have done escaping correctly, right from the start. Ideally, it should be a flag that you can toggle on and off on the level of individual text fields, controls, or a whole page, and the default should be safe.
Storing HTML in databases is one thing, and there are controls for emitting such data, such as XML, Literal or Placeholder controls, but that's a special case where a page is assembled fro
Re:So let me get this right... (Score:5, Insightful)
For example, the entire ASP.NET API suffers from a similar mismatch of encodings flaw: All of the data binding controls fail to properly HTML encode strings coming from a database. This makes virtually all ASP.NET applications ripe for exploits via XSS or other script injection attacks.
I would be pretty upset if everything I pulled from DB was automagically HTML encoded. I protect against XSS where it needs to be done. There are places where HTML encoding your data would not work. I do, however, always use parameterized inserts to protect against sql injection on top of an appropriate string cleaning function. Few things aggravate me like shitty ad-hoc inserts and the absence of string cleaning tied to a client-driven interface.
Re: (Score:2, Informative)
Re:So let me get this right... (Score:4, Insightful)
I just tried it with ASP.Net 2.0. A TextBox, HTMLInputText, div, and span control all escaped HTML properly. A Label did not properly escape the Text property. I can't think of very many situations where you would use user supplied values for label text, that a span wouldn't be more appropriate for. By default TextBoxes don't allow HTML to be submitted at all. BTW, ASP.Net 2.0 is four years old.
Well, I just tested it with 3.5, and it's still just as broken as when I first tried it with 2.0.
First of all, "div" and "span" aren't controls at all, but are simply markup elements, and neither support data binding (which is what I was talking about), and neither do any kind of encoding at all, so I think you might be missing my point entirely. Also, "Label" is not that rare - it's the default control inserted by the GUI designer in Visual Studio if you bind a text field in a FormView, and as you noticed, it fails to encode.
Second, while some controls do perform encoding, this only works sometimes, usually if the target control is a "Literal", or effectively the same (e.g.: If a Literal control is generated by a data bound control as a child control). As far as I know, the Literal control is the only control that has a "Mode" property that can be used to toggle HTML encoding modes, so most other text fields are not encoded.
For example, if you bind the "Text" property of a HyperLinkField of a DataGrid, then no HTML encoding is done, and no encoding options are available. The only option is to do a manual bind to a code-behind method that performs the encoding for you.
What particularly shits me is how random the encoding is. Sometimes it works (literals), sometimes it doesn't (hyperlinks), but then sometimes it randomly works again, such as the Alt text of Image fields. It's not documented either!
Is this the quality and attention to security you'd expect from the world's biggest software company? Random, unpredictable, undocumented, insecure behavior in their flagship web framework? Really?
Re: (Score:2, Insightful)
Re: (Score:3, Insightful)
This is what I mean when I say Microsoft's attitude to security is still half-assed.
Or rather that's their attitude to standards. With the security issues being one of the consequences.
Re:So let me get this right... (Score:5, Interesting)
I have never understood that for years, you have been able to create a folder with a space at the end of its name in a script. Try, just try, to delete that folder.. You can't create it in explorer, you can't delete it in explorer.. in fact, the only way to fix that I have found, is hope to god its a long file name, drop to a command prompt, and delete it with "Del folder~1"
Years and years...
Speaking of which, I got to try that in server 2008, and Windows 7.. Its a fun way to use 3 lines of script to really piss off your IT co-workers...
Re:So let me get this right... (Score:5, Informative)
I have never understood that for years, you have been able to create a folder with a space at the end of its name in a script. Try, just try, to delete that folder.. You can't create it in explorer, you can't delete it in explorer.. in fact, the only way to fix that I have found, is hope to god its a long file name, drop to a command prompt, and delete it with "Del folder~1"
Well, the documentation for Windows Explorer specifically states that it may not support all the naming conventions of the underlying file systems. Of course, it would be entirely reasonable to expect it to fully support the naming conventions of any Microsoft file system, but MS seems to operate under an unusual definition of "reasonable"...
/X may fail to reveal this as a long filename (by definition, any filename containing a space is a long filename even if it's eight or fewer characters in length), in which case there's no way to use dir to make it obvious there's an abomination in the list of folders.
You don't need a script to create such folders, just the command prompt. This will work just fine: mkdir ".\Space \". Even better, dir
Note that mkdir "Space " won't give you the trailing space in the folder name, at least not on anything earlier than Vista or 2003 (never tried this trick on anything after XP). Similarly, rmdir "Space " fails to remove the directory, but you can remove it with rmdir ".\Space \".
File this under "Stupid cmd.exe tricks".
Speaking of which, I got to try that in server 2008, and Windows 7.. Its a fun way to use 3 lines of script to really piss off your IT co-workers...
Heh, create three sibling directories named "stuck" where they have one, two, and three trailing spaces - then sit back and watch the consternation. It will look like there are three folders with identical names under the same folder (impossible!), and none of them can be deleted with Explorer. Pure, evil fun.
- T
Wow? (Score:4, Funny)
Moxie Marlinspike - that's a goblin name if I ever saw one.
Re:Wow? (Score:4, Informative)
Re: (Score:3, Insightful)
You do know what a marlinspike is right?
Yeah, it's the place where Captain Haddock lives. (I'm sorry, I know what the actual object is, but my childhood Tintin reading and viewing has forever fused the word "marlinspike" to the word "hall".)
Re: (Score:2)
I know what a Marlinspike is, but wft is a Moxie?
Re: (Score:2)
I know what a Marlinspike is, but wft is a Moxie?
I don't know, but Knob Goblins fear it.
Is that... (Score:2, Interesting)
What about the CA that issued it? (Score:5, Interesting)
With CNs like www.paypal.com\0ssl.secureconnection.cc
Shouldn't the CA who issued the certificate bear *some* of the blame here?
It just seems logical....
Re:What about the CA that issued it? (Score:5, Insightful)
Ahh, you've discovered why SSL on the web is fundamentally broken -- CAs have no incentive to act responsibly, since their customers are certificate requestors, not relying parties. And certificate requestors like CAs who don't have heavy process and high fees.
I believe the only way forward is for browsers to change the model: associate a certificate SKI with a web site on first visit, warn if that changes. Don't worry about certificate validity, since the hierarchical trust model has been compromised from the root.
Re:What about the CA that issued it? (Score:5, Interesting)
Especially Comodo [theregister.co.uk]:
Re: (Score:2)
I believe the only way forward is for browsers to change the model: associate a certificate SKI with a web site on first visit, warn if that changes. Don't worry about certificate validity, since the hierarchical trust model has been compromised from the root.
Something else that should work (once DNSSEC is actually implemented everywhere) would be to list your SSL fingerprint as a DNS entry. This is less secure in some ways (say, if someone hijacks your account with whoever you bought your domain from), but better in others (better assurance on first visit, you can change the fingerprint if your server is compromised and someone else gets hold of your cert's private key).
Re: (Score:3, Informative)
You also typically will not get any warning if the certificate or the CA change.
Yet, some common browsers today make people j
Re: (Score:2)
With CNs like www.paypal.com\0ssl.secureconnection.cc
Shouldn't the CA who issued the certificate bear *some* of the blame here?
So I can't have a .paypal.com\0ssl.secureconnection.cc subdomain of secureconnection.cc?
Re:What about the CA that issued it? (Score:4, Interesting)
Jacob Appelbaum presented a wildcard cert that you can use for any domain a week ago. Not sure why this is a story when a paypal-only forged cert comes out.
https://www.noisebridge.net/pipermail/noisebridge-discuss/2009-September/008400.html [noisebridge.net]
Note that you can create a SSL cert for any subdomain you host. I.e. CA root gives you *.example.com, you sub-certify a certificate for mail.myhome.example.com. So you can not blame a root CA for this issue, as anyone who is in the hierarchie can create a \x00 cert.
Update (Score:5, Informative)
Sounds like PayPal should be freezing everyone's account until this is fixed.
Re:Update (Score:4, Informative)
Just anyone who has ever logged in from a Windows box running a browser other than Firefox.
Re:Update (Score:4, Informative)
Just anyone who has ever logged in from a Windows box running a browser other than Firefox.
and Opera. Opera uses OpenSSL, thus avoids broken Windows crypto stuff.
"...PayPal has suspended Marlinspike's account." (Score:5, Insightful)
Re: (Score:2)
Because that is totally going to fix the problem.
It sure as hell will. They should have done that 9 weeks ago!
Re:"...PayPal has suspended Marlinspike's account. (Score:5, Funny)
If you don't shoot the bearers of bad news, people will keep bringing it to you.
Re: (Score:2)
If you don't shoot the bearers of bad news, people will keep bringing it to you.
Awesome. This is a quote I'm going to remember for a long time!
Re: (Score:2)
They are not, however, within their rights to keep his money. He is within his rights to take them to the cleaners, sorry, courts
Re:No, but (Score:5, Insightful)
AFAIK, the law supports your position. But I really think we need to examine whether that's the kind of society we want. It's perfectly fine for a small business to arbitrarily refuse to have a relationship with a particular person. That person can go elsewhere, and the small business is only hurting itself. But large companies like PayPal are different. They form an integral part of the fabric of modern life. When one of these large companies denies service to an individual, that person's quality of life is reduced without an opportunity for rebuttal, or for a fair judgment by his peers. These companies have become de facto utilities, and just as the electric company cannot turn off your lights because of a personal grudge, PayPal should not be able to arbitrarily cripple your ability to send and receive money.
When a company gains quite a bit from being large enough to matter in this way; it should give something in return.
Was he really causing them grief? (Score:2)
If you cause someone grief, don't expect them to be nice to you in return
Was he causing them grief, really? The vulnerability existed whether he talked about it or not. Given that it's tied to some deep long-term issues with null-terminated strings, it's entirely credible to theorize that there are black hats that knew about it already, and his disclosure gave software developers a chance to do something about it. That keeps PayPal from having to deal with fraud and theft problems associated with the vulner
ow, retaliate! (Score:5, Insightful)
If you cause someone grief, don't expect them to be nice to you in return.
Look at it this way: If a doctor jabs you with a mortally-needed anti-venom needle, do you have the right to tell him "Fuck off!"?
I suppose... "He caused me grief!" Yeah, okay. It's a bit of a simplistic metric, really, for determining what is a good response. Appropriate for a young child or a retard. Maybe not for a large corporation. Hopefully not for you.
It does matter what the person's intentions were.
Re:No, but (Score:5, Insightful)
From Paypal's justification of their banning:
"We do not, however, allow PayPal to be used in the sale or dissemination of tools which have the sole purpose to attack customers and illegally obtain individual customer information," the spokeswoman, Sara Gorman, wrote in an email. "We consider whether there is any legitimate use in helping to strengthen the defenses of one's site when determining violation of our policy."
The problem with your statement is that he did not cause Paypal problems in the way that you think. He showed a widespread security flaw, using Paypal as an example... and Paypal suddenly decided that the tools he was producing "have the sole purpose to attack customers and illegally obtain individual customer information". This is a complete and utter load of bollix.
So yes, Paypal may not be happy they have a vulnerability... the same vulnerability that every other SSL cert user has I might add... but he was not breaking their TOS. What they did was infantile and very counter-productive.
This kind of behaviour means the only people that know the flaws in your system are the hackers who want to exploit them for nefarious means, rather than these researchers, who are doing it partially to "help the world", but also to HELP YOU.
I wouldn't trust a company who discourages security penetration testing and thorough investigations of their systems in these ways. Because you can bet your pants, the black-hat hackers will do their homework and find these flaws if our researchers don't.
Microsoft got it right? (Score:2)
FTA :
"It won't work for exploiting the bug for software written with the WIN32 api, they don't accept (for good
reason) *!"
Como?
Video Of The Defcon Talk (Score:3, Interesting)
For more information about null-prefix attacks, the video is here [defcon.org].
Boy I sure am glad.. (Score:2)
Shooting whom? (Score:5, Funny)
Kirk: How is the messenger, Bones?
McCoy: He's dead, Jim.
Kirk: Well, I suppose our mission here is accomplished.
McCoy: Yes, I suppose you're right.
How does this work (in 20 seconds) (Score:5, Informative)
what usually happens:
* you request a cert common-name=serverbox.mydomain.com from a Certificate Authority (CA)
* CA determines you are authorized to make this request on behalf of mydomain.com
* serverbox.mydomain.com serves down the signed cert, your browser makes sure website == common-name == serverbox.mydomain.com
what these clever guys discovered:
* you can request a cert common-name=paypal.com\0.mydomain.com
* CA determines you are authorized to make this request on behalf of mydomain.com
* man-in-the-middle sits in between you and paypal.com, serves down this cert, victim's browser makes sure website == common-name == paypal.com (whoops!)
* victim sees paypal.com in their browser with that reassuring padlock
escape-characters poorly misunderstood (Score:4, Informative)
escape-characters poorly misunderstood? (Score:4, Funny)
I dunno, they seem fully misunderstood in this case.
Re:Heh... surprised? (Score:5, Informative)
Re: (Score:3, Informative)
http://changelogs.ubuntu.com/changelogs/pool/main/w/wget/wget_1.11.4-2ubuntu1.1/changelog
Re: (Score:3, Informative)
Don't forget about elinks (http://elinks.or.cz/)
Re:Heh... surprised? (Score:5, Informative)
From the article:
Fortunately, Mozilla developers patched the hole a few days after Marlinspike's demo and Apple followed suit a few weeks later with Safari for OS X. That means if you're on Windows, the only way to protect yourself against this critical vulnerability is to use versions 3.5 or 3.0.13 or later of Firefox. At least until Microsoft fixes the CryptoAPI, whenever that may be.
Re: (Score:3, Funny)
So am I more secure if I sing myself instead of the computer letting it do for me?
Does it matter which song I sing? I guess "ring of fire" would make a good firewall?
SCNR :-)
Re: (Score:2, Informative)
From the information I can find online, Opera does not use the affected Windows Crypto API.
Re:Such dependancies annoy nLite users! (Score:5, Insightful)
This has to be the worst advice I've ever heard.
Re:Such dependancies annoy nLite users! (Score:4, Insightful)
Amen brother, bad coders re-making existing functions or API's is what fills up The daily WTF [thedailywtf.com]
Re: (Score:2)
I read that site sometimes. I don't make mistakes like that - not because I'm brilliant, but because I actually write unit tests and try to fark my own code over. I never assume because I think it should work, that it will work.
For me, actually writing code is probably less than 20% of the time spent on a piece.
I also follow the rulebook when it comes to sanitizing input, or anything that could be modified by a user.
But none of this has anything to do with not depending on Microsoft when third party libs ar
Re: (Score:2)
Install less software to protect yourself?
Yeah, that's like wearing little armor to be able to dodge all enemy attacks. You have to know what the hell you are doing, and even then it can still be disasterous.
Re: (Score:2)
Install less software to protect yourself?
Yeah, that's like wearing little armor to be able to dodge all enemy attacks. You have to know what the hell you are doing, and even then it can still be disasterous.
It's more like parking fewer cars on the street in north jersey - every app is a way to be attacked.
Re: (Score:2)
Install less software to protect yourself?
Use different software. There's a difference between not using anything, and preferring manually installed FOSS to Microsoft's solution.
Re:Such dependancies annoy nLite users! (Score:5, Insightful)
NO! Don't roll your own crypto. This is madness!
*Kicks BikeHelmet into pit*
OpenSSL is available for windows; use that.
Re: (Score:2, Insightful)
Re: (Score:2)
Hehe... it'd be a horrible idea for me. :D
But automatic updates and XML parsing are easy. I wouldn't expose an app to the vulnerabilities Microsoft's implementations provide.
Re: (Score:3, Interesting)
NO! Don't roll your own crypto. This is madness!
I'd never do that.
OpenSSL is available for windows; use that.
->
go for a third party library. (perhaps open source)
The rewrite it bit was actually referring to automatic updates and XML parsing. Those are pretty easy to implement properly in an app, without depending on Microsoft-coded services.
Apparently I'm 80% overrated, but that's also why a single exploit can affect so much software. Rather than using a third party lib, most devs just use whatever you stick in front of them. :/
Re: (Score:3, Insightful)
XML parsing. Those are pretty easy to implement properly in an app
No, no, God, no. I'm sick to death of crappy applications not handling Unicode element names, not understanding XML namespaces properly (I've seen several that thought that prefix is the namespace, and required you to use specific prefixes), not properly parsing CDATA, not understanding XML whitespace rules or xml:space, not understanding DOCTYPE and entities, and so on.
XML is not simple. Don't think you can whip up a parser in an evening unless you really know the W3C spec well, including all corner cases
Re: (Score:3, Insightful)
So you are saying reinvent the wheel? Don't use the system resources at your disposal? Should we just all go back to DOS way of doing things?
Re: (Score:2)
No. Just consider where you're placing your faith.
As someone above posted - OpenSSL or MS Crypto? I know which one I'll be using!
Java XML Parser? MS XML Parser? Have you seen the number of published exploits and fixes released?
Automatic updates for your app?
Those last two are probably best implemented by reinventing the wheel.
Re: (Score:2)
What makes you think your own code is any better?
Re: (Score:2)
What makes you think your own code is any better?
His own code can be easily updated when it needs to be. Microsoft's... heh heh.
Re: (Score:3, Informative)
When I wrote an XML parser for app settings, I chose...
ASCII only, no XML attributes(only simple tags), strict closing tag order. Also, opt-out input sanitization(all chars rejected unless... A-Z, a-z, 0-9, +_-, etc.) when both saving and loading.
So you didn't write an XML parser, then. I sure hope that when you documented that thing, you didn't call the format of your app settings file "XML", because it sure as hell isn't that.
Re: (Score:2)
So in your book, a monoculture is okay so long as it's an open source monoculture?
OpenSSL's license is incompatible with the GPL, by the way, so we need at least two SSL libraries in the world.
Re: (Score:2)
You are advocating security through obscurity.
Somewhat - but I prefer security through limited feature sets.
In the case of XML Parsers, they have a lot of features, and XML can have very complex syntax. New exploits pop up quite often. If you only need to store a few settings, why not roll your own simplistic XML parser? Or go even simpler and use INI!
For an XML parser, make it only understand <tags>, data inbetween tags, and spit out errors if there isn't an ending tag for every single tag, in exactly the right order. Sanitize all input with che
Re: (Score:2)
Re: (Score:2, Insightful)
Re: (Score:2)
There are some things that should be taught in every school in America. Just as there are mandatory classes in sex education and home economics, there ought to be a mandatory class (at least a short one) about basic computer safety. This isn't a complete list, but it's a s
Re: (Score:2)
"Never click "yes" to dialogs you weren't expecting."
Clearly you have never used Windows Vista.....
Re: (Score:2)
Whilst the above points should be taught at an early age, at present I can only see regular users paying attention to maybe points 1 and 2 above, the others are just more hassle than they're worth (in their opinion)
I like to consider myself pretty knowledgeable about computers and even I break at least one of those rules (I open emailed attachments)
Re: (Score:2)
Well seeing as you're logged into slashdot to post the comment, you probably broke rule 1 :)
(Sure - maybe there's an https login page for slashdot I don't know about but you get the point).
Re: (Score:3, Funny)
> Never type a password into a site unless you see a lock icon in your browser.
So how'd you log into Slashdot?
Re: (Score:3, Insightful)
*doesn't chain to an EV provider* it's not much of an exploit,*doesn't chain to an EV provider* it's not much of an exploit, really. No green bar, not safe. really. No green bar, not safe.
Have you lost your mind, or are you joking?
Assuming a rubber room is being prepared for you, I have to wonder why you would think anyone knows to look for green bars.
I might actually agree with you that this isn't a huge problem, but for very different reasons. MITM attacks are relatively hard to exploit. You're essentia
Re: (Score:2)
MITM attacks are relatively hard to exploit. You're essentially limited to wireless networks, or hostile LANs..
Just one compromised workstation in a LAN makes it hostile.
Re: (Score:2)
Interesting summary [ivanristic.com] and paper [blackhat.com]. The gist of it is that EV-validating the main page doesn't help if it pulls in content that's protected by a weaker certificate.
I can't believe browsers do this. Just like there's a warning when a page protected by normal SSL includes unprotected content, there ought to be a warning about an EV-validated page including non-EV-validated content.
It's really terrifying how people who really should know better are negligent when it comes to browser security.
Re:Yay Choices! (Score:5, Informative)
This is a nice definition [softlab.ntua.gr]:
Security Through Obscurity (STO) is the belief that a system of any sort can be secure so long as nobody outside of its implementation group is allowed to find out anything about its internal mechanisms. Hiding account passwords in binary files or scripts with the presumption that "nobody will ever find it" is a prime case of STO.
For shits and grins here is a slashdot feature on the topic [slashdot.org]; the first couple of paragraphs should make the usage clear. In fact he even goes on to point out that it can not be used by opensource software.
Re: (Score:2)
I completely agree with your definition and rebuttal to the grandparent, but can I just say that STO is often used as an excuse for poor secrecy? Yeah, it's great if you can write perfect code and implement an adequate encryption standard, but that's no reason to go advertising which encryption standard you're using, unless you really have to. If someone is intercepting traffic on the wire I'd rather make them know stuff about the entropy of common encryption standards and have to guess which one it is..
Re:Yay Choices! (Score:5, Informative)
Or just use Firefox. Wow, that's a lot easier!
Re:Yay Choices! (Score:5, Insightful)
I am not a security expert, but does switching to Firefox really solve the issue? For browsing, sure. But everyone is saying this is part of the core crypto API in Windows. Certs are used in more things than just IE.
When the app you want to install says it is signed by Microsoft, Mozilla, or Nullsoft, can you still be sure that it really is? Can you be sure the Windows Update software is actually retrieving updates without a man-in-the-middle?
I really don't know the answers to these questions. But I would be surprised if switching to Firefox is a cure to a bug in the core Win32 apis. Helpful: yes. A solution: probably not.
Re: (Score:3, Informative)
IIRC Firefox has its own cross-platform libraries for the code in question, which is why it isn't vulnerable like the browsers that depend on the win32 libs. Mozilla can just patch those libs whenever they want, and in this case they did so before Microsoft patched the win32 libs.
Re: (Score:2, Informative)
Re: (Score:2)
So paypal violates their own privacy policy by not using working encryption
There is absolutely nothing wrong with Paypal's encryption. There is nothing wrong with the CA that paypal uses for their SSL cert. There is technically nothing wrong with the CA that allowed a null-prefixed SSL cert to be created, although they were stupid to do it. Microsoft needs to fix their ^$@&#.