Monthly Archives: August 2009

CAcert.org at OpenExpo09 in Switzerland – Winterthur / Zürich – September 23.-24., 2009

OpenExpo, the Swiss leading conference and trade show for Free and Open Source Software, will take place for the 7th time Wednesday and Thursday, September 23. and 24. 2009 at the Eulachhallen in Winterthur / Zürich. CAcert.org is proud to be present among many other Open Source Projects as part of the Open Source Community.

Additional Swiss CAcert assurers or CAcert assurers from any country with successfully passed assurer test and willing to help, register in the CAcert.org Wiki.

———————————————————————————————————————————————————————————————————————————————–

OpenExpo, die Schweizer Messe und Tagung für Freie und Open Source Software findet zum siebten Mal statt, am Mittwoch und Donnerstag, 23. und 24.September 2009 in den Eulachhallen in Winterthur / Zürich. CAcert.org ist stolz darauf, mit vielen anderen Open Source Projekten an diesem Anlass teilnehmen zu dürfen und Teil der Open Source Community zu sein.

Zusätzliche Schweizer CAcert.org Assurer oder CAcert.org Assurer aus irgend einem Land mit erfolgreich absolviertem Assurer Test, welche mithelfen wollen, tragen sich bitte im CAcert.org Wiki ein.

Evidence of Destruction of Broken Signer Disk Drive

CAcert’s SysAdmin team used the opportunity of HAR2009 to destroy a broken disk drive. HAR2009 is an open-air gathering of hackers, and although “hard to explain” it was ideal for this need. The disk had only been in use for a short period within the signing server, but was taken out of service because of reliability issues. This is common with today’s disk drives, and does not relate to a particular manufacturer. To get high performance, the envelope is pushed, and consequently many more drives fail than we want.

In order to be in compliance with CAcert’s policies, the disk must be wiped and then destroyed. With a newly-developed disk destruction machine MAXXeGUARD offered for free use by CMGG and Security.nl for all attendees of HAR2009, it was an opportunity too good to pass up.

All such actions are logged and witnessed for future audit purposes. The process has been photographed (see pictures below) both for the evidence purposes and to give us all an idea as to how much work goes into CAcert’s systems.

The disk destroying machine, Front view
The disk destroying machine, Front view

Close-up of the disk destroying machine with disk drive
Close-up of the disk destroying machine with disk drive

The disk drive starts his way to heaven
The disk drive starts his way to heaven

Shred as shred can or no way to escape the shredder
Shred as shred can or no way to escape the shredder

Tiny bits and pieces
Tiny bits and pieces

SysAdmin Team Leader Wytze showing the final result
SysAdmin Team Leader Wytze showing the final result

Photos by Hans Van de Looy, CAcert.org Assurer

New Legislation for CAcert Inc.

As we know, CAcert Inc. is incorporated in NSW, Australia under the Association Incorporation Act 1984. That Act has now been updated to the Association Incorporation Act 2009, which is expected to come into effect during late 2009. Once in effect, the new Act will apply automatically, which means that any changes required will have to be aligned with our rules.

For CAcert Inc. the most significant change, among other changes is, that three (3) committee members (CAcert Board) will have to reside in Australia. Other relevant changes will come into effect as well. This gives us tasks: to evaluate consequences for CAcert Inc. and for members, and propose any changes required at a General Meeting.

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.