Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Microsoft Software Apache

IE, Apache Clash on Web Standard 51

Posted by krow from the are-the-malicious,-or-just-idiots dept.
sbsea1 writes "Here is another instance where Microsoft is going one way and everybody else going to other. eWEEK Labs found that Microsoft is using a different implentation of digest authentication which differs from the W3C's digest authentication standards. Internet Explorer Version 5.0 and higher--as well as Microsoft's IIS Web server--has a significant security incompatibility with other major Web browsers and with the Apache Software Foundation's Apache HTTP Web server."
This discussion has been archived. No new comments can be posted.

IE, Apache Clash on Web Standard More

IE, Apache Clash on Web Standard

Comments Filter:

  • doesnt look that bad... (Score:5, Insightful)

    by jeffy124 ( 453342 ) on Tuesday March 19, 2002 @08:00PM (#3191388) Homepage Journal
    the article says that even MS spokespeople are admitting that it's a bug. I dont see it as anything to get all up in arms and angry about.
    • Blockquoth the poster:
      I dont see it as anything to get all up in arms and angry about.
      Remember, this is /. If it's about Microsoft and it goes against anything open or standard, then everyone will get pissy. If it were Netscape or Opera, then it will be passed of as a fluke.
      • oh i'm definitely aware of the anti-microsofties there are at /. I just think it's good to point out to those that skip straight to the comments that MS is taking it seriously and not trying to change the embrace/extend yet another standard like they have in the past, which was implied by the original poster: Here is another instance where Microsoft is going one way and everybody else going to other
        • <nod>

          It nice to see that Microsoft and the Apache group are able to work out the little bug or mis-implementation. I'm not thrilled nor very happy with Microsoft, but they aren't always at fault.

      • of course. I call it the religion of Stallmanism. Most religions need an icon of evil, something so unpure and unjust that it can do absolutely NO good, EVER. Microsoft is that icon for slashdot. :(

        I believe most of microsofts "flukes" are looked at in the wrong light here.. the way i see it, their "innovation" as they call it, is just a way for them to make my job as a sysadmin (okay.. so i don't have a job right now. damned economy.) easier by integrating their products together in the best way possible - most of their products still have some backwards compatable functionality..

    • It's not like Microsoft has ever done anything like this before. :) The proof is in the pudding, when it gets fixed then we can all talk about how they were malaigned. I am not going to hold my breath, however.
    • ...MS spokespeople are admitting that it's a bug...

      This incompatibility has been in place for about 2 years in IE, and is also built-in to IIS. That is not an oversite. That is yet another example of a company trying to pick and choose which standards they can disregard with impunity.

      Make no mistake, Microsoft aren't going to willingly "comply" with any technology or standard that facilitates fair competition.

    • the article says that even MS spokespeople are admitting that it's a bug. I dont see it as anything to get all up in arms and angry about.

      I am running Windows 3.1 beta on DR-DOS and I keep getting this "Non-fatal error" message. If Microsoft would only stop writing buggy software ;)
  • I hate Microsoft as much as the next Slashbot, but let's get the facts before we post frontpage Slashrants. It says, and I quote:

    We [microsoft] were told by the Apache group that it would support multiple digest protocols. The MS Digestion protocol just hasn't been implemented by Apache yet.

    In other words, like the libXML problem we all remember from last year, this is Apache's fault.

    • Where or freakin where is that quote in the article? I did read it and couldn't find that quote.
    • This is a bizarre interpretation. MS introduces
      an incompatible extension to a standardized
      protocol (as usual) and then when someone doesn't
      implement that proprietary extension, you fault
      them for it? I think you are using the word
      "fault" in some new monkeyboy sense.

      As is so very typical of Microsoft's "innovation",
      it is the pitiable consumers of MS software who
      suffer, and nobody gains except MS. Because of the
      prevalence of IE on corp desktops (declining, yes,
      but still a substantial prevalence), they can
      use this as an opportunity to push IIS, which
      implements the proprietary version of digest
      authentication compatibly with IE.

  • Clash on web standard? (Score:1, Redundant)

    by SteveX ( 5640 )
    Someone reported it to Microsoft and they admitted it's a bug. This is a clash?

    - Steve
    • > Someone reported it to Microsoft and they admitted it's a bug. This is a clash?

      I'd say that it is a clash in that obviously Microsoft did not then do compatibility testing with any non-MS products it seems. Not to mention that for everybody else to have interpreted some other way implies to me that there was discussion about the issue. Strangely enough, that's one of the purposes of the working group mailing lists, to help implementors iron out deficiencies in the spec.

      IIRC, the spec isn't supposed to become a true standard until there are two independent implementations. So, again, if MS had a question about an inconsistency in the spec, they should have been able to test against those implementations.

      -Robert
      • Hey, that works both ways!!

        Obviously the Apache Group did not do compatibility testing with the most popular browser on the net, either. Both sides (or, IMHO, none) are at fault on this.

        The fact is, this is a new standard that practically no-one is using in anger at the moment. Look at all the other incompatible implementations there have been of new RFCs. It happens all the time, not just with MS.

        This is a complete non-issue. "Today, a very early adopter of a new technology notified two software companies that they'd chosen incompatible interpretations of spec. The two companies agreed to make their implementation compatible in future."

        Yeah, big story.

        • Re:Clash on web standard? (Score:1, Insightful)

          by Anonymous Coward
          With digest authentication there is only one correct answer. If you can interop with anyone else, the chance you're wrong is vanishingly small. Why then is a nonprofit development team for free software supposed to pay a vendor money for the privilege of proving that vendor's employees aren't fit to read an RFC, when everyone pretty much already knew that? Microsoft blew it, and they would have known that if they had tested with anyone outside themselves.

  • Does anyone have any real information about the actual differences between how Microsoft and Apache are computing the message digest? The article does not say much. I know the Microsoft and Netscape used to have some interop problems because one implemenation (Netscape's, I think) would include a string's NUL terminator when computing a message digest. This would obviusly lead to a different result. :)

  • It's not a bug - it's a feature ;)

    Microsoft is not doing anything which other companies don't do. They are just too big to be ignored, that's the real problem.

    But that's our own fault. Why do we buy and use MS products? Why do we program for Microsoft (directly or indirectly)? Could be we all have the same motive$ as M$ has? And are just envious, because if M$ coughs, everyone else has a cold?

    No need to change a single line of code in Apache. Apache is the de-facto standard, not IIS.

    • Re:It's not a clash it's a discussion ;) (Score:1, Insightful)

      by Anonymous Coward
      But IE is the de-facto standard. IE isn't going anywhere for a while. Is Apache really willing to stare down IIS? If it does, there's the distinct possibility that it will be relegated to the niche non-Microsoft market.
      • I agree, IE is the de-facto standard for browsers.

        Hence it breaks down to standard browser against standard server.

        But there is no need to give up too early from Apache's side. The function is not in wide use yet and will not in the near future IMO. If a web apllication needs authenticication, it will probably also need encryption of the data somewhere down the menu-tree (if only to change the password). Allthough SSL has a higher price-tag (in dollars or cpu-cycles), it also has the advantage of being supported by practically all browsers.

        Time for discussions - not for early give-ins.
      • IE's hold as the de facto browser is based purely on demographics.

        Demographics change. Quickly.

        Hence, relying on IE as the de facto standard is pretty near-sighted.

        inkly
      • It's amazing what can be done when one has more money now than even Michael Jordon could make in 400 years. This isn't the first time MS is fucking w/apache. Anyone here tried to set up MS Media streaming and use .htaccess rewrite for security? Good luck! Hell, if your u/p is posted as part of your URL(http://user:pass@www.here.com) IE tries to download every image as untitled.bmp. WTF? How many anti-trust suits do we need? Evidently Bill doesn't have enough money to not be worried about a free OS that is far superior. It's like AOL trying to convince the world that setting up a PPP client is so hard that "AOL is so easy no wonder it's number one!" The new (old?) american motto "The truth is what I say it is!"

  • who cares about digest authentication anyway? (Score:4, Informative)

    by phr2 ( 545169 ) on Thursday March 21, 2002 @03:05AM (#3198944)
    Sending the digest in the clear still makes most user passwords vulnerable to offline dictionary search. Digest authentication was a kludge on top of HTTP basic authentication (which sends the naked password in the clear) designed at a time when SSL was scary and complicated and there were no free SSL web servers.

    These days, for casual passwords like /. logins, HTTP basic authentication is still usually good enough. For passwords that need real security, use mod_ssl [modssl.org] instead, which is easily added to Apache 1.3 and comes with Apache 2.0 by default, and do basic auth over SSL so the whole HTTP stream is encrypted including the password. HTTP digest authentication's security is sort of halfway between HTTP basic auth and HTTPS basic auth. As a halfway measure, it's not really that useful any more.

    • Re:who cares about digest authentication anyway? (Score:5, Informative)

      by Zeinfeld ( 263942 ) on Thursday March 21, 2002 @05:27PM (#3203779) Homepage
      Digest authentication was a kludge on top of HTTP basic authentication (which sends the naked password in the clear) designed at a time when SSL was scary and complicated and there were no free SSL web servers.

      SSL did not exist when I invented the Digest mechanism. The problem was the patent on RSA and Diffie Helleman.

      Digest was invented for one reason and one reason alone which was to provide a replacement for BASIC and avoid sending password in the clear.

      Microsoft implemented Digest first, but Netscape refused. This was before they hired a credible security person. They believed that sending passwords over the internet en-clair was a less important security issue than protecting the authentication information in the Web server storage.

      Microsoft removed Digest from IE in IE4 as Netscape refused to implement. Then the IETF stated that HTTP could not become a standard if it sent passwords en-clair at which point people pulled the draft out again.

      Removing Digest from IE was not a big issue for me since if only Microsoft was going to implement the standard they might as well use the NT password authentication scheme.

      The dictionary attack issue is important, but it was not possible to address it given the state of the IPR at the time. If Diffie Helleman had been available I would have designed the protocol entirely differently. It would have been possible to address security of the auth data on the wire and in storage.

      For passwords that need real security, use mod_ssl [modssl.org] instead, which is easily added to Apache 1.3 and comes with Apache 2.0 by default, and do basic auth over SSL so the whole HTTP stream is encrypted including the password. HTTP digest authentication's security is sort of halfway between HTTP basic auth and HTTPS basic auth.

      Actually I would recomend Digest over HTTPS. The problem with BASIC is that you have to trust the end point, that is fine if the application is such that the application justifies buying a certificate or securely distributing the point of trust.

      More generally however I would suggest people look at our more recent work in SAML (security services at www.oasis-open.org)

      • Thanks for the response, and I'm not saying Digest was badly designed. It was a reasonable response to the situation that existed at the time it was first proposed. It's just that the current situation isn't like that--SSL is easily available now.

        I don't understand "The problem with BASIC is you have to trust the end point", unless you mean you have to give them a password that you might also be using on other sites. Of course by even giving them the digest of the password, you let them mount an offline dictionary search. That means that the site also needs to keep the digest secret from attackers who might also want to do searches, so again you have to trust the site's security.

        I agree with Netscape that unencrypted BASIC is good enough for a lot of purposes (how bad is it if someone intercepts your Slashdot password and changes your user preferences?). Applications that need more security (online banking) need enough design attention that buying a certificate ($125/year) isn't that big a deal. Low traffic sites can always use self-signed certificates which cost nothing (but pop a browser dialog when the user first connects). Really high security applications should use SSL client certificates instead of passwords. That avoids the need for any shared secrets. If you really want to use passwords over an unencrypted channel, it's best to use a protocol like SRP [stanford.edu], though like SSL, SRP would have been a problem before the DH patent expired.

        Yes, if you look at the spectrum of all possible web applications, there's probably some examples where Digest is slightly preferable to the next best alternative, but with SSL easily available Digest just doesn't seem like a big deal any more.

        • Re:Digest vs HTTPS (Score:3, Interesting)

          by Zeinfeld ( 263942 )
          One of the main design issues for DIGEST was to eliminate BASIC from the spec entirely. There is no place for a spec that sends passwords en-clair.

          The problem is that most people, myself included share passwords across uses. I have something like 200 active authentication points, there is simply no way that I could remember 200 separate passwords if I tried. I have three passwords that I use for high medium and low security. But most people happily share their corposrate password with their WareZ site password.

          Although passwords inevitably involve a certain degree of information sharing, DIGEST is dfesigned to ensure that this is minimized. If you give a password to a site and the site is compromised the information stored in their database does not compromise any other site.

          The main problem with mechanisms such as SRP is that they are all aledgedly encumbered. The patents are also fairly new.

          • I'd thought that SRP wasn't patented, and the whole purpose of its development was to get around the EKE/SPEKE patents. If it's encumbered by different patents instead, well, thanks a lot dude :-(. But its license [stanford.edu] says it's unencumbered, and "What is SRP?" [stanford.edu] amplifies:
            SRP is available to commercial and non-commercial users under a royalty-free license. The Internet played a significant role in SRP's early development; without it, SRP would not have received anywhere near the amount of analysis and feedback that it has gotten since it was first proposed and refined. It is thus fitting that the Internet at large can benefit from the fruits of this endeavor. Since SRP also works around existing patents in the area, it gives everybody access to strong, unencumbered password authentication technology that can be put to a wide variety of uses.
            It's really isn't feasible to get rid of BASIC once BASIC is in a lot of browsers. It's not enough to get it out of the spec; it has to be removed from both browser and server implementations, and that won't happen. Browsers will keep it to interoperate with old servers and servers will keep it to interoperate with old browsers. So we're stuck with it forever. It's unfortunate that it was put into the spec in the first place instead of using something like Digest.
            • I'd thought that SRP wasn't patented, and the whole purpose of its development was to get around the EKE/SPEKE patents. If it's encumbered by different patents instead, well, thanks a lot dude :-(.

              One of the bastards that owns one of the other patents sent a patent troll letter to the IETF.

              It's really isn't feasible to get rid of BASIC once BASIC is in a lot of browsers.

              It wasn't when I wrote the spec, a week after they did BASIC. What happened was that they told me they were using RSA, then they found the patent issues were going to be too much of a problem and they did BASIC without actually mentioning the change of plan to me.

              The problem was that the people writing the code knew enough about security to be dangerous, but not enough to be useful. They had heard the UNIX encrypted password file argument and were applying to an inappropriate context. It was cargo cult security, slogans not thought.

  • I don't use Windows Authentication in my applications because it wont work in anything but IE. I guess the same can be said for digest.

    huper

Slashdot Top Deals

How many hardware guys does it take to change a light bulb? "Well the diagnostics say it's fine buddy, so it's a software problem."

Close