Issue #10111 has been updated by Brice Figureau.
Daniel Pittman wrote: > Brice, this looks pretty awesome. It has taken a while to get to looking at, > so a couple of things: > > Can you retarget this at master - this is way too big a change to introduce > in a stable release, but it looks like a great feature to add. No problem. I will do that ASAP. It was my intention to target Telly anyway. > How mature do you think this is? I'd say it is beta quality. I tested all I could, and the code is pretty quite isolated from the puppet core that when disabled it shouldn't introduce any side-effect. Note that to properly test the setup you need a separate CA server than your master (otherwise CRL will be much more useful and faster). So this feature is more useful to larger deployments than the average. >You note that you didn't test a Passenger based setup, and that you don't >cache the CRL. How significant do you think those issues are? For the passenger setup, we just need to perform testing on this stack. At that time I didn't had a passenger setup ready for testing the whole code. The problem I was outlining with the CRL caching is the following. The OCSP responder checks the revocation of a given certificate serial number in this CRL. Due to the nature of the CRL, the revocation check is done linearly, and the CRL is reloaded on every request. I implemented a cache on the client side to mitigate this issue. To properly fix this, we would also need a server side CRL cache, and/or load the CRL and index it in memory, or use a different on-disk revocation storage (ie a secure database of some sort). I believe, if proven that it is a problem, we can add server-side CRL indexation/caching quite easily. I didn't went that far, because I didn't really stress test the OCSP responder. > Is this a mature commit that just needs some testing, or do you think that we > are likely to uncover bugs in testing it? I believe it just needs more testing and production workload. I don't think we'll hit major bugs. But it might also require a thorough code review. > Finally, do you have a sketch for how we could test that this feature works > at a high level? What are the edge cases we should be validating? There are basically three tests to perform (with a CA only server, 1 master, and 1 client): * no certificates revoked, check that the client can gets its catalog. * revoke client certificate on the CA server: check the server rejects the client * revoke server certificate (with valid client cert): check the client rejects the server This has to be done on the 3 stacks we support for the master: passenger, mongrel and webrick (we don't care what the CA server is running on). The reason we have to test the 3 stacks is that every stack uses a different way to check for the OCSP status (for instance webrick does it in the certificate store callback, but the 2 others are not the SSL endpoint and thus don't have access to these information directly). On mongrel or passenger setup, the ssl endpoint configuration should be adjusted to send the client certificate to Puppet. > With those answers, and a branch targetted at master, I am happy to take this > and get it in place for Telly. OK, that sounds great, thanks! ---------------------------------------- Feature #10111: Puppet should deprecate the use of CRLs and move towards OCSP https://projects.puppetlabs.com/issues/10111 Author: Nigel Kersten Status: In Topic Branch Pending Review Priority: Normal Assignee: Brice Figureau Category: SSL Target version: Telly Affected Puppet version: Keywords: Branch: https://github.com/puppetlabs/puppet/pull/233 OCSP: <http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol> OCSP scales significantly better and we should consider it in Puppet. We need to investigate whether Ruby/SSL allows us to use a nonce with the OCSP request, otherwise we may open ourselves up to replay attacks. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
