Fix for issue 857: RFC-7230 compliant forwarding of client certificates
dren.dk at gmail.com
Fri Nov 25 14:06:06 UTC 2016
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...
More information about the nginx-devel