In the specific case of http://www.wachovia.com/, they used http to deliver the original form to the browser. However, that content includes form method=“post” action=“https://onlineservices.wachovia.com/auth/AuthService” which should send the user credentials to wachovia wrapped in ssl. It would be nice if the browser could show some indication of http/https when the mouse is over a link, but in many cases including this one, the bank has used javascript or other methods to hide that information.

Carl, I don’t care how they post it.  It doesn’t matter if you “securely” deliver your login credentials to an attacker whose identity you failed to verify due to the lack of HTTPS.  This is the same dumb argument those banks have been using to justify this bad practice.

The whole point of this MANDATORY SSL/TLS article is that the user should be taken out of this decision process and they shouldn’t be bothered with it.  The site should be 100% valid or it should not work period.

Like most proposals for a security solution, this article dedicates insufficient time to analysing the security problem. What are the possible threats? Which of the possible threats does this solution address? What avenues of attack remain open given each suggested implementation? What are the other drawbacks of the security mechanism? And ultimately, are the benefits (if any) worth the costs?

I have other things to do today, so I’m not going to perform that analysis here and now. I do note, however, that the solution does not address the problem of phishing at all: if a user can be tricked into visiting a malicious website, then no amount of SSL validation (or its absence by publicly stated policy) helps. At a glance, the proposal doesn’t seem to offer any significant benefits, particularly given the implementation effort involved.

The problem is that web authentication with SSL can be hijacked nearly 100% of the time based on every study conducted through simple social engineering techniques.

As for the costs, do you see a problem if your bank account gets hijacked?  Do you see a problem if your email or facebook account gets hijacked?  Do you see a problem if your Ebay account gets hijacked?  Do you see a problem if any website with sensitive information gets hijacked?  If the answer is yes to any of these questions, then you should care about the proposed solution.

The proposed solution would facilitate a systematic way of locking down websites so that they can avoid page hijacking which would avoid the said problems.

Brett says: “I do note, however, that the solution does not address the problem of phishing at all: if a user can be tricked into visiting a malicious website, then no amount of SSL validation (or its absence by publicly stated policy) helps. At a glance, the proposal doesn’t seem to offer any significant benefits, particularly given the implementation effort involved.”

If the user is redirected a malicious but seemingly legitimate website (extremely simple to do with a fake hotspot), then the proposed solutions DOES fix the problem.  The web browser in this case would systematically refuse to open up the site (with no GUI opt-out) if they’ve visited the website from a secure location before.  That’s why I proposed web browsers should maintain a list of mandatory SSL/TLS websites.

If the user visits a site they’ve never been to from a compromised network, then the proposed solution would fail to operate but this would be a smaller vector for attack.  Covering this last vector of attack would be extremely impractical without universal DNSSEC deployment with ZERO backward compatibility for plain old DNS and that won’t be practical even when DNSSEC is 99% ubiquitous.  I suppose it might be possible if operating systems maintained a list of DNSSEC enabled domains but that would probably be impractical.

The proposed solution can’t possibly cover every angle of attack e.g., if your computer is completely hijacked by malware.  What it does do is cover one of the biggest vectors of attack for uninfected computer systems when DNS is intact and it even protects websites the user has already visited when DNS is not trustworthy.

And how does a normal user know that https://www.bank.com != https://www.b4nk.com !?
(and better fake names with the nice IDN names of course, or just https://www.thebank.com)

Both will have a valid security certificate, correctly received from a very trusted CA, both domains and SSL cers are really owned by the respective owners, no need to do hacking here in anyway. There just is no way that the user can know which one is the real one.

The b4nk.com website will just mirror 100% the look and feel of the b4nk.com website and that is all there is to it, the user will just think it is from there bank, that is all there is to it for all those phishing things, nothing difficult. SSL, DNSSEC and all that tech doesn’t help here at all.

One of the few solutions is to have a ‘white list of good domains’, but who decided what goes on the whitelist? IMHO b4nk.com is MY bank and is just as ‘legit’ and ‘good’ and ‘white’ as your bank.com domain. Same for your ‘mandatory tls/ssl’ thing: b4nk.com will be listed in the same way too. Where is the difference?

“And how does a normal user know that https://www.bank.com != https://www.b4nk.com”

Jeroen, that’s far cry from proper DNS names.  Like I said, the proposal is designed to help users against the biggest vector of attack where consumers are protected from http://www.bank.com when they’re really trying to go to http://www.bank.com.

I agree that there will still be some users who might get suckered by a misspelled domain name or where someone will obfuscate the real domain name by using a super long URL with one of the host names masquerading as a proper DNS name.  I think Google Chrome has the right idea by highlighting the proper DNS name and graying out everything else.

Why is that not a proper DNS name? Mmistypes and fake websites is how phishers work, hacking into “hotspots” really is not worth the effort (unless you get to hack up a big ISP network, but hey, why not go for the DSL and cable directly then if you are doing that).

I’ll assume you tried to write “http://www.bank.com when they’re really trying to go to https://www.bank.com.” note the missing ‘s’ after the second http.

How does an entry in DNS, which can be faked (otherwise the attacker can’t set up the fake http://www.bank.com either to point it somewhere else in the first place) help? One would need full DNSSEC supporting webbrowser and resolvers to recognize that it is the wrong bank. And also, because of that silly MD5 problem they can just fake the correct certificate, thus even if there is a white-list, the fact that it is SSL’d is useless.

> I think Google Chrome has the right idea by highlighting the proper DNS name and graying out everything else.

Since when is Google is the Boss of The Internet who controls what is good and bad?

Your “proposal” (quoted as there is no real proposal aka an IETF-like draft) defines to have “a special DNS record which describes that a host only should use HTTPS”.

There is already such a record: SRV (with usage from the Zeroconf RFCs).
eg the following would specify that the TCP HTTP service is to be found at the HTTPS TCP service and is actually located on 3 hosts which have certain load balance ratios etc (read up on SRV records for that, it is a really useful RR):
$ORIGIN example.com.
_http._tcp PTR _https._tcp
_https_._tcp SRV 0 100 443 www1
_https_._tcp SRV 0 0 443 www2
_https_._tcp SRV 0 0 443 www3

And of course a bank (or for that matter any other secure thing) can just force all connections to be redirected to https using HTTP 302 redirects.

Unfortunately SRV lookups are not enabled in any of the mainstream browsers. Safari does understand it, but doesn’t do it for http://www.example.com.

The problem of course still is, that one can always set up b4nk.com and make it identical to the original, the client won’t know better even if it is SSL’d or not.

What I’m trying to say is that in the case of DNS hijacking (either DNS poisoning or fake wireless hotspot), you won’t be fooled by a fake bank.com when you’re trying to go to the real bank.com.

This mechanism doesn’t stop you from being redirected to b4nk.com or bank.com.iejl.ejhn.b4nk.com/login.  At that point, we are hoping that the user understands that they don’t want to be at the b4nk.com domain.  The latter case of name obfuscation is a little harder to combat and Google’s Chrome does a good job of highlighting b4nk.com and graying out everything else so that it makes it easier to recognize the domain name as b4nk.com.

As for HTTP redirects, that isn’t good enough in the case where DNS isn’t trustworthy.

Nobody ever types HTTP or HTTPS or bothers to check it.  When people go to bank.com, they either type http://www.bank.com or just bank.com and expect to be taken to the right place.  I can’t think of a single person that manually types HTTP or HTTPS and it’s clear from all studies that people don’t care whether there’s an “s” in HTTP or not.  It’s also clear that a lot of banks (and websites like facebook.com) routinely use HTTP for user login.

> What I’m trying to say is that in the case of DNS hijacking
> (either DNS poisoning or fake wireless hotspot), you won’t be fooled by a
> fake bank.com when you’re trying to go to the real bank.com.

How? When one is in the middle one can spoof it all, including your in-DNS entry for saying “only use SSL”. Full supprt and verification of DNSSEC would be required to catch it. And of course on top of that a secure cert (thus not that MD5 thing *anywhere*, as as long as browsers support that or another hole, the attacker can use it). Note that DNSSEC is not the full answer either, as routing can still be faked too.

> At that point, we are hoping that the user understands that they don’t want to be at the b4nk.com domain.

You assume that users actually know what they are doing. If they where, then these issues would not exist in the first place. The biggest issue with anything is stupid users; and I am not insulting anyone here, granny is not supposed to know or be bothered with anything like certificates.

As for ‘obscuring’ things. There exist quite a few CSS-based hacks which make sites look like ‘ok’. The user still has to be educated on which part of the screen to trust and which part they are not supposed to trust.

Not even forgetting the other annoying part: if your computer is hijacked, because you visited some shady site accidentally that installed something for you, or you did accidentally follow that link in that email you got from that good “friend”, you still have nothing as they can modify any data going in and out of your browser. Something like that in the video here http://www.youtube.com/watch?v=mPZrkeHMDJ8 is supposed to fix that though, although that thing is just the next step to be compromised.

> As for HTTP redirects, that isn’t good enough in the case where DNS isn’t trustworthy.

It is better than nothing: if the user always expects a SSL domain, then they will expect it. Though some users indeed will not notice at all.

Oh and as we are actually mostly mentioning banks, check http://video.google.com/videoplay?docid=3041861094296331549&hl=en to see a lot more ways to actually get around it all ;)

“How? When one is in the middle one can spoof it all, including your in-DNS entry for saying “only use SSL”. Full supprt and verification of DNSSEC would be required to catch it. And of course on top of that a secure cert (thus not that MD5 thing *anywhere*, as as long as browsers support that or another hole, the attacker can use it). Note that DNSSEC is not the full answer either, as routing can still be faked too.”

Full DNSSEC with no backward compatibility to regular DNS can certainly make DNS extremely secure even when the routing is faked.  However, as I’ve written above, it’s highly unlikely we can give up backward compatibility to regular unsigned DNS even if 99% of the world supports DNSSEC fully.

As I’ve said, the browser can maintain a list of sites the user has visited and any site it has been to that requires mandatory SSL/TLS it will insist on it perpetually until someone manually deletes or modifies the list.  Granted, this does not cover sites you haven’t visited before which may have been hijacked but I never advertised the solution as full proof.  The primary purpose of this solution is to cover the largest vector of attack and offer the user a reasonable amount of additional protection.  Even a partial implementation of DNSSEC would be helpful because it can override the cached settings and offer assurance when the DNS server isn’t trusted.

As for complete computer hijacking, nothing is going to protect you there because the root DNS records and certificate authorities can be hacked and the hacker can already see everything you’re doing anyways.  No one has ever claimed to protect against this vector of attack.

“It is better than nothing: if the user always expects a SSL domain, then they will expect it. Though some users indeed will not notice at all.”

Expecting the user to check for SSL is NOT better than nothing because research has shown it’s about as useful as nothing since everyone ignores the lack of SSL.  This proposal isn’t full proof, but it’s miles ahead of nothing.

> ...it will insist on it perpetually until someone manually deletes or modifies the list…

Take a small guess what malware will do for you, totally automatically and free ;)

> ...I never advertised the solution as full proof.

If it does not fully cover the problem, why try to add it and encumber a lot of people and organisations with something that doesn’t work in the first place. Yes, it covers a part of the issue, but only when DNSSEC is globally deployed, which is unfortunately not going to happen. Next to that, most credentials get nicked by infected hosts, because the user is ‘stupid’.

> Even a partial implementation of DNSSEC would be helpful because it can override the cached settings and offer assurance when the DNS server isn’t trusted.

How exactly can it do that? Lets say you are a bank, and lets say that you DNSSEC protect your bank, and lets say that you get your domain in the ISC DLV (should not be too hard) and then oops, oh yes, please upgrade ALL the users to fully support DNSSEC in both their DNS caches/resolvers which are run by their ISPs in most cases etc etc. Neither IE or Firefox have DNSSEC support, thus even if you are able to upgrade all of that, you still need to upgrade those too. A lot of users simply do not upgrade their browser or computer, either due to corporate policy or due to simply not caring or knowing; the field of upgrading gets better, but there will always be computers which are not upgraded.

Nevertheless, before you are at a ‘partial DNSSEC implementation’, one is a lot of changes ahead. And even if it is partial, how do you differ between ‘there is no DNSSEC for this domain’ and ‘my packets are being routed to a DNS Server which is simply ignoring all the DNSSEC muck’; unless you start dropping all domains that are not DNSSEC signed of course, but guess what, that will just break computers and make customers unhappy == support costs at the ISPs will go up == unhappy ISPs == not going to happen (even if I would like to see it that DNSSEC gets deployed…)

> This proposal isn’t full proof, but it’s miles ahead of nothing.

But it is also eons into the future before it can possibly be used due to the simple missing factor of globally deployed DNSSEC (infrastructure and applications).

You keep coming back to the malware issue but as I keep saying, it’s already game over if you have malware.  So the malware issue is moot in this discussion.

“If it does not fully cover the problem, why try to add it and encumber a lot of people and organisations with something that doesn’t work in the first place. Yes, it covers a part of the issue, but only when DNSSEC is globally deployed, which is unfortunately not going to happen.”

1.  It doesn’t encumber companies with anything if they don’t want to use it; but it does help consumers stay away from hijacked websites with perfectly legitimate names.

2.  It doesn’t require DNSSEC at all to offer the benefits that I have claimed.  I only brought up DNSSEC as a requirement to cover a wider array of attacks.

Most phishing attacks involve either a lure to a false URL or malware at the client end. Given that your proposal addresses neither of these problems, I don’t see that it warrants much attention. Having said that, your proposal may offer a good idea for a Firefox plugin: a secure bookmark manager. This bookmark manager would be for sensitive sites (let the user decide what sites are sensitive). All bookmarks stored in the secure bookmark manager must be HTTPS or its equivalent, and the page will only load if all security checks pass.

As has been pointed out, this “secure” bookmark manager is just as vulnerable to tampering by malware as anything else, but it may be a good-enough and simple-enough interface to keep dear old grandma out of trouble on most days.

The malware issue is moot here.  As I’ve stated over and over again, malware means game over for everything.  If you’re going to knock any solution for failing to protect against complete PC hijacking, then you can argue against any security solution.  Heck, PKI can be hacked with malware since you can modify the Certificate Authority list so would you argue that PKI is not worth it?

But you’ve essentially agreed with me that a secure bookmark manager (possibly an online validation service with digitally signed results) could be a very good solution.  So why would it be wrong to add a DNS mechanism to this to offer some centralized control?

“let the user decide what sites are sensitive”

Why confuse the user?  Would it be that awful if too much of their surfing habits are protected?  Encryption is so cheap that a $30 CPU can encrypt 800 Mbps of AES-256 so you can only do too little encryption and not too much.  Does a user really understand that the data in Google maps could be used to track where they live?

Also, regarding fake and possibly similar looking URL, I’ve already responded to that and we try to protect against that using blacklisted sites on search engines and anti-spyware protection built in to Windows Vista and other anti-spyware applications.  They’re not perfect, but they help and it’s not what this proposal addresses.  The key is that software and infrastructure should do all that it can to protect the user because processing is cheap.

Lastly, another great mechanism would be a secure DNSSEC server on the Internet that can respond to queries.  If the browser is going to bank.com which isn’t in the secure bookmark list, it should query that DNSSEC server on the Internet and get a validated response.  If that server isn’t reachable for any reason and bank.com isn’t on the bookmark list as a non SSL site or an SSL site, then the secure response would be to refuse the connection.  There are too many HTTP hotspot portal systems that ask for login credentials and credit card numbers and this mechanism could combat that fraud.

Lastly, it is important to acknowledge that wireless access is becoming the dominant form of Internet access as laptops are now beginning to sell better than desktops.  It’s critical that we secure this mode of Internet access as much as possible.

> So why would it be wrong to add a DNS mechanism to this to offer some centralized control?

Because without *FULL* DNSSEC, the DNS is just another way to inject more false details. As such it doesn’t help. “Caching the first response” just means you cache the wrong information. And what if the bank policy changes?

> Most of us have fairly predictable web surfing patterns and it doesn’t require
> a massive list to maintain all the secure sites or unsecured sites we visit.

Does granny understand those concepts? Smart

> The unsigned DNS mechanism would only act as an on-trigger for the “secure bookmark” manager. 

There is already such a thing in place in Firefox. You can “View Page Info” (right mouse) and under the security tab it at least tells you how often you where at that site. Which helps against bank.com != b4nk.com as you have not been at the latter before; it does not helped against somebody hijacking the route (be it using DNS or just re-routing it somewhere else) for that domain though. But how many people know that they can check that and how many people actually do?

> Encryption is so cheap that a $30 CPU can encrypt 800 Mbps of AES-256

Maybe $30 for the CPU, but the rest of the box, what will that cost? What will the interface costs be, interconnect, is it stable? The internet at large also does a bit more than 800mbps. Just AMS-IX does a 1000 fold of that (see http://www.ams-ix.net/technical/stats/) and that is just public peering, ignoring all the 40GE links to Google around the world. I really would not want to tell my budget folks to upgrade everything to SSL and that we would need a million US$ in hardware extra because of SSL, sorry but the accounting people will ask “what are you protecting of” and there will be no proper answer. It all comes down to how important the data is of course. Costs still outweigh that though especially for public services. For banks the story is different and they already do SSL in most cases. The problem there is “do you really know who you are talking to”? And without DNSSEC you can’t be sure that bank.com is bank.com from the last time; and even if you know that bank.com should be correct, is it really your bank.com and not the competition?

> Does a user really understand that the data in Google maps could be used to track where they live?

Does it really help to encrypt that data if Google is storing it on their ends anyway? It only ‘protects’ from intermediate sites to see where you are going to, does that help?

> Lastly, another great mechanism would be a secure DNSSEC server on the Internet that can respond to queries.

Sorry to ask, it probably sounds insulting, it most likely is, but do you know how DNSSEC works? There is no such thing as a “central server”. Next to that, as I re-iterated before, ALL the tools and infrastructure need to understand it for it to work, if there is a cache/resolver in the middle which doesn’t pass through the DNSSEC specific records (like quite a few DSL/Cable modems resolvers just drop AAAA records or break on large TXT records as they don’t support EDNS0) then everything breaks and you are out of luck.

Indeed, if DNSSEC was in place then one could store something in DNS telling “hey that site is HTTPS only”, as I also mentioned already that CAN already be done with SRV records. Tools don’t use that though and you would need to upgrade EVERY user for it to work (including those corp lap/desktops). The problem here is not the people who upgrade (they will be fine most of the time), it is the people who don’t upgrade and who can be tricked into things as they use outdated software, they get infected in most cases anyway. And a forced-upgrade is not going to happen as that would mean that some users don’t have the tools to use it which means revenue loss either due to customers going somewhere else and/or due to loads of helpdesk costs being incurred.

> There are too many HTTP hotspot portal systems that ask for login credentials
> and credit card numbers and this mechanism could combat that fraud.

If you are connecting to an unknown system, then that is your problem. Nothing one can do against that. As for ‘HTTP hotspot portal systems’ hijacking DNS and pushing one to a portal page, yes, they do, how else are those systems supposed to authenticate the user in a method that is convenient for the user? You really want the user to install a special application for every hotspot they might encounter (where do they get that app from, the malware site? :) 802.1x might work here a bit, but try convincing all those hotspot providers to remove their cool logos and advertisements and very handy instructions for new users from their portal sites.

If people just connect to random hotspots, then you can’t protect them against providing their credentials to banks either.

> It’s critical that we secure this mode of Internet access as much as possible.

Ever read something about WPA2+PSK? When that is in use it is more protected than an Ethernet link (which can be protected with more or less the same system, see 802.1x).

Even with those authentications in place, there is generally further no crypto happening over the rest of the Internet and this only solves the part of the access to the gateway. Anybody not using SSH or SSL-protected connectivity is sending their data in plaintext if that goes over Ethernet or Wireless (which is also Ethernet mind you ;). Nothing to do about that. If you want secured links, you will have to fix every part of the Internet, starting with a signed root in DNS (or using DLV) and demanding every single component that you are using to be DNSSEC compliant (apps, infrastructure etc). That requires a lot of work though, I would say that you go try to fix up DNSSEC for your own domain/organisation/site/computer etc, when you have done that, come back and explain how hard it was and how useful it can be.