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

[Flemming Frandsen]

On Fri, Nov 25, 2016 at 12:58 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> > 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.
>

Well, ok, mine worked out of the box, because the server changed newlines
to spaces before I got the value in my application.

I'm using Jetty, which is quite popular in Java circles, so I suspect a lot
of people would be unsurprised to find the newlines replaced by spaces,
like you suggested.


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

Yes, that's true.


> 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.
>

Yes, I think I did find a comment somewhere that said that openssl wanted a
max line length.


> 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.


>From where I sit it looks like this problem was reported about a year ago
without any solution being merged, so I just want try to help things along.




> 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.
>

I agree wholeheartedly.


So at least urlencoded variant is needed ($ssl_client_escaped_cert?).


Yes, and at least it's consistent with the other solution as you noted.


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.
>

I'm afraid I don't know what this means, care to elaborate?
Do you mean people who simply set a header to $ssl_client_cert?


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.
>

I'd be very happy with this as the only change as my server already gives
me exactly this value when I ask for the header, so my application would
not even notice the change.

-- 
Flemming Frandsen - YAPH - http://osaa.dk - http://dren.dk/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20161125/455d2bef/attachment.html>