Flemming Frandsen
November 24, 2016 02:58PM
Yes, that's correct, but:

1: You'd need custom code to url decode the header anyway and ignoring lack
of newlines is simpler.
2: No existing parser will handle url decoding of the header without
changes, but some might work without the newlines.
3: You don't need to recover the original PEM format as newlines are
optional for any reasonable base64 parser.

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.

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.




On Thu, Nov 24, 2016 at 2:39 PM, Maxim Dounin <mdounin@mdounin.ru> wrote:

> Hello!
>
> On Thu, Nov 24, 2016 at 02:15:17PM +0100, Flemming Frandsen wrote:
>
> > Hi, I've been bitten by issue 857: https://trac.nginx.org/nginx/
> ticket/857
> >
> > I terminate TLS in nginx, but I need access to the full client
> certificate
> > in the backend, so to that end I've been using $ssl_client_cert, but now
> > I've upgraded the application to a version that is RFC 7230 compliant and
> > that means blowing up when multi-line headers are seen.
> >
> >
> > As there's no reason to have newlines in a PEM file, my fix for #857 is
> to
> > remove all the newlines, as my PEM parser in the application already
> > ignores all newlines this works perfectly for me.
> >
> > I think simply removing the newlines is a much better solution than url
> > encoding the newlines as less code (in my case none at all) is needed to
> > deal with no newlines than urldecoding.
>
> The problem with removing newlines is that it requires custom code
> to recover original PEM format.
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>



--
Flemming Frandsen - YAPH - http://osaa.dk - http://dren.dk/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
Subject Author Views Posted

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

Flemming Frandsen 1153 November 24, 2016 08:16AM

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

Maxim Dounin 510 November 24, 2016 08:40AM

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

Flemming Frandsen 442 November 24, 2016 02:58PM

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

Maxim Dounin 471 November 25, 2016 07:00AM

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

Flemming Frandsen 461 November 25, 2016 09:08AM

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

Flemming Frandsen 488 November 28, 2016 04:22AM



Sorry, you do not have permission to post/reply in this forum.

Online Users

Guests: 267
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready