by Kurt Seifried

SSL transactions are not secure.

The title is a bit scary, but I wanted to get your attention (worked, didn't it?). Most security experts have been aware of problems with SSL, but generally speaking we haven't said much because there wasn't much of a replacement available for it, and it hasn't been exploited extensively (chances are it will be, though). I'll start with an explanation of the basic attack, followed by some methods to protect yourself, and finish with an interview with Dale Peterson of DigitalBond.
October 13, 1999

How To Do It

Let's say I want to scam people's credit card numbers, and don't want to break into a server. What if I could get people to come to me, and voluntarily give me their credit card numbers? Well, this is entirely too easy.

I would start by setting up a Web server, and copying a popular site to it, say www.some-online-store.com, time required to do this with a tool such as wget is around 20-30 minutes. I would then modify the forms used to submit information and make sure they pointed to my server, so I now have a copy of www.some-online-store.com that looks and feels like the "real" thing. Now, how do I get people to come to it? Well I simply poison their DNS caches with my information, so instead of www.some-online-store.com pointing to 1.2.3.4, I would point it to my server at 5.6.7.8. Now when people go to www.some-online-store.com they end up at my site, which looks just like the real one. 

How to Prevent Being Taken

Most forms online are not on secure servers, but the data you provide is usually sent to a secure server, which leads to one of the major problems. The form data may not be going where it should. A simple attack is to have the fake site, and a form that takes the data, without using a secure server at all. How many of you actively check the source HTML of pages you are plugging your credit card data into? The title bar should start with https:// followed by the sitename (i.e.: https://www.microsoft.com/). You should also examine the HTML source to make sure the form data points to where it should go, you should see something like:

<form method="POST" action="/order.cgi">

or:

<form method="POST"

 action="https://www.yourdomain.com/cgi-bin/order.cgi">

If a store is using the "GET" method, do not buy from them, any data you enter will be passed along as the query string, if you look in the text of your address bar you will see your credit card info. If a store specifies a relative link (i.e.: /something/something.cgi) then make sure the current site you are at is a secure server, and that the certificate is legitimate. If the link is absolute, and points to an IP address, be suspicious, I personally would not buy if this were the case. Ideally the link should point to something like "https://www.some-online-store.com/cgi-bin/order.cgi", and you should first browse to that site, and make sure the certificate is legitimate, before hitting the submit button on your order form. Most current SSL attacks are based on fooling the user, more so than breaking the technology. If you are vigilant, and check certificates before you submit to sites you will be a little safer (but not completely).

SSL Certificates contain various pieces of information, such as who issued them, when it was issued, when it expires, who it was issued to and so forth. Who it was issued to (usually the "subject") is a very important field, and the issuer field. To view the certificate details double click on the lock icon, usually at the bottom left of the screen in Netscape, and at the bottom right in Microsoft Internet Explorer. Let's take https://www.microsoft.com/ for example, the Issuer field looks like:

OU = Secure Server Certification Authority
O = RSA Data Security, Inc.
C = US

The C stands for country, the O for organization (usually the company's name), and the OU stands for organizational unit (a division of the company). The subject field looks like:

CN = www.microsoft.com
OU = mscom
O = Microsoft
L = Redmond
S = Washington
C = US

The S stands for state, the L for locality (the city), and the CN is the certificate name (the site it applies to). Make sure all these are spelt correctly, many attackers will use domain names that look familiar (such as miicrosoft.com) in order to get legitimate certificates. Taking these precautions every time you use an SSL secured service is tedious, and underlines one of the major flaws with SSL, in that is susceptible to "social engineering" attacks. Another flaw in SSL is that it only secures the session, it doesn't secure any actually transaction. This means if someone does steal your credit card number and use it online, it is almost impossible to prove that it wasn't actually you that issued the order. SSL does allow for the client to authenticate to the server, however very few people have digital certificates compatible with this (I have one, and know of perhaps a half dozen other people, a definite minority). In addition to this the major certificate vendors have stopped issuing the personal certificates that guarantee the person's identity, so they are a dead end. There are newer protocols and systems that allow for two parties to safely conduct transactions with all these features.

An Interview With Dale Peterson

The following is an interview with Dale Peterson of DigitalBond (www.digitalbond.com). DigitalBond is currently working on a product to secure Internet transactions, and is targeted at brokerage houses which have many thousands of users on a daily basis, making them an especially tempting target.

Kurt: Is SSL dead?

Dale: No.  It is a fine session encryption protocol.  The editor for the TLS (new name for latest version of SSL) spec works at Certicom and is our partner.  I've talked this over with him, and he is very insistent that SSL is not broken.  But he does say it suffers from all the problems we have discussed in these emails and could be augmented with a transaction protocol.

I think that it certainly shouldn't be the protocol for most e-commerce transactions, but for the exchange of private data over the Internet it is ok.

Kurt: What do you envision replacing SSL?

Dale: We see a lot of businesses that are doing two-party transactions. Nice and simple, unlike the multi-party bank card model that SET addresses.  We have developed a two-party transaction security model that we thinks meets the needs of Internet Brokerages, Internet prescription drugs, and other two-party transactions.  It is being reviewed by Carnegie Mellon University, and they will publish a paper this year.

Kurt: Should we be educating users about these technologies? Do they care?

Dale: The most important education needed is that SSL transactions are not secure.  The whole Internet community has been fed this baloney because SSL was around and easy.  I have found it difficult getting reporters to even believe this vulnerability exists, even with a live demo.  The response is "That can't be true.  We would all know about this if that were true".  That is why I think this story will be big when it breaks in the mainstream press.

Summary

SSL is not dead. It is just an inappropriate security system for many Internet based transaction systems. As with many things on the Internet the growth of online sales, and especially the growth of online brokerages has been stupendous. SSL was simply not designed with systems like these in mind, and systems like DigitalBond are attempting to fix this. Chances are in 5 to 10 years that the existing systems will be found to be "weak", and replaced with better systems.

Related Links

http://www.digitalbond.com/

http://developer.netscape.com/tech/security/ssl/howitworks.html

http://developer.netscape.com/docs/manuals/security/sslin/index.htm

Kurt Seifried is a security analyst and the author of the "Linux Administrators Security Guide", a source of natural fiber and Linux security, part of a complete breakfast. This article was originally published in SecurityPortal.com - the focal point for Security on the Net.