mmalone

Yea that's why I'm surprised that Google has issued more certs than Amazon has :P.

Hey, author here. There are some pros and cons, but here's my (obviously biased) position. I'm not a CFSSL expert so I invite people to correct me if I'm wrong anywhere here.

- CFSSL by default runs open -- it's an unauthenticated API that'll sign anything. Figuring out how to securely authenticate to the CA is one of the hardest parts of automated enrollment. `step` & `step-ca` solve this for you.

- Building on the last point, there are multiple ways to authenticate to `step-ca` for various scenarios: one-time tokens, OAuth OIDC (SSO)[1], and now instance identity documents for VMs (more coming soon)

- The `step` command-line tool integrates with `step-ca` and makes the entire enrollment process super easy -- we focused a lot on usability (and misuse resistance)

- `step` also helps with other certificate management workflows[2] like root certificate distribution, root federation, root certificate (un)installation[3], certificate renewal, and (passive) revocation

- `step` is also useful as a generic swiss army knife for security tech like JWTs, JWKs, NaCl, OAuth, and more... not necessary relevant for this comparison, but useful[4]

This might be unfair... but I think philosophically the projects serve different purposes. CFSSL was created to serve CloudFlare's specific internal PKI needs, and it does that well, and it was awesome of them to open source it. `step` & `step-ca` was created because we believe everyone deserves great internal public key infrastructure and there's a tooling gap. So I think we're more interested in addressing a broader variety of use cases than CFSSL is.

There are some definite advantages of CFSSL though. Someone can probably extend this list and I'd love to discuss, but some obvious ones from my perspective are:

- They have a bigger community (at least for now :)

- They've been around longer

- There's more documentation out there about how to do things with CFSSL (see point #1)

Functionally, I think the only thing that CFSSL has that we don't at the moment is "active" certificate revocation -- CRLs & OCSP. We think short-lived certificates[5] are a better approach, and design for that primarily, but we're planning to fill this gap soon so at that point I think we'll be parity+ with CFSSL.

[1] https://smallstep.com/blog/easily-curl-services-secured-by-h...

[2] https://smallstep.com/docs/cli/ca/#commands

[3] https://smallstep.com/docs/cli/certificate/install/

[4] https://github.com/smallstep/cli/blob/master/README.md#Featu...

[5] https://smallstep.com/blog/passive-revocation/

Kinda surprised that Google is so much bigger than Amazon...

Yea, by default anyways, but that doesn’t mean you need to use/trust them for a particular request. I’m talking mostly about service-to-service traffic fwiw, not browsers.

If you’re talking about services that you’re accessing via a browser, true. If you actually do pinning (properly).

For service-to-service stuff and APIs the number of TLS clients that respect pinning is approximately zero.

Either way, the other problems remain, and running an internal PKI is really pretty easy.

It sounds like using Let’s Encrypt makes sense for your use case since people are accessing these appliances via a web browser, but for “normal internal servers” the right answer is almost definitely to use your own internal PKI, not to use wildcard certs.

See:

https://github.com/cloudflare/cfssl

https://github.com/hashicorp/vault

https://github.com/smallstep/certificates

And if you just rely on the default trust stores you’re actually introducing over 100 third parties, some of which are known to be controlled by (or at least work with) the NSA, China, etc.

The disadvantages are:

it’s less secure — you’re trusting (many) third parties with your security and relying on the security of DNS

it’s less flexible — you can’t sign certificates with internal names (e.g., *.cluster.local) and certs must be for 90 days, etc

it’s kind of hacky — you have to work around rate limits and whatnot because Let’s Encrypt wasn’t designed for this use case

The advantage is it’s easier. But that’s arguable. What the article describes isn’t easy. Using something like cfssl (https://github.com/cloudflare/cfssl) or vault (https://github.com/hashicorp/vault) or step certificates (https://github.com/smallstep/certificates) (which I work on) is probably easier and definitely better for internal services.

This is a new project I've been working on with my colleagues.

We believe every non-trivial cloud infrastructure would benefit from real public key infrastructure (a private CA and management tools). The challenge is making this stuff more accessible to non-experts.

We have some generic tooling, but now we're starting to go deep on a few verticals. In this case, we're trying to get "real PKI" spun up on a Kubernetes cluster quickly and easily.

We'd love feedback! Aside from the obvious technical stuff, if you have ideas on how we can communicate the value of proper certificate management I'd love to hear them!

There’s nothing special about a “client certificate” —- they’re not (necessarilly) any different than a TLS server certificate. Technically a relying party might check that a client certificate includes the “client auth” key use, but most (all?) commercial certificates issued for TLS/HTTPS servers do this (I know Let’s Encrypt does).

So... what they’re asking for isn’t actually anything fancy. Just go buy a normal certificate like you would for any other server (or get one for free from let’s encrypt).

In fact, if they want a cert that is signed by a CA that “works in browsers by default” it must be the case that what they’re looking for is a vanilla commercial “Web PKI” certificate. This must be true because the CA/Browser Forum requirements that commercial CAs are audited against stipulate that CAs are only allowed to sign vanilla certificates. They can’t sign anything fancier.

It sounds like what the vendor you talked to was trying to sell you was a commercial CA that they manage for you. In other words, your own root certificate authority. Those certificates would not be trusted by browsers by default. There’s no reason to pay for that — you could just run a CA yourself and do the same thing. In fact I contribute to an open source project[1] that does exactly that, if that’s what you end up needing.

[1] https://github.com/smallstep/certificates

Hi, am author. Ah, yea, I know that CAs are supposed to check CAA before issuing and I do understand the security model. Figured browsers could/should too, but just dug a bit more and you’re right that CAA is explicitly not supposed to be checked by RPs.

Conceptually I don’t see any major problem with using CAA for this purpose though, at least for your own internal PKI. The only potential issue is that if you change your CAA record your issued certs would break, so there’s an availability attack.

I just found a reference to another standard called DANE that’s supposed to do this, but I don’t know anything about it.

Lol oops. Thanks.

That’s weird. Screen shot or something?

(Edit: work at smallstep; want to fix)

I work at smallstep and figured I'd add a bit more context. `step` implements a bunch of "zero trust" primitives: authenticated encryption (X.509, TLS), single sign-on (OAuth OIDC), multi-factor authentication (OATH OTP), and encryption / signing (JWE, JWT, NaCl). We built the tool for our customers to debug and operate our certificate authority, OAuth IdP, and to authenticate to our identity-aware / policy-enforcing proxy from the command line. Some of these infra bits will be open sourced too, over time.

In the meantime we figured the core tool might be useful to other people for debugging, scripting, and automation. You can use it in a bash script to authenticate to Google using OAuth, or to securely connect to your own services that use OAuth OIDC for single sign-on. You can use it to implement MFA for SSH. You can use it to encrypt secrets for services (simple secret management). It's also got all of the core functionality you need to build a simple certificate authority. It's still pretty low level at the moment, but it's a whole lot easier to use for this sort of stuff than OpenSSL. Hope people find it useful!

Oh, I assumed we were talking distributed. Fsync to more than one disk. My biases :).

Log structured merge is the last piece of your architecture. It solves the latency part. It can also solve your durability issues, if you fsync when necessary and you understand your hardware.

ACID semantics subtley and indirectly requires locks. Any scenario where lock contention might be a problem would be a problem for an RDBMS (assuming the traditional definition of RDBMS as a ACID compliant). Those scenarios can easily be “super-constant”, especially if you have to distribute across multiple nodes. That requires locks that are held for the duration of an “external call” over the network which is A Bad Idea and could definitely be “super-constant”.

What’s that opinion based on? Apparently 75% of auto execs have a different opinion. I just read the two posts in this thread and it seems the argument is that hydrogen is less efficient to produce and distribute? Well even if that’s true it shouldn’t matter. There’s plenty of clean energy available. Our goal should be to use clean energy, not necessarily to minimize energy use.

The articles are then dismissive that the “only advantage” of fuel cells is energy transfer rate. That’s by far the biggest problem with electric. It’s a big deal.

No major manufacturer is “doing nothing”. They’re all investing in electric. What’s wrong with investing in hydrogen, too? Either would be great and they both have pros & cons. I’d love to have both.

It looks like they’re saying that we’ll move to hydrogen fuel cells, not that we’ll stick with gasoline. That’s not really a bad thing.

This is a whole lot of conjecture. Auto manufacturers were investing in alternative fuel way before Tesla came around. BMW lost some ground on electric because they made a huge bet on hydrogen in the late 90s/early 2000s that didn’t pan out (which is too bad because it probably would have been better and easier to transition to). There will always be nostalgia for the “purity” and raw mechanical feel of older big gas engines, but car people tend to like better cars, regardless of tech. Gas engines are getting smaller across the board. Many of the newest hypercars incorporate electric motors, and they’ve been generally well received.

I think what’s most likely is that they are right: they can’t reliably produce electric cars at scale that meet all of their requirements and customer expectations. Tesla is having trouble doing it, why wouldn’t BMW? Musk is charismatic and well liked. He is able to speculate wildly and miss deadlines with little consequence. I think BMW is right that they wouldn’t be given the same affordances by investors and consumers.

Daemons running on user VMs? Or is ssh terminated in a bastion and forwarded somehow?

Edit: sorry didn’t read far enough and have now answered my own question. In VMs. So yea, Amazon could not duplicate without getting people to change AMIs or install some agent. Still seems like an SSH CA is a better option. Curious why google didn’t go that route. Maybe not an option when they built this?

Kerberos / Needham-Schroeder usually refers to an authenticated encryption protocol that uses symmetric keys (shared secrets). It lets two parties who have never communicated, but who both mutually trust some third party, establish one another’s identities and negotiate a symmetric key for encrypted communication.

The SAML core is an XML-based system for serializing, signing, and encrypting assertions. There are also SAML flows, and they likely use something Kerberos-esque. So SAML is to Kerberos what HTML is to HTTP, or what x.509 is to TLS, or something like that.

Are you talking about the `gcloud compute ssh` stuff? I wonder what magic google is using to grt public keys on boxes. I’d think there’d have to be some coordination with the machine image being run for this to work, so it wouldn’t be something Amazon could just turn on for everybody. You could probably roll your own using an SSH CA though.

Around 6%/yr... more than a savings account, but pretty reasonable. I think the IRS charges 6%/yr too.

Still easy to argue that no rational person would do x, therefore x should not be allowed.

Really I think it's just too hard to scale the protections and legal mechanisms. ICO solves some (not all) of the scalability problems.

Not necessarily. You should be able to write a halting computation to determine whether a number is prime in a Turing complete language. It may be stupid hard to encode, or take a really long time to run, however.

The halting problem says that you can't write a halting decision procedure that takes an arbitrary program as input and determines whether that program halts, for any program. That doesn't mean that no programs halt. On the contrary, most programs in Turing complete languages obviously do halt and it's often trivial to tell if a particular program halts or not (e.g., `print "hello"` obviously halts). A Turing complete language can compute anything that is computable. So if the type system is Turing complete, you should be able to type a function that only takes primes... in theory.

Yea, turns out programmers are pretty good at writing code that halts in Turing complete languages.

> Is PwC any good for real security audits?

It depends on what you mean by "real security audits." If you want someone to audit your new crypto protocol, probably not. PwC is more about internal control / governance audits. They're making sure financial reporting is done correctly, segregation of duties are enforced within the organization, record retention policies are documented and enforced. Less technical, more organizational / meatspace. PwC is the sort of auditor that would find out that a company has a beneficial owner that's connected to a high ranking political figure in China... stuff like that. And I think they're pretty good at it.

Interesting. Thanks for the details.

In theory a compiler can do this optimization for you and can use simple syntactic checks to determine whether recursion terminates and whether the optimization applies (at least given a language designed with these things in mind, I'm sure this is much harder or maybe impossible in C++). With something more modern than C++ I'd imagine you could adopt a rule that says "you can use recursion but we compile with --dont-allow-nonterminating-or-unoptimizable-recursion".

Eve? http://witheve.com/

The Eve core is based on a distributed logic programming semantics (although SQL-like is a good accessible description). It was inspired by a datalog-based language called Dedalus (amongst other things).