Slashdot Mirror

Dunno if this will get modded out of AC-land, but here goes:

For the newbs, CRLs or Certificate Revocation Lists are nothing more than lists of which certs have been revoked. If you're going to deal in non-physical access tokens (as opposed to, say, metal keys and RFID badges) you're eventually going to want to deal with the eventuality that people's lifespans are generally longer than the amount of time that they have access to your stuff. PKI is excellent for mathematically proving that noone that can't factor huge primes can get your secrets just by looking at bits on the wire, but you can't really demand that your recently fired employees surrender their keys since they could very well have made copies in advance. Now that I think about it I suppose the same is true of keys, so consider CRLs the digital equivalent of changing locks.

A CRL is a list of all they key IDs of keys that have been revoked. If you get terminated, you go on the list, and when you subsequently try to use your key, even though mathematically it works great, if you're on the CRL you get a 403 (or big guys with guns or whatever your model for Access Denied happens to be).

CRLs are as dead end as it gets. Especially if you're working with a lot of end-devices or end-users, your CRL situation is going to get fantastically out of control very quickly. Picture, if you will, the DoD. How many people do you think had keys last year who aren't entitled to them now? Sure, the really old keys expire, but the new keys that were revoked all have to be downloaded *every time* a user makes a query, or else you risk race conditions of varying severity. (One could easily imagine the race to get home and log in over the VPN to copy the Secret Plans after being fired; the amount of time a user would need to do this is about the longest you'd want to go between CRL updates. If a CRL was many megabytes large and if the authenticating device got many hundreds of requests per second you might have a problem.

OCSP , or Online Certificate Status Protocol, is a huge step in the right direction; instead of downloading the entire CRL to the authenticating device, the device instead makes a quick call to a OCSP responder, querying the status of the cert. The OCSP has a store of CRLs which it obtains from the CA/VA, and can create a signed response containing the status of the certificate: good or revoked (or, I suppose, unrecognized or otherwise munged). Now you only have to distribute CRLs to one/several devices, instead of every one in the infrastructure.

Some groups (Corestreet, among others) have created distributed versions of OCSP which use precomputed proof lists in order to avoid the problem of distributing private keys to a network of distributed OCSP responders for use in signing OCSP responses. This D-OCSP is vastly more powerful and flexible than CRLs (and proportionally expensive).

PKI is a pretty daunting challenge to implement correctly, and its even harder to make the other links in the chain nearly as strong as the crypto. Best of luck.

vvj

With Phishing so much in the news http://yro.slashdot.org/article.pl?sid=05/03/05/00 42226&tid=158&tid=218, http://slashdot.org/article.pl?sid=05/03/08/005223 5&tid=95, and the difficulty that most users have in detected a phishing url without tools like http://toolbar.netcraft.com/, http://www.corestreet.com/spoofstick/ it occurred to me that maybe a solution lies in creating a exclusive Top Level Domain(TLD) for banking. Many of the current problems reside in the free-for-all nature of registering a .com domain name which allows anyone with a credit card, forged or real, to create a domain name convincing enough to phish people. For example my email from Saturday contained an email with these two links purporting to be from Washington Mutal, https://login.personal.wamu.com/logon/logon.asp?dd =1> and http://login.personal.wamuecare.com/%20/logon/logo n.asp/dd=1/login.php in it. One is Washington Mutual's one is a phish.

I propose setting up a new .bank TLD, but making it exclusive to banking and financial isituditons with heavy checking of the business records of the applicatnt and even requiring a bond be posted in the range of $100,000 to $1,000,000. This high a level of entry to registering a domain in .bank would prevent all but the most dedicated phishers from registering say, wamuecare.bank since they would lose their bond if any fraud was found. While your typical user would have no trouble with seeing the .bank at the end of the domain name, and would have confidence in the web site he/she was visting. The cavaet being that the current round of url line spoofing attacks need to be solved, as Opera has http://it.slashdot.org/article.pl?sid=05/02/25/155 3236&tid=172&tid=218 . Of course International Domain Name (IDN) characters would have to be disallowed in .bank as well.

In my mind any organization that has real or "credit" monies that is keeps for it's customers, PayPal comes to mind, could apply for .bank domains but no one else. Lastly perhaps our govenments can mandate the use of this .bank TLD as a consumer protection keeping banks from trying to be cheap and stick with the .com domains they currently have.

I'm interested in what the ./ community thinks of this as well as what we think the defintion of a "bank" would have to be for this to work.

Spoofstick is a Firefox extension that might help in avoiding phising scams. It displays "the most relevant domain information". Looks like its available for IE too.

It still doesn't work. I've tried this on multiple systems.

except for the people who use Mozilla/FireFox because their friend/relative have advised it. Can you think of anyone that wasn't too technical whom you advised they should use an alternative to IE?

Btw, what's wrong with spoofstick?

Already available from Corestreet for Firefox and IE http://www.corestreet.com/spoofstick/

Although not a fix, there is an extension called SpoofStick (http://www.corestreet.com/spoofstick/) that lets you know if the webpage you are looking at has been spoofed. It is available for Firefox and IE. I tried the test at Secunia and it worked as advertised. So you can always verify that you are at the the website you intended to be.

The spoof worked for me on FF 1.0 on W2K. One more reason to use the Spoofstick browser plugin for FF or IE. It clearly showed the popup originated from secunia.com and not Citibank.

The Firefox plugin you're looking for is Spoofstick.

A little simple but it tells you exactly what site you're on.

They also have one for IE.

Spoofstick is a plugin for FireFox or Internet Explorer that can help identify 'phishy' sites while surfing.

It does take a little more real estate out of the browser's window, but it's a pretty useful tool when teaching people about the dangers of clicking links blindly.

I first thought changing themes would be sufficient to trick the "trickster", but I soon found out it called the current theme's images.

Spoof Stick is a plugin which allows you to see the real address of the website you are currently viewing.

All in all that spoof is very impressive from a web developers standpoint.

You might be interested in Spoofstick it shows you the "real" domain url for whatever webpage your connected to.

SpoofStick

it puts the base URL up in BIG, colored, text in your toolbar.