Slashdot Mirror
IE and Konqueror Bug Makes SSL Insecure
Spad writes "The Register reports that IE and Konqueror both have a bug that allows anyone with a legit Verisign SSL certificate to issue a 'legit' certificate for a 3rd party site. IE and Konqueror don't both to check the issuer of this intermediate cert making SSL in both browsers something of a joke". Update by Hetz: if you're using KDE from CVS, the fix is inside or you can wait to next week for KDE 3.0.3 (which will have more fixes for KDE 3.0). Thanks to Waldo bastian for the blazing fast fix (95 minutes since it was reported).
Has Slashdot become the comment board for The Reg articles ?
Little did I know, the answer was right in front of me, in the form of the one Verisign certificate I shelled out the cash for :-)
I do not deploy Linux. Ever.
making SSL in both browsers something of a joke.
And here I was assuming that a fine MS product like Internet Explorer would embody the rock-solid security I've come to expect from the fellows in Redmond.
For shame, for shame.
--saint
From the article:
"Mozilla was not vulnerable, but I'm not sure if that's because it handled the situation properly, or is, ironically, somehow too buggy to be exploited."
I don't know if that's exactly a show of support. It goes into more depth if you'd bother to read the article.
The opposite of progress is congress
No, if (shock) you had read the article, you would have seen that Mozilla (.94) is working fine and does not suffer from this problem. It has yet (IIRC) to be tested on newer versions, but they should still be fine...
After all, Konqueror is clearly a clone of IE (think about it: explorer vs. conqueror, both are file-managers cum web browsers, etc.). This is just a demonstration of how well the KDE people can emulate MS.
IE and Konqueror don't bother to check the issuer of this intermediate certificate, making SSL in both browsers something of a joke.
Now, in L33T SP34K:
1E 4ND KoNKw3R0r d0n'T BO+her tO cHeCK Th3 1$Su3r 0f +h15 iNTERmEdi@+E cEr+1PHiC4+3, M4K1nG 55l iN BO+h BR0w5ERS 5OMe+hIN9 0F @ JoK3.
Anyone up for Swedish Chef'ing this?
Let's say I go to verisign and get a certificate for encryption, which also garantees my identity. With in the cert, is my information, encryption information, where the cert came from and who issued the cert. I can use my cert to generate other certs using encryption software.
What this means, for people who have browsers which don't check where the cert came from, will not be warned that a certificate was granted from an untrusted source. Who are trusted sources? AOL, Thawte, Verisign.. etc.. Look in browser prefs for certificate authorities; the trusted circle of people to say you are who you are.
Why is this dangerous? Well, for one, you can claim you are whomever you wish, while looking like you are from this trusted circle. You look like you are from this trusted circle because no one claims otherwise. Your browser would usually bitch at you about certs made from non-authorities. But since your browser won't bitch about where your cert came from, and just looks at the authority..
So what if it isn't from a trusted circle? Using this in combination with dns spooofing, you could get people to give you information over ssl "secure connection" (rolling eyes) without the browser bitching at you that the cert you are looking at was made by verisign but not issued by verisign.
-
ping -f 255.255.255.255 # if only
Since the title of the article is "IE and Konqueror bug makes SSL Insecure" and the article body says "IE and Konqueror don't both to check [sic] the issuer of this intermediate cert making SSL in both browsers something of a joke," then I would venture to say that they were not calling SSL in itself insecure. Let's try not to be nit-picky for the sake of being nit-picky.
There's no place I can be, since I found Serenity.
Before the M$ vs Everyone war starts...how about we have a fair and simple timing contest.....where does this get fixed first? ;)
When in doubt, parenthesize. At the very least it will let some poor schmuck bounce on the % key in vi. (Larry Wall)
The certificate issuer is not exactly a secure concept anyway. The whole idea of "trusted providers" being a list of folks engineered by the browser's authors is just asking for trouble. Any of those companies can "go rogue" and start issuing free certs to anybody who asks, which one of them did a while back (then they succombed to the pressures and revoked all the rights, which was pretty crummy).
Besides, the contracts of all cert providers totally absolves them from any crime or misuse of data undertaken by their issued members. Which is a strange definition of "trust"...that it can only be placed in an unknown third party who has no control nor responsibility over the site you're connecting to, and neither has any liability should your data wind up in the hands of ne'erdowells.
Which is why I self sign everything. Since it all boils down to whether or not you trust me, why should I spend $150 trying to trick you into thinking I've passed some rigorous test for "trust". All that matters is that the data users send me is encrypted, which it is. That $150 cuts into my already wafer thin margins, and it cuts even more when you think I'll have to get a different sert for each of my subdomains.
Which is where this bug is actually beneficial. It allows you to get signed once for all your domain names. No more paying exorbitant sums for the paltry 10,000 cycles of processor time it takes to generate a certificate, you can get www.yourdomain as well as yourdomain, yourmisspelleddomain, secure.yourdoman and mail.yourdomain certified for the price of one. Just sign the main site...and use the money to buy an escrow insurance policy.
Hey freaks: now you're ju
The version of this exploit referenced from Larholm's unpatched IE vulnerabilities does not work in Moz 1.0-RC3. It fails with "connection refused".
~~~LXT~~~
Life is like a computer program: anything that can't happen, will.
So, why on earth would a bank, or all companies, only allow what is probably the most insecure browser around to access the site? A bank for cryin out loud! A company that people trust to handle their hard earned cash, allows only IE to handle "secure" transactions on their site!
And don't get me started on payment processing companies partnering with MS to develop secure payment solutions... You'd think they'd partner with IBM or any other company with a decent track record of reasonable security.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Now, in L33T SP34K:
Clearly, this is for you. As for your Scandanavian relatives with professional interests in cooking, you might suggest they visit this instead.
Given one hour to live, the student replied: "I'd spend it with professor FP who can make an hour seem like a lifetime."
Somebody please turn this guy onto Mozilla 1.0!
One simple rule for its versus it's
This gives us a beautiful opportunity to demonstrate the advantages of open source over closed source when it comes to bugfixes. I'm really interested to see the results and whether reality lives up to rhetoric.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
Lets see how fast the KDE team fixes their software and how fast the Microsoft team fixes theirs. If its not already done that is.
Comment removed based on user account deletion
Don't be so sure about that. For the longest time windows allowed javascript to edit c:\windows\hosts (has the same affect)
Also the entire *point* of SSL certs is to make this sort of thing impossible. It should have popped up a warning telling the user that it wasn't the real certificate.
Take a look here. I specially like the last paragraph about "reimplementing" the bug.
Ask yourself, how is that insightful? The author clearly intended that the SSL functionality in the browsers is a joke. Not SSL itself. In fact, it says that both in the story and the comment. Do not be tempted onto the moderation bandwagon!
====
Crudely Drawn Games
http://online.securityfocus.com/archive/1/286893/2 002-08-05/2002-08-11/1 (opens in new window).
It seems that it isn't TOTALLY browser related. Verisign and Microsoft both know about this error, according to the people in the thread. It's a good read with a lot of detailed info about the flaw and where the flaw exactly is.
Never underestimate the relief of true separation of Religion and State.
It's been 20 minutes now and KDE doesn't have the fix up yet.
;)
This is just rediculous. Why are they taking so long? I don't have all day.
Seriously though, with a long list of IE bugs still outstanding and Microsoft blaming Verisign, rather than fixing their software, I'll bet that KDE has a fix a month or more before MS.
I've had Moz 1.1 complain about certificates where the cert company was inconsistent with the issuer.
I disagree they are easier to pull off than people think. DNS buffer overflows have been rather common in the past and for the longest time IE allowed hostile pages to overwrite c:\windows\hosts (Not sure if they have even fixed this issue)
Especially considering that a lot of online banks forcefully opt to make you use IE nowadays which is rediculous). I usually have to set Opera to act as IE5 or Mozilla 4.78 to get banking sites to allow me to log in. Makes it a pain for Linux users like myself, when the bank insists that you use an insecure browser.
Where is the logic in that?
And please don't take this as a flame against Windows and IExplore. Konq has the same problem, but it will be fixed like- immediately. No waiting on the MS code monkeys to do the job.
Totally broken protocol from the end users' perspective.
sPh
A few weeks ago I ran into a site (forgot which one) that has a certificate belonging to another site. Mozilla detected that and displayed a warning dialog.
> Man-in-the-middle attacks are very complex and
> not likely to be pulled off "in the wild".
No. MITM attacks are very easy to pull off with the right tools. You can easily take control of any TCP connection made by any other machine on the same Ethernet. Even if the network is fully switched you can use ARP poisoning to get around that.
Of course, if you manage to take control of a DNS server then you can easily do MITM attacks against many machines. Heck, do you trust the employees of your ISP with your banking information?
if you install kde-bindings for konqueror when you install KDE then it uses the mozilla engine to render HTML/CSS/JavaScript etc. when you surf. however, i don't believe installing kde-bindings exempts konqueror from this problem - Security is handled in a separate module within the Control Center. anyone know otherwise?
when it rains, it gets real soggy. when it pours, i'm under the tap just _waiting_ for the joy
.. to a buried page on the guy's own site. This shows a little more detail on how to get a test setup running.
Alison
"It is a miracle that curiosity survives formal education." - Albert Einstein
The real insecurity is that they trust Verisign by default.
-Adam
If you hit the discoverer's web site using Mozilla 1.1b you get an -8183 error and it
will not display the page. Note this is not a complete spoofed-site demo unless you trick your DNS resolver into reporting his IP for www.amazon.com and pull up his page using SSL with that URL.
I would infer that Mozilla is correctly detecting the mistake in the certificate chain.
Notes on another practical demonstration of this bug are here.
With this article from the Atlantic Monthly about Bruce Schneier and bad security.
Best Slashdot Co
Ok, who stole code from who?
(B) + (D) + (B) + (D) = (K) + (&)
Signed certificates simply state that Verisign trusts the company is who it says it is. That's about it. Signed certificates do not define whether your communications are encrypted or cleartext.
Signed certificates cannot prove that:
Many companies don't bother with having their certificates signed. It's pricey, an administrative burden, and doesn't really increase security. I'm annoyed that browsers have been swept into warning you if the site you're visiting doesn't support Verisign's cash flow.
About 99.999%+ of the primary uses of SSL/TLS out there are for transport encryption, not for site authentity verification, and this does nothing to reduce the security of the transport encryption.
Indeed, the site authentity thing is the way Verisign and friends get away with charging ridiculous amounts to spin off a key pair. I'm not saying that it's a useless service (it is nice to know that I'm talking with my bank versus the incredibly remote scenario that someone hijacked their domain), however that feature is pretty low on most people's importance list.
A lot of people have been saying that, so I wrote a tool (sslsniff) to demonstrate the problem in a more "real-world" setting. It performs undetected hijacking/sniffing of IE SSL sessions, even on a switched network. sslsniff: http://www.thoughtcrime.org/ie.html
Comment removed based on user account deletion
That doesn't fix the problem. You're not testing it correctly, contact me offline if you want to do some actual testing.
"I'm annoyed that browsers have been swept into warning you if the site you're visiting doesn't support Verisign's cash flow."
I know the feeling... the only other problem is, though, how does the vast consumer-base out there deal securely online? It doesn't add anything to have to phone up to read out an SSL certificate fingerprint - you might as well just place the order over the phone!
Maybe what we need is a kind of web-of-trust like the idea of a PGP key-server, only for SSL certificates?
~Tim
--
Rushing on down to the circle of the turn
Doh...
I guess it wasn't, my mistake. Never mind that if I made that comment about Microsoft I'd get a +1 Funny.
Frankly, my feelings aren't hurt. If I'm going to get modded down for pointing out that Linux has it's own security problems, that's fine. I'm not the one who's pride's gonna bite me in the butt down the road.
You'll get an "end-entity" certificate earmarked for your own website (you have to prove you're in charge of the URL that you are getting a certificate for). The certificate won't work on other sites (because the browser compares the site's URL with the URL embedded in the certificate),...
Start producing certs
Say no to software patents.
"Konqueror != Linux, unlike IE which IS part of Windows (see Microsoft's own testimony in the antitrust trial)."
It still comes with KDE. Now, to be fair, it's not as interconnected as say Outlook is to IE. However, SSL is a typical browsing mode that has to be secure. Just because the problem exists, it isn't anymore a vulnerability to Windows than Konqueror is to Linux.
However, that is far from the point I was making. The point I was making was that security on any OS or browser is a myth. Switching to Linux doesn't make your computer more secure, it makes it more obscure.
The only reason that hasn't harshly been demonstrated yet is that Linux users are few and far between compared to Windows or even Mac users. So Windows bears the most of the brunt of the effort put into taking it down. Trust me, if/when Linux has it's day, it'll have it's share of security related issues as well. I don't care if you disagree with me on that point or not. However, you're not doing yourself any harm by treating your computer as though it is vulnerable, and take sensible precautions.
Read your RFCs and then re-read them with a friend or two to make sure you read them right the first time.
I'd say another thing is to give some glory to people that write regression tests for RFC compliance for various applications.
Even all the stupid sounding things that people think "never" happen in real life. Those things that happen only one out of 1e7 times are the first things that the cracking crowd applies their crowbars to.
Microsoft, especially, could do with some of that kind of testing given their huge R&D budgets. It might help diminish the public black eyes they keep getting with respect to standards compliance and security vulnerabilities. Getting the mindset of being compliant to a standard rather than "we are the standard" might help them to write more watertight APIs.
"Provided by the management for your protection."
Please beware that the overall impact of this problem is relatively minimal. The sky isn't falling. What this allows is a man-in-the-middle attack without the usual telltale browser confirmation box that one sees when using an unsigned certificate. The attacker still has to get on the network between you and the website and essentially transparent-proxy your connection through a rogue ssl proxy to make this all work. For the most part people with this level of network access for wide numbers of people are not so devious as to actually do this for profit.
On another note - if they did a traditional man-in-the-middle SSL attack, it might be very hard to track down who did it, but it would be very easy to tell it was being done (because you'd get a browser warning about the certificate not being vaild for this site and/or signed properly). With this new approach, you get no browser warning, but it's presumably easy to track down the culprit, since the certificate signing chain will include a legitimate cert issued to the attacker that can be queried at Verisign or whoever they used - unless they steal a cert from someone else.
11*43+456^2
...any more than gcc is "fundamentally" flawed because it allows the use of sprintf() and sprintf()s have been the cause of countless buffer overflows.
Good developers use the tools, bad developers end up getting abused by them. The concepts of how to properly use them have been kicked around for years; if a programmer decides to use an inherently insecure protocol as a security mechanism, whose fault is it? I suppose it depends on whether we're developing for Microsoft or *nix, eh?
Easy does it!
This comment has been submitted already, 276865 hours , 59 minutes ago. No need to try again.
By the way, I've performed full man-in-the-middle with a real bank
involved and myselft as victim. It's easy and works perfectly, so I've put
a brief description and screenshots at http://arch.ipsec.pl/inteligo.html
Details on programs' setup and fake certificate generation are omitted
not to provide script-kiddies with a ready recipe.
Actually, you can use Mike's https://www.thoughtcrime.org/ as demo
site but you first need to DNS spoof your browser into thinking
that www.amazon.com has address of 66.93.78.63, which is easy using
dnsspoof from dsniff for example.
From the SecurityFocus thread referenced in another post.
Just tried it (opera 6.02/Linux) and it complains... asks whether you want to accept this dodgy certificate and gives you lots of info. So no, it's not vulnerable.
I expect that this bug could exploited in a deadly manner with some onmouseover tricks. The unwary user could be lulled into a false sense of security by seeing amazon.com (placed by javascript) in the status bar when in fact they are being sent to some other IP address, whose secure certificate is spoofed by exploiting this vulnerability.
Of course, if you consider how many of the "trusted circle" have been indicted or are being investigated for fraud of one sort or another...
A Web-of-Trust is the only way to really have much confidence that you're not being Man in the Middled.
Or to put it another way: SSL sucks, PGP rules.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Besides, the poster has a point. In case you haven't been keeping up lately:
- Microsoft gets worried about their bad record in terms of security - reflected in anti-hacking insurance premiums amongst other things. Which are calculated by actuaries, of course - not random Slashdot posters.
- Microsoft made a big song-and-dance to the press about their month-long code stoppage and
security awareness initiative within the company.
- Since then, has their security record improved? Does the fact that they have no plans to fix this bug, ever strike you as a little odd?
Contrast that to the fact that the Konq people already have a fix available for testing, and I think you'll find that even were we to hold a multibillion dollar corporation to exactly the same standard as a handful of volunteers - which would be absurd, in the general case - it looks like Konquerer is going to come out ahead.People who bogusly defend multibilllion dollar corporations against altruistic volunteers annoy me.
Female Prison Rape in NY
Don't forget that the certificates cannot control the data once it's been uploaded to the server. How many attacks have their been where the DNS was redirected to a false server compared to how many have there been where the true server was compromised? SSL certificates are a solution to the wrong problem.
Sorry bud, ya did write that in a Linux-unfriendly way.
I do agree with you, though. To assume that a system is any more secure than another system is ridiculous. You're just begging for a huge problem that way. It's nice that Linux is free from some of the common Windows issues that come up, but shit still happens. The true problem isn't defects in the design of either OS or application. The true reprecussions of an exploit used in a system are multiplied by the dependence on the system.
If it's really important for me to have a particular file, but I only have the one copy on my hard drive, then a Windows or Linux exploit's true danger cannot be measured by the loss of my file. If that file costs me my job, I can't say that anybody in particular is responsible for my lost wages. It's my own fault. I overly trusted my system. I didn't make a backup of the file. I didn't set up a firewall or take sensible internet precautions. Maybe I bought a defective hard drive. Who knows?
It doesn't matter which OS you use, you still have to be cautious.
"Derp de derp."
Assuming the sources cited are accurate, we now have two independent misimplementations of SSL certificate handling, indicating that two purveyors of software that is entrusted with providing a secure (ie, private and authenticated) communications channel have screwed up in a way that suggests they did not understand properly what they were doing.
Rather puts buffer overflows into the shade, doesn't it?
As the late Professor Doctor Edsgar W. Dijkstra commented: "If you don't know what your program is supposed to do, you'd better not start writing it." RIP, a great man.
Uh, that website you mention...thoughtcrime.org...I hit it with IE6, and it gives me a warning saying "Everything checks out EXCEPT the address on the certificate does not match the address of the site trying to send it." Then it gives me an option of accepting it, rejecting it, or viewing the certificate.
How exactly is this a bug? IE saw a problem, reported the problem to me, and gave me options on how to handle the problem. If a user decides to hit "Yes" thats their problem, not IE's.
The world moves for love. It kneels before it in awe.
A [PGP/GNUPG style] Web-of-Trust is the only way to really have much confidence that you're not being Man in the Middled.
I understand the advantages of PGP's model over SSL's, but under PGP's model, how do I get my key signed by somebody who does not live within a few kilometers of my residence? How do I, an individual who wants to send and receive secrets to another party who lives on another continent, establish a chain of key signatures from myself to the other party?
Will I retire or break 10K?
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
That URL alone isn't a full demonstration. Your browser notified you of a problem because it thought the web site was www.amazon.com, and you typed in www.thoughtcrime.org. You have to edit your hosts file:
66.93.78.63 www.amazon.com
For the full effect.
One bank security official once told me unofficially wrt that is that the bank does not like the fact that the source is availible. To them, this means that anyone can compile the browser and "take out" some of the features that make the browser secure. Or trojan it to make an SSL connection, get the username/password, and dump it to a text file or send it remotely.
With the older closed browsers there is supposedly a much smaller chance of that happening.
Try Opera... Some of them disallow NS6, but allow opera...
--
Time is on my side
[i]When did working flawlessly become a bad thing?[/i]
My point was that while Mozilla was accepted (which is good) and IE wasn't (which was funny, and a little relieving).
Sorry if you didn't understand.
sin(6cos(r)+5A)
By consulting with a mutually trusted third party, of course. A similar concept as that of a notary public. (I said similar, not identical).
Trust centers such as Verisign make it a little simpler to verify identity: I don't have to personally check you out myself -- I accept Verisign's "voucher" that you are who you say you are, and therefore I offload my research responsibilities onto Verisign.
This is not a perfect system for many reasons. But you can't HAVE a perfect secure system. I think this system is about the best we have for now.
Now, do the spoof as he suggests. Edit your hosts file so that www.amazon.com has www.thoughtcrime.org's IP address, ie put in the line: 66.93.78.63 www.amazon.com into your hosts file. Where that file is depends on your system; in Unix it's in /etc, in Windows 9x it's in C:\WINDOWS (or whatever %WINDIR% is), in Windows NT it's something like C:\WINNT\System32\Drivers\etc. It's a plain text file. To confirm you've set it up right, type "ping www.amazon.com" afterwards, if it's pinging 66.93.78.63 then you're all set.
Now open your browser, and go to https://www.amazon.com/. If you don't get an error, your browser is vulnerable.
KMSMA (WWBD?)
[laughing] Man, you got that one right... I have "excellent" karma, thus the +1 bonus, so my posts start life at +2 by default. The other day I posted a quick "how to keep your credit card a bit more secure in the event that it gets lost or stolen" and some moron modded it "Overrated", even tho it was still at its +2 default. Yeah, that took real modding skill.
Anyway... a bit to the topic at hand: my preferred browser is NS3.04, which is old enough that it thinks most of these Certs are no good anyway. To get to the test page, I had to jump thru all the hoops involved to get NS3.04 to accept the cert for this session only, and that meant going against the defaults in 5 or 6 dialog boxes before I finally reached the "you've been hacked" page. There's no way I could avoid noticing the problem!
Most users would have gone "Whoa, NS thinks this site is like really bad, let's not go there!"
~REZ~ #43301. Who'd fake being me anyway?
IE which IS part of Windows My solaris and mac versions of IE beg to differ with you there, buddy. The windows version is integrated into windows, however the versions on other platforms are simply regular applications (unless they are loading a windows implementation in the background just to run correctly)
Signed certificates simply state that Verisign trusts the company is who it says it is.
Other than take money do they do that much to establish that the company is who they say they are.
Anyway the certificate can say that the company is A and the webpage can say it's company B. If the certificate is okeyed by Verisign the user won't even see the certificate by default.
I tried the thoughtcrime.org test with the browsers I keep around under OS X. Here are my results:
Mozilla 1.0: passed (the others are right, the error message could be more user friendly, but it worked)
Chimera 0.4.0: failed (no SSL options in Preferences, also an early version without many features)
Omniweb 4.1 (v422): failed (SSL options in Preferences)
iCab Preview 2.8.1: failed (no SSL options in Preferences)
By "failed", I mean displayed the web page with no error messages (which I presume is the test). Some of those that failed don't appear to provide SSL support in the first place.
OmniWeb doesn't have much excuse though, it appears to have SSL support, and it is not a beta.
It's beginning to look like Mozilla is the only one on the ball here.
"What I'm thinking is different from what you are."
Belabera, "Mothra 3" 1998
I sign the keys of people I know by phone, or interact with entirely online on an ongoing basis.
I understand how it would work by telephone (read the hex digits of the fingerprint) because the public telephone system is a reasonably secure system, but I don't see how it could work for signing a public key you see on somebody's web site. How do you know the connection over which your online buddy sends her key isn't tampered somewhere between her computer and yours?
Will I retire or break 10K?
then I would:
The chances of being discovered during the time that your conducting the attack can be minimized by parsing the http headers for the browser type, and only attempting the attack for clients using vulnerable browsers. This way you could leave it in operation for longer, and steal more information.
So what have I missed here? is there some other aspect to this that makes it more complicated than I've made out? stealing the certificates was meant to be the difficult part, getting access to the network is not difficult if you are big enough, and creating a transparent-proxy is going to be relativly easy.
Somewhere there I wasn't thinkging straight:
.....
Obviously you can't parse the http header for the browser type until after you've already set up the ssl connection, which you won't have been able to do if the browser was not susceptible
However, the attack would still work, you just rely on grabbing enough passwords and stealing enough money before being discovered and shutdown to make it workwhile.
also re:
> that your conducting
should read
"that you're conducting"
According to the recent email to the kde-devel mail list, the fix for the SSL vulnerability is in KDE CVS and the stable KDE 3.0.x branch and will be part of the 3.0.3 release next week.
Interesting ... I read an account from one company where the Thawte people actually physically came to the premesis (a computer equipment + mod/cooling + hotrodding shop) and verified that they were a real legitimate business. If you browse the linked site's news archives, you'll see mention of it.
Actually, you are correct about the mac version but the solaris version does load a win32 implementation just to run correctly.
.sig: file not found
> With the older closed browsers there is
> supposedly a much smaller chance of that
> happening.
Completely wrong. With a little practice and the right tools it's easy to understand and modify binaries. The idea that binaries are somehow "hard" to work with is a pervasive myth that has no basis in reality.
In this kind of situation, i.e., an opportunity to install some trojan, I wouldn't even bother trying to modify the browser, whether I had the source or not. I'd just inject a keyboard sniffer into the user's system.
This flaw does not expose Windows to any more problems than is exposed to Linux. If I'm running Opera on Windows, it's not an issue unless Opera itself also has the issue.
To put it simply: This is not a devastating blow to my point.
Message on kde-devel:
2 86895/2 002-08-08/2002-08-14/1l e.pl?sid=02/08/12/134123 9t ml
Date: Mon, 12 Aug 2002 10:22:55 -0700
From: Waldo Bastian
Subject: SECURITY: Konqueror SSL Vulnerability
To: kde-devel@kde.org, kfm-devel@kde.org
Konqueror (kssl to be precisely) fails to detect certificates as invalid that
have been signed by an issuer who is not allowed to do so. A patch for this
problem has been commited to both the CVS HEAD branch and the KDE_3_0_BRANCH.
KDE packages for the upcoming KDE 3.0.3 release will be updated to include
this fix. We hope to have binary packages for KDE 3.0.3 available by the
start of next week.
Thanks go to Mike Benham and Gregory Steuck for alerting us to the problem.
See also:
http://online.securityfocus.com/archive/1/
http://slashdot.org/artic
http://www.theregister.co.uk/content/4/26620.h
Cheers,
Waldo
Do you have to take over a DNS server?
Why attack DNS when DHCP is there for anyone else to play with.
I wonder what would happen if I set my home cable modem based server to act as a DHCP server to other systems on the shared cable segment, re-issuing their existing IP addresses and telling them to talk to me for DNS.
Well, the issue has been known to Waldo Bastian for the last 2 days and he fixed in on both KDE HEAD and KDE 3.0.x branch, and he's now fixing the KDE 2.2.2 branch (for people who preffer to stay with KDE 2.2.x yet).
The patch HAS been tested in the last 2 days, but it took 95 minutes to post a fix since the story was released..
Thanks,
Hetz (Heunique)
This isn't true at all.
When you phone up to get the SSL fingerprint, all you're doing is asking the company for data that is already public, but doing so in such a way that you can reasonably be sure that you're getting it from the official source. This transaction doesn't involve any private, sensitive data at all.
If you then use the certificate to conduct a business transaction, the sensitive data (credit card data, for instance) will be encrypted end-to-end using the now trusted certificate so that eavesdroppers cannot intercept that sensitive data (and the fact that you're using a verified certificate prevents man-in-the-middle attacks).
So the end result is quite a bit more secure than simply placing the order over the telephone, since it is possible to tap a telephone line without either end knowing about it.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
According to Merriam-Webster, the answer is no.
So why not save the confusion and use pedant instead? Then everyone wins!
I've always found Netscape (and therefore Mozilla I guess) to handle security properly. (The fact that the rest of it is so horrible to use, not withstanding). In fact the article says that Mozilla is not vulnerable.
w .fakeserver.com]
I'm annoyed that this is reported as 'making SSL insecure' or making a 'joke' of it. It isn't. It is a failure of the browser to verify the certificate authority chain.
With OpenSSL you can generate a certificate request, and then use another certificate to sign it (or, in this case, submit it to Verisign so that they can sign it with their certificate). You can then use this new certificate to sign more, and so on. So the chain might look like:
[Verisign root certificate]
--->
[www.myserver.com]
--->
[ww
Obviously in this example www.fakeserver.com only belongs to the group of servers trusted by www.myserver.com and not to the group trusted by Verisign. The bug being reported is that IE and Konq mistakenly assign www.fakeserver.com to the group trusted by Verisign.
Now, what is the upshot of all this? What we have lost here, from the client's point of view, is the assurance that the server is who they say they are. Other aspects of SSL (secure encryption, inability for other parties to intercept connection, client validation) still work. A successful workaround would involve the person operating the client manually inspecting the certificate chain, and checking that *all* the sites on it are ones he/she trusts, not just the top one.
Translation: KDE's open-source dev team blows MS's out of the water in bug fixing.
May we never see th
What does your sig mean? Does it mean anything at all?
Please, its driving me crazy.
"but doing so in such a way that you can reasonably be sure that you're getting it from the official source."
....
So let's see... I google around for "soundbug UK" as something I recently wished to purchase, find a sponsored link pointing me at a site I've never heard of before, get as far as the obligatory https:// part, take a phone number from the site, phone them up say "what's your fingerprint?"
Spot the flaw?
Phoning someone up out of the blue adds nothing to the trust factor at all. You need for the out-of-band communication to be trusted for external reasons (e.g. recognizing their voice on the phone) before you can trust them. That's why I might as well save time and place my order while I'm at it.
That's where I think a web-of-trust would win; at the very least you've added in the potential for scoring, or "if it's good enough for my mate Dave, it's good enough for me", with the strength of the crypto-key signature pulling your trust up towards 100% instead of it dropping off with more levels-of-removal from the original trust-er.
~Tim
--
Rushing on down to the circle of the turn
Who says you have to get their phone number off their web site? If they have a phone number, then they should have a phone book entry, right? So you call the number in the phonebook. Now the attacker has to hijack the company's SSL sessions and their telephone lines -- a much more difficult problem.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
hey, it was a monday and i was busy eating lunch... my mind wonders every now and then, sorry english police.
sin(6cos(r)+5A)
I'm not referring to idiocy, I'm referring to zealousy. I've seen a whole lotta that.
> Unfortunately most clients/browsers seem to go out of their
> way to discourage self-signed certificates with error messages
> that sound like "This certificate was self-signed.
Yes, and at that point the user's eyes glaze over and if
he doesn't have a guru to call, he clicks any button at
random. VERY few users would deign to read the entire
message. The dialog probably has "Okay" and "Cancel",
plus the close box on the window frame. Since "Okay" is
the default button, it's highlighted, and hitting "Enter"
will select it too, so there's probably at _least_ a one
in three chance the user will hit "Okay". That's on the
first try. What is more, if the desired result is not
achieved the first time, most users will try again and
hit a different button.
Translation: SSL certs only matter to people who care
about security and privacy.
This is not helped any by the fact that older browsers
used to display a dialog that looked basically identical
to the users whenever any information was sent over an
unencrypted socket -- for example, every time the user
did a web search at an http site like Yahoo! Users who
have been around for a few years have learned to just
bop Okay whenever they see that dialog -- and they teach
this behavior to the newer users.
So users who don't know anything about security or privacy
(i.e., almost everyone) are fairly unlikely to be dissuaded
from visiting a site just because the certificate is invalid.
They're WAY more likely to skip a site because it uses a
plugin that didn't come preinstalled, or takes too long to
load during peak hours.
Cut that out, or I will ship you to Norilsk in a box.