Fix for issue 857: RFC-7230 compliant forwarding of client certificates

[Maxim Dounin]

Hello!

On Thu, Nov 24, 2016 at 08:57:35PM +0100, Flemming Frandsen wrote:

> Yes, that's correct, but:
> 
> 1: You'd need custom code to url decode the header anyway and ignoring lack
> of newlines is simpler.

URL decoding is available out of the box in most environments.  
That is, recovering original PEM is as simple as wrapping a 
reference to a header into a function call.

> 2: No existing parser will handle url decoding of the header without
> changes, but some might work without the newlines.

You may want to name a few.

And we already use URL encoding in out mail module, so the are 
good reasons to keep things consistent.

> 3: You don't need to recover the original PEM format as newlines are
> optional for any reasonable base64 parser.

They aren't optional at least for OpenSSL itself.

> If anything, it could be argued that the -----BEGIN CERTIFICATE----- and
> -----END CERTIFICATE----- bits should be removed too as that's of no use to
> the base64 decoder and has to be removed to get started parsing the actual
> content anyway.
> 
> Without the begin and end bits someone who is really interested in getting
> a complete PEM file out of the header could very easily slap the start and
> end lines around a line-wrapped base64 content.

Such approach was already considered when working on the mail 
implementation of client certificates support.  Essentially, this 
provides Base64-encoded certificate in DER format.  This is 
certainly better than just removing newlines, yet urlencoding is 
considered to be better in most cases.

> If you're really unhappy with my proposed solution, then I can try to fix
> up the url encoding patch that was posted earlier, though I still think
> it's silly to go to such lengths to preserve newlines that nobody wants.

There is no problem with preparing any patch.  And there 
were already quite a few.  The main problem here is naming things: 
that is, how things are expected to be named in the future, and how 
transition is expected to look like.  The situation when 
$ssl_client_cert variable is not usable in most if not all cases 
looks at least strange.

We probably need to switch it back to original meaning of 
PEM-encoded certificate (now available as $ssl_client_raw_cert).  
And it would be enough if we have some trivial functions like 
urlencode/urldecode available (see ticket #52) - but, 
unfortunately, we don't have them now.  So at least urlencoded 
variant is needed ($ssl_client_escaped_cert?).  And the next 
question is what to do with current $ssl_client_cert, as we need 
to preserve compatibility at least somehow for people who 
currently use certificate with tabs added as a multiline header.

Another possible approach might be to change $ssl_client_cert to 
use spaces (tabs?) instead of newline + tab.  This should be 
compatible with what most servers provide as a result of parsing 
multi-line header, and implies less changes.  This needs an 
additional investigation though.

-- 
Maxim Dounin
http://nginx.org/