Dan

<Warning Long Story --- mainly for Steve Riley {MSFT} benefit as well as
anyone interested and caring enough not to give some smart aleck response}:->

Thanks BD. I am going to start ignoring Paul because the fact is the
Albuquerque Public School Network was hacked in the middle of 2007 and Paul
continues to be rude to me unlike other mvps. The fact is that my Windows XP
SP 2 fully updated was hacked when connected via VPN (Virtual Private
Networking). The fact is that it was APS's fault due to default and not
secure domain settings on their end and their server(s) end. APS just used
all the default settings and images to set things up. When I worked there in
2006-2007, the Network at the elementary school was a mess. I worked very
hard with Stephanie H. the networking admin. to hack into the computers that
previous staff had left fully in locked mode and unusuable mode by the
students. It was so locked down there that it made me think of being on a
military base kinda. Stephanie H. explained that former workers had left the
computers in such a mess because they were angry at APS for firing them from
their jobs and of course would not hurt the children so hurt the children's
tool for learning which was the computers.

Chris Quirke, mvp explained the whole situation very clearly to me of how XP
Home and Professional can be broken if the domain is not safeguarded properly
by custom settings and the appropriate hardware as well. I am glad that
people from southern Africa like Chris Quirke, mvp at least understand
internal safety of the consumer 9x source code which has the consumer
maintenance operating system of disk operating system and is built upon the
rock. Chris explained how with Windows XP Home and Professional the security
is external because it is based on the NT source code. The 9x source code
was completely perfected with Windows NT.

However, according to secunia.com and if you go back and research just plain
vanilla Windows NT you will see that it is as secure as 98 Second Edition
which shows us how the problem of extra services including especially remote
access leads to easy hacking capabilities thus showing us that we must go
back in time to the true and tried hardware methods that IBM used back in the
days of the IBM PC in the 1980's. In addition, I am contradicting myself
because I am just searching for the proper solution to the problems of safety
in electronics today. We need Microsoft and hopefully IBM to lead in the
hardware arena again and not just have IBM focus on businesses but start
caring about the little people like BD and I again who are the consumers.

Hardware is better than software I feel because software can be broken.
Parts of the NT source code were indeed leaked over the Internet back in the
day. Microsoft has nicely provided us with a 100+ page document on the
proper security and safety of Windows NT and Windows 98 computers. This is a
critical read for those to help understand the proper settings of the
situation we are currently in these days. The question is can hardware be
broken and Gary S. Terhune, mvp of 98 general newsgroup claims correctly that
it can be broken with the proper software and I feel this may be able to be
done by forcing the hardware to overload itself with the properly written
software programs forced unwilling upon the average joe or jill consumer(s).
The external security of NT (New Technology) business source code is great
within Windows Vista but if someone is able to bypass certain procedures one
can still inflict pain and hacking even upon Vista but it is indeed much
harder than XP. Vista does still lack in terms of backwards compatibility.
Even Windows 7 that is coming out is still NT source code based and it looks
like it may be kind of like Windows ME that broke lots of stuff in Windows 98
Second Edition but hopefully Microsoft can fix it well. Thus, we, BD, as
civillians are left with what alternatives. The current alternatives are
open source of course as well as closed source technologies. This shows us
that in my small and weak opinion the only future is harmony between internal
safe and external secure computing. The cloud computing is upon us but
nothing in my opinion beats having your backup on a seperate external hard
drive that you can move at a moment's notice if the situation arises.

Thus, I feel that Microsoft will indeed lead the way because Microsoft has
the resources. Microsoft has MAPP coming out in October which I am very
grateful for and it is a nice 3 easy step system which is a nice break for
consumers from DHS's more complicated methods on us-cert.gov.

The fault was on APS's side because APS used the "dumb" default settings.
Unfortunately, my Windows 98 Second Edition disappeared during the summer
because APS stupidly phased out Windows 98 Second Edition. They also did not
provide me with my computer. I did erase data on the computer but it is
indeed recoverable with the proper software and that computer did not have
any critical data on it anyway but my home computer with the dual-boot of 98
Second Edition on C:\ in Fat32 and XP Professional in NTFS on D:. Now, so
much for all the supposed external security of Windows XP Professional ---
fully updated on my end mind you. Now, the feds are involved with this
situation thankfully and DOD and DHS are involved as well as lawyers so a
resolution will happen eventually because not only my information but
students information at the Elementary School were compromised. I am indeed
working on a detailed report for the feds but it just takes time. Sorry,
Paul -much to your dismay I am sure-- Windows 98 Second Edition only suffered
a denial of service error which I recently posted here and at the 98 general
newsgroup and interestingly enough no one responded to it on either end
because probably only Bill Gates or the original Windows 98 second edition
team understands the errors involved.

Over and Out, Dan W.


"~BD~" wrote:

>
> "Paul Adare - MVP" <pkadare@gmail.com> wrote in message
> news:s5kai30oe5ub.tl3rblibm2lf.dlg@40tude.net...
> > On Tue, 26 Aug 2008 08:49:01 -0700, Dan wrote:
> >
> >> How about the problems on web sites with errors about missing scripts and
> >> lost objects and other stuff?
> >
> > The error you mentioned on the MSNBC site the other day was simply that, a
> > coding error on the web site, not some malicious attack as you stated in
> > your post.
> > You seem to think that the DNS poisoning issue is currently a big problem
> > and it simply is not.
> > You're like the proverbial man with a hammer, to him, everything looks
> > like
> > a nail.
> >
> > --
> > Paul Adare
> > MVP - Identity Lifecycle Manager
> > http://www.identit.ca
> > Variables won't; constants aren't. -- Osborn
>
>
> Paul,
>
> Your web site says "IdentIT is offering public training on ILM 2007
> Certificate Management. The course covers the fundamentals of ILM 2007
> Certificate Management and provides you with hands-on experience with the
> product before deploying ILM 2007 Certificate Management in your
> organization.
> The following dates have been booked for ILM 2007 Training:
>
> a.. Mississauga, Ontario, Canada - November 13 - 16, 2007 - Click here to
> register!
>
> b.. New York City, NY, USA - TBA"
>
> http://www.identit.ca/clm.html
>
> I've mentioned this before, but no action has been taken to correct matters
> (2007 has long gone!)
>
> Would you like to borrow a hammer? <wink>
>
> Dave
>
>
>
>
>
>
>
>
>

~BD~

You're welcome, Dan.

For the most part, I understand your posts - all of them!

Stick with it!

Dave

--
"Dan" <Dan@discussions.microsoft.com> wrote in message
news:FA0EE75A-8851-4F30-99E7-C763FFC05BFC@microsoft.com...
> <Warning Long Story --- mainly for Steve Riley {MSFT} benefit as well as
> anyone interested and caring enough not to give some smart aleck
> response}:->
>
> Thanks BD.

<snip>

FromTheRafters

Ahhh - I see. In fact it seems so obvious now - the word
"DUH" comes to mind. )

Thanks.

"Steve Riley [MSFT]" <steve.riley@microsoft.com> wrote in message
news:46EE9170-67E3-4792-A154-850CEDEF2E7E@microsoft.com...
> Cache poisoning is only a means to an end. The attacker's _real_ goal is
> to get you on his server rather than the one you actually want. So
> ensuring authenticity of the legitimate server is the proper defense here,
> rather than worrying about the plumbing. And we can accomplish that today
> with SSL and IPsec.
>
> --
> Steve Riley
> steve.riley@microsoft.com
> http://blogs.technet.com/steriley
> http://www.protectyourwindowsnetwork.com
>
>
>
> "FromTheRafters" <erratic@ne.rr.com> wrote in message
> news:er3ykC#BJHA.1228@TK2MSFTNGP02.phx.gbl...
>> Yeah, it is important. Akin to the way you should get
>> programs only from trusted sources. But how can
>> anyone verify the validity of the data returned? AV
>> is in place to stopgap the bad information from trusted
>> source issue when programs are the concern, do you
>> think it is completely unnecessary to stopgap the same
>> sort of thing for poisoned DNS data?
>>
>> Sure, if DNS poisoning is not very common, then there
>> is little risk - and crypto is like a 12gauge flyswatter.
>>
>> "Steve Riley [MSFT]" <steve.riley@microsoft.com> wrote in message
>> news:840985B2-477A-4757-BBC2-852DD7EBDEF1@microsoft.com...
>>> Signed name resolution records won't address those issues.
>>>
>>> Say you want to connect to WebServerA. Say you want a way to be assured
>>> that you are, indeed, connecting to WebServerA, not some imposter. Well,
>>> there already exists a mechanism to do that: SSL. SSL authenticates the
>>> server to your computer, because your computer trusts the organization
>>> that issued the server's certificate.
>>>
>>> Say you want to connect to FileServerB. Say you want a way to be assured
>>> that you are, indeed, connecting to FileServerB, not some imposter.
>>> Well, there already exists a mechanism to do that: IPsec. IPsec
>>> authenticates the server to your computer (and your computer to the
>>> server), because both the server and your computer trust the issuers of
>>> their respective certificates.
>>>
>>> See, this is really what matters. Spoofing DNS is a useless attack if
>>> the servers are protected by SSL or IPsec. Bolting cryptography onto DNS
>>> will be monumentally expensive to deploy across the Internet and doesn't
>>> address the real question. DNSSEC answers this question: "Can I trust
>>> the answer given to my name resolution request?" Yet the more important
>>> question is "Can I trust that I'm going to the right server?" And this
>>> question is already answered by SSL and IPsec.
>>>
>>> --
>>> Steve Riley
>>> steve.riley@microsoft.com
>>> http://blogs.technet.com/steriley
>>> http://www.protectyourwindowsnetwork.com
>>>
>>>
>>>
>>> "Dan" <Dan@discussions.microsoft.com> wrote in message
>>> news:0A907A01-2DC6-4A22-B075-F2DE8C4BBABA@microsoft.com...
>>>> How about the problems on web sites with errors about missing scripts
>>>> and
>>>> lost objects and other stuff?
>>>>
>>>> "Steve Riley [MSFT]" wrote:
>>>>
>>>>> What problem can you solve with DNSSEC that is not already solved with
>>>>> IPsec
>>>>> or SSL?
>>>>>
>>>>> --
>>>>> Steve Riley
>>>>> steve.riley@microsoft.com
>>>>> http://blogs.technet.com/steriley
>>>>> http://www.protectyourwindowsnetwork.com
>>>>>
>>>>>
>>>>>
>>>>> "Dan" <Dan@discussions.microsoft.com> wrote in message
>>>>> news:7571D3C3-6A37-47E9-A937-CD6B198B400B@microsoft.com...
>>>>> > Will DNSSEC be fully supported in future versions of Windows, Steve?
>>>>> > In
>>>>> > addition, will any current versions of Windows be updated to fully
>>>>> > support
>>>>> > it
>>>>> > via cryptography, authentication and/or verification, Steve
>>>>> > including but
>>>>> > not
>>>>> > limited to Windows Server 2003?
>>>>> >
>>>>> > "Steve Riley [MSFT]" wrote:
>>>>> >
>>>>> >> Clarification. There is _limited_ support: Windows Server 2003 DNS
>>>>> >> can
>>>>> >> act
>>>>> >> as a secondary DNS server for an existing DNSSEC-compliant zone.
>>>>> >> Windows
>>>>> >> clients will cache DNSSEC resource records, but perform no
>>>>> >> cryptography,
>>>>> >> authentication, or verification.
>>>>> >>
>>>>> >> More information here:
>>>>> >> http://technet.microsoft.com/en-us/l.../cc728328.aspx
>>>>> >>
>>>>> >> --
>>>>> >> Steve Riley
>>>>> >> steve.riley@microsoft.com
>>>>> >> http://blogs.technet.com/steriley
>>>>> >> http://www.protectyourwindowsnetwork.com
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> "Steve Riley [MSFT]" <steve.riley@microsoft.com> wrote in message
>>>>> >> news:5CCD3A14-68B3-471F-9328-D1ED272FD113@microsoft.com...
>>>>> >> > No, DNSSEC isn't supported in any version of Windows.
>>>>> >> >
>>>>> >> > --
>>>>> >> > Steve Riley
>>>>> >> > steve.riley@microsoft.com
>>>>> >> > http://blogs.technet.com/steriley
>>>>> >> > http://www.protectyourwindowsnetwork.com
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > "totojepast" <totojepast@razdva.cz> wrote in message
>>>>> >> > news:4cdf919f-4cba-4940-aead-fb1d460c0fbe@k13g2000hse.googlegroups.com...
>>>>> >> >> Is the Windows XP DNS resolver able to check the validity of the
>>>>> >> >> DNS
>>>>> >> >> data using DNSSEC? Is this feature turned on by default?
>>>>> >> >>
>>>>> >> >> And does the Windows Server support DNSSEC for publishing the
>>>>> >> >> public
>>>>> >> >> DNS records?
>>>>> >> >
>>
>>

Dan

Steve, what is a network administrator or in my case a desktop support
specialist to do when https:/ is broken because of web errors from hackers
and then the safety and security of average joes and jills is compromised
when they put their personnel information on to the web site because the
informatiton can be viewed and/or redirected to the hackers. I have seen
this just recently and I reported it through responsible disclosure through
us-cert.gov.

"Steve Riley [MSFT]" wrote:

> Cache poisoning is only a means to an end. The attacker's _real_ goal is to
> get you on his server rather than the one you actually want. So ensuring
> authenticity of the legitimate server is the proper defense here, rather
> than worrying about the plumbing. And we can accomplish that today with SSL
> and IPsec.
>
> --
> Steve Riley
> steve.riley@microsoft.com
> http://blogs.technet.com/steriley
> http://www.protectyourwindowsnetwork.com
>
>
>
> "FromTheRafters" <erratic@ne.rr.com> wrote in message
> news:er3ykC#BJHA.1228@TK2MSFTNGP02.phx.gbl...
> > Yeah, it is important. Akin to the way you should get
> > programs only from trusted sources. But how can
> > anyone verify the validity of the data returned? AV
> > is in place to stopgap the bad information from trusted
> > source issue when programs are the concern, do you
> > think it is completely unnecessary to stopgap the same
> > sort of thing for poisoned DNS data?
> >
> > Sure, if DNS poisoning is not very common, then there
> > is little risk - and crypto is like a 12gauge flyswatter.
> >
> > "Steve Riley [MSFT]" <steve.riley@microsoft.com> wrote in message
> > news:840985B2-477A-4757-BBC2-852DD7EBDEF1@microsoft.com...
> >> Signed name resolution records won't address those issues.
> >>
> >> Say you want to connect to WebServerA. Say you want a way to be assured
> >> that you are, indeed, connecting to WebServerA, not some imposter. Well,
> >> there already exists a mechanism to do that: SSL. SSL authenticates the
> >> server to your computer, because your computer trusts the organization
> >> that issued the server's certificate.
> >>
> >> Say you want to connect to FileServerB. Say you want a way to be assured
> >> that you are, indeed, connecting to FileServerB, not some imposter. Well,
> >> there already exists a mechanism to do that: IPsec. IPsec authenticates
> >> the server to your computer (and your computer to the server), because
> >> both the server and your computer trust the issuers of their respective
> >> certificates.
> >>
> >> See, this is really what matters. Spoofing DNS is a useless attack if the
> >> servers are protected by SSL or IPsec. Bolting cryptography onto DNS will
> >> be monumentally expensive to deploy across the Internet and doesn't
> >> address the real question. DNSSEC answers this question: "Can I trust the
> >> answer given to my name resolution request?" Yet the more important
> >> question is "Can I trust that I'm going to the right server?" And this
> >> question is already answered by SSL and IPsec.
> >>
> >> --
> >> Steve Riley
> >> steve.riley@microsoft.com
> >> http://blogs.technet.com/steriley
> >> http://www.protectyourwindowsnetwork.com
> >>
> >>
> >>
> >> "Dan" <Dan@discussions.microsoft.com> wrote in message
> >> news:0A907A01-2DC6-4A22-B075-F2DE8C4BBABA@microsoft.com...
> >>> How about the problems on web sites with errors about missing scripts
> >>> and
> >>> lost objects and other stuff?
> >>>
> >>> "Steve Riley [MSFT]" wrote:
> >>>
> >>>> What problem can you solve with DNSSEC that is not already solved with
> >>>> IPsec
> >>>> or SSL?
> >>>>
> >>>> --
> >>>> Steve Riley
> >>>> steve.riley@microsoft.com
> >>>> http://blogs.technet.com/steriley
> >>>> http://www.protectyourwindowsnetwork.com
> >>>>
> >>>>
> >>>>
> >>>> "Dan" <Dan@discussions.microsoft.com> wrote in message
> >>>> news:7571D3C3-6A37-47E9-A937-CD6B198B400B@microsoft.com...
> >>>> > Will DNSSEC be fully supported in future versions of Windows, Steve?
> >>>> > In
> >>>> > addition, will any current versions of Windows be updated to fully
> >>>> > support
> >>>> > it
> >>>> > via cryptography, authentication and/or verification, Steve including
> >>>> > but
> >>>> > not
> >>>> > limited to Windows Server 2003?
> >>>> >
> >>>> > "Steve Riley [MSFT]" wrote:
> >>>> >
> >>>> >> Clarification. There is _limited_ support: Windows Server 2003 DNS
> >>>> >> can
> >>>> >> act
> >>>> >> as a secondary DNS server for an existing DNSSEC-compliant zone.
> >>>> >> Windows
> >>>> >> clients will cache DNSSEC resource records, but perform no
> >>>> >> cryptography,
> >>>> >> authentication, or verification.
> >>>> >>
> >>>> >> More information here:
> >>>> >> http://technet.microsoft.com/en-us/l.../cc728328.aspx
> >>>> >>
> >>>> >> --
> >>>> >> Steve Riley
> >>>> >> steve.riley@microsoft.com
> >>>> >> http://blogs.technet.com/steriley
> >>>> >> http://www.protectyourwindowsnetwork.com
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> "Steve Riley [MSFT]" <steve.riley@microsoft.com> wrote in message
> >>>> >> news:5CCD3A14-68B3-471F-9328-D1ED272FD113@microsoft.com...
> >>>> >> > No, DNSSEC isn't supported in any version of Windows.
> >>>> >> >
> >>>> >> > --
> >>>> >> > Steve Riley
> >>>> >> > steve.riley@microsoft.com
> >>>> >> > http://blogs.technet.com/steriley
> >>>> >> > http://www.protectyourwindowsnetwork.com
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> > "totojepast" <totojepast@razdva.cz> wrote in message
> >>>> >> > news:4cdf919f-4cba-4940-aead-fb1d460c0fbe@k13g2000hse.googlegroups.com...
> >>>> >> >> Is the Windows XP DNS resolver able to check the validity of the
> >>>> >> >> DNS
> >>>> >> >> data using DNSSEC? Is this feature turned on by default?
> >>>> >> >>
> >>>> >> >> And does the Windows Server support DNSSEC for publishing the
> >>>> >> >> public
> >>>> >> >> DNS records?
> >>>> >> >
> >
> >

Paul Adare - MVP

On Thu, 28 Aug 2008 03:20:01 -0700, Dan wrote:

> Steve, what is a network administrator or in my case a desktop support
> specialist to do when https:/ is broken because of web errors from hackers
> and then the safety and security of average joes and jills is compromised
> when they put their personnel information on to the web site because the
> informatiton can be viewed and/or redirected to the hackers. I have seen
> this just recently and I reported it through responsible disclosure through
> us-cert.gov.

Just because a web site throws errors in the browser does not mean that it
has been hacked. Having said that, to answer your question, identify what
the problem is, fix or patch it, and then if necessary report it.

--
Paul Adare
MVP - Identity Lifecycle Manager
http://www.identit.ca
Any sufficiently advanced bug is indistinguishable from a feature. --
Kulawiec

Dan

Thank you Paul. I appreciate your answer.

"Paul Adare - MVP" wrote:

> On Thu, 28 Aug 2008 03:20:01 -0700, Dan wrote:
>
> > Steve, what is a network administrator or in my case a desktop support
> > specialist to do when https:/ is broken because of web errors from hackers
> > and then the safety and security of average joes and jills is compromised
> > when they put their personnel information on to the web site because the
> > informatiton can be viewed and/or redirected to the hackers. I have seen
> > this just recently and I reported it through responsible disclosure through
> > us-cert.gov.
>
> Just because a web site throws errors in the browser does not mean that it
> has been hacked. Having said that, to answer your question, identify what
> the problem is, fix or patch it, and then if necessary report it.
>
> --
> Paul Adare
> MVP - Identity Lifecycle Manager
> http://www.identit.ca
> Any sufficiently advanced bug is indistinguishable from a feature. --
> Kulawiec
>

Alun Jones

"Steve Riley [MSFT]" <steve.riley@microsoft.com> wrote in message
news:840985B2-477A-4757-BBC2-852DD7EBDEF1@microsoft.com...
> Signed name resolution records won't address those issues.
>
> Say you want to connect to WebServerA. Say you want a way to be assured
> that you are, indeed, connecting to WebServerA, not some imposter. Well,
> there already exists a mechanism to do that: SSL. SSL authenticates the
> server to your computer, because your computer trusts the organization
> that issued the server's certificate.
>
> Say you want to connect to FileServerB. Say you want a way to be assured
> that you are, indeed, connecting to FileServerB, not some imposter. Well,
> there already exists a mechanism to do that: IPsec. IPsec authenticates
> the server to your computer (and your computer to the server), because
> both the server and your computer trust the issuers of their respective
> certificates.
>
> See, this is really what matters. Spoofing DNS is a useless attack if the
> servers are protected by SSL or IPsec. Bolting cryptography onto DNS will
> be monumentally expensive to deploy across the Internet and doesn't
> address the real question. DNSSEC answers this question: "Can I trust the
> answer given to my name resolution request?" Yet the more important
> question is "Can I trust that I'm going to the right server?" And this
> question is already answered by SSL and IPsec.

You address only the impersonation side of the attack, and even then you're
ignoring the fact that users have been trained by any number of websites to
"just ignore the error and click on through". SSL and IPsec both confirm
(when correctly used) that you're connected to a site with current
credentials to match the site's name.

What they don't do is prevent you from being denied access to the correct
site.

If I've poisoned an 'upstream' DNS cache from you, whether it's yours, your
ISP's, or the root DNS servers, I now redirect every request you make.
Perhaps you are the sort of iron-willed user who steadfastly clings to the
practice of refusing to connect to systems with incorrect certificates -
even so, you're still not getting to your chosen web server.

The denial-of-service element of the DNS poisoning attack cannot be resolved
by IPsec or SSL between the server and the client.

If, however, your DNS server, and all those upstream, could somehow
determine that a DNS response was forged and could be thrown away in favour
of a known-correct name to IP mapping, the DoS aspect of this attack could
also be prevented. If a DNSSEC-enabled DNS server received a thousand DNS
responses, and two of them matched the name being requested, the DNS server
could arbitrate between those two responses by discarding the one that
wasn't appropriately signed.

Alun.
~~~~
--
Texas Imperial Software | Web: http://www.wftpd.com/
23921 57th Ave SE | Blog: http://msmvps.com/alunj/
Woodinville WA 98072-8661 | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(425)807-1787 | Try our NEW client software, WFTPD Explorer.

Dan

What Paul does not realize and if he followed US-Cert proper procedure and
doxpara website and the Sans Storm Center then he would realize that DNS
Pollution is and was a huge problem. The technology industry is mainly in
denial about Chris Cquirke, mvp's research and now Dan K's research with DNS
Pollution and the biggest reason this is such a big problem is the NT source
code that has been leaked out over the Internet in the past and is solid
external defense but has no true internal safety like DOS (Disk Operating
System). The majority of people here are indeed smart but they have followed
their senses and bought the company line hook line and sinker and did not go
far enough and ask why the individual operating systems cannot be made safer
on the inside and what is the use of all this external security that will
indeed crumble if there is no internal safety of Disk Operating System or an
equivalent and all users are left with is a cheap command.com interface that
may be satisfactory for many but sucks for the individual home consumers who
I represent. Sure, the price of having two lines of source code is expensive
but how does one company have the right to say which line of source code is
superior and if it is so superior how come we suddenly are having so many
problems with security. It is an easy concept because if you want all your
computers linked as one and one gets a virus then all the others can share
that virus and sicken too. Now, remember if we backtrack and have each
computer become a unique individual that creates and learns without the need
of the collective then we are making progress. Do we really need computers
to become like the Borg where all the computers are connected to one super
computer. Why not let man and womankinds creativity flow from each machine
and not have to be so reliant upon the others that the machine can not do
anything without checking what machines b,c,d,e, and f are doing before the
machine is even confident enough to proceed. I am purposely stretching the
truth and exagerrating but I am making a point on how the entire industry
went wrong when the wrong source code was chosen. The only real solution is
for Microsoft to bring the new source code to the market that is internally
safe with a maintenance operating system and also externally secure.

"~BD~" wrote:

> You're welcome, Dan.
>
> For the most part, I understand your posts - all of them!
>
> Stick with it!
>
> Dave
>
> --
> "Dan" <Dan@discussions.microsoft.com> wrote in message
> news:FA0EE75A-8851-4F30-99E7-C763FFC05BFC@microsoft.com...
> > <Warning Long Story --- mainly for Steve Riley {MSFT} benefit as well as
> > anyone interested and caring enough not to give some smart aleck
> > response}:->
> >
> > Thanks BD.
>
> <snip>
>
>
>

~BD~

"Alun Jones" <alun@texis.invalid> wrote in message
news:2977A22C-A3A4-429A-B3B4-9005D31E5D7C@microsoft.com...
> "Steve Riley [MSFT]" <steve.riley@microsoft.com> wrote in message
> news:840985B2-477A-4757-BBC2-852DD7EBDEF1@microsoft.com...
>> Signed name resolution records won't address those issues.
>>
>> Say you want to connect to WebServerA. Say you want a way to be assured
>> that you are, indeed, connecting to WebServerA, not some imposter. Well,
>> there already exists a mechanism to do that: SSL. SSL authenticates the
>> server to your computer, because your computer trusts the organization
>> that issued the server's certificate.
>>
>> Say you want to connect to FileServerB. Say you want a way to be assured
>> that you are, indeed, connecting to FileServerB, not some imposter. Well,
>> there already exists a mechanism to do that: IPsec. IPsec authenticates
>> the server to your computer (and your computer to the server), because
>> both the server and your computer trust the issuers of their respective
>> certificates.
>>
>> See, this is really what matters. Spoofing DNS is a useless attack if the
>> servers are protected by SSL or IPsec. Bolting cryptography onto DNS will
>> be monumentally expensive to deploy across the Internet and doesn't
>> address the real question. DNSSEC answers this question: "Can I trust the
>> answer given to my name resolution request?" Yet the more important
>> question is "Can I trust that I'm going to the right server?" And this
>> question is already answered by SSL and IPsec.
>
> You address only the impersonation side of the attack, and even then
> you're ignoring the fact that users have been trained by any number of
> websites to "just ignore the error and click on through". SSL and IPsec
> both confirm (when correctly used) that you're connected to a site with
> current credentials to match the site's name.
>
> What they don't do is prevent you from being denied access to the correct
> site.
>
> If I've poisoned an 'upstream' DNS cache from you, whether it's yours,
> your ISP's, or the root DNS servers, I now redirect every request you
> make. Perhaps you are the sort of iron-willed user who steadfastly clings
> to the practice of refusing to connect to systems with incorrect
> certificates - even so, you're still not getting to your chosen web
> server.
>
> The denial-of-service element of the DNS poisoning attack cannot be
> resolved by IPsec or SSL between the server and the client.
>
> If, however, your DNS server, and all those upstream, could somehow
> determine that a DNS response was forged and could be thrown away in
> favour of a known-correct name to IP mapping, the DoS aspect of this
> attack could also be prevented. If a DNSSEC-enabled DNS server received a
> thousand DNS responses, and two of them matched the name being requested,
> the DNS server could arbitrate between those two responses by discarding
> the one that wasn't appropriately signed.
>
> Alun.
> ~~~~
> --
> Texas Imperial Software | Web: http://www.wftpd.com/
> 23921 57th Ave SE | Blog: http://msmvps.com/alunj/
> Woodinville WA 98072-8661 | WFTPD, WFTPD Pro are Windows FTP servers.
> Fax/Voice +1(425)807-1787 | Try our NEW client software, WFTPD Explorer.
>
>
>

Hi Alun

This is all a little beyond me but .............

When you said "What they don't do is prevent you from being denied access to
the correct site" - did you really mean to say INcorrect site?

If I've got the wrong end of the stick, please forgive me!

Dave

--

~BD~

Might this be relevant here too?

http://apnews.myway.com/article/20080827/D92QSA880.html

Dave
--