Starting a new Thread because at this point, I don't want to dilute
Eddys proposal any further.
Rather than start a flame war, lay out an experiment, like I did to
prove me wrong. Did you actually TRY the experiments I laid out? I
suspect not.
I know that these things work, as I use this everyday to test my
development on a website, so I can do things locally, rather than
having to push changes to the live server. In fact I have my developers
doing the same thing, so your assertion that SSL will somehow detect
this is false, even with Firefox(we also test with IE and Opera) . If
your assertions were correct, our Internal DNS would be detected as bad,
because we are using internal DNS servers rather than the servers
specified at the registrar (this is functionally identical to DNS
hijacking or drive-by pharming), it would also flag the names I resolve
with my "hosts" file as suspicious(as this could be malware just as easy
as my modifications).
Prove me wrong, I will gladly change my view and even offer a public
apology but offer an experiment to backup your claim. I am already
DOING some of these "attacks", where is your proof?
Nelson Bolyard wrote:
Actually, even if you have the right IP you _still_ might be in the
wrong place thanks to virtual hosting.
And again, SSL will detect that. As of FF 2, FF's SSL/TLS code now has
the ability to send the desired host name to the server during the
handshake, so that if the server serves multiple virtual hosts, it can
pick the cert for the right one and answer with it.
exactly! and one more place for an attack.
Lots of places for attacks. Thankfully, SSL detects them
But again, if the cert presented doesn't match the hostname the
browser requested the browser should not show the result.
However, with a DNS attack in combination (drive by pharming, dns
hijacking, hostfile modification with malware etc... ), the browser
becomes helpless to detect the problem.
No, wrong. Regardless of how many attacks are done, falsifying IP
addresses, port reassignment, false routing, and direct MITM data
rewriting, unless the final host has a cert from a trusted issuer,
and that cert has the host name that was in the user's URL, the attack
is detected and thereby thwarted. Period.
And this.
In any case, if the user clicks thru the warning box,
Then the user has chosen to hurt himself. Not SSL's fault.
The user's willingness to hurt himself is a vulnerability of the user,
not of SSL.
or if the DNS is hijacked so the browser can't tell,
With SSL, the browser can always tell. What the browser does after
being told about the detected error/attack does not reflect on SSL.
the assertion of the identity in the certificate is meaningless.
If ignored by the user or his application, all security provisions
are meaningless.
This has been my statement about how DNS can sabotage identity
assertions all along.
So far, the only vulnerability you've identified is in the user, and
arguably in the application's UI design, but not in SSL. Your repeated
assertions that SSL is vulnerable to falsified DNS simply don't hold up.
I'm sure you will continue to repeat it, but you won't convince the
readers here.
But then again this DNS issue was only one specific example of a
particular problem with SSL, one of many that EV certs do NOT address.
I guess you will repeat this in the face of evidence to the contrary.
Go ahead, but you're not making any points.
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
