Domainkeys becomes a standard
Today, CNET reported that Domainkeys are adopted by the IETF as a standard and that the outlook of a lot less spam and phishing is nearby. In my opinion it will not solve the spam problem and fulfill Bill Gates’ prophecy of a spam free world any time soon.
The Domainkeys system works similar as signing your mail with PGP. The difference is that instead of signing your message to authenticate you as the sender, Domainkeys embeds a cryptographic signature in the header of the mail to authenticate the sending mail server for a domain. The public key, which is needed to check if a cryptographic signature is valid, is stored in the domain’s zone file.
The receiving mail server can check the signature of a message by fetching the public key through DNS for the sending domain.
On paper this seems great. It would mean that no one can spoof the sender’s domain.
The caveat is that, in order to make it really work, everyone needs to update their DNS and especially heir email infrastructure. Thinking about how slow the transition of IPV4 to IPV6 is going, this could take some time. Granted, a change (or update) of mail server and an update of the zone file is less work and less invasive then migrating your entire IP infrastructure but still it will be a long time until every domain runs on Domainkeys enabled servers.
Now, what will happen in the transition time? Having installed a few anti-spam solutions in various corporate infrastructures, I have learned a few things. One thing is that businesses hate false positives. No matter how much their dislike of spam is, no one wants to wait for an important corporate e-mail because the anti-spam solution falsely recognized it as spam.
So, in the transition time, when a mail arrives from someone@importantcustomer.com without a Domainkeys signature, most companies’ policy will be to just allow it even if another mail from someonelse@importantcustomer.com earlier had a Domainkeys signature. This is because the receiving party cannot be certain during the transition phase that the sending party has indeed upgraded their entire mail infrastructure.
Furthermore, a corporation is certainly not going to block mail from newcontact@futurecustomer.com just because futurecustomer.com does not have their Domainkeys in place yet.
This means that spammers can use domains to send their mail from and don’t even need to bother with setting up Domainkeys.
It is very important to understand that Domainkeys only authenticates the sending domain. This means that, as a spam protection, it would only work against spam mails which spoof a trusted domain. If a spammer would write spam from me@myjustboughtdomain.com, Domainkeys offers no extra protection whatsoever to prevent the spam from reaching its target audience.
An advantage of Domainkeys would be that it could mean the end of phishing. Assuming that yourbank.com has indeed installed the Domainkeys and you only trust Domainkey signed mails from yourbank.com, what would stop a fisher from acquiring y0urbank.com, setting up a Domainkey infrastructure for the domain and phishing you from there? Nothing at all, domains are being bought and sold every minute and that is not going to change. Will the user trust y0urbank.com? Most likely he will. It reminds me of a story about phishers acquiring a valid SSL certificate for one of their domains. Did the user fell for it? Off course, he did, since the user was always taught that a valid certificate (little padlock in your browser) means it is all secure right? No one ever educated him that SSL only secures the transport not the content, and in the phisher’s case, SSL secures a malicious message.
This brings me to the last part. Domainkeys only verifies the authenticity of the domain’s sending server, not the content of the message. The message could be modified in transit, if the Domainkey of the header is correct; the message is authentic for the receiver. Is it technically possible that the message could be modified in transit? Sure it is. It is not unthinkable that the sending mail server or another device along the path gets compromised.
To summarize, I think that Domainkeys could be a step in the good direction when it would be made mandatory for every server starting right now. Even, if it would happen overnight, Domainkeys would still not solve the spam problem. The only thing which would be a little harder is phising.
I think we will have to live with spammed inboxes and phishing a little longer.
Long weekend
This week, thanks to some holiday in Belgium, the weekend started on a Wednesday evening instead of a Friday. Every week should have a 4-day weekend!
Apart from some sleeping in, squash, hanging out in the pub, going out, catching up on my favorite feeds, watching some TV (I have refound my old love for South Park ), assembling a new gas barbecue (and eating food from it
), I have been playing with sguil.
Sguil is an open source framework to practice network security monitoring (NSM). It uses SANCP and barnyard to analyze Snort data. It seems like a good framework but the documentation is, in my opinion, not the best I have ever seen. After some compilation issues, I have managed to get all the needed software compiled now on my Linux box. The only thing left to do is to configure it to match my needs.
But, that will be something for later. Right now, Jack Bauer is eager to get his nephew back from the Chinese.
Time to update more frequently!
I noticed that, again, I did not update this blog for quite some time now. Of course, I have been busy with all kinds of stuff. But part of maintaining a blog is actually blogging about the stuff you are busy with and not using it as an excuse not to blog. Therefore I am going to try to update this site more frequently with all kinds of stuff.
On a technical level, this month I have been busy (apart from my day job as a security consultant) with some fun security topics including WEP cracking (the new and faster method), USB switchblades and some other stuff. I just ordered a new Bluetooth stick to play with so I will probably blog about that somewhere in the future
I also discovered google reader which is the best feed reader I have ever seen. Thanks to this excellent google tool, I can read my news, blogs, websites, etc in one interface accessible from everywhere.
How NSA access was built into Windows
A friend of mine sent me an email today with a link to an article stating how NSA access was built into Windows.
Although, it seems that this news is quite old, I only heard from this today. In my opinion, it is very scary that there are master keys for the encryption in Windows. This means that the NSA can look into your encrypted data at any time.
Now, while that may be handy for the NSA, what would happen if a disgruntled employee of the NSA/Microsoft dropped this ‘magic’ key on the black market. Suddenly anyone willing to pay for it could decypher your precious encrypted data. Scary stuff.
So, my suggestion is not to use the MS implementation of Encrypted File Systems but go with Open Source solutions like TrueCrypt . At least for the OS soft, the code can be reviewed by others.
Tom