The history of your threat model
Ian Grigg posted a screed about how the threats SSL is intended to counter (network eaves dropper) are not the most common threats that web users actually face (trojans, worms, and other host-based security problems). He talks about the need for page based security, rather than connection based security. Historical note: at one point there was a page-based alternative (SHTTP) but it was more expensive and not backed by the winning team.
Due Diligence provides a history of the SSL threat model, blaming it on bad business strategy. Unfortunately, the account is factually wrong on several points. STT wasn't Microsoft's answer to SSL. Microsoft already had, actually, already implemented SSL. In fact, Microsoft and Netscape had even managed to do some interop testing by the time STT was under way.
STT was a joint project between Visa and Microsoft. It was Microsoft's attempt to get a piece of each credit card transaction on the Internet; it was Visa's effort to beat MasterCard to the punch and gain market share. Rumor had it that Visa had given Microsoft some favorable terms in exchange for an exclusive arrangement.
Not to be left out, MasterCard teamed up with IBM, Netscape, GTE, and Cybercash to create their own protocol, SEPP.
As it happens, MasterCard and Visa are both directed by the banks they serve, and those banks (many of whom offered both Visa and MasterCard), weren't keen on implementing two similar technologies (especially given all the infrastructure they required). It quickly became clear that this was not an area where Visa and MasterCard were welcome to compete.
And, thus, SET was born -- even American Express and Discover were invited to the table. It was initially was a simple merging of the two protocols, but quickly expanded to cover all the specific requirements of each of the credit card associations. And this was it's downfall, because, at the end of the day, the card associations weren't the customer for this: the merchants and the member banks were. While SET did a great job of covering the risks the card associations were worried about (e.g. merchant fraud, stolen cards), it did nothing for the banks or the merchants, who were expected to pay the majority of the cost to implement SET.
It didn't help SETs case that it was slow out the gate: by the time it was ready, consumers had ample opportunity to become comfortable with the risks of the internet (which, in point of fact, were small -- merchant's eat fraudulent transactions on internet and phone orders).
Merchants had also gotten a sense for what fraud would cost them and found that there were cheaper ways to mitigate the risk (e.g. checking for real email and street addresses) than SET. So, SET was DOA.
I know this because I had a small to role to play in these events -- a great experience to have early in my career. Great lessons learned, the most significant of which was cool technology is nice, but if you don't know who your customers are and understand their needs, you're wasting your time.
WRT to Ian Griggs post: From my point of view, SSL was never really intended to address the risks we know of today. The funny thing was that the risks that people were afraid of on the internet were largely not an issue -- already well handled by the credit card processing model (which distributes risk to those who benefit the most and are in the best position to make informed decisions). SSL was just the placebo for the thing that people found most unnerving -- dangling their private bits out on the new and unknown internet.
Posted by dapkus at October 21, 2003 09:32 PM
| TrackBack