Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Microsoft

Don't Trust Code Signed by 'Microsoft Corporation' 270

omarius writes "From the Microsoft Security Bulletin: 'VeriSign, Inc., recently advised Microsoft that on January 30 and 31, 2001, it issued two VeriSign Class 3 code-signing digital certificates to an individual who fraudulently claimed to be a Microsoft employee. The common name assigned to both certificates is "Microsoft Corporation".' See the bulletin for more information. Brings a whole new meaning to the concept of 'Windows Update.' ;)" Most users probably ignore the name on a certificate presented to them anyway, but even that minimal protection is worthless if certificate authorities don't perform their job.
This discussion has been archived. No new comments can be posted.

Don't Trust Code Signed by 'Microsoft Corporation'

Comments Filter:
  • by Anonymous Coward
    It is because they haven't bothered to do this yet that this is possible - think about it - if CRLs were implemented, and every application that used Certs checked the Revocation list of the issuing CA, this problem would have a trivial solution - Revoke the Cert, and this "fraudulent" issued cert becomes useless.
    No it doesn't. The problem with CRLs is that they don't work, they've never worked and they never will work. CRLs are like 1970s credit-card blacklists where each week the card issuers/banks would send out a blacklist of cards which merchants weren't supposed to accept. The lists were long and took too much work to check, by the time a new blacklist arrived the crooks had long since sucked the account dry, and if you wanted to prevent a card from being revoked you just made sure the blacklist never arrived. CRLs are even worse, although at the moment I don't really feel like typing up a 10-page technical bulletin on their various flaws.

    A slightly better approach is OCSP (online cert status protocol), although that too has enough problems for at least two pages of writeup. The basic problem is that revocation doesn't work (once you've emitted a datum you can't retroactively take it back), which the credit card companies discovered about twenty years ago and which the X.509 designers may discover at some point in the future, although for now it's much more fun to fiddle with revocation protocols and mechanisms. Let's face it, as long as there are hordes of people willing to give you money for band-aids and pretend-fixes, why address the real problem?

  • by Anonymous Coward
    No, the real point is that now, whenever you see 'Signed by Microsoft Corporation' on the bottom of your installer, you can't be sure anymore. That's why the 'Microsoft Corporation' is quoted in the story headline.

    It may not be MS's fault in the slightest, but that doesn't stop their name from being all over it. And dammit, why does the parent to this post, a whining apologist, deserve Score:4?
  • by Wakko Warner ( 324 ) on Thursday March 22, 2001 @12:05PM (#346350) Homepage Journal
    maybe the next "service update" will magically "install debian" on some "lusers' PCs"?

    In a perfect world, anyway...

    - A.P.

    --
    * CmdrTaco is an idiot.

  • When you get the "Always trust..." message, it applies to a particular certificate. These are new certificates, so you'll get the message again. The danger is in all the people that will see that the bogus certificate is from "Microsoft Corporation" and click "Accept".


    ...phil
  • At the present time, what is distinguishing the two in question from the 'real' MS certificates?

    The dates. Microsoft says that they received no legit certificates on the dates in question (Jan 29 and 30, 2001). If you check the date of the certificates and it says "Microsoft Corporation" on those dates, it's bogus.

    And how many people are going to look at the dates?

    If it's possible for MS to revoke those two, why can't the crackers revoke the real ones?

    Microsoft didn't revoke them, Verisign did. The problem is that essentially nobody looks at the Revocation List.


    ...phil

  • What was that someone said about security thru obscurity? No matter how good your code is, you're still vulnerable at the hardware level, and thru social engineering.
  • I said it in 1978, when I was 11 years old, and my only computer experience was a TRS-80 my Science teacher brought into the class from his own funds.

    "The only legitimate use for computers is games - everything else is a waste of time"

    So, can you ever trust an automated software update again?
    Sure, if you never use your computer for anything important ever again. Which pretty much relegates computers to only games.

    Well, games and pr0n. Even my twisted 11-year old mind could not forsee the computer's role in the pr0n revolution.
  • Are these dates adjusted by time-zone?

    IOW; if I'm in Fiji (opposite side of the international date line), and I check the cert at 12:00 noon GMT, could the UI tell me that the Jan 30, 2001 cert was actually dated Jan 31?
  • by jafac ( 1449 ) on Thursday March 22, 2001 @01:09PM (#346359) Homepage
    Better yet, how in hell is Microsoft goint to implement this "patch"? They can't do it securely. How can I trust that this "patch" is really the real one now, and not one that will permantently etch a back door into my system?

    Ladies and Gentlemen, the barn door is open, and the genie is molesting the horses.
  • It has failed at the point that someone successfully uses it. That has not yet happened.
    And your authority for making this assertion is...?

    There is no way ANYONE, even Microsoft, can prove that it has not happened. But it will only take one counterexample to prove that it has.

    And the current appparent lack of a counterexample does not prove anything.

  • When you download files with certificates, doesn't Windoze provide you with the option to allow acceptance of future files certified by the provider?
    Yes, but as the advisory points out, that isn't determined by the common name in the certificate. So even if the user has said "always trust Microsoft", an attempt to use code signed by this fraudulent certificate will pop up a warning again because it appears to be a different Microsoft.

    The danger is that the user will believe that the code really is from THE Microsoft.

  • What, and you think that Microsoft has been using these certificates for over five years, yet it never occurred to them to investigate how the revocation worked? The fact that the CDP wasn't in the certificate is entirely irrelevant. VeriSign is the best-known CA in the world, not some random CA that MS has never heard of. MS could and should have built the checking in to the browser in the first place, special casing VeriSign code-signing certs if need be.

    Or MS could have noticed the problem when VeriSign first started issuing code-signing certs, complained to Verisign, and had them put the CDP into the certificates.

    Either way, MS is much more at fault about this than VeriSign, since they made NO effort to check that their browser supported revocation of certificates for signed code.

    As I said, VeriSign screwed up but corrected their mistake within two months. Microsoft has been so negligent that they CAN'T POSSIBLY correct their mistake for many years, because so few people will apply their patches.

    The security needs to be built into the software at the outset, not patched on later.

  • In their advisory, Microsoft writes:
    Vulnerability identifier: None. This issue is not the result of a flaw in a Microsoft product; it results because of an error made by a third party.
    Which is an out-and-out lie. This wouldn't have been an issue for more than two months if Microsoft had made their browsers properly deal with VeriSign CRLs (Certificate Revocation Lists). Instead, it will continue to be an issue for a long time: even after MS releases patches, it takes years before the majority of users apply them. Earlier in the very same advisory, they wrote:
    VeriSign has revoked the certificates, and they are listed in VeriSign?s current Certificate Revocation List (CRL). However, because VeriSign?s code-signing certificates do not specify a CRL Distribution Point (CDP), it is not possible for any browser?s CRL-checking mechanism to download the VeriSign CRL and use it. Microsoft is developing an update that rectifies this problem.
    However, Microsoft has known for years about the CDP problem. They knew that VeriSign would be issuing the vast majority of code-signing certificates, so they could have (and obviously should have) included a mechanism in the browser to explicitly use VeriSign's CDP.

    Instead, they chose to ignore the possibility that the security might be flawed and allow revoked certificates to be used. They didn't give a damn whether someone got a fraudulent code-signing certificate for J. Random Software Company, and the browser couldn't tell that it had been revoked. They've only been prompted to take action when this unexpectedly happened using their own name.

    VeriSign made an error and corrected it within two months. Microsoft made a bigger error and has taken five years (and counting) to fix it, then has the gall to blame it all on VeriSign.

  • The general idea is that the code comes with a proof of its safety

    I have to agree that this research is very interesting, but everything that I've seen and heard about that requires a formal model of software becomes too complicated to use when applied to anything beyond trivial programs. This may be useful for something like little web applets, but forget trying to do something like a payroll, word processor or language interpreter in it.

    -"Zow"

  • Okay, there's plenty to be said about this article, but two things that stand out to me are:

    Microsoft is developing an update that rectifies this problem.

    And how many people will go to install this update and click "OK" to accept the certificate signed by "Microsoft Corporation"? I mean, they heard that there was some serious problem in Windows, so they better apply this patch right away and the signature on the patch says that it's from MS, so it must be okay, right?

    Consider temporarily removing the VeriSign Commercial Software Publishers CA certificate from the Trusted Root Store.

    And this will prevent how many commercial web sites from working? "I just did what Microsoft told me to to fix the problem and now I can't buy anything at Amazon - not even with 'One-click' shopping."

    Normally, I wouldn't want to see Microsoft take legal action against anyone, but I really think they should ream Verisign a new one for this. Maybe Verisign should learn not to take their job so lightly then.

    -"Zow"

  • I imagine that if you look closely at Verisign's terms and conditions, there's very likely a disclaimer of liability in there.

    Oh, you're probably right, which is why you or I would never stand a chance to go up against them if Verisign screwed us over like this, but for all the lawyers that MS has, I imagine that they could make a case that stands up in court (I mean, look at what they pulled at the Antitrust trial - if they can use a defense like "innovation", I'm sure they could find something to attack Verisign with). Of course, IANAL, and even if I were, I wouldn't work for MS.

    -"Zow"

  • by jjr ( 6873 ) on Thursday March 22, 2001 @12:12PM (#346369) Homepage
    We can not only have one company to handle Digital Signatures. The internet community should create a non profit company to help with this problem. I am assuming that Microsoft is not the only company that this has happened to.
  • Guys, Microsoft is not nearly as evil as you think it is. Yes, they had a track history, and yes clearly Bill Gates is a dick, but there are a lot of cool OS and game programmers, and hardware specialists that put out some wicked shit. You have to separate the company from the nerds like you and me.

    So... why don't you? You're essentially saying that ``the compnay is nerds like you and me'' but really, how much of the company's personality comes from said nerds, and how much from obsessively competitive people like William Henry Gates III?

    Time and time again, reading the testimony of ex-Microserfs, you see statements like ``we adopted the Microsoft culture'' which was...? Nerdism? Gentle altruism? Quiet pride? No, it was always obsession, competition, fear, elitism (FY-IFV badges), a cog-in-the-machine mentality.

    You may fervently hope otherwise, but Microsoft is at heart an extension of Trey Gates, not a collective manifestation of geek culture with a few management problems. It has a track record, not ``had'' one. The mentality which gave it that criminal record is what drives Microsoft along. Separating Microsoft from their history is like unto separating the eggs from a well-cooked omelette. Remember the parable of the frog and the scorpion.

    Much better to separate the nerds from the company, than the company from the nerds. That way, the nerds won't be so badly hurt when Microsoft bluescreens, which I suspect will happen with shocking speed.

  • You can get mod_ssl to send the user to a page that quietly uploads your self-signed cert into their browser anyway.

    I think I should make up a CA called `Microsott Corporation' to self-sign these things with... (-:

    The idea of an Open CA is a good one, but... how do we get M$ to include them in the list of trusted authorities within IE? A website with an audit trail of the emails/letters/transcripts from such an attempt would be interesting. (-:
  • What's funny about the situation with washirv (the original poster) is that, OK, he's got a copy of the public key. But what good is that going to do him? Without the originally generated secret key, the server can't verify itself to incoming SSL connections.

    The information he got from Verisign was almost useless, and his company will have to shell out another $500 for a new certificate (which as someone else pointed out isn't a bad idea anyway).

  • Well M$ didn't screw up this one. However, this story is the clearest example of a future nightmare scenario. Imagine if such things happen under the promiscuity of the .NET overworld? No even this case might not be M$ screwing up everything. No, not directly.

    However it is the WAY these things are set up. On how corp's deal with each other. On how systems and users are protected from everything except corporative interests. On how corp's try to gather everything into a weird electronic Mega-Bazaar. Do you think this is not so dangerous?

    Note just how fast they reacted to this. It happened in January. If I'm not mstaken we are already a week before Mars ends. Can anyone be sure that these certificates were not used already?
  • Don't trust certificates issued by VeriSign?

    Then who will you trust?


    Who will trust the trustees????

    --

  • Microsoft and said authority didn't think of this, and so they now have to come up with a totally kludgey patch which they promise won't break anything else.

    Half right. VeriSign *DID* think of this, and followed the documented standard protocol to revoke the certificate.

    Microsoft has chosen not to implement a protocol to accept those revocations. That isn't VeriSign's fault, that's 100% grade-a Redmond stupidity, stemming from the facts that:

    1) Their security people come from a Windows world.

    2) More importantly, their marketing people write checks the programmers can't cash.

    Don't blame VeriSign for this, it weakens your case on all the other things you might choose to blame them for. :-)

    -
  • the fact that this one is a *different* Microsoft Certificate means you will still be prompted to trust it.

    That's all well and good - until I need to install a new system. If I've never run windows update before, and have never been asked to accept a microsoft certificate, how do i know the one i'm receiving is really from microsoft, and not a man-in-the-middle attack, or a dns-spoof?

    --Cycon

  • We trusted MS Before?! Did i blink and miss something?

    Actually, yes I trust Microsoft. To a limited degree, anyway. I decided years ago that if I was going to play in MS's sandbox, I'd play by their rules. It was just too fscking hard to install Unix-like utilities, editors, and what-not, just to have the whole house of cards come tumbling down because something expects filename case sensitivity or bare LFs or some other niggling little detail.

    I went through a period of trying to do things "the right way" -- Backing up old versions of software before installing new, stuff like that. And you know, that didn't work either. Because unless you get all the crap they put in the Windows directory and the registry, you're screwed when you try to back out a change anyway.

    So, when in Microsoft, do as Bill Gates does. I'll let programs crap all over the Windows directory and registry. I'll take everything offered by Windows Update. It's the MS way. It's stupid, it's insane, it's plainly the wrong way to design an OS, but you gotta play by the OS's rules or you'll go insane. (I'd have the same problems trying to apply MS or Mac conventions to the Unix world. It just don't work that way.)

    So, yeah. I've trusted MS far enough to install their OS on my machine, I may as well trust 'em to give me an ActiveX component now and then.

    But never, ever, ever install the Comet Cursor!


    Chelloveck
  • Open Source developers aren't immune either. Occassionaly, some rogue hacker inserts malicious code into the linux kernel or utility source. If undetected, we may all be compiling in those changes and thereby compromising our systems as well.

    OK, back that up with some actual facts . . . Still waiting . . . OK the fact is this has never happened or even been attempted (yet). Quit with all your over-dramatized, emotional statements, please.

  • There are lots of Class 1 certs [verisign.com] (search under Option 2 for Microsoft) issued under the OU 'Microsoft' that are obviously invalid. Class 1 certs are only email-verified, so, it's certainly a caveat emptor world with Class 1s...

    Anyone have any lead on the certs we should be avoiding? Are they on their CRL (even though codesigning wisely (cough) doesn't check the CRL)?
  • Whenever you find yourself thinking "Slashdot sucks", just step back for a moment and try to figure out where you went wrong in your train of thought. It's usually one of four things:
    • You were suckered into thinking that Microsoft was not truly evil, possibly by an article on MSNBC or ZDNet. Take note: All your media are belong to Microsoft.
    • You were suckered into thinking that Linux, open source, or free software is less than perfect in some way. See above.
    • You were reading an article written by Jon Katz. I have to admit, this is strong evidence that /. sucks. Happily, you can set your user profile to filter out such articles.
    Therefore, /. doesn't suck. QED.
  • This sounds like a serious fraud charge might be hanging over his head. I wonder if the FBI is on the case. And can they trust that the perp hasn't modified Carnivore using his MS Cert?
  • by McAlister ( 20810 ) on Thursday March 22, 2001 @12:12PM (#346395) Homepage
    Ok...I hope this finally get's Microsoft and Verisign out of their complacent moods, and prompts them both to implement Certificate Revocation Lists capability that WORKS in all of thier offerings -

    It is because they haven't bothered to do this yet that this is possible - think about it - if CRLs were implemented, and every application that used Certs checked the Revocation list of the issuing CA, this problem would have a trivial solution - Revoke the Cert, and this "fraudulent" issued cert becomes useless.

    But since Microsoft, Netscape/AOL, and most other vendors of Certificate aware software haven't bothered until VERY recently to even think of the CRL, then this is now a rather large problem...
    ame)

    Anyways... I hope this causes them to go and actually implement RFC compliant CRL capabilities in all of their products - would make those of us who work with them VERY happy....

    McAlister
  • I was looking on MicroSoft's website, and saw this:

    Microsoft tested the following products to assess whether they are affected by this vulnerability. We will waive normal support guidelines to provide remediation for all operating systems that are still in widespread use, regardless of whether they are normally supported or not.

    * Microsoft Windows 95

    * Microsoft Windows 98

    * Microsoft Windows Me

    * Microsoft Windows NT 4.0

    * Microsoft Windows 2000


    Now, maybe I'm wrong here. But it seems to me that this problem affects other operating systems, not just windows. What about windows 3.11? While it is mostly phased out, it would affect anyone using it who happened apon a website that had these certificates on them. What about a linux or mac user? It certainly would also affect them if they came apon the website. Now, to my knowlden, MS doesn't make any linux software, so it doesn't do anything with ActiveX, but what about Macs? There are versions of Office for macs, wouldn't it affect them? Seems to me that someone was a bit cloud headed when they wrote this.

  • by MindStalker ( 22827 ) <mindstalker@@@gmail...com> on Thursday March 22, 2001 @12:16PM (#346399) Journal
    Actually its only accepts code also signed by the identical certificate as this is a different certificate but the same name it would not automatically accept it based on a previous acceptance of "Microsoft"
  • Following the instructions in the warning, I'll beware of stuff from ?Microsoft Corporation?, as opposed to "Microsoft Corporation".
  • by SEWilco ( 27983 ) on Thursday March 22, 2001 @04:06PM (#346403) Journal
    No, it's due to the effects of the nonstandard "smart quotes [rainmaker.iki.fi]" plague.
  • From the article that's linked:
    VeriSign has revoked the certificates, and they are listed in VeriSign's current Certificate Revocation List (CRL). However, because VeriSign's code-signing certificates do not specify a CRL Distribution Point (CDP), it is not possible for any browser's CRL-checking mechanism to download the VeriSign CRL and use it. Microsoft is developing an update that rectifies this problem. The update package includes a CRL containing the two certificates, and an installable revocation handler that consults the CRL on the local machine, rather than attempting to use the CDP mechanism.

    It seems that VeriSign really dropped the ball here by first not properly verifying the submitter, then by not providing a way of getting a revokation out in the case they made a mistake. This is just poor planning overall.

    Not that I'm surprised, they also own Network Solutions [netsol.com]... birds of a feather.

  • by DJGreg ( 28663 ) on Thursday March 22, 2001 @12:18PM (#346406)

    This goes great with this [slashdot.org] article from a couple of days ago.

    I used to think that the whole idea of paying a shitload of money to goons like Verisign was that you could trust the certificates issued by them. If they make mistakes like this, how can I trust them anymore? Furthermore, how can I trust the certificate any ecommerce site that uses their certificates?

    This is a huge problem for all CA's if this is a precedent. I'm really curious to see what, if anything, Verisign will do about this.

  • Forget CRLs, they should just create some nice OCSP responders, so everybody can be *really* sure that the certificate they are being presented is still valid.

    OCSP = online status checking protocol

    This means that instead of checking your cert against a huge CRL (that you have to download every day) you just query the appropriate OCSP responder for that issuer, and you do a realtime query.

    The dialog should be of the type:

    software xyz presented certificate abc: what do you want me to do?

    accept cert refuse cert check cert cancel

    where 'check cert' does a query. Problem with this approach is that they have to beef up their hardware to handle all these requests, but if you don't care if the cert is valid at all, why even bother with certs in the first place.
  • Sure, just install Service Pack 7, followed by Service Pack 3, Service Pack 6, then Service Pack 7 again. Now, delete everything in your Windows directory, and your "My Documents" directory, and the auto-restore will change your state so that it asks who to trust again.

    This post is Verisign certified Microsoft content. Trust us, it will work. Really.
    ---
  • &nbsp

    CRLs are the nuclear waste of the PKI industry.

    They never go away, they keep getting larger, and eventually, there will be no place to keep them :-)

  • by Shotgun ( 30919 ) on Thursday March 22, 2001 @12:20PM (#346411)
    The problem with any encryption system, neigh any protection system at all, is the point at which they break.

    They super heavy deadbolts on my front door are useless if I pass out they key. The electronic security system is just a bunch of lights and buzzers if I give out the passcode or everyone ignores it. The extra heavy combination lock is just dead weight if the hinges of the safe are on the outside of the door.

    Public Key cryptography is only as strong as the security on the key. The article says that this doesn't fit the strict definition of a security vulnerability, presumably because it doesn't break the software. Well, I'd like to disagree. Part of the product, part of what M$ sells with the promotion of signed inActiveX controls, is that the pieces of code are trusted. This is not a piece of software they are selling, it's an entire system. The software is only part of it. The system has been broken. This makes it a security vulnerability in the same way that giving out keys to my front door and the combination to my safe are security vulnerabilities.

    The gist of my rant, and the point I'm trying to convey, is that systems are more than just the software. To concentrate only on one part of the system when defining terms to describe the safety of the whole system is foolish.

  • Gee, one thinks they should have encoded the web site domain in the certificate so browsers could immediately reject a Microsoft certificate not from microsoft.com

    It's a code-signing certificate. Not a certificate for a web site.

    Even then, people have thought of this problem. That's why you revoke certificates. The only problem is that Microsoft doesn't check for revoked certificates. This has been brought up before, with no action on Microsoft's part... until now, when it's too late.
  • by Stavr0 ( 35032 ) on Thursday March 22, 2001 @12:07PM (#346414) Homepage Journal
    Don't trust certificates issued by VeriSign

    I dunno, but it seems to me that they have the bigger problem. We put our trust in VeriSign to properly identify people requesting certificates. That trust has been broken now.
    ---

  • by mpe ( 36238 )
    The real question is, why is this story posted under Microsoft at all? Clearly Verisign made the mistake.

    A few days back we had the whole thing about "why are these certificates so expensive".
    Self evidently their procedures for checking are (or were) insufficent.
  • by macpeep ( 36699 ) on Thursday March 22, 2001 @12:20PM (#346416)
    It's not a problem. The "always trust content from ...." is not on a name basis but on a certificate basis. These phoney (or any other) certificates won't automatically be accepted.
  • by Greg@RageNet ( 39860 ) on Thursday March 22, 2001 @12:11PM (#346419) Homepage
    Guess the problem here is that it should have always been up to the end user as to which certificate signing authorities to trust, rather than for software manufacturers to decide for us. At least browsers are getting better, before if they saw a certificate that the browser didn't trust it would reject it outright.

    But nowadays if a company becomes untrustworthy through malicious intent or just plain incompetence it's not possible for users to 'un-trust' a certificate authority trusted by the browser/software manufacturers.

    There should be a higher degree of control at the end-user as to which CA's are trusted.

    -- Greg

  • I was just wondering -- when one of those VeriSign things pop-up, you have an options to check "Always Trust Xyz Corp". If users have already done this - will this setting apply to ALL certs from Xyz Corp, or just Certs dated before the current date? I am wondering if that prompt is authorizing all certs from a company - or a subset ( by date or by class, etc)? Anyone know?
  • We trusted MS Before?! Did i blink and miss something?
    No. but now you can't be sued for saying:
    "Microsoft -- a name that you shouldn't trust.".
    --
  • The problem is two-fold:
    • Verisign did not provide a Certificate Distribution Point (CDP) that is supposed to be used to get a CRL for each cert from. i.e. programs wouldn't know where to look for the CRL.
    • Even if Verisign had provided a CDP, it would appear that Microsoft software doesn't pay much attention to them, anyways.
      It would appear that as a result of this, MS is also providing users with the ability to supply personal CRLs. -- Not that I'm paranoid enough to probably ever need to build one, but you never know
    Some of you may wonder why we actually need a CDP? Why can't we just always check Verisign's database for revocation lists? The answer is obvious if you look in the security window of your browser. There should be a couple dozen certificate authorities listed there -- and there may be thousands of private certificate sources out there as well (including self-signed certs). It would be horribly expensive to have to search all known CRL databases for every cert you look at.

    With a CDP, the Certificate sitner is telling you who they are, and where to find the CRL for that cert. This makes it computationally feasible to check the CRLs for each cert (presuming that you're online!). It would also (presumably) make it possible for a certificate authority to segment their database, and provide different search points for various groupings of certs -- thus minimizing the work needed for any database serving up CRLs.
    --

  • > from what little I read the person who fraudulently claimed to represent Msft might be in some serious trouble.

    ...and this stops others from misusing the fraudulently-obtained certificate... how?

    Sure, MSFT will have a patch out for W95 through XP. But given the number of Solaris boxen out there still running Sendmail 8.6 - how likely is it that every Joe-average windoze luzer in the world will apply the patch?

    Someone's gonna make a lot of money off this cert. Illegally, yeah. But it's gonna happen. Given the bits about the organized cracking attempt made on the banks recently, this scares the living fuck out of me.

  • > So even though VeriSign lists the certificates in their CRL, they don't provide a way for the browser's CRL-checking mechanism to check it. Looks like its still VeriSign's fault.

    s/still/operating to spec, and as designed from Day One, this design flaw always was/g

  • > Do they want to wait until the next cracker to deface the front page of Altavista or Yahoo adds an ActiveX virus and wipes out (quite easily) ten million machines?

    Stop thinking "cracker", "portal page", and "0wn j00", and start thinking "criminal", "financial institution", and... well, "0wn" is the right word, isn't it?

    Nobody takes the kind of risk this guy took without a reasonable expectation of reward. The individual(s) who got the certs is probably not the group who ultimately intends to use them.

  • > I betcha it was the NSA who did this, trying to put their backdoor on Windows systems!!

    Actually, the first thing that went through my mind was "I'm glad NSA is gonna be all over this."

    The number of users likely to click "yes" to the question "Always trust certificates from Microsoft Corporation" is staggeringly high. In the absence of a viable CRL (certificate revocation) capability in browsers, these certs, if (when?) they fall into the wrong hands, are dangerous weapons.

    If the "wrong hands" are organized criminals, the stability of the banking system could be at risk. If the "wrong hands" are agents of another government, it could get even worse.

  • Funny how this story would probably be rejected if 'Microsoft' didn't figure in it somewhere...
  • by CmdrPinkTaco ( 63423 ) <emericle AT chubberware DOT com> on Thursday March 22, 2001 @01:01PM (#346437) Homepage
    The only truly effective answer to the question "who watches the watchers" must be "the public themselves".

    pardon my ignorance but is there an "open / free" (im using the terms loosely and not interchangebly) CA out there? I know that there was an Ask Slashdot about why SSL Certs are so expensive (here [slashdot.org] for the curious). I agree with the position that certs are issued typically for piece of mind, but would it be practical to implement an open standard of secure communication specifically for browser / server communications or is SSH adequate for this? Obviously Im not a security expert, but I am a concerned person who would rather place their trust in an open standard than in a hidden company that requires "blind faith"
    --------
    "Counting in octal is just likst counting in decimal--if you don't use your thumbs."
  • by The-Pheon ( 65392 ) on Thursday March 22, 2001 @12:24PM (#346438) Homepage
    Don't trust certificates issued by VeriSign?

    Then who will you trust?

    With the amount of money verisign requires you to pay for their various types of certificates, you would think that they could take the proper steps to ensure that the application is valid? A phonecall to the posted number for the company perhaps?

    Running a script to generate a key does not cost hundreds of dollars, we are paying for the extra for the cost of validation. I expect Verisign to DO that validating!

  • Aren't the certificates actually tied to the URLs? I thought the browser was suppossed to see the certificate, then check with Verisign (or whoever) to see that the certificate matches the URL it came from. Can't the certificate then be denied when the browser polls Verisign? Or is it the certificate itself that is "signed", with Verisign's seal of approval?

    If your browser doesn't at least do something to actively "ask" the Authority about the certificate, the system seems broken internally. It may be hard to forge a certificate, but it's not impossible (although I don't know if anyone has that sort of computing power lying around). Still, you could make up a lot of wasted time in the time a fraudulent ticket would be working.

    Oh well.
  • If I recall, there was an issue about a month ago where DNS entries were falsified by a foreign ISP resulting in web traffic being redirected (presumably to their servers).

    If Microsoft has been compromised as of Jan 30th, what's the probability that their software updates website has been spoofed? Even if it hasn't happened, its food for thought.

    And, if this event has occurred, all MS users could be effectively fsck'd if those "critical" updates were trojan in nature (or worse). Imagine the implications if your PC were happily sending all your correspondence, stock trades and other financial transactions to a foreign power. Imagine if you are a DOD or gov't employee or contractor (Or a high ranking politician). The potential for cyber-terrorism from this incident is rather extreme.

    Not that I'm an alarmist or anything....but when did the stock market start taking a dive?

    RD
  • Alas, Outlook does not check CRLs (hence the need for a patch). Makes you feel real comfortable, doesn't it?

    RD
  • News of the latest Microsoft compromise should send shivers down all of our spines and makes us wonder if we are under cyberattack.

    Some may argue that our PKI infrastructure is in need of review. Whether or not this is true, clearly we must consider whether the products we use can be considered safe. Microsoft is aggressively patching a hole in their Outlook product so that certificates can be checked against so-called "Certificate Revocation Lists". And, while many think CRLs are new, they are not. The specification for CRL's has been available since at least November, 1993. So, why has a critical feature of PKI infrastruction been overlooked?

    The pattern of attack against Microsoft began last year. In an article "Microsoft Hack wasn't espionage" by Kevin Mitnick (Nov. 5, 2000), Kevin point out;

    "Most newsworthy was the possibility that Microsoft's highly guarded source code was compromised and possibly misappropriated. The Wall Stree Journal reported that the hacker might have had access to Windows or Office 2000 source code...Only the hacker and, quite possibly, Microsoft know the real truth."

    Today, on Security Focus, there's another article with the headline "White House: Hack attacks are new cold ware". The author, for those interested, is Kevin Poulsan.

    In this article, it is stated that "Virtually every vital service- water supply, transportation, energy, banking and finance, telecommunications, public health -- all of these rely upon computers and fiber optic lines, switches and the routers that connect them. Corrupt those networks and you distrupt this nation.", Condoleezza Rice.

    Our nation runs on computers. Many critical infrastructure systems can be compromised by the simple dismissal of a security warning about a "Microsoft Certificate". But, has anyone stopped to think that we may already been compromised?

    Bind, that daemon that tells computers where to locate a resource, has been discovered to have flaws. Less than a month ago, there was a big concern that a well planned attack could take down the internet as we know it. If one recalls, there was an incident where an ISP on a South Pacific Island introducted false DNS data to redirect traffic to "their" servers.

    If one of those servers was a spoofed "Microsoft Update" site and people casually dismissed that security warning that may have popped up on their screens (Hey, it's from Microsoft, right), millions may have download malicious code right into their operating systems, word processors, or whatever. Given the fact that the source code for Microsoft's OS and Word products may have been compromised in the fall of last year, it would give ample time to develop a functional trojan disguised as a security update or critical update.

    Open Source developers aren't immune either. Occassionaly, some rogue hacker inserts malicious code into the linux kernel or utility source. If undetected, we may all be compiling in those changes and thereby compromising our systems as well.

    Clearly, something needs to be done. Software that uses PKI must check CRLs for starters. Certificate vendors need to check identification a bit more closely. And, legislation must be enacted to reduce the liability to individuals whose digital certificates may have been compromised. Finally, the punishment for illegal use of a computer system and intentional computer virus, release should be punishable by severe mandatory sentences (20-25 years would be a start).

    I have never been a strong advocate for cyberpolice. But, as the frequency of attacks and the damage estimates rise, it makes one wonder.

    RD

  • Sorry, you are incorrect. About a year and a half ago, somebody made alterations to a common utility (I don't remember which...sorry...but maybe somebody else out there does remember). The code was posted in CVS and downloaded by thousands before it was caught.

    Fortunately, it *WAS* caught and the situation rectified by removing the malicious code and reposting on CVS. But, *IT* did get out there. Whenever you have a lot of complex code and many fingers in the pie, this situation can and does occur.

    So, before you condemn me for my opinions, jump off your high horse and get a grasp on reality.

    The argument that there are more eyes on the code and somebody will catch it is not necesarrily true. If the code looks beneign or appears to work as expected, that code probably will not be inspected.

    Open Source, while a wonderful thing, is not immune to sculdugery any more than proprietary code if vigilence is not maintained to keep the code pure.
  • What world are you in? I know of very very facilities where there isn't at least one computer connected to the internet in some fashion. Plus, it isn't necesarrily the internet from where the intrusion will occur.

    While I was in the military, we had a virus problem. We installed AV software on all machines. Every disk was scanned prior to sending them to the shore based communication facility.

    Yet, invariably, when the disks were returned to us and we prepared new messages, the virus was back. As it turned out, the virus was on a PC at the communications facility and they were spreading it unwittingly. The internet was only an academic oddity then...so where do you think the virus came from?

    Major corporations use MS software. Vigilent administrators are always downloading the latest security or critical update to keep their systems in top form.

    The fact that the identity theft was not made public for almost two months is a scary thing. This means that if the original MS intruder got the OS or Word source code in the fall, they had plenty of time to make malicious modification.

    Couple this with the hiccups on the web lately (DNS and router problems at major ISPs), and there is the potential for some serious damage to have been done. Has it? I don't know.

    Similarly, if somebody managed to get a modified service pack out there, it could easily spread before the dame is realized just by the sheer goodwill nature of many admins to help others.

    Scaremongery? In some respects, yes. But, the fact remains that our systems are vulnerable and only due vigilence will slow the tide of hacker attacks. For this potential scare, I do blame MS as they have known their identity has been compromised and their software does not handle CRLs. I blame Verisign for nonchalantly issuing a certificate in Microsoft's name without proper identify verification. As a result, there is a window of opportunity for damage to occur.

    That so called "spanner in the works" could be as simple as somebody unwittingly upgrading their systems will altered software or having played a game with an embedded trojan program during those dull moments.

    The manual control you refer to only applies if people are cognizant that there is a problem. If the altered software makes all appear fine, then you've got a real problem. Don't you? Now, couple this with undermanned facilities during the late night shift...get the point now?

    It happend ten years ago on a military installation. Why can't it happen in the civilian workplace?
  • I mean.. Verisign TRUSTED that the person was really from Microsoft...

    What more do you want?
  • Given Microsoft's unique position in the browser marketplace, why do they not run their own certificate servers and include themselves as one of the default certificate authorities ?

    It's not as if they show much concern about breaking compatibility with other browsers (even earlier versions of their own) so what's going on ?

  • > The security depends on you maintaining the secrecy of your private key. That was generated by your engineer on the server itself and VeriSign would never see it.

    But the engineer who had left could very well have taken a copy for himself; and use that for his advantage one day...

  • A while ago I checked a checkbox labelled "Always trust content from Microsoft Corporation". Is it possible to undo that?
  • Ever read the warranty that comes with anything from Verisign? They won't even warrant that their certificates actually represent the individuals or organization that they claim they represent.
  • I don't know about IE, but Netscape most certainly does allow the user direct control over what root CA's he or she trusts. The default is set up for you to trust all of the normal ones, but go to:

    • Communicator
    • Tools
    • Security Info
    • Select 'Signers'
    • Click the certificate in question
    • Click 'Edit'
    • Change your trust buttons

    That is all there is to it...

  • by Billy Bo Bob ( 87919 ) on Thursday March 22, 2001 @01:50PM (#346463)
    Actually, MS has a good share of the blame here. Two things which make this an effective hack:
    • The lack of CRL support. This is largely MS's fault (no in there) and Verisign's fault (no CDP)
    • The all or nothing trust model. This is seriously flawed; you do not get the option of letting a control have a 'little' access.
    Both share a good bit of the blame. OTOH, it is more fun to just bash MS.
  • by nublord ( 88026 ) on Thursday March 22, 2001 @12:05PM (#346464)
    Guess we need another layer of certificates to verify VeriSign, Inc.

    Yes, I'm joking.

  • Good question. Microsoft is playing a dual role here. One, Microsoft was the company whose identity was stolen and Two, Microsoft makes the operating system. To make it easier to think about, suppose that it was Oracle Corporations identity that was accidentally stolen instead. Microsoft would still (assuming they cared) be issuing the patches to allow users to distinguish between the real and the revoked certificates and other OS vendors would be responsible for issuing the patches to their OSes
  • (From the NTBUGTRAQ) Despite the fact that its a Microsoft Certificate (for all intents and purposes it appears as such), it WILL NOT automatically be trusted by anyone's system. Even if you have previously stated that you want to trust all signed software from Microsoft, the fact that this one is a *different* Microsoft Certificate means you will still be prompted to trust it.
    So it's still a big deal, but if you keep that little bit of knowledge in hand, you wont have to worry (to much)

    ----------------------------------
  • The trouble with all this is: how can VeriSign (or any other CA) verify individuals' IDs? How can VeriSign (or any other CA) verify a corporation's officers' IDs?

    The answer: they can't do as good a job as government agencies can.

    Governments make ideal CAs: they issue birth certificates, drivers licenses, passports and they are, or tend to be distributed. I.e., different govt agencies issue different ID docs and can verify each other's documents, usually by requiring people to submit multiple IDs from different sources -- the idea being that to fake your ID you must fake ID documents from multiple agencies, a task that is, hopefully difficult.

    Ultimately you can only approach 100% certainty of a person's ID, and the best way to do it is by requiring and reviewing multiple claims of ID from different sources. A birth certificate can be validated by contacting the issuing authority. A driver's license can be validated by checking the picture on it and then checking the license's validity with the license's issuer. Hopefully the issuers are well-known and hopefully the communications with them are somewhat secure (circularity rears its head). And so on.

    In fact, DMVs (Dept. of Motor Vehicles) in the States (ok, New York's at least) have ID point systems whereby they assign different point totals to different kinds of IDs and require that you submit enough IDs to add up to a minimum ID point total in order to establish your ID to them. I think the U.S. Post Office does the same sort of thing for passport applications.

    So, IMHO, government agencies would make very good CAs. At least they should sell ID verification services to third party CAs (in a way they already do: notarys public can attest to an individual's ID and the notarys can be verified with the state and can be contacted by the CAs to verify their IDs).

    Of course, it would be nice if there were a smartcard standard that all citizens (of a country or of any country) could use and to which their governments could download certificates....

    But hey, even then, certificates can be stolen; passwords can be stolen; fingers can be cut off; people can be coerced into providing their biometrics ("stand in front of that retina scanner and act normal"); OS security can be broken and CA public keys modified/added.

    Oh well...

  • The upshot is this: even though the two bogus certificates say they are Microsoft certificates, they are not trusted by default. You are guaranteed to see the warning dialogue the first time you encounter a program signed using either of these certificates, and will continue to see it unless you select "Always trust content from Microsoft Corporation" in response to the warning dialogue.

    So does Microsoft seriously believe that the public, the same audience to which Microsoft caters as the "lowest common denominator" when developing such novelties as the talking paperclip, will suddenly divine an understanding of public key cryptography and the meaning behind these certificates? I think this might be the death knell for Microsoft as far as the ideas of "trust" and "security" are concerned.

    Good riddance.

  • Exactly my point also. If someone posing as a Microsoft employee would write you a bad check, would you then post a story saying that 'Microsoft has a bad credit history' or something similar?

    No, but I would expect my bank to have the capability to cancel a stolen credit card, by having the ability to check against a list of cancelled cards.

    The problem with IE is that it has no method of doing such a check on a Verisign certificate. Oh geez, IE isn't compatible with the #1 CA. Obviously, entirely the CA's fault.

    OK, it was human error on Verisign's part. However, it was caught by their internal people. It should be a dead story by now. That it isn't is largely MS's fault.

  • by Tom7 ( 102298 ) on Thursday March 22, 2001 @12:35PM (#346482) Homepage Journal
    That may sound like a bold statement, but if you think about it for a moment, can you ever trust an automated software update again, even a "secure" one?

    Yeah, maybe. Research is currently being done on how to do this without the idea of a trusted party. The general idea is that the code comes with a proof of its safety (or a proof that it meets some other specification), which is "easily" verified by a small piece of software on your computer. It's not a panacea (there is a world of difficulty in specifying the right policies), but it could certainly stop updates of application-level (or especially applet-level) software from containing naughtiness.

    Check out http://www.cs.cmu.edu/~petel/papers/pcc/pcc.html [cmu.edu] for more info on Proof Carrying Code.

  • All that checking that box does is to make the "accept" button the default instead of the "deny" button. it took me a few times to figure out what it was doing.
    =\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\ =\=\=\=\
  • All PKI does not suffer from this. All poorly implemented PKI does. Microsoft is in a very difficult situation here, and this is why:

    Verisign issued a certificate containing the Microsoft name, which it should not have. Most likely this is human error. This kind of thing happens all the time, from the inocuous (name misspelled) to the not-so-good (name of summer intern happens to be the same as the CEO). PKI has revocation options, including certificate revocation lists (CRLs) and online certificate status protocol (OCSP) to handle the case in which you want to stop trusting a certificate that you issued.

    So, Verisign issues the certificate, realizes that the dude doesn't work for Microsoft, and then revokes the certificate and calls Microsoft. Verisign has done their duty here, and although they get some of the blame for the initial certification, they have issued a revocation list containing these certificates. Verisign has now done its job.

    Unfortunately, Microsoft has crappy PKI capabilities in their products. It wasn't until Internet Explorer 5 that they could handle CRLs at all, and that's only in the case where the CRL is available over the web (HTTP:) and the certificate contains a pointer to its CRL (called a CRL distribution point or CDP).

    So, Microsoft's difficult situation is that they must now patch the client software on EVERY Microsoft client that uses Microsoft Crypto API (including IE, Office, and Win2K to name a few) in order to add this new CRL and be able to check it. If their PKI was able to check an OCSP responder at Verisign, or always knew that they could get Verisign CRLs from ldap://ldap.verisign.com, they wouldn't have to issue this press release and a patch at all.

    --Peter

    DISCLOSURE: I work for Entrust Technologies [entrust.com], a company which makes PKI software that does not suck.
  • by Wizard of OS ( 111213 ) on Thursday March 22, 2001 @12:05PM (#346489)
    What if i would own (I don't by the way ;-) the domain www.microsoff.nl. I register my company 'Microsoff' here in the netherlands, and claim I do window-cleaning (as long as the type of commerce you do is different, you can register a name here).

    It should be possible for me to get a Verisign certificate for 'the Microsoff corporation'. Most users won't notice this, so I can trick people into running my code.

    Is there anything that can be done against this? Has Microsoft trademarked all 'Microsoft'-alike names? Can Verisign refuse to give out a certificate?

    --
  • by alexburke ( 119254 ) <alex+slashdot@@@alexburke...ca> on Thursday March 22, 2001 @03:29PM (#346494)
    Don't Trust Code Signed by 'Microsoft Corporation'

    I've had that one covered for the last 18-24 months or so...

    --
  • This is all fine and dandy, assuming that you can personally be sure that all of the physical and transport layer connections between you and that host name, as well as the system which resolved the hostname are completely secure and trusted. Otherwise someone could see that you are downloading packets from host X and poof as host X, sending you packets that you now trust based on the host name only. After all, Microsoft has forgotten to renew a domain once before, who's to say they won't do it again? Only this time it might not be a white hat that fixes the problem.
  • by washirv ( 130045 ) on Thursday March 22, 2001 @01:57PM (#346499)
    The company that I used to work for bought a certificate from them for their https site. (yep the one that costs some $500 a year). Unfortunately, the engineer who had done all the certificate generation and signing had left the company, and when it came time to deploy the server, we couldn't find the certificate, and the engineer was vacationing in the Amazon forests or something: unreachable except by snail mail. So I called Verisign customer service, told them that I was calling on behalf of this company, the engineer had left so could they send me a copy of the certificate? The customer service representative goes: "Oh sure, what's your email address?". I give her my email and she emailed it to me. That was it! No id checking. No passphrases. Nothing. And they sent it to me in plaintext email.

    And the bastards charge money for this service.

  • by Otis_INF ( 130595 ) on Friday March 23, 2001 @12:29AM (#346500) Homepage
    Everyone can setup a certificate server and give out certificates. Do you check the contents of the certificates? most people don't. They just see "ah! A certificate! so it's ok!", while there is a possibility it's not ok.

    Verisign gave out the wrong certificates. If browsers now already have stored these certificates as 'safe', users should remove them, but it's VERISIGN's fault. They should have been more careful when they gave out the certificates. the person who now got the certificates could also have used 'Sun' or 'Red Hat' or any other company. Would that company then be 'the faulty'? NO.
    --

  • I infinity bad Japanese translation you!!!

  • by istartedi ( 132515 ) on Thursday March 22, 2001 @12:11PM (#346502) Journal

    This is a security story. The lock logo would have been more appropriate. Oh, wait... every time MS is mentioned on /. you get a spike in ad revenue. Carry on.

  • by Pakaran2 ( 138209 ) <windrunner@@@gmail...com> on Thursday March 22, 2001 @12:12PM (#346512)

    Who should read this bulletin: All customers using Microsoft® products.

    Impact of vulnerability: Attacker could digitally sign code using the name "Microsoft Corporation".

    Recommendation: All customers should follow the administrative procedures detailed in the FAQ. A software update will be issued shortly to provide permanent remediation.

    I find it very fascinating that MS doesn't mention anything about the hazards of running code from an unknown author.

    I would also hope that Verisign is taking a very serious look at their procedures - if CAs don't verify identities before issuing certificates, what good are they?

    For that matter, how were individuals - MS employees or not - given keys in the company's name? There's no need for an individual employee to have those - especially before calling to check with executives within the company.

  • by Fervent ( 178271 ) on Thursday March 22, 2001 @01:02PM (#346528)
    The real question is, why is this story posted under Microsoft at all? Clearly Verisign made the mistake. And the title "Don't Trust Code Signed by 'Microsoft Corporation" doesn't exactly help the situation.

    Guys, Microsoft is not nearly as evil as you think it is. Yes, they had a track history, and yes clearly Bill Gates is a dick, but there are a lot of cool OS and game programmers, and hardware specialists that put out some wicked shit. You have to separate the company from the nerds like you and me.

  • by jonfromspace ( 179394 ) <jonwilkins@NOSpaM.gmail.com> on Thursday March 22, 2001 @12:07PM (#346531)
    Hmmm... Verisign and Microsoft... now there's a team that just reaks of reliability!

    Surprised? - Not really
    Worried? - No more than yesterday
    Still accepting certs without EVER reading them? - You Bet Your Sweet Ass!!!

    It's not just an OS, It's an adventure!
  • by dR.fuZZo ( 187666 ) on Thursday March 22, 2001 @12:43PM (#346534)
    They make me send them multiple faxes and wait two weeks when I forgot my domain password, but some guy says he's from MS and that's good enough for them?
  • by sulli ( 195030 ) on Thursday March 22, 2001 @01:09PM (#346537) Journal
    This has happened with domain names too - someone claimed to be the Excite webmaster and pointed the Excite.com domain to nowhere a couple of years ago... Maybe they are in fact less secure when the customer is a Big Important Corporation with No Time to Waste!
  • by sulli ( 195030 ) on Thursday March 22, 2001 @12:30PM (#346538) Journal
    From the MS announcement, why PKI sucks:

    VeriSign has revoked the certificates, and they are listed in VeriSign's current Certificate Revocation List (CRL). However, because VeriSign's code-signing certificates do not specify a CRL Distribution Point (CDP), it is not possible for any browser's CRL-checking mechanism to download the VeriSign CRL and use it. Microsoft is developing an update that rectifies this problem. The update package includes a CRL containing the two certificates, and an installable revocation handler that consults the CRL on the local machine, rather than attempting to use the CDP mechanism.

    Translation: This cert is bad, but the authority issuing it can't tell you this, even though the authority claims to be responsible for doing so. Microsoft and said authority didn't think of this, and so they now have to come up with a totally kludgey patch which they promise won't break anything else.

    This is so fucking confusing even to someone who is fairly technical - can you imagine Joe User's reaction to this? Makes code signing pretty much useless.

  • by ExTycho ( 218077 ) on Thursday March 22, 2001 @12:04PM (#346545) Homepage
    We trusted MS Before?! Did i blink and miss something?
  • by HyperbolicParabaloid ( 220184 ) on Thursday March 22, 2001 @12:07PM (#346547) Journal
    This certainly adds a new dimension to recent /. discussions about what, exactly, you get when you pay for an expensive certificate!!


    -------------------------
  • by canning ( 228134 ) on Thursday March 22, 2001 @12:54PM (#346548) Homepage
    A software update is under development and will be released shortly. When it is available, we will update this bulletin to provide information on how to obtain and use it.

    What if the hacker(s) releases a patch before MS releases one?

  • by RareHeintz ( 244414 ) on Thursday March 22, 2001 @12:17PM (#346564) Homepage Journal
    If this doesn't wake people up to the problems with the very idea of certification authorities, I don't know what will. Any public key infrastructure hinging on trust of a central authority like this is doomed to fail, and in exactly this spectacular manner.

    That may sound like a bold statement, but if you think about it for a moment, can you ever trust an automated software update again, even a "secure" one?

    OK,
    - B
    --

  • by Mercaptan ( 257186 ) on Thursday March 22, 2001 @12:10PM (#346567) Homepage
    I know it's Verisign's fault, but it really doesn't make the consumer side of .NET sound very trustworthy. I understand they're going to be using Kerebos for the Hailstorm identity back-end, but clearly there's plenty of room for Microsoft to botch. They're well positioned (and well funded) to actually go head with it, but the question is how much will people trust Microsoft? Even paired up with AmEx?
  • by Zeinfeld ( 263942 ) on Thursday March 22, 2001 @02:06PM (#346584) Homepage
    So I called Verisign customer service, told them that I was calling on behalf of this company, the engineer had left so could they send me a copy of the certificate? The customer service representative goes: "Oh sure, what's your email address?". I give her my email and she emailed it to me. That was it! No id checking. No passphrases. Nothing. And they sent it to me in plaintext email.

    The certificate would also be in the VeriSign LDAP directory and would in any case be handed out to everyone who accesses your Web site using SSL

    With certificate based PKI the security does not lie in keeping the certificate secret. The purpose of the certificate is to authenticate your public key.

    The security depends on you maintaining the secrecy of your private key. That was generated by your engineer on the server itself and VeriSign would never see it.

    So calling up VeriSign and asking for a copy of the certificate does not constitute a security problem. It is like telling someone your PGP fingerprint, or someone downloading a keysigning from BAL's MIT key server or whatever it does not compromise your key.

  • by dachshund ( 300733 ) on Thursday March 22, 2001 @12:32PM (#346588)
    when one of those VeriSign things pop-up, you have an options to check "Always Trust Xyz Corp"

    That dialog refers to the organization that signed the certificate. Most browsers (at least, IE and Netscape) come equipped to trust any certificate signed by Verisign. When you go to a page with a Verisign cert, the browser will trust the certificate, regardless of what company actually owns it.

    Since in this case the certs were purchased from Verisign, your browser won't have any problem at all with them (it'll just assume that Verisign is trustworthy.) You won't get that dialog at all. If you look at the security info for that page, it'll show the page as registered to Microsoft corporation. Generally MS signs their own certificates, so it would be a little odd to see a cert owned by MS and signed by Verisign (although they may actually do this.)

  • by banuaba ( 308937 ) <drbork&hotmail,com> on Thursday March 22, 2001 @12:06PM (#346595)
    It's usually not hard to figure out if you're getting a MS product online.
    The files tend to come from domains like, oh, say, microsoft.com or mechwarrior4.com...
    Now, of course, if you are trying to download 'http://ftp.goatse.cx/hotgaypr0n.exe' and it's signed by MS you a) have other problems and b) deserve whatever you get if you accept the file.

    Of course, this is probably not too good for Verisign, as they now look like dumbasses, and have probably pissed off MS to boot.


    Brant
  • by Robert A. Heinlein ( 315073 ) on Thursday March 22, 2001 @12:58PM (#346596) Homepage
    Take a look at the requirements to get a Class 3 cert:

    http://www.verisign.com/repository/CPS/CPSCH2.HTM# _toc361806948 [verisign.com]

    http://www.verisign.com/products/asb/faq.html [verisign.com]

    Especially interseting is the Assurance level that comes with this cert.

    Even if these certiciates are never used, there will be some pretty heavy US govt. involvement as a result of this.

    Anyone know if this has happened with any companies less visible than MS? A quick search did not turn anything up, but if Versign's procedures could let something like this slip through...

  • Exactly my point also. If someone posing as a Microsoft employee would write you a bad check, would you then post a story saying that 'Microsoft has a bad credit history' or something similar? I'm exaggerating here a little but you get the idea.

    For some reason /. is assuming that Nerd=='someone who hates MS' and News for Nerds==Microsoft-bashing, using any means possible?

    Get a life and realize that there are actually many many pro-microsoft (or at least neutral) geeks out there also, who would sometimes rather like to read something where the primary goal would be to tell people about some interesting/cool stuff done by MS, not just bashing. Right now you are just missing all these potential readers who are getting news from more balanced sources elsewhere. Don't get me wrong, I think /. is very cool but it's really harming itself more this way.

E = MC ** 2 +- 3db

Working...