The Wikimedia Foundation has been running nginx-1.9.3 patched for
multi-certificate support for all production TLS traffic for a few
weeks now without incident, for all inbound requests to Wikipedia and
other associated projects of the Foundation.
We initially used the older March variant of Filipe's patches (
), and last week we switched to using the April 27 variant (
), which is the last known public variant I'm aware of.
These were in turn based on kyprizel's patch (
), which was based on Rob's patch from nearly two years ago (
). It has a long and colorful history at this point :)
We've forward-ported Filipe's Apr 27 variant onto Debian's 1.9.3-1
package. Most of the porting was trivial (offsets / whitespace /
etc). There were a couple of slightly more substantial issues around
the newer OCSP Stapling valid-timestamp checking, and the porting of
the general multi-cert work to the newer stream modules. The
ported/updated variant of the patches we're running is available here
in our repo:
Our configuration uses a pair of otherwise-identical RSA and ECDSA
keys and an external OCSP ssl_stapling_file (certs are from
GlobalSign, chain/OCSP info is identical in the pair). Our typical
relevant config fragment in the server section looks like this:
Obviously, we'd rather get this work (or something similar) upstreamed
so that we don't have to maintain local patches for this indefinitely,
and so that everyone else can use it easily too. I'm assuming the
reason it wasn't merged in the past is there may be other issues
blocking the merge that just weren't relevant to our particular
configuration, or are just matters of cleanliness or implementation
I'd be happy to work with whoever on resolving that and getting this
patchset into a merge-able state. Does anyone know what the
outstanding issues were/are? Some of the past list traffic on this is
a bit fragmented.
Could you please review and consider including the attached patch. It fixes
a bug which is only created by some gcc's, you will understand looking at
I reproduce using nginx with openwrt on marvell platform, so I can't tell
what else might be affected.
How it works.
upstream do something like this
still some data
and proxying module changes value of handle_header to some new function
inside handle_header. if we have enough data to still stay in this loop
some gcc would call a wrong pointer. (this bug is floating as if data goes
in slow we exit this for loop)
Proposed patch only fixes consequences as it is not an upstream bug, it is
a gcc bug. If there would be some trick adding volatile keyword the
resulting code would be too fragile to stay cross compilable and cross
platform. So checking one pointer seems a reasonable price to pay
considering some gcc can do this with a loop and using this kind of loop to
read remaining data is a very common pattern is the project design.