At 11:07 08.03.99 -0600, iversen wrote: >Oliver Lineham wrote: >> If this is how the zones are implemented, then its insane. If not, then >> IE's claim of being able to distinguish intranet sites from internet ones >> is an outright lie and the "feature" should be removed. > >This seems to be trivial to resolve - put everything in the internet zone >unless it matches a list containing the local intranets. Then do >reverse-dns >of everything that's allegedly inside the intranet and make sure everything >matches up. This is of course the correct way to implement an "intranet zone". It has, however, one serious drawback: you have to configure it. Consumer product manufacturers like Microsoft want their product to work as much "out of the box" as possible. However, IMHO there is no way to implement the concept of "intranet zone" reliably without actually telling the browser the exact extent of your intranet one way or other. Heuristics like "if there is no dot in the hostname then let's assume it is in the intranet" just aren't reliable enough to base a security mechanism on. At Mon, 8 Mar 1999 11:58:55 -0800, Paul Leach wrote: >I believe that the rule for Intranet zone is simple -- if the name has no >"." and is less than 15 characters long, then it's Intranet zone. This >algorithm works with the default configuration of Windows. If you configure >your machine so that the above assumption is violated, then you'll get a >mis-classification. It doesn't even work with the default configuration of Windows, because the basic assumption that every host with an FQDN in the same DNS domain as the client is also in the intranet zone is flawed. There are perfectly legitimate configurations where this is not the case. >When designing better ways of doing this, keep in mind that the primary tool >that the browser has to work with is "gethostbyname" -- which, IMO, doesn't >return enough information about how the name was resolved to be helpful for >security purposes (even though it garnered some in the process of >resolution). For example, it doesn't say whether /etc/hosts or LMHOSTS was >used to resolve the name, or which DNS search suffix was used. It is irrelevant how the name was resolved. You need a mechanism to specify the intended scope of your intranet unambiguously, instead of relying on some unspoken assumption like "for our purposes, 'intranet zone' will be taken to mean all hosts which happen to have at least one FQDN in the same domain as the client". -- Tilman Schmidt E-Mail: Tilman.Schmidtat_private (office) Sema Group Koeln, Germany tilmanat_private (private) "newfs leaves the filesystem in a well known state (empty)." - Henrik Nordstrom
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:38:25 PDT