Hi Kurt,

Not wanting to start a flame war, but here is some extra information to consider:

1. Trusted roots in browsers: - Yes the list of "trusted roots" that ship with IE and Netscape is an issue and one that is being looked at by both vendors. Interestingly this is not because of security concerns but due to performance issues and size of trusted root stores. - It is possible to use Active X controls in IE to both automatically import trusted roots and disable imports. - Previously to get your Trusted Root in a browser, you just needed to pay M$ or Netscape a large sum of money.

These would seem to be points in my favour =).

2. CRL's - IE 5.5 SP1 uses CRL's, as do most commercially developed PKI enabled applications

Check whether "check for revoked certificated" is on or not. It probably isn't.

3. CA's - The process of becoming a CA is actually not as trivial as people think. Here in Australia for example the process of becoming a CA involves complex Government accreditation and costs around $35k US. This is without any hardware or software costs.

Uhmm, 35k is peanuts, hardware/software are a coupla of hundred k and up, again it's not expensive. Plus you can always go offshore (some of the certs in IE 5.5 are in .... interesting countries).

4. PGP - Pretty Good Privacy, would you trust something that claims to be "Pretty Good" ?

Exactly, especially with that teeny little key bug in every version till 6.5.3.

5. SSL certs. - Ever signed up for one of these from a CA such as Thawte or Verisign? The process involves some complex paperwork to establish trust and to prove your organisations identity and is coupled with some severe instructions on securing your private key. In most experience this is a process that is too hard for inexperienced admins.

WRONG. I used to have a Thawte cert for www.seifried.org (I figured it was the best way to learn about secure webserving). It took me 20 minutes to get the paperwork done and cost a hundred odd bucks. They also used to sell class 2 personal ID's (verification done by equifax, a major credit bureau, in other words stupidly insecure), all you needed was name/address/etc and social security number, all trivial to get.

6. Kerberos - RSA SecurID provides a better solution that Kerberos, as it does not present issues of pack expiry times. In theory it could be possible to capture a users pack and then be automatically authenticated to systems. For single sign on in a secure environment, PKI protected with SecurID provides for far stronger security than Kerberos.

single sign on also means single point to break in =). RSA's ACE server has numerous problems, I'm not terribly enamoured by the company. Kerberos doesn't require certs/etc, a huge advantage for implementation. I could roll my stuff over to kerberos tommorow and users wouldn't really be bothered to much.

7. Self Signed Certificates - Who signs a root cert depends on the trust model and organisation wants to implement. Is the business environment an open or closed model? It is not always necessary to have a certificate signed by a third party. Indeed, in a closed B2B environment a self signed root cert can provide an equal amount of trust as one signed by Verisign. If I am only

This root cert needs to be installed in whatever software you use.... this is usually done after the factm getting more root certs in (from an attackers point of view) is way to easy (my follow up covered a variety of methods).

transacting with my own organisation or with partners, there is no need to involve a third party as I can validate all trading parties. In

Most of these companies can't protect credit card data properly (why do they store it in the first place??) and you expect them to setup and run a CA properly? You have a lot more faith then I do ;).

addition once I have created a signing certificate (a jurisdiction) I no longer have a requirement for my bootstrap certificate, or root cert.

Yeah but you have to expire that cert once in a while.

This can be safely exported from the CA and stored safely. By embedding CRLs into my application, I can revoke a jurisdiction if my signing certificate is compromised. When I control the CA, this response can be initiated significantly faster than when a third party is involved. The third party could be compromised and I do not even know about it.

Embedding certs in software raises some points, for one thing an attacker can still modify them.

8. Open source, versus commercially developed. - What your focus has been on so far is pretty much open source security. I am a huge fan of open source development however in this

There aren't really any widespread closed source crypto things =) All the important algo's/methods are publically documented to death and have been beaten on repeatedly. I picked on some commercial products in my two articles =). I don't really see the flaws in ssh/ssl as having anything to do with opensource verse close sources.

instance commercially developed software provides much greater security. In an enterprise environment, or where I was committing high value transactions, I would not even consider using SSH or out of the box SSL.

Hopefully others will come to learn this =). My articles on ssh/ssl is an effort to educate people, make them realize these solutions are far from perfect as many seem to think.

The use of Reduced Sign on PKI toolkits with Certificates provides a much better method of providing security. Unfortunatly, these types of products are to expensive for low value transactions (and the use questionable due to the value of the information being protected).

Yup. Any who cares anyways, credit card companies just pass the cost on to consumers and merchants (who pass the cost on to consumers). Consumers need to stand up and make some noise, egghead just had 1.3 million card numbers stolen, great.

9. Sliding security scale - Security can be described on a scale ranging from DC to AR. At one end of the scale you have Admins who don't care, the other extreme is Anal Retentive. Both extremes are inherently bad for the protection of systems. The DC admin doesn't believe that his or her system is worth protecting. While the AR admin believes no security measures offer enough protection and hence refuses to do anything.

Well I would hope everyone realizes no security is 100%, it's about striking a balance, aka "risk management". It's fine (IMHO) for a major company with say 500 million a year in revenue to suffer say 3 incidents that cost them a couple tens or hundreds of thousands of dollars. This is why we have insurance.

There are however products that sit on various places on the scale with the cost increasing exponentially as you progress from DC to AR. Products such as PGP, SSH, and SSL out of the box sit just to the right of DC. Cryptographic Toolkits such as SSL-C, Crypto-C, Cert-C and WTLS-C from vendors such as RSA Security and Baltimore take you further along the scale (as they enable you to rewrite applications to improve their security). PKI products progress further to the right and when combined

And way to many companies make a mess of things when they roll thier own. Look at eschwab's password storage mechanism. Whooops.

with Two Factor or Three Factor authentication (SecurID, biometrics, smart cards) you are as close to AR as you can get.

Fortunately these products are coming out (I saw a nifty smart card reader with thumbprint scanner, you could setup the smartcard to need a PIN and thumbprint to access it, very good stuff).

The question is, which part of the scale should a good admin reside? The answer depends on the value of the information they are trying to protect. Personally, I use a self signed Cert, created using ssleay, combined with user name and password to access my email remotely. However the NCA use cryptographic toolkits, with custom applications and three factor authentication. Why? Their email is a little more valuable than mine.

In summary, the type of attacks described by yourself, while possible, present no real threat to an organisation because the complexity of the attacks do not really justify the benefit gained from the retrieval of information. If I was to fall victim to a man in the middle SSL attack while shopping online, AMEX pick up the bill, not me personally.

Uhmm. No. Have you downloaded dsniff and used it? It's trivial to do these attacks. Especially SSL ones because you just do a man in the middle while they are on the insecure part of the site (ie poisoin their dns). See the article below all this (the article is over a year old, wheeep).

The true enemy to security is not pie in the sky exploits as you have described but apathy in the boardroom and by IT managers to implementing a security policy and products in the first place. Articles such as yours, while valuable from an academic view point do not assist this cause.

Pie in the sky. yeah. ./configure ; make ; then use it.

Regards,

Kelvin Rundle.

Further Reading: http://computerworld.idg.com.au/cwt1997.nsf/all/6BBEB57277625B344A2569A60077...

======================== September 30, 1999 - 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 and the summary. 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.some-online-store.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. 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.