Sunday, September 19, 2004
Browser Spoofing: Determining the Criteria
So, we know what the problem is, I think. But that doesn't quite get us to what criteria we'll use to judge possible solutions.
Obviously, the first criteria is that it needs to make it possible to identify spoofing in the situations listed in the problem description. But, does it just need to possible by a computer literate user who's paying attention? Or does it need to be so obvious that anybody will notice? Does the solution need to have limited impact on the UI of current non-spoofed pages? When it comes to spoofing to get around the browser's existing anti-page-spoofing, are we only limiting our concern to "secure sites" (https://)?
Here's what I'm going to use:
- It needs to address the listed problems.
- It needs to make it possible for a fairly computer literate user to identify.
- It should address non-secure sites as well.
- A compromise between making things more obvious for all users and keeping the UI clean needs to be made.
Regarding #3: This really goes above and beyond the current problem, as it's an attempt to add web-site spoofing protection to non-secure sites. But the use of certificates to authenticate a site's identity is a joke on the modern internet. Many sites I do trust don't have the money for a proper certificate for every domain name that points to that content. A real site that had the web server hacked is just as untrustworthy as someone putting up a fake version. So, I'd rather we simply assume that the domain name is valid, and prevent spoofing from there. Certainly, secure sites should continue to receive the extra UI they do now, but all sites should be included in anti-phishing schemes.
Labels: web
Comments:
If you're trying to really prevent all spoofing, then you're going to need to look beyond the domain name. There should ultimately be some way to validate that the actual web server you are talking to is the correct and legit server.
Domain names can be easily hijacked and redirected to other services due to the way DNS works. In the future we'll probably have to replace DNS as the way we resolve domains on the internet, but in the short time, a solution may need to address the validity of the domain resolution as well as other issues.
Certificates can work to help this, in that if you always get certificate A from the website, and suddenly you get certificate B, where something critical has changed (company name, certificate owner, certificate co-signatures, etc), then that may indicate that something is wrong (but not always..). Of course, you also point out the flaws in certificates (if they were cheaper to obtain this would clearly be less of an issue).
Is it really easier to hijack DNS to point to another server than it is to just hack the machine and use its current certificate?
Besides, like I said, there's so many bad certificates out there that people just ignore the warnings. Minimally, if there's a site that you had trusted the certificate on once, and then you go there some day and you get warnings about the certificate, you MIGHT feel suspicious. But that's only one attack out of several possible.
All those need to be addressed, for sure, but I'll keep my focus on assuming DNS is trusted. Fixing DNS is a whole 'nother can of worms.
