<div dir="ltr">Hello.<br><div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-02-11 13:41 GMT+01:00 Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<div class=""><br>
On Mon, Feb 10, 2014 at 02:08:52PM +0100, Franck Levionnois wrote:<br>
<br>
> > > + b64_cert->len = ngx_base64_encoded_length(pem_cert.len);<br>
> > > + b64_cert->data = ngx_palloc(pool, b64_cert->len);<br>
> > > + if (b64_cert->data == NULL) {<br>
> > > + b64_cert->len = 0;<br>
> > > + return NGX_ERROR;<br>
> > > + }<br>
> > > + ngx_encode_base64(b64_cert, &pem_cert);<br>
> ><br>
> > Using a raw certificate escaped as other other Auth-* headers may<br>
> > be a better idea than inventing another method to pass things.<br>
> > Base64 encoding of base64 encoded data looks especially strange.<br>
> > :)<br>
> ><br>
><br>
> Base64 encoding of the PEM certificate may looks strange, but it is done<br>
> for compatibility with other reverse proxy like F5 BigIp. It is also<br>
> possible to simply remove PEM header / footer and carriage returns (like<br>
> another reverse proxy)<br>
<br>
</div>While compatibility with 3rd party code is a good thing, I don't<br>
think that it should be done at cost of consistency with other<br>
code.<br>
<div class=""><br>
><br>
> The function "ngx_ssl_get_certificate" is about to do the work, but it let<br>
> headers, and replaces carriage returns by tabulations. Modify this one to<br>
> remove the headers may have some consequences.<br>
> Although i would have preferred not to have the headers, i think i can do<br>
> with it, if you think this is better than adding a third function to get ssl<br>
> client certificate.<br>
<br>
</div>The ngx_ssl_get_certificate() is for $ssl_client_cert variable in<br>
http[1], and it uses header continuation to make it possible to<br>
pass certificate to upstream servers. This aproach doesn't work<br>
very well as header continuation isn't really supported nowadays<br>
(in particular, by nginx itself) and deprecated by HTTPbis, so it<br>
probably needs revision. But I don't think it's relevant to this<br>
case, as we already have escaping applied to other Auth-* headers,<br>
and it should be trivial for auth script to unescape certificates<br>
as well.<br>
<br>
[1] <a href="http://nginx.org/en/docs/http/ngx_http_ssl_module.html#variables" target="_blank">http://nginx.org/en/docs/http/ngx_http_ssl_module.html#variables</a><br>
<br></blockquote><div><br></div><div>Ok, it's trivial. I'll modify the patch to use the escape function.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[...]<br>
<div><div class="h5"><br>
> > > + if (ngx_ssl_get_issuer_dn(s->connection, pool,<br>
> > > + &client_issuer) != NGX_OK) {<br>
> > > + return NULL;<br>
> > > + }<br>
> > > +<br>
> > > + if (ngx_ssl_get_serial_number(s->connection, pool,<br>
> > > + &client_serial) != NGX_OK) {<br>
> > > + return NULL;<br>
> > > + }<br>
> ><br>
> > One of questions left open during Sven Peter's patch review was<br>
> > whether subject/issuer can contain CR/LF and require escaping.<br>
> > The code here suggests they can't. I would like to know if it was<br>
> > actually checked.<br>
> ><br>
> > It would be also cool to get Sven's review of the code (and/or his<br>
> > own patch improved instead if he don't happy with one from<br>
> > Franck). Added Sven to Cc.<br>
> ><br>
> ><br>
> Subject and Issuer DN may contains special chars but "X509_NAME_oneline"<br>
> function escapes every chars outside " " -> "~" range (in ASCII table).<br>
> This is the function used by "ngx_ssl_get_subject_dn" and<br>
> "ngx_ssl_get_issuer_dn" to get the DN<br>
> This is a sample output from the function of DN with carriage returns :<br>
> Issuer: /C=FR/ST=Some-State \x0D\x0A\x0D\x0A\x0D\x0Atest/<br>
> L=Paris/OU=An\x0D\x0Aign/CN=Autorite de certification<br>
><br>
> Even if i've never seen Distinguished names with carriage returns, i<br>
> haven't seen such limitation in RFC 3280 / X500.<br>
> RFC 2253 shows a sample of distinguished name with carriage return.<br>
<br>
</div></div>So escaping or CR/LF is already done by X509_NAME_oneline() and<br>
there is no need for additional one, right?<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div>Yes, it's right. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" target="_blank">http://nginx.org/</a><br>
<br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra">Kind regards.<br></div><div class="gmail_extra">Franck Levionnois.<br></div></div></div>