DomainKeys Identified Mail (DKIM) – Phishing protection

DKIM is a standard for answering the old security question ‘is this email really from the author?’. As the DKIM related standard Author Domain Signing Practices (ADSP) just got approved it is timely tell you about it.

DKIM, like PGP and S/MIME signatures, answers this question DKIM using a digital signature of the email content. DKIM differs by making it more conducive to sign and verify the validity of the email at the email gateway and, just as importantly, signs email headers.

This is a fairly effective way of making it possible for the receiving email server to validate whether an email was sent through an email server under the control of the author’s domain. The author domain can through ADSP DNS records advice the receiving server that it signs all email and encourages that the receiver to discard email that is unsigned or has a broken DKIM signature.

As DKIM ADSP validation is based off the From: email which is effective in protecting users from phishing and social engineering attacks with a correct From: address. DKIM is not effective in preventing spam as any spammer can DKIM sign emails with their own domain.

To reap the benefits of DKIM you will need to deploy a DKIM signing and verifying product or service on your email gateways and follow the deployment guide.

CAcert has been signing personal emails and some email list emails for over a year and is moving to sign all automated emails before deploying a ADSP DNS record. DKIM Email validation as been occurring for also over a year without any problems.

Learn from each other

Free and/or Open Source projects are about sharing and learning from others as well. An inspiring example is Lydias proposal of a Social Media Guide [1], giving an practical introduction. Have a look at it, read and learn about social media and get inspired for the benefit of CAcert and the Free and/or Open Source Community.

Download:
[1] http://www.lydiapintscher.de/whitepapers/Social_Media_Guide_For_Free_Software_Projects.pdf

quick reboot on Friday

Wytze writes: In order to install a kernel security update on the CAcert webdb server it needs to be rebooted. We are scheduling this reboot to take place on August 21 around 10:00 CEST (08:00 UTC). The expected downtime is around 5 minutes.

FrOSCon 2009

FrOScon2009
Dieses Wochenende ist es wieder soweit, die FrOSCon 2009 in Sankt-Augustin bei Bonn findet vom 22.-23.08.2009 statt.
Es werden wieder zahlreiche Besucher erwartet und es wird wieder die Möglichkeit der Beglaubigung der Identität (Assurance) geben. Interressierte Besucher sollten bitte mindestens einen gültigen Lichtbildausweis dabeihaben.
Weitere Informationen sind auch im CAcert wiki und auf den Seiten der FrOScon zu finden.

Signing server outage [solved]

Friday August 14, 2009 19:15 CEST both the webserver and the signing server suffered from a short power glitch. Due to this power glitch both servers performed a spontaneous reboot. After a reboot both servers will wait for manual input, as a critical server engineer has to enter the decryption-password. The webserver can be managed remotely, this server was operational again Friday at 22:15 CEST.
The signing server cannot be managed remotely. In order to restart the signing server a visit has been made to the hosting center this morning. The signing server is operational again since Saturday Aug 15 10:30 CEST.

No other servers were involved. The signing server will be replaced with new hardware (with a dual power supply) within a few weeks, the new server is currently under test.

Vanish, Smoke and Mirrors

A little story is circulating around about a thing called Vanish. Basically this is a proposal to make keys disappear after some period of time, thereby making your messages safe from decryption by bad guys. Here’s what the Economist says:

“The researchers developed a piece of software called “Vanish”, which encrypts information before it is sent, breaks the encryption key into pieces and then sends the bits out to randomly selected “nodes” created by computers that are logged on to the P2P network. Once sitting on a node, the pieces of the key wait for another copy of the Vanish software to access them in order to read the encrypted message. However, the pieces of key do not remain on the P2P in perpetuity. When a computer is disconnected from the network, the node it formed ceases to exist and any encryption-key data stored there are lost.”

This sounds good, and it looks in the direction of a real problem: how to stop innocent gossip turning into damaging claims in the far distance future. But the problem space is wrongly understood, and hence the solution is only cute: Distracting at best and dangerous at worst.

It is a real problem that others can read your emails. But the essence of “who” the “others” are may be more important than the way of protecting the email. It turns out that in the history of communication, indeed of all of society, the damage done by unknown and remote others is miniscule and rare, vanishingly small as it where, whereas the damage done by those you are in close contact with outweighs anything the bogeyman ever did to you. Real harm is a story of enemies-once-friends, partners turned civil suitors, spouses now friendly with expensive divorce lawyers. Statistically, the rest is just smoke.

Usefully, Vanish takes aims at this important group of future threats by trying to make the encryption key unavailable to everyone after a certain period of time, both for ourselves, and our friend-turned-enemy. But there is a lurking problem here, as once the message is seen on your counterparty’s screen, it can also be trivially copied and archived.

Hence, approaches like Vanish become more like a warning to honest people to be honest, please, and less a defence against people who aren’t so honourable. In other words, a cute trick. It does nothing to stop their good intentions from shifting to bad, and thus works more for your future aggressor than it does for you.

Indeed, people being people, Vanish sets you up for the fall. In the trade, we call this a false sense of security; while you believe your messages are “vanishing” your counterparty is screen-scraping them into a secret archive, to be revealed at a moment of considerable discomfort to you.

This is not the first time such a marketing claim has been made. SSL is frequently claimed to protect transactions, even though they are woefully unprotected in the most dangerous of places: the server and client nodes. Closer to Vanish’s design space, a protocol called OTR tried a similar trick, and fell to the same trap of false security. OTR, for “off the record,” purports to make it hard to prove that you sent a message. Hence, by some mathematical logic, you are safe to say outrageous things, because nobody can prove you said it. But this is just techie fantasy. Cryptographic proof of sending a message is a trivial barrier overcome with great ease in real life, and generally with much cost to you. Try lying to your parents, but don’t try it before the judge. Still, one has to admire the supreme faith that technical protocols and especially cryptographic blah blah can solve our human shortfalls in societal behaviour!

CAcert has another answer, although again it is only a partial answer and not a comprehensive solution. You and I can agree that our messages are private and are to virtually vanish within X hours. As a contract, and under our civil jurisdiction of CAcert’s Arbitration, we can make CAcert Assurer Reliable Statements to each other, and be held to them. If we agree that our discussion is “gossip” and we will delete them in 12 hours, and act as if deleted in all ways, then that’s something we can rely on. Even if I were to breach my CAcert Assurer Reliable Statement, you can ask the Arbitrator to remind me of my duties.

Of course, that won’t work under a criminal investigation; whatever we think about “honour amongst thieves,” that limitation is there. Also, an Arbitrator or Judge cannot stop these embarrassing emails being leaked, once already done. But at least this concept reaches into the future, and rests on human behaviour not cryptographic blah blah.

Null-stuffing attack on SSL certificates

There is much news lately about the Null-Stuffing attack to SSL presented at BlackHat by Dan Kaminsky, Len Sassaman and Moxie Marlinspike. Quick answer: Our current assessment is that we were “probably not” vulnerable to this particular attack.

Bug: there is a theoretical possibility to create a certificate for example:

myspace.comNULLmy.cheapdomain.com

A CA might check the domain, and end up accepting a POSITIVE on the second part only. Meanwhile, a browser might show the first part, because it is written to stop processing when it sees the NULL . This is because NULLs are special characters that might be interpreted as the end of string, or might not be, and a browser might mistake it one way while a CA another way.

Analysis: At one level this is “just” input validation, and both browsers and CAs should reject immediately. At another level, the code that manages this input is very complicated, because of the way certificates are built. Too many standards, layouts, encodings. Hence the comments by many that this bug is actually indicative of systemic weaknesses in SSL. Technically, implementing SSL properly means this isn’t possible, but the system is so complex that it isn’t easy to rule out these sorts of issues. But, we don’t win anything if we pass the blame onto someone else, because we’ve still got the bug. Basic technical conclusion is that we need to check our inputs carefully, and hope that others do the same.

CAcert. So where are we at? Is CAcert vulnerable? This boils down to whether CAcert can issue a certificate with a NULL stuffed into a domain name. Which is in two parts: adding a domain name to your account, and sending in a request for a certificate (CSR). Investigations are on-going, but here is a status update:

  • Adding domain names is now covered with a quick fix that was patched in Friday.
  • CSRs were already being filtered on NULLs, so someone was alert back in the earlier years!

What is outstanding is checking that the database copy of the domain name is used instead of the CSR, and scanning the database for any NULLs. It’s still not entirely clear if there was a way to sneak a NULL through before that patch in, but it’s covered now. This work is ongoing, and updates will be reported here.

Service Failure of CAcert Email System

The CAcert Email System went down Friday fornoon 31th of July 2009. This problem caused that no emails could be transferred. The systems team works on it to solve the problem.

update:
After a reboot of the server, the Email system is working again. Multiple non-critical services were affected to a more or less extent. The cause was a problem with NFS.

Special General Meeting 20090725

CAcert Inc, the association within the Community, held an SGM or special general meeting on Saturday 21:00 UTC. Which makes it evening in Europe, afternoon in the Americas, and tomorrow morning in Australia.

Between 38 and 42 members were present. 4 business items were duly filed (21 days in advance) and were dealt with in the meeting.

#1, that pending applications for joining the association be accepted was passed with no vote, because all applications had already been dealt with.

#2 is a comprehensive rule change that (among other things) asked to do this:

  • made the status of Assurer the only requirement for membership of the Association,
  • increased the size of the board to 10,
  • rewrote and fixed up lots of other bugs in the rules.

It was voted and achieved 24 AYES against 14 Nayes. As this is a rule change, it required 75% and therefore failed. But, a good showing.

Item #3 was the controversial one. The first resolution said we association members were “disenheartened at the breakdown of working relationship.” It passed with 35 AYES to 5 Nayes. The second resolution said “the committee no longer enjoys the confidence, of the members, and [they] are removed.” It was duly voted and passed with 20 AYEs to 16 Nayes. With that resolution the board was relieved and opened for the next item.

The final business of the day was to elect a new board of 7 seats for an interim period of 4 months, until the next AGM. This was conducted on a person-by-person basis, and the 7 top-voted candidates were chosen:

Name Position
Nick Bebout President
Mark Lipscombe Vice-President
Ernestine Schwob Secretary
Philipp Dunkel Treasurer
Guillaume Romagny Ordinary Member
Andreas Buerki Ordinary Member
Ian Grigg Ordinary Member

This is the new committee of the association, or board. Please note:

  • the committee will adjust the positions somewhat, and
  • this committee is interim only, in place for 4 months. At the AGM, traditionally in November, they will stand down and face re-election.

Postscript: By means of m20090728.1 the committee agreed that Ernestine Schwob is now Treasurer and that Philipp Dunkel is now Secretary. No other changes are envisaged.

CAcert at Webmontag Berlin, Montag, 20. Juli 2009

Am Montag, den 20.7.09 findet in Berlin bei newthinking store, Tucholskystr. 48, Berlin-Mitte
der nächste Webmontag statt. Zu diesem Termin wird es für CAcert einen 10 minütigen Vortragsslot geben.
Arbeitstitel: CAcert – Was ist das? Wer steckt dahinter? Wie geht es weiter?
Anschliessend wird es die Möglichkeit für Assurences geben (Für Assurances bitte einen oder mehrere offizielle Lichtbildausweise mitbringen – Personalausweis, Führerschein, Reisepass).
Weitere Details unter Webmontag Berlin 20.7.09