The by-now infamous signed certificate was deployed for two reasons, being, a) to stop the MITM, and b) to stop the spoof.
The MITM - man in the middle - is an attack possible when the attacker is already in the middle of two communicating endpoints, and thus has an ability to change the packets as they go through his service.
Then, he simply presents one sequence of packets upstream, and a second, distinct sequence of packets downstream. If those packets were intended to set up a secure session, our attacker can set up two secure sessions, one upstream, the other downstream, and copy from one to the other.
The certificate is used to defeat this, by using an authenticated key exchange to bootstrap into a secure session. As the key exchange is signed (a brief description not doing justice to the full story) the MITM cannot change the signed key without revealing the attack.
The spoof, on the other hand, is where the attacker tricks a victim into communicating directly with him, by pretending to be someone else. For example, a spoofer pretends to be a site of some repute, rather than going to that site directly.
Once so tricked, the victim can set up the secure connection to the pretended site. But, again, as a signed certificate for the site includes the real address and can bootstrap a secure session, the browser can avoid being fooled.
As described above, at least, that makes for two forms of attack - as defended by the cert. What makes the situation murky is that the attacks are not totally distinct; the MITM could use his attack to redirect to the same site or to a spoofed site, and the spoofer might often pass the traffic back to the original site, thus converting his attack into the MITM.
The essence of the difference then would seem to be in the initiation; the MITM is already in the middle, whilst the spoofer needs to trick one end or other into letting him be in the middle.
Either way, these are the definitions used here, but have a care with them! Switching between threats and amongst purposes, aims, interests and whimsical and personal desires is endemic within the SSL community, and can suffer the outsider a permanent headache.
I looked at the MITM in a previous rant [1]. The assumption is that the cert does stop your common or garden variety MITM, as defined above. I went on to ask whether implementations need to in fact defend against it, an odd question, given that SSL is fairly universally deployed with certs in place [2].
The accepted dogma is "of course!"
A slightly less quick and much more accurate answer is: "a definite maybe."
The frequency of a true MITM - one defined above where someone has the ability to control an intermediate node at low level and take central position - is so low as to be difficult to measure. Using risk analysis, there is no economically viable support for mandating protection, so the deployment of a cert should be optional if there is any cost involved.
What about the spoof? In total contrast to the MITM, spoofs are common. As common as dirt, and as equally unclean.
E-commerce sites with real value for thieving suffer spoofing attacks (or perhaps, to be more pernickety, their users are attacked) on a regular basis.
(I have most experience with the world of internet gold (IG) systems, a small, rabid band of gold bugs, libertarians, and other intellectual misfits that, to their credit, actually made net payments work. I will rely on their experiences as a benchmark.)
Within what we call the gold community, every week or so, a spoof attack is launched [3].
Here is how it is done. An email is sent to a (big, targeted) list of addresses, encouraging the recipient to click on a link. The link takes the user to a site that is not the IG, but instead is a mere pretence at the targetted IG. The user types in her account number and password into the pretend site.
Our faithful and persistent attacker collects the details, logs into the *real* site, and scarfs up the gold. As there is a ready and reliable exchange market, the funds are washed more quickly than any response can occur in higher layers in the protocol [4].
Does the Cert stop the Spoof? Nope. Well, of course not - not as described above. Obviously the user is at fault for entering - clicking - the wrong address, and not checking...
Well, hold on there! Wasn't the cert supposed to stop the spoofed URL?
What we have here is a clash of expectations. The security model claims that the cert will protect from the spoof, in that the URL typed will be the one that is reached.
But, the user's actions derive the URL from some email or other source; a click launches the URL into the browser, and no typing is done. The browser accepts the 'click' and, as the user has already signalled acceptance, there is no need of further checking!
But - say the security types - the user shouldn't click on a URL that is wrong. Um, ok, but users do, because that's what their trusty browser asks them to do!
But (3) they say - the precise spelling should be checked! And, sometimes, our dear user does even check the URL. And, it is perfect, within the text of the email. And ... And ...
The ways to create a spoofed URL are many and imaginative [5]. Scammers have an infinite amount of time, and the ways of the URL are complex, flexible, artistic even. Browsers and Email clients boast much facility at hiding critical security information, under the guise of user- friendliness. Presenting users with easy choices and other such marketing-driven imperitives rules.
Perhaps, worse of all, these scams don't seem to worry about SSL at all. Well, why should they? That would only mean that the attacker would have to fork out good money to get some nonsense string of numbers so that the victim's browser didn't interfere with the attack by giving the game away.
What a sad state of affairs. The CA-signed certificate, far from being the key to browsing security, is the Maginot Line that preserves the masses in a state of blissful ignorance.
It works perfectly against the attacks conceived and theorised as the dramatic threat to mankind, commerce and the Internet, a decade ago. Problem is, the attackers bypassed it, with as much disdain as any invading army against the last war's dug-in defence.
Problem is, the security model had unreasonable expectations. Problem is, the users didn't subscribe to their part of the protocol. (To be fair, it's hard to communicate to users that they are even expected to be part of anything.)
Problem is, the browser manufacturers that were sold on the need for the certs also got sold on the convenience of click and launch. So, they turned around and sold the security model down the river faster than one can say "check the URL..."
In the wider picture of the web, the goal of the security model is to protect value and information. Within that wider picture, the systems in place - browsing and ecommerce and implementations thereof - lost sight of the security model, paying only lip service to the security needs, while scrabbling to please the customer with more click-and-buy models.
The parallels with the original Maginot Line are embarrassing. The real Maginot Line was erected by the French during the years between WWI and WWII. This marvel of engineering was designed to defend against a massive attack by Germany, Evidently, an event that France fully expected, and planned for!
At an initial budget of 3.3 billion francs, it stretched from Switzerland to the Ardennes (an impenetrable forest) for some 240 kilometres (150 miles).
It might have done its job, had the German army been so polite as to stick to the French security model.
Instead, the Germans bypassed it. The main invasion went through the impassable forest, and the Maginot line itself was mostly ignored. The garrisons surrended a few months later, as a sort of afterthought.
There are some who say that Maginot Line did its job. In fact, the line created a sense of false security; it placed all of France under what was later termed "Maginot mentality."
Likewise, the CA-signed cert. It has created the appearance of security, at massive cost. The real attacks on users go right past it. Probably, if one were to ask an attacker about the certificate protection, it's odds-on that he would think us mad for even suggesting that he pay attention to it.
Not only do the attackers ignore the convention of presenting the certificate, they have the temerity to hack sites on mass, stealing whole databases of credit card numbers.
Which is not the effect we expected! Precisely the reverse, if the 100%ers intent were to hold sway.
( The notion of 100% cryptography is that if a threat can be protected against, it should be. This is the underlying design principle that places the CA-signed cert as the lynchpin of SSL security; the final keystone that brings the arch of complete browsing protection to a reality. )
Obscurely, if one has the gall to question the need for the cert, one is informed that dropping it would result in a "false sense of security," amongst other crimes. Yet, this is precisely the state of SSL implementations today; those that have stuff to protect are molested by attacks they do not understand, over protocols they were sold as secure.
How to change the Maginot mentality of the SSL systems; that is the question that faces us.
It might prove hard to change the mentality, but luckily it is not hard to fix the systems once that change is achieved. There are a few minor tweaks that will redeem the protocol.
It is not, as with the Maginot Line, that the SSL implementations are a complete waste of energy; more, that there is an imbalance in the security model as deployed.
The blindspot from the Ardennes and on across the Belgian frontier was the scene of much hurried attention from 1936, after the declaration to independence by a weary and jaundiced Belgium.
In the case of SSL, it is a likewise attention to the blindspots that will improve the overall security. It goes like this.
Browsers now force the use of CA-signed certs on merchants, for some unmeasurable security benefit.
They should not!
Instead, Browsers should accept ADH and other techniques such as self-signed certs.
These should be deployed as intermediate- level security models.
The single binary lock of security, as presented by the browser, results in a compressed message to the user. This forces a binary choice between what is accepted and what is unaccepted. Hence, the false sense of security, as described above.
Browsers should cease this binary choice.
Browsers should present compelling imagery to show the user the nature of the security:
ADH is better than HTTP,
self-signed better than ADH, and
trusted third party (arguably) best of all.
The user may not understand the message, or merely choose not accept it, but, the message must be present as an initial step in encouraging the user to participate in the security protocol!
Browsers - not web sites - should show who signed the cert. Not with a click, nor on the untrusted page, but, on some protected area of the browser.
These steps are needed to fulfill the promise of an increase in security; they would go a long way towards preventing spoofs (which are now practically unprevented).
What would be the downside of this? Certainly not the decommissioning of the CA architecture, as feared by some. What would then be deployed would be a graduated ramp of security, where each server enjoys the best it can afford.
No longer would the choice be: security, but only if your merchant can spend the price of erecting his own personal Maginot Line. With the above series of choices, security could be delivered according to cost, the only way that we would know that it was the right security [6].
iang
Addendum: [0] This rant originally posted on the cryptography list 20th April, 2003.
[1] "Who's afraid of Mallory Wolf?" posted 23rd
March 2003 on cryptography list.
http://www.iang.org/ssl/mallory_wolf.html
[2] "How effective is open source crypto?" posted
15 March 2003 on cryptography list.
http://www.iang.org/ssl/how_effective.html
[3] Here's several all collected in the month of writing this rant:
http://www.iang.org/ssl/spoof1.html - repeated several times over ensuing days,
http://www.iang.org/ssl/spoof2.html - not really a spoof, but a harvesting, and
Here's a useful summary added 10 July 2003. http://www.iang.org/ssl/spoof4.html. Identity theft is now America's #1 problem.
[4] This has been going on for a long time in the e-gold community, but now seems to have crossed over to credit cards:
New way to steal password. A Discover credit card customer receives an e-mail telling him that his account is on hold due to inactivity, and that in order to reactivate his account, he must log in to this phony Web site. The information collected includes plenty of data that would enable identity theft: Social Security number, mother's maiden name, account number, and passwords. Similar scams have targeted PayPal and eBay customers.
<http://www.msnbc.com/news/884810.asp>
<http://www.computerworld.com/securitytopics/security/cybercrime/story/0,10801,79380,00.html>
or <http://tinyurl.com/7mgh>
Cryptogram, 15th April, 2003.
[5] It's probably worth stressing that these attacks are extraordinary in their inventiveness! Emails encouraging great things, warning of dire consequences, alerting to supposed controls, all sorts of things. Wonderfully accurate sites, convincing URLs. It makes you want to employ these people, as their resumes are impeccable, and often, economically productive!
[6] Analysis would go like this: If each spoof managed to grab $100, and there are 2 per month against that one site, he and his customers (same thing) will incur losses of $2400 per year.
So, spending money on a cert would be justified for that site, assuming that the cert protected against the spoofs. To meet that assumption, however, would involve fixing the browsers as described above.