I say "for a change", but we have people that help with testing these early releases all the time. However, the ACME code has really been very popular and people want to test it. The whole project has been fun for us too.
The good news is that for most testers the ACME system has "just worked" - they set up DNS for a hostname for the public IP of their FireBrick, put in the config, and within seconds they have a certificate for HTTPS and IPsec. Indeed, so simple and so fast, people are already asking if any way for FireBrick to do the ACME as a front for other servers?!? I thought apache made this easy, but apparently FireBrick is easier, according to customers. That is, perhaps, a good sign!
What is also fun is the number of ways people find to break it!!!
This is one of those cases where we will be making alphas with minor tweaks for a week or two I am sure. Some of the challenges have been surprising, although all, so far, have been minor.
We have people running networks that only work over IPv6, which is good. But then we have people doing that only over 6over4 tunnels, which causes some challenges with source IPv6 addresses.
We have had a few cases with firewall issues. The logic on the FireBrick is that the brick itself should not need a firewall. The individual services have, at the initial packet level, controls on IP access ("allow" lists, and "local-only" settings). Indeed, some versions of FB600 have no "firewall" as such, and only use these access controls. This is important for the ACME logic as the brick needs to be accessible via HTTP on port 80 from Let's Encrypt (or chosen CA) to authenticate the domain. The code allows port 80 access even when otherwise locked down so as to establish TCP and send an HTTP request for the specific ACME authentication URL. This means port 80 open for a few seconds every couple of months but only for that specific URL and no other access (unless allowed anyway). That does not work if firewall rules (on the FireBrick, or externally) stop that access.
We are also looking at what controls we need. For example, the FireBrick obtains new key pairs as needed (and we need at least two for ACME) from a FireBrick server (see P.S. below). But best practice is to create your own private keys on an isolated laptop and install via a direct connection to the FireBrick. That is hard work for most so we have a convenient and secure way to get from us over TLS (trusting us), but for good security reasons we need config settings to prevent that if the end users wants it locked down. We have that (acme-keygen) for those that need it.
We also load some root CA certificates so we can access Let's Encrypt servers and check them, but again we may need some controls so people can decide what CA certificates they have installed. So there are likely to be some changes to control that soon.
This is a key example of the fact that security is a compromise with convenience, and sometimes the convenience is important as without it people won't bother with the security. So a lot of what we are doing is a fine line - make it so people can, and will, use https with proper certificates, but that means some levels of trusting us as well. And we have to allow for the fine-tuning that some people may want to decide which side of that fine line they wish to work.
So it is a fun bit of code, not just at the "nuts and bolts" level as per my last blog post but at the high level of considering attack vectors and risk and trust.
I am sure more issues will come to light over there next week or two - so do try the alpha, and let us know any issues you have.
P.S. After a lot more research, we feel confident enough to have the key generation done locally in the FireBrick, which is obviously better. It means first time of ACME will take longer, obviously, as we need to collect entropy and generate keys. Obviously you can still load your own keys instead.
Looks like you're making really good progress! Personally I use ngix as a reverse proxy on my network, adding a certificate along the way but I'll be keeping an eye on the firebrick to see if this could offer a better solution.
ReplyDeleteAs a side note, looks like a minor victory today against the investigatory lowers act: https://www.ispreview.co.uk/index.php/2018/04/high-court-rules-uk-isp-internet-snooping-law-is-unlawful.html
“Minor” in the sense of “basically nothing there”!
DeleteWhy are you generating the keys on your own servers rather than on the firebrick? I think this may technically make the certificates compromised since a party other than the intended one had access to the private key. Indeed globalsign recently revoked a large number of certs because of something like that involving a reseller.
ReplyDeleteIt is a trade off of making “good” keys locally or using TLS to get from server we control. Best is make them youself and we say that in the manual. As I say, trade off for convenience.
DeleteDoes the firebrick not have sufficient entropy to produce good random numbers? Since a tls client requires that the firebrick have some entropy anyway for dhe I would assume it could easily generate its own keys for tls certs. Also it was digicert not globalsign.
DeleteIt is not entropy that is the issue. May change in future.
DeleteWhy can you not generate a suitable keypair on the administrators' web browser using Javascript via the FireBrick web interface ?
ReplyDeleteThis is infinitely more preferable to obtaining key material from a remote server.
I’ll look in to that.
DeleteDoes not look like a native feature, and the best will be for the keygen to be in the FireBrick, which I am sure we will do at some point (even better if you provide a key yourself, which you can now). We’re keen to ensure good quality of key, hence the hesitation at this point.
Delete