CAcert: Client-certificates and SSO - the old-new thing
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 97 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/45684 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 201091 / 97
1
2
4
5
6
8
14
15
16
17
23
29
38
41
42
44
46
47
48
50
53
54
62
63
64
65
66
71
74
75
77
78
79
80
82
84
85
94
00:00
Client (computing)Public key certificateLoginPasswordAuthenticationKolmogorov complexityInformation securityWebsiteOvalPublic key certificatePasswordMultiplication signBounded variationDifferent (Kate Ryan album)WebsiteSingle sign-onService (economics)Complex (psychology)AuthenticationClient (computing)Computer animation
02:08
Server (computing)Web browserComputerAuthenticationSoftwareClient (computing)Scale (map)Distribution (mathematics)Public key certificateOvalClient (computing)NeuroinformatikPhysical systemInternetworkingKey (cryptography)Electronic signatureWeb browserWebsitePasswordSoftwarePublic-key cryptographyCryptographyComputer animation
03:26
Physical systemSoftware testingPublic key certificateFormal verificationStandard deviationClient (computing)PasswordInformation securityThumbnailRule of inferenceWebsiteHuman migrationVotingWhiteboardPublic key certificateOvalVotingComputer-assisted translationPhysical systemSoftware testingClient (computing)WebsiteSoftwareDifferent (Kate Ryan album)Service (economics)Task (computing)MultiplicationPasswordBitWeb 2.0Standard deviationAxiom of choiceAsynchronous Transfer ModeWeb browserCasting (performing arts)BlogSystem administratorRootAreaIdentity managementComputer animationLecture/Conference
06:58
WritingPasswordSystem administratorMessage passingSoftware developerServer (computing)Client (computing)MultiplicationWebsiteSoftware developerClient (computing)Connected spacePublic key certificateInformationCommunications protocolError messageWeb browserPoint (geometry)Interactive televisionLine (geometry)PressurePasswordDifferent (Kate Ryan album)System administratorBlogServer (computing)WritingGoodness of fitBitData managementComputer animationLecture/Conference
09:14
PasswordHybrid computerWebsiteData recoveryCoding theoryStrategy gameProcess (computing)CodeEmailDatabaseReading (process)Subject indexingDatabaseExterior algebraInformationVariable (mathematics)Cartesian coordinate systemGame controllerBitClient (computing)Process (computing)Address spacePasswordQuicksortPublic key certificateParsingPoint (geometry)Strategy gameSubject indexingGoodness of fitDifferent (Kate Ryan album)CausalityEmailAxiom of choiceEntire functionComputer animationLecture/Conference
11:25
System administratorInformation securityPasswordWebsiteBuildingFactory (trading post)Process (computing)CodeStrategy gameService (economics)OvalDifferent (Kate Ryan album)TheorySoftware bugPoint (geometry)Communications protocolAssociative propertySystem administratorAreaConnected spacePublic key certificateClient (computing)Transport Layer SecurityComputer fileProcess (computing)Slide ruleRule of inferenceDirectory serviceMultiplication signStrategy gameSoftwareCartesian coordinate systemPatch (Unix)Factory (trading post)Drop (liquid)Single sign-onInformation securityWebsiteOpen set2 (number)Computer-assisted translationServer (computing)Computer animationLecture/Conference
15:53
Computer animation
Transcript: English(auto-generated)
00:09
This is CA-CERT, the community CA, and I want to talk about client certificates, the old new thing. This is really a story about authentication.
00:21
In the beginning, everybody was trusted on the net. We're talking the 1980s, and that 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.
00:41
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.
01:04
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,
01:21
and eventually, the whole thing looked rather insecure. Single sign-on was invented conceptually to solve that problem. Its 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 chose the methods, and in the
01:42
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, and it turns out that companies really didn't like it either because they
02:04
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? We have the stuff to do it, and it's called client certificates.
02:22
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.
02:42
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? Well, 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
03:04
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.
03:23
Nobody had an egg, so the chickens didn't get laid. Why not? Well, the best way to think about that is don't ask. However, CA-CERT accidentally found itself solving the problem. Now, we got into this egg business, the idea of giving everybody a client certificate,
03:41
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. 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 FOSTEM.
04:01
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. CA-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?
04:22
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 CA-CERT. We invented this CA-CERT automated testing system called CATS. We just needed a name.
04:42
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 CA-CERT would insist all CATS access would be via client certificates.
05:06
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.
05:21
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.
05:43
We started out with something like 10,000 assurers around the world, and then it nose dived 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.
06:01
If you take any community and then put a big test on it, it will 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. What it does mean is every issuer in the CACERT world has got a certificate, which means
06:22
we can now go across to all of the websites that CACERT 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. That's what we're doing. We've done WordPress. We've done Simper. We have a board voting tool, which only takes certificate access, so we do all our
06:41
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.
07:01
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
07:21
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
07:41
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 assurance muck around with certificates quite a bit.
08:01
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.
08:20
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. 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
08:43
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 browsers and the servers, 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.
09:03
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 their differences. How do we do this? It's now getting to the point where we can see the strategies.
09:20
The first strategy is simply that we set up client certificates alongside passwords and 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
09:44
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.
10:01
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
10:22
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
10:41
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 you 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
11:03
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
11:24
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
11:42
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.
12:03
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 chicken and egg problem, which the certificates in theory do not, as long as you can figure out how to get everybody to use client certificates. That's your challenge, to go where we've already gone and got all our people across
12:25
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.
12:42
The top strategy is another one, which I do over at a little association where we run a bunch of sysadmins. We've simply set a rule. All of our sysadmins must be CA cert 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
13:01
to our news 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 that 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.
13:21
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.
14:08
It's kind of out of scope of what I'm talking about here. Yes, TLS renegotiation. What happens with TLS and renegotiation? There's a bug in the protocol which caused Firefox to put in a patch to drop certain
14:26
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 the problem that occurs is when you are using Apache to do your processing
15:02
and you're just essentially following Apache's rules and setting up multiple directories which cause the triggering of renegotiation. If you just use straightforward connections and don't do any trickery in Apache, I gather, I'm told, there is no problem.
15:21
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 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.
15:44
But this is a very complicated area and I can't possibly answer that in one question. Anybody else? It's gone.