SSL is the backbone of the way we secure connections between internet users and web servers.
The vast majority of web sites will tell you that because you're using SSL you're secure and will have no problems.
One essential point to remember about SSL is that it is a communications security protocol - not an information security protocol. It carries out the things it was designed to do very well, but the design may not match user expectations. It has the following characteristics:
- it is designed to provide strong protection between two points in a communications system such that information passing between those points cannot be read or altered without detection;
- it can be configured such that the two points do not attempt to authenticate each other when making a connection;
- it does not authenticate the source of the data that is being carried over the connection;
- it does not protect the data in any way once it has left the communications point (onto a server, perhaps).
You may not have understood what SSL was not designed to do. Its weakness is not cryptographic attack, despite recent reports, but web site spoofing, something the industry has known about for a long time now, and has had periodic attempts to stop. It is the Achilles heel of the system, and increasingly threatens the validity of its most popular use - for 'guaranteeing' where data comes from and goes to.
What is web site spoofing?
Summed up, web spoofing is a man-in-the-middle attack that makes users think they have a secured session with one specific web server, when in fact they have a secured session with an attacker's server. At that point, the attacker could persuade the user to supply credit card or other personal info, passwords, etc. You get the idea. Here's how it works in a nutshell:
The attacker has compromised XYZ Company's web site, using DNS spoofing, or some other means such as being listed in a search engine to provide an intercept to XYZ, as explained below. The user wants to visit XYZ Company's web site and clicks on a link. The attacker has built their own SSL 'certificate' and the domain in this certificate looks authentic to the user's browser.
The user gets the solid key and now assumes all is safe and will be encrypted and secure. The attacker's forms on this Trojan site may include fields for passwords, credit cards, bank accounts, etc. and the unknowing user provides this info to the attacker as they use the forms.
What is the problem here? It is not SSL. It is the certificates. You see, as long as you have what looks to be the proper info in the certificate, the user will never know the difference. Sure, the URL might not look right, but you can use Java to control that.
Of course, only an idiot would redirect a user to a server in their home or office, you would of course redirect them to a server you have compromised. And you would use the compromised server's certificate to get that solid key. That's the trick - make the key solid, and the user is fooled.
Persuading your browser to go to a different address from the one that you are expecting may be done in several ways.
The first might sound a bit odd, but when you type a site name into your browser (www.xyzcompany.com) it is sent to a thing called a DNS resolver, which translates the words into an actual address (159.172.000.1). Obviously if the DNS resolver address can be altered then you can be routed to somewhere other than the site you intended. So if a hacker can alter any DNS server, whether it's the local one on your intranet or one of the major internet ones, they can send anyone asking for a specific site to any address they want, without the user being able to detect anything at all.
Attacking a major DNS resolver is now quite difficult, but such attacks have taken place before and at a local level are still quite possible.
The second is to attack any server containing cached pages for web sites. Generally your local internet services provider will be operating caching and, even though you expect to go direct to the actual source web site, the ISP will supply pages as if they had come from the actual site (your own PC also does this). Here the attacker alters the commands that route you to the correct site, to point to their own site. This is quite easy because all they have to do is add their own site address to any address given in the page. Once they have done that, all subsequent traffic can be routed through their site, and the user is none the wiser.
This is a much easier route for the attacker, and although it does not potentially compromise as many people, it is technically easier to carry out.
An attacker can create a spoof version of the target site very easily. Using a spider (a program commonly used by search engines to locate search phrases on web sites) you can quickly collect the pages on a site and then mount them on your own machine for subsequent processing.
Spoofing tools are readily available, on the internet and commercially; you don't have to become an expert in all these technologies to get started. (See www.iol.ie/~fod/sslpaper/sslpaper.htm, www.cs.princeton.edu/sip for more details on this type of attack.)
But surely SSL stops all these problems?
SSL implementation
SSL was developed as a method for authenticating computer systems using public key technology and the X.509 public key certificate.
The idea is that every web server has a 'server certificate' that proves their identity, so any user can check that the certificate matches the claimed site identity. That allows the server to be authenticated, but manually.
At the user side, generally speaking, the user has no identity at all, and so one is created 'on the fly.' (Even if one were available, say in the browser certificate store, there is no mechanism to choose a certificate and use it.) Quite obviously this identity cannot be identified by the server, because there is no identity to verify.
So there is a logic problem - you can't verify something you don't know.
But the real problem with SSL is the way in which it is switched on. What happens is that the server sends the instructions to the browser to set up an SSL connection. Anything altering the page coming down to the browser can change the destination of the SSL connection, and the user will not know. If the hacker connection actually opens an SSL session with the real web site it can request the server certificate and pass it onto the browser (if the user requests it), so the user cannot see anything wrong at all. The attacker can also set up the session with the user so that there is no automatic verification of a certificate.
So we have a number of problems with ways in which SSL can be implemented.
Relying on users checking identities manually 'if they have any concerns' in the unreal environment of the internet is hardly a good security strategy. It's nothing unusual to have server certificates that use generic names (they use * as any character when used for multiple sites) or where an ISP allows sites to use an overall certificate that belongs to the ISP, and therefore is not connected to the actual web sites in operation.
Even if checking is switched on, the server does not know what it is connected to and cannot check it anyway.
To add to those problems, languages like Java script can be used to hide information from the user that would otherwise perhaps betray what is going on. As the University of Dartmouth in the U.S. has demonstrated conclusively, (see www.cs.dartmouth.edu/~pkilab/demos/spoofing/), it is possible to spoof any part of the standard browser without being detected.
Is web site spoofing a real problem?
The first well-publicized use of web spoofing took place as recently as 1997 (see www.nwfusion.com/archive/1997/97-07-28____.html). It came to light principally because it was caused by an argument about the right to sell internet addresses, and therefore routed users to a visible site offering addresses. If it had been a large-scale system for collecting personal information without making any disclosure at all it would have gone unnoticed.
There have been examples of attacks on DNS servers that have been successful for a period of hours. Other reports of spoofing attacks are more anecdotal. One of the problems here is that there is considerable commercial pressure on organizations not to admit to this kind of attack. In the case of altered pages on a web site organizations may not be aware of it, especially if they regularly update their caches.
There are an increasing number of readily available hacker tools to capture information or spoof information with ease.
Can something be done?
The major problems are both financial and technical.
Changing server controls may be acceptable, but suppliers are completely scared by the thought that something must be done at the client side. DNSSEC "is a no-brainer if it can be easily done," says Rohi Sukhia, CEO of Tradeloop.com, a web site offering spare parts and used equipment to computer dealers. "If it requires us to make a change on our DNS server, that's no big deal. But if it requires us to go out to our customers and change something on their systems, it's not going to happen."
Fear centers around having to support software at the client, and whether that software is capable of compromise. Both have cost implications. At the moment the security industry has not found any simple way to educate end users into the problem and solution, and certainly not at a price that makes economic sense to the user. Until that can be solved, absorbing the damage (as the credit card companies do) continues to be a cheaper route forwards.
The technical problems are fairly obvious. If the client is going to verify server pages, then there must be software on the client to carry out these checks. Further, that software must be proactive, monitoring every page all the time, not manual, waiting for the user to detect something that they cannot perceive. Since the user cannot rely upon any visual indications something proactive must operate.
Further, it must be linked in to the normal use of web site certificates in all environments to prevent a proliferation of technologies - and costs. Getting the services we already have to work properly would be a good start.
For some of the major supply industries the problem is that they have no incentive to solve the current problems because they make no money fixing what they have already sold. Their interest is selling something new which is supposed to fix the problems. Unfortunately the industry track record so far is not good and the market is becoming increasingly cynical about the gap between advertising and delivery, and more resistant to hype.
Some real proposals have been made that would prevent web site spoofing, but industry interest is low because the desire to have uninhibited selling outweighs the desire for security. Just think about how many sites demand you accept cookies, Java script, or other methods that have known security problems. These are excellent indicators of the real desire to get security into the picture.
Steve Mathews is CEO of ArticSoft (www.articsoft.com).
