 This is CSert, the community CA, and we want to talk about client certificates, the old new thing. This is really a story about authentication. In the beginning, everybody was trusted on the net. We're talking the 1980s, and they didn't last long. Then they got stuck into passwords, usernames, and so forth. In the 1990s, we were all talking about single sign-on, the ability to manage all of our assets on the net, connect everywhere with just one password, and followed in the early 2000s, we were talking about federation, which is this idea of going through one particular company or service to manage all that. What actually went wrong? We talked about it for a long, long time, and we did lots of stuff, but we never really got it going. In the beginning, it just didn't work out because everybody wasn't trusted. The passwords came along and solved that problem, but we hit the explosion of complexity. With too many websites and too many services, users were faced with remembering too many passwords, and consequently, this became complex for them, which caused support problems, and eventually the whole thing looked rather insecure. Single sign-on was invented conceptually to solve that problem. This problem was that every particular website out there wanted to choose a method, but it looked across at all the users who weren't choosing those methods. All the users would look at the websites who hadn't chosen the methods, and in the end, you have this chicken and egg problem. Chicken meets egg, nobody does anything. Federation was a similar variation where you've got your different companies and services managing and intermediating, but users didn't really like it because the company would hold all the data. It turns out that companies really didn't like it either because they were worried about customer data being held outside their site. You'd think that because we've done all this computer stuff and internet stuff, we would know how to do this by now, and we do know how to do it. Why didn't it work out? Well, we have the stuff to do it, and it's called client certificates. It's just this cryptographic stuff, public-private keys. You stick a signature on the end of your public key, you call it a certificate, you give everybody one of these, and supposedly, that's going to solve the problem. Technically, simplicity-wise, you can think about these things as super passwords, they're crypto passwords, they're much stronger than passwords, but other than that, there isn't really much except a lot of blah, blah. Every browser's got them, every website's got them, why didn't they work out? It's not the problem with the software, it's not the problem with the distribution. It isn't your data that's at risk, the data that we need to deliver to a CA is so small that it's not really worth worrying about. Companies don't care about their customer data being lost. The problem was every person needed one of these certificates, and getting the certificate turned out to be a lot more complicated, a real hassle, and it just dragged the system so in the end, the problem was nobody had the egg. So the chickens didn't get laid. Why not? Well, the best way to think about that is don't ask. However, CO-Cert accidentally found itself solving the problem. Now, we got into this egg business, the idea of giving everybody a client certificate by a roundabout route, and that's what this story is about. Technically speaking, certificates are about your identity, or that's what they want to tell you. And to check your identity, we need a thing called assurance. We do that with something like 3,000 of our people around the world. Many of whom are in the audience today or at FOSSTEM. We check your identity, and that means you can get a certificate. So the story goes, this whole thing where we have a bunch of people checking another bunch of people is called the Web of Trust. CO-Cert had a problem. It needed to get audited to get into the browsers. And the audit looks at this thing called the Web of Trust and says, how the hell do you audit a Web of Trust? It's such an informal thing. Well, the classical answer is the same as always. You do some documentation. You set some standards. You test that the standards have been met. And that's what we did at CO-Cert. We invented this CO-Cert automated testing system called CATS. We just needed a name. It's simple. It's 25 multiple choice questions in a PHP website, very boring. Anybody can knock it up within a couple of weeks. We insisted that all assurers go through the little challenge. And they did. This is where we had a bit of an inspiration. We then decided that CO-Cert would insist all CATS access would be via client certificates. No passwords. It just isn't there. So did we do this because we're a CA? Probably. We could also do this because we want our assurers to know about certificates. But that's a bit controversial. Maybe we want to look cool. And it's really not about high access. Why did we do it? Well, maybe it's because we wanted this story to happen. CATS was very successful for us. We turned it on in 2008. 2009, we made it compulsory by putting in this switch that stopped all assurances from working unless you have gone through your challenge and done your 25 questions. We started out with something like 10,000 assurers around the world. And then it nosedived down to the low hundreds and gradually climbed up. Today, it is 3,339. This is a week out of date assurers, which is about right. If you take any community and then put a big test on it, it'll drop down to about a third because you've got about a third who are serious and then two thirds who are just coming in to check it out. Today, our community is much stronger because we've done this. But what it does mean is every assurer in the CA cert world has got a certificate, which means we can now go across to all of the websites that CA cert runs, which is about 20 and growing. We have a lot of different little services everywhere. And we can insist that they all use certificate access. So that's what we're doing. We've done WordPress. We've done Simpar. We have a board voting tool which only takes certificate access, so we do all our little governance tasks in the board just using client certificates. It's now standard practice for all of our system administrators of whom we've got about 30 in different areas to put all their software into client certificate mode because we know we've all got the client certificates. Let's talk about the blog. This is just one example of how successful it was for us. With the blog, we've now got the situation where you don't need to control the account. There is no administrative step required. You just get your client certificate, go there, and start writing your article. It's a public blog, but we don't care about spammers because spammers don't have client certificates. We just let you all come in. If you've got the client certificate, you're in. Which means our administrator is not hassling with lost accounts and lost passwords and people phoning up in the middle of the night saying I must have a password now because I've got to get my blog article out. The administrator is now doing other things and the users are now getting more articles written. It worked for us, but there are some problems and we're getting the experience of how to navigate this minefield. The first problem, the gotcha, is Firefox isn't good at multiple certificates and of course, our assurers muck around with certificates quite a bit. With Firefox, if you use a certificate at one site and then want to use a different certificate at another site, it gets a bit confused. The bottom line is we're waiting for Firefox developers to do white listings such that the user can manage different certificates for different websites. It's unfortunate, but we just have to wait. The second gotcha is the crazy interaction between the server and the browser. What happens is the server will drop the connection because it doesn't like the certificate. But instead of giving some detailed information across to the browser, what it'll do is send back a protocol error. The protocol error is then given to the user via the browser and of course, the user has no clue what's going on. The user then says, well, basically, this doesn't work and goes off somewhere else. This is going to keep going on because the problem is that the browser and the servers, that the browser developers and the server developers don't communicate very well together and they both point at the other guy to say, this is where the problem is, we're doing the right thing. Well, it'll get fixed when more people are using client certificates and more pressure goes on these guys to sit down and work out the differences. How do we do this? It's now getting to the point where we can see the strategies. The first strategy is simply that the, we set up client certificates alongside passwords, allow both of them to go in. This is the sort of obvious thing that people do, but it's not really a good idea because it's a bit too much like the problem with HTTP versus HTTPS, you end up with phishing because there's a gap between them and there's no difference for the user, so the user doesn't know what's going on. You're better off going to the second strategy which is to use client certificates only and forget about passwords completely. Only SSL, only certificates, always certificates. And then you've got a choice. You can do your processing of the certificate inside Apache because it does have the facility to look at the certificate and do some parsing of it and give you some control, but it sort of does too much and too little. It's not quite right. So the other alternative is to just read the information from Apache through the PHP variables straight into your code and do it inside your application. And it turns out this is the best way to do it. Make Apache dumb, don't give it any control, just do it all in the application. Talking about that a bit more, one of the problems is that certificates will change when they expire. So you want to be able to give the user this seamless experience where that doesn't cause a heartache for anybody. What you do then is read the certificate information straight into your database and use that information to index across to the accounts. So when a new certificate turns up, you can scan that certificate and then go searching the database for matching information. You can match on the email address which is in the cert or you can match on the name that's in the cert. This is okay, it's a bit of a clutch, but if you do it carefully, you can basically manage the process. If the user goes and changes too much, like the entire name and email, then you've got to do something else. Conclusion, for us certificates really did work internally. We got a lot of benefit. We got a lot of advantage for the system administrators who had to do less work and lots of advantage for the users who found a much nicer way to get access to the service. We're saving time and effort. We've got to compare it against other methods. The big contender out there is OpenID. That's pretty good, but it's actually not good for high security stuff whereas certificates are good for high security stuff. It solves the problem across a much broader scope. Then there are lots of other single sign-on methods out there, federation methods and so forth, but they're not as available. They face this check and an egg problem which the certificates in theory do not. As long as you can figure out how to get everybody to use client certificates. And that's your challenge to go where we've already gone and got all our people across the client certificates. How do you do that? Well, what we did was the second of those, the bullet point there, we just built a site. We built the cat site. We said it's going to be certificates only and it's up to you guys to sort it out. And they did. Well, that's kind of easy because we're a CA. The top strategy is another one which I do over at Little Association where we run a bunch of CIS admins. We've simply set a rule. All of our CIS admins must be CA people. Half of them are. The other half can be fairly quickly and they will be. Once they are CA cert people, they can get their client certificate and get access to our new servers, which we're putting up. So it's simple. We just set a rule. You've got to be a CA cert person and away you go. The third thing you can do is you can create an internal CA using various pieces of software and start creating factory certificates for your people and push them out. That's another thing. It's a strategy. It's a way of getting into this certificate business. That's the end of my slides. I don't know what my time is looking like. I guess it's time for questions. It's kind of out of scope of what I'm talking about here. But yes, TLS renegotiation. Yeah, what happens with TLS and renegotiation? There's a bug in the protocol which caused Firefox to put in a patch to drop certain accesses for TLS. Client certificates still work. TLS still works. But if you're using renegotiation features, yes, you're going to have a problem. And this is one of those things going back to... That's... Hold on. Right. Yeah. The problem that occurs is when you are using Apache to do your processing and you're just essentially following Apache's rules and setting up multiple directories which cause the triggering of renegotiation. If you just use straight forward connections and don't do any trickery in Apache, I gather, I'm told, there is no problem. So you don't need a renegotiation. You're probably using .htaccess files in lots of different directories. And that's where you get into trouble. So hence, this is why I recommend that the Apache should be turned to dumb and the application should do all the processing because the application can be patched far more easily than the SSL protocol. But this is a very complicated area and I can't possibly answer that in one question. Anybody else? I'm afraid that the end of the time...