Author Archives: iang

About iang

Contrarianism rocks! Security for the members. Help yourselves, coz no-one else will. Must be time for a cup of tea.

Wien [Metalab] Einladung zum Fellowship-Treffen in Wien

Liebe Freunde der Freien Software,

am 15. Jänner 2010 findet ein Fellowship-Treffen in Wien statt. Wir treffen uns ab 18:00 Uhr in der Bibliothek im Metalab, Rathausstraße 6.
Die Agenda starten wir um 19:00 Uhr.

Folgende Punkte stehen dieses Mal auf der Tagesordnung:

  • Rückblick Vortrag TU Graz
  • Ausblick 2010
  • GnuPG Keysigning (dezentralisiert), auch CAcert assuren mögl.
  • Diverses
  • gemütliches Beisammensein

Wie immer richtet sich die Einladung an alle, die sich für die FSFE oder für Freie Software interessieren. Wir freuen uns auf eine große Teilnehmerzahl!

Viele Grüße,

Das österreichische Team der Free Software Foundation Europe
* Werde ein Fellow der FSFE und verteidige deine Freiheit! *
*** https://www.fsfe.org *** https://fellowship.fsfe.org ***

Support Activity and Error Rates

In the last few weeks, our one Support Engineer (Werner, working mostly alone) has processed 65 support requests, 40 in the last week. Each case generates 5 mails. At the moment, the SE works with an absence of system, on a clunky silly mailing list, so there is no workflow assistance available to him. He has to remember each of those cases over the days-cycle time, and relate them to all the other emails.

Errors are inevitable. I’ve so far seen and counted 3 errors or blunders. Which means we’re talking around a 5% error rate. That’s to be expected when building a new system, working with fresh people, with minimal historical help, and working through a flood of a backlog with crappy technical support and poor information. Also known as, drowning.

(Obviously, in time, we want to reduce that to around 1-2%. When I did my 5-10 cases a month back, I generated at least one error. I’m not good enough for Support, I’m up in the 10-20% range.)

You can help us by pointing out the errors, directly, and suggesting what it is you would rather have seen. Positive suggestions are always appreciated.

an almost empty Triage mailboxThe Triage team — Wolfgang, Martin, Michael, Joost — have to this point worked through outstanding emails back to July this year. See the attached for a picture of today’s Inbox. *Yes, it’s more or less empty!* They got there last night, and have reached the target I set them, to get back to July.

That means a human has processed every one of approximately one thousand support emails received over the last 5 months. There’s probably dozens of errors in their processing, but that misses the point.

In the next month or so, some or all of the Triage people above will get through their ABCs and become SEs or Support Engineers. At that point Werner will have help. At that point, we’ll be able to improve our systems. And, we’ll need more Triage people!

You can help us by signing up to Triage. Let me know if you fit the profile: Assurer, great with mail / MUA, etc, time to handle lots of little, quick tasks, good with English reading (other languages an advantage), and you grok the community (CCA, DRP and you want to know more about Security Policy but were always afraid to ask…). IRC.

We need people outside the European evening slot…

iang,
interim, temporary, impatient Support t/l,
looking for any excuse to get sacked!

A small milestone: CPS to the main site

After a recent policy group decision p20091106, Philipp moved the DRAFT CPS onto the policy page on the main website, and also got rid of the old document that was at cacert.org/ policy .php with a redirect.

We started writing the CPS or Certification Practice Statement way back in early 2006. It was the first document to be considered, and the last to get to DRAFT state. This is in part because stuff was thrown out of it into other more appropriate documents: Organisation Assurance Policy, Dispute Resolution Policy, Policy on Policy, Assurance Policy and Security Policy all took their roots from this area, and for a while, we concentrated on those. CPS became the one that couldn’t be finished until the others were stable.

Curiously, there was already a fairly good effort at a CPS in place, written by Christian Barmala. This was a pretty good effort really, and it formed the starting point. There were two problems with the old document, which were that CAcert didn’t own or (totally) control it, and it had never faced audit scrutiny. So the decision was made pretty early on to rewrite it, and looking back, that was the right one.

Today’s move marks the removal of that old document. But our thanks go to Christian for giving us a starting point, to study and build on. Major influences on this new CPS include Philipp Güring, Jens Paul, Philipp Dunkel, Teus Hagen, Daniel Black in time order. And of course, myself, as eternal critic.

If you’re wondering, what next? then hop on over to the policy group and lend a hand. They’ve got a lot to do: CCS, finish the CPS and SP, PoJAM, TTP, Remote/Desert, Tverify, Code-Signing. Recently, the policy group just made it easier to get IDNs (a change that made it into the CPS).

And, if you’re wondering why it took 3.5 long years to get the CPS to where it is, you’re asking the wrong question. To paraphrase a recent post;

“ask not when your policy is written and ready for you,
ask when you are ready to write your policy”

Client Certs are the future…

One of the things I recently discovered (to my surprise) is that client certs used in browsers are out of scope for browser policy purposes. This is because *the server* is the relying party, and there is no decision of reliance to make in the browser. So the vendor doesn’t care.

And, as we know, for the most part servers require a fair bit of config to get up and going … so even a decision to distro the root of one player or another isn’t so important.

The playing field is more or less level. What’s perhaps more controversial is this claim: client certs deliver more bang-for-buck in real security benefits than any other use of certs.

Which means that our idea of using client certs every where (CATS.cacert.org originally, but now webmail, archives, and this very blog!) is also a good strategic direction. We can deliver!

Therefore, Apache tutorials like this one by Dan are much more important. Download it today! Put it into practice on your website! Not to mention, that client certs delivers lots of administration benefits in easing our management of sites, as I muse on over at my blog. Have you noticed how there are no complaints about lost passwords over at CATS.cacert.org? No more comment spam on this blog [1]?

Say No to Spam!

What I would like to see is a list of systems where CAcert certs are now in definite use. Production. Benefits! This would include CATS in pole position, also the blog, the webmail, the mail archives. Also possibly that OpenID server (is that run by Assurers? I assume so… I’m not even sure where it is).

[1] OK, it seems that only a very few long suffering admins could even see it. So you probably can’t see it, … and can’t imagine the joy of not having to deal with it ever again 🙂 I checked last night, there is a tiny bit of trackback spam, which I can’t quite see how to deal with, but nobody cares about trackback these days…

The Future Of Identity will not be found in Britain

Commentary, rants, not warnings of Downtime! Dave Birch runs a blog called Digital Identity to promote his consulting company (CHYP or Consult-Hyperion) which specialises in Money and Identity systems. His recent post on British experiences with Identity things is of interest to people here. Here’s a quick summary:

  • A French ID card can be used to get you a job at Sainsbury’s, but not to buy alcohol.
  • Banks can tell whether local passports are real, but foreign passports are just accepted. Because they can’t tell, they don’t.
  • Remember the Irish Police force’s search for their most wanted speedster: Mr Prawo Jazdy. Once they translated the term into “driving licence” in Polish … all became clear.
  • A car owner was arrested because his new form was a slightly different colour. The registration people thought it was a forgery and called the police…
  • You can call the UK Border hotline to confirm a national ID card. They will tell you “to ask [your] customer for a ‘second proof of identity’.”
  • It’s a smart card, and the smart way to check it is “to flick the card and listen for a distinctive sound, if they doubt the card’s authenticity.”
  • More here on how it is easier to get a bank account if you are a criminal or a foreigner than a poor unidentified person.

That’s all good fun! We know where all this is going … indeed, one of the strengths of the CAcert Assurance Process is just this. Working with the documents might be called a competence of CAcert, if we were into management-speak.

Read the whole article for the fuller picture; it’s fun. One thing I will disagree with Dave on is his recommendation that there be a digital solution that either works or it doesn’t. Although I frequently remind people that, in a well designed security system, “There is only one mode, and it is secure,” I think actually it is a hopeless goal to expect the British government to field such a system. They will create a pink elephant.

Far better for new identity systems to emerge from the marketplace. As suggested by Dave, this is likely to be the mobile phone. We are around 80% of the way there; and with things like Android, the other 20% is now on the marketplace. Soon enough…

Ask not what your country can do for you…

John F Kennedy inspired a nation by saying that. Then he said:

“ask what you can do for your country!”

What can you do for your community? Here’s one idea I’ve been playing around with. I call it Adopt-A-Page but I reckon there is a better title out there for it. It works like this:

  1. Identify your place inside the Community. Sysadm? Assurer? Coder? Arbitrator? Cert-user? There are lots of possibilities.
  2. Find your favourite CAcert.org web page that relates to your part in the Community.
  3. Link to that place from your many websites.
  4. Keep it live and relevant. Update your collection from time to time.

That was easy! Why is this so important? Another easy question with a simple answer: FUNDING. CAcert needs money to finance the current audit work programme and the next audit. We can get that by (a) being a source of advertising and (b) by being higher profile.

Both of those things can be helped by YOU linking into CAcert. That’s because a little help by you, multipled by the size of our community, equals a lot of help!

It really doesn’t matter where you link in to. You choose. What matters more is that you use diverse websites, if you have them to hand.

This is one thing you can do for your Community!. Point your website to us. Proclaim your ability as an Assurer. Tell the world which system you administer. Tell us you care. Loudly! Tell us you’re part of the community. Hell, tell us anything you like, as long as it includes a link 🙂

Can a competition help?

Over at the Economist, they are reporting on how to figure out whether a bot can be human: that which we software geeks call the Turing test.

IF A computer could fool a person into thinking that he were interacting with another person rather than a machine, then it could be classified as having artificial intelligence. That, at least, was the test proposed in 1950 by Alan Turing, a British mathematician. Turing envisaged a typed exchange between machine and person, so that a genuine conversation could happen without the much harder problem of voice emulation having to be addressed.

It’s curious how Alan Turing managed to predict the arisal and social domination of things like IRC, ICQ and now Skype. Back to the Turing Test, some AI people are now doing it within competitions:

At a symposium on computational intelligence and games organised in Milan this week by America’s Institute of Electrical and Electronics Engineers, researchers are taking part in a competition called the 2K BotPrize. The aim is to trick human judges into thinking they are playing against other people in such a game. The judges will be pitted against both human players and “bots” over the course of several battles, with the winner or winners being any bot that convinces at least four of the five judges involved that they are fighting a human combatant. Last year, when the 2K BotPrize event was held for the first time, only one bot fooled any judges at all as to its true identity—and even then only two of them fell for it.

Can a competition help? Apparently, Yes! It revealed that the way to tell if it is a bot is to measure its perfection:

…But it must also have enough flaws to make it appear human. As Jeremy Cothran, a software developer from Columbia, South Carolina, who is another veteran of last year’s competition, puts it, “it is kind of like artificial stupidity”.

Mr Pelling says that one of the biggest challenges lies in programming the bots to account for sneaky tactics from the judges. It is relatively easy to manipulate the game and do unnatural things in order to elicit behavioural flaws in a badly programmed bot. And if a judge observes even a single instance of unnatural behaviour the game is, as it were, over.

To me, that’s a surprising result. Obvious now that I think about it.

Maybe competitions can help because they encourage really innovative things and thinking? Can they help us at CAcert?

To this end, we recently had the bright idea that one way to get our systems to the next level in security and robustness was to run a competition to create a signing server. The idea behind the signing server is that it is basically a hand-built small computer that just does signing. That part is simple, and the obvious approach is to buy a small machine, load up Linux or BSD, install Apache, and start signing. And, that’s precisely what we do! Today, right now, as it happens. Good luck, guys!

But how to make such a signing server secure? That’s a really tricky question. Worse, it is a question with many contradictory answers, and many very expensive answers. I have a feeling that it should be cheap, it should be something we can do without contradictory answers, and it should be something we can do ourselves.

It should also be fun! Maybe, just maybe, we can run a design competition to create the design for a new-generation, open and secure signing server. Any one agree?

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.

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.