Nginx 1.12 Released
incorporating new features and bug fixes from the 1.11.x mainline branch - including variables support and other improvements in the stream module, HTTP/2 fixes, support for multiple SSL certificates of different types, improved dynamic modules support, and more." The changelog has more details.
Posted Apr 12, 2017 20:51 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link] (7 responses)
Moving on
One thing I'd like to see in these popular web servers is AIA chasing. The Authority Information Access field commonly found inside modern SSL certificates tells a reader where to find another certificate whose owner probably signed this one. Modern leaf certificates aren't (shouldn't be) issued from a trusted root CA directly, so we need at least one such "intermediate" certificate to make a chain of trust and decide the leaf is trustworthy. A conscientious and knowledgeable systems administrator ensures any necessary intermediates are installed when supplying the certificate, that's why nginx lets you put the entire chain in a single PEM file, but so very many servers are just installed with the leaf on its own and nobody at the wheel to grok why that's wrong.
Some web browsers, most notably Internet Explorer do AIA chasing to "fix" such broken sites. Before giving up and telling you the site's certificate isn't valid IE will chase AIA to find one or more certificates and see if those are enough to construct a trustworthy chain. But in a browser AIA chasing is a privacy leak - you visit example.com but then your browser goes out and tells example.com's SSL certificate vendor that you need the intermediate certificate too; plus it's significantly slower than just delivering the whole chain originally, and of course if the client can't reach the Internet (e.g. maybe the web site that's misconfigured is a captive portal) it still won't work anyway.
In the web _server_ though there is no privacy leak from doing this, the performance penalty is paid only once, perhaps once per startup if the server is disinclined to keep the results of AIA chasing anywhere between sessions, so it seems like a win-win. If the administrator configured a chain properly, you carry on, otherwise you'd do AIA chasing and automagically fix things for all visitors. If server programmers are really worried they can always fit a (default off) config switch to disable the AIA chasing for the half dozen people in the world who have a legitimate need for such a thing.
Posted Apr 13, 2017 2:13 UTC (Thu)
by gutschke (subscriber, #27910)
[Link] (6 responses)
I certainly agree that anything that helps with avoiding mistakes when deploying certificates is a good idea. But I am not convinced that AIA chasing is the right thing to do. Hidden DWIM (do what I mean) functionality is always error prone. And isn't that exactly what you were criticizing in the browser's behavior? It seemed like a good idea at the time, and now we are stuck with it. Maybe, it would be a better idea if an incomplete certificate chain was a fatal error and NGINX failed to start until the problem is corrected. Of course, this would require a configuration option to register non-standard root certificates. But that's a minor implementation detail. Most CAs are really good these days about publishing the chains in a readily available location. And if they don't, it's not as if one-time manual AIA chasing was all that difficult. Here is a quick script that I whipped up, in case you want to give it a try:
Posted Apr 13, 2017 7:45 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (5 responses)
I want it in the server (and switched on by default), not in somebody's LWN comment, or on the third answer below the tick on Stack Overflow, or as a comment to a blog post somewhere because that's the only way it actually gets done, and thus the only way to make a dent in that significant failure rate and let the browsers choose the safe option in our lifetime.
Take the all too common experience where a user with a toy web server runs the Certbot software to get Let's Encrypt SSL certificates. If they trust Certbot to do everything, and it works, fine. More likely they either don't trust it or it can't fathom the insane web server config on their system so Certbot provides them with a bunch of files, and instructions for how to use them. Then the user ignores the instructions, sees cert.pem and figures "There we go", they set that as their certificate, restart the web server and are pleased they've "done it". This server is now misconfigured. Some of these users will appear a few minutes later on Let's Encrypt's forum site, asking why 3rd party tests say their server is misconfigured. Most will sleep soundly believing they did a good job.
We can't go back in time and make all software accept a chain of PEM encoded certificates in a single file so that cert.pem needn't exist, and we can't make users read instructions, otherwise every year there'd be a huge drop in the rate of trivial fatal accidents in the home. But we can make server software bright enough to spot the trouble and fix it in the 99.999% of cases where that's the right thing, rather than focusing on making sure we behave correctly the 0.001% case where we were deliberately sending an incomplete chain for a test or something. Every one of those 0.001% admins already knows how to read a manual, they will find your "aia_chasing [defaults on]" config setting and change it.
There are a bunch of not-so-great things that would happen, but none that I can think of are fatal, and all are either rare or involve people learning not to deliberately set fire to their own house which I'll take as a win. For example don't add bogus AIA information to your privately issued certificates. I'm sure someone, somewhere, has decided to do this because stupidity knows no bounds, but it isn't easy AND it doesn't help, so that's a good lesson for them to learn.
Posted Apr 13, 2017 20:20 UTC (Thu)
by Lennie (subscriber, #49641)
[Link] (4 responses)
(even if just on a test-server/-site)
What I would like to see is other CAs to adopt ACME(-like) protocol.
Posted Apr 14, 2017 0:06 UTC (Fri)
by gutschke (subscriber, #27910)
[Link] (1 responses)
And that's why I suggested, nginx should simply fail to start when configuration is incomplete. Administrators are used to read instructions, if things obviously don't work. If things fail silently or sometimes, that's a lot worse.
Posted Apr 20, 2017 5:54 UTC (Thu)
by Lennie (subscriber, #49641)
[Link]
I've actually hacked up some scripts to do some of the checking on my own.
Posted Apr 14, 2017 16:05 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
It is likely that we'll see wider use of ACME. However, ACME only tells you _how_ to configure the correct chain, we happen to have already seen that, just as in web server software generally, in the real world people don't follow the instructions, they do whatever they think is a good idea, regardless.
About a year ago now Let's Encrypt moved from the X1 (and X2 as standby) intermediate CA to the X3 (and thus X4 standby) which lack desirable but Windows XP incompatible negative name constraints (ISRG are not permitted by contract to use their CA to issue for the US military's dedicated .mil TLD, this was originally enforced through an X.509 name constraint, but it turns out XP doesn't grok such constraints and so they agreed to just be careful)
A correct ACME implementation would have received a new (e.g. renewed) certificate from X3, followed the ACME-standard HTTP Link: header to get an X3 certificate, and supplied that in the chain.
But a _lot_ of third party implementations simply ignored the Link: header and hard-coded the X1 intermediate. These all ceased working correctly immediately. Surprisingly many were "repaired" by still ignoring Link: and now hard-coding X3 instead.
Posted Apr 20, 2017 5:53 UTC (Thu)
by Lennie (subscriber, #49641)
[Link]
My suggestion was that the software would do it correct so that most users (admins) don't have to know to do it. Things: "just work".
Clearly that isn't the case yet. :-(
Posted Apr 15, 2017 6:35 UTC (Sat)
by flussence (guest, #85566)
[Link] (1 responses)
They made a lot of noise 1½ years ago about being first-to-release with H2 support (a mere 3 weeks ahead of that other server behind the link, whom aren't exactly known for speed of progress), but that's dishonest advertising if it's going to remain half-unfinished.
Posted Apr 20, 2017 4:52 UTC (Thu)
by Lennie (subscriber, #49641)
[Link]
docs & AIA chasing
docs & AIA chasing
#!/bin/bash
export LC_ALL=C
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
[ "$#" -eq 1 ] || { echo "Usage: ${0##*/} <certificate>" >&2; exit 1; }
aia() {
local cert="$(openssl enc -base64)"
echo "${cert}" | openssl enc -d -base64 | {
[[ "${cert}" =~ ^LS0tLS1CRUdJTi ]] && cat || {
openssl x509 -outform PEM -inform DER 2>/dev/null || {
echo "${cert}" | openssl enc -d -base64 |
openssl pkcs7 -outform PEM -inform DER -print_certs 2>/dev/null
}
}
} | tee /dev/stderr |
openssl x509 -text -noout 2>/dev/null |
sed 's/\s*ca issuers\s*-\s*uri://i;t1;d;:1;q'
}
{ uri="$(aia <"${1}")"; } 2>&1
while [ -n "${uri}" ]; do
{ uri="$(curl "${uri}" 2>/dev/null | aia)"; } 2>&1
done
docs & AIA chasing
docs & AIA chasing
docs & AIA chasing
docs & AIA chasing
ACME
ACME
I'm slightly annoyed to see nginx still doesn't have any trace of HTTP2 push, one of the more useful and webmaster-accessible upgrades to the protocol.
Nginx 1.12 Released
Nginx 1.12 Released