Hi,
I''ve recently been trying to setup Mongrel behind Pound so that I can
do mutual SSL authentication. I''ve had a few problems with Pound
(documented at [1]), but now have it working correctly.
However, I think there is a problem with Mongrel and how it deals with
the headers Pound adds to the HTTP header block. One of the extra
headers Pound adds is ''X-SSL-certificate'' - the full
multi-line client
certificate in PEM format. As the certificate is spread over multiple
lines like this:
X-SSL-certificate: -----BEGIN CERTIFICATE-----
MIIFbTCCBFWgAwIBAgICH4cwDQYJKoZIhvcNAQEFBQAwcDELMAkGA1UEBhMCVUsx
...
Yhixw1aKEPzNjNowuIseVogKOLXxWI5vAi5HgXdS0/ES5gDGsABo4fqovUKlgop3
RA= -----END CERTIFICATE-----
...with a carriage return between each line Mongrel, it seems, cannot
handle the line breaks in the header and with this header present
returns an internal server error ''500''.
Looking at RFC 2616 it seems that whitespace such as this _is_ allowed
in the header block. Section 4.2 says "Header fields can be extended
over multiple lines by preceding each extra line with at least one SP
or HT" - which is exactly what Pound does. Therefore, I think the
problem may be with Mongrel.
I''ve tested this by doing the following:
1) Sniffed the whole HTTP message sent from Pound -> Mongrel using
tcpmon. (Fails - returns ''internal server error'' / 500).
2) Replaying the message into Mongrel directly using telnet, cutting
out the X-SSL-certificate header. Mongrel responds correctly (200).
3) Added in my own arbitary header with a carriage return in it.
Mongrel again returns 500.
I turned on debugging with the ''-B'' option hoping there would
be
something in the log files, but they''re empty.
Can anyone else confirm that caarriage returns in HTTP headers is a
problem for Mongrel?
Many thanks,
Michael.
[1] http://www.apsis.ch/pound/pound_list/archive/2006/2006-10/1159900707000
On Wed, 11 Oct 2006 16:06:34 +0100 "Michael Parkin" <michaelparkin at gmail.com> wrote:> Hi, > > I''ve recently been trying to setup Mongrel behind Pound so that I can > do mutual SSL authentication. I''ve had a few problems with Pound > (documented at [1]), but now have it working correctly. >So with Pound...> However, I think there is a problem with Mongrel and how it deals with > the headers Pound adds to the HTTP header block. One of the extra > headers Pound adds is ''X-SSL-certificate'' - the full multi-line client > certificate in PEM format. As the certificate is spread over multiple > lines like this: > > X-SSL-certificate: -----BEGIN CERTIFICATE----- > MIIFbTCCBFWgAwIBAgICH4cwDQYJKoZIhvcNAQEFBQAwcDELMAkGA1UEBhMCVUsx > ... > Yhixw1aKEPzNjNowuIseVogKOLXxWI5vAi5HgXdS0/ES5gDGsABo4fqovUKlgop3 > RA=> -----END CERTIFICATE----- >You have some need to send the client''s certificate in a bizarre header? Ok, before I go about answer your question you should probably explain what it is you''re trying to do with this. There might be a simpler way.> ...with a carriage return between each line Mongrel, it seems, cannot > handle the line breaks in the header and with this header present > returns an internal server error ''500''. > > Looking at RFC 2616 it seems that whitespace such as this _is_ allowed > in the header block. Section 4.2 says "Header fields can be extended > over multiple lines by preceding each extra line with at least one SP > or HT" - which is exactly what Pound does. Therefore, I think the > problem may be with Mongrel. >That is a horrible bastardization of the RFC and I''d consider it an abuse of the headers, especially since only Pound does this out of *all* the HTTP clients people have used. I''d almost tell them to screw off on principle (especially since they can encode this without the newlines). But, let''s look at the Mongrel grammar for headers: field_name = (token -- ":")+ >start_field %write_field; field_value = any* >start_value %write_value; message_header = field_name ":" " "* field_value :> CRLF; Says right there field_value accepts "any*" and it''s closed by a CRLF. Probably just have to make the exit stronger so that it can include CR or LF but not both. If you work up a test case that demonstrates it (preferably a patch to the mongrel tests) then I can fix it up.> I''ve tested this by doing the following: >One thing you didn''t do is give me information from the mongrel.log. There should have been BAD CLIENT information in there. You also didn''t turn on USR1 logging so that Mongrel dumps the whole request that caused BAD CLIENT errors. If you do send in a test case then include this information too. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
Hi, On Mit 11.10.2006 17:17, Zed A. Shaw wrote:>On Wed, 11 Oct 2006 16:06:34 +0100 >"Michael Parkin" <michaelparkin at gmail.com> wrote: > >> ...with a carriage return between each line Mongrel, it seems, cannot >> handle the line breaks in the header and with this header present >> returns an internal server error ''500''. >> >> Looking at RFC 2616 it seems that whitespace such as this _is_ >> allowed in the header block. Section 4.2 says "Header fields can be >> extended over multiple lines by preceding each extra line with at >> least one SP or HT" - which is exactly what Pound does. Therefore, I >> think the problem may be with Mongrel. > >That is a horrible bastardization of the RFC and I''d consider it an >abuse of the headers, especially since only Pound does this out of >*all* the HTTP clients people have used. I''d almost tell them to screw >off on principle (especially since they can encode this without the >newlines).Let''s look at http://www.and.org/texts/server-http, I think it''s a nice conclusion of the rfc. Regards Aleks
Michael Parkin wrote:>Hi, > >I''ve recently been trying to setup Mongrel behind Pound so that I can >do mutual SSL authentication. I''ve had a few problems with Pound >(documented at [1]), but now have it working correctly. > >However, I think there is a problem with Mongrel and how it deals with >the headers Pound adds to the HTTP header block. One of the extra >headers Pound adds is ''X-SSL-certificate'' - the full multi-line client >certificate in PEM format. As the certificate is spread over multiple >lines like this: > >X-SSL-certificate: -----BEGIN CERTIFICATE----- > MIIFbTCCBFWgAwIBAgICH4cwDQYJKoZIhvcNAQEFBQAwcDELMAkGA1UEBhMCVUsx > ... > Yhixw1aKEPzNjNowuIseVogKOLXxWI5vAi5HgXdS0/ES5gDGsABo4fqovUKlgop3 > RA=> -----END CERTIFICATE----- > >Do you actually need to use the certificate down stream, if not and you just need to know the original request was SSL''d then pound should add X-FORWARD type header instead...>...with a carriage return between each line Mongrel, it seems, cannot >handle the line breaks in the header and with this header present >returns an internal server error ''500''. > >Looking at RFC 2616 it seems that whitespace such as this _is_ allowed >in the header block. Section 4.2 says "Header fields can be extended >over multiple lines by preceding each extra line with at least one SP >or HT" - which is exactly what Pound does. Therefore, I think the >problem may be with Mongrel. > >I''ve tested this by doing the following: > >1) Sniffed the whole HTTP message sent from Pound -> Mongrel using >tcpmon. (Fails - returns ''internal server error'' / 500). > >2) Replaying the message into Mongrel directly using telnet, cutting >out the X-SSL-certificate header. Mongrel responds correctly (200). > >3) Added in my own arbitary header with a carriage return in it. >Mongrel again returns 500. > >I turned on debugging with the ''-B'' option hoping there would be >something in the log files, but they''re empty. > >Can anyone else confirm that caarriage returns in HTTP headers is a >problem for Mongrel? > >Many thanks, > >Michael. > >[1] http://www.apsis.ch/pound/pound_list/archive/2006/2006-10/1159900707000 >_______________________________________________ >Mongrel-users mailing list >Mongrel-users at rubyforge.org >http://rubyforge.org/mailman/listinfo/mongrel-users > > > > >
Hi Zed, Thanks for the reply. I''m new to Ruby, Mongrel, Rails, etc. So please bear with me... On 10/12/06, Zed A. Shaw <zedshaw at zedshaw.com> wrote:> You have some need to send the client''s certificate in a bizarre header? Ok, before I go about answer your question you should probably explain what it is you''re trying to do with this. There might be a simpler way.Actually, no - I don''t have any use for this header that Pound sends Mongrel. But, AFAIK there''s no way to remove it from the headers Pound sends (ok, I could go in an hack Pound''s source, but I want to have standard code on my boxes...)> If you work up a test case that demonstrates it (preferably a patch to the mongrel tests) then I can fix it up.ok, as I''ve said I''m new to Ruby and I''m using developing this application as a way to learn. This may take some time!> One thing you didn''t do is give me information from the mongrel.log. There should have been BAD CLIENT information in there.There''s nothing in mongrel.log apart from the standard startup blurb. I.e: ** Daemonized, any open files are closed. Look at log/mongrel.pid and log/mongrel.log for info. ** Starting Mongrel listening at 127.0.0.1:3000 ... ** Writing PID file to log/mongrel.pid> You also didn''t turn on USR1 logging so that Mongrel dumps the whole request that caused BAD CLIENT errors. If you do send in a test case then include this information too.Thanks for the USR1 tip: when I turn on USR1 I get the output at the bottom of the email. Is it the \r\n\t''s in the "X-SSL-certificate" header that''s the problem here? Thanks again, Michael. ** USR1 received, toggling $mongrel_debug_client to true Thu Oct 12 11:04:48 +0100 2006: BAD CLIENT (127.0.0.1): Invalid HTTP format, parsing fails. Thu Oct 12 11:04:48 +0100 2006: REQUEST DATA: "GET / HTTP/1.1\r\nUser-Agent: curl/7.13.1 (powerpc-apple-darwin8.0) libcurl/7.13.1 OpenSSL/0.9.7i zlib/1.2.3\r\nHost: 127.0.0.1:3001\r\nPragma: no-cache\r\nAccept: */*\r\nX-Forwarded-Proto: https\r\nX-SSL-Subject: C = xx, O xx, OU = xx, L = xx, CN = michael parkin\r\nX-SSL-Issuer: C UK, O = eScience, OU = Authority, CN = CA, emailAddress ca-operator at grid-support.ac.uk\r\nX-SSL-notBefore: Jun 19 12:10:30 2006 GMT\r\nX-SSL-notAfter: Jun 19 12:10:30 2007 GMT\r\nX-SSL-serial: 8061\r\nX-SSL-certificate: -----BEGIN CERTIFICATE-----\r\n\tMIIFbTCCBFWgAwIBAgICH4cwDQYJKoZIhvcNAQEFBQAwcDELMAkGA1UEBhMCVUsx\r\n\tETAPBgNVBAoTCGVTY2llbmNlMRIwEAYDVQQLEwlBdXRob3JpdHkxCzAJBgNVBAMT\r\n\tAkNBMS0wKwYJKoZIhvcNAQkBFh5jYS1vcGVyYXRvckBncmlkLXN1cHBvcnQuYWMu\r\n\tdWswHhcNMDYwNzI3MTQxMzI4WhcNMDcwNzI3MTQxMzI4WjBbMQswCQYDVQQGEwJV\r\n\tSzERMA8GA1UEChMIZVNjaWVuY2UxEzARBgNVBAsTCk1hbmNoZXN0ZXIxCzAJBgNV\r\n\tBAcTmrsogriqMWLAk1DMRcwFQYDVQQDEw5taWNoYWVsIHBhcmQYJKoZIhvcNAQEB\r\n\tBQADggEPADCCAQoCggEBANPEQBgl1IaKdSS1TbhF3hEXSl72G9J+WC/1R64fAcEF\r\n\tW51rEyFYiIeZGx/BVzwXbeBoNUK41OK65sxGuflMo5gLflbwJtHBRIEKAfVVp3YR\r\n\tgW7cMA/s/XKgL1GEC7rQw8lIZT8RApukCGqOVHSi/F1SiFlPDxuDfmdiNzL31+sL\r\n\t0iwHDdNkGjy5pyBSB8Y79dsSJtCW/iaLB0/n8Sj7HgvvZJ7x0fr+RQjYOUUfrePP\r\n\tu2MSpFyf+9BbC/aXgaZuiCvSR+8Snv3xApQY+fULK/xY8h8Ua51iXoQ5jrgu2SqR\r\n\twgA7BUi3G8LFzMBl8FRCDYGUDy7M6QaHXx1ZWIPWNKsCAwEAAaOCAiQwggIgMAwG\r\n\tA1UdEwEB/wQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwID6DAs\r\n\tBglghkgBhvhCAQ0EHxYdVUsgZS1TY2llbmNlIFVzZXIgQ2VydGlmaWNhdGUwHQYD\r\n\tVR0OBBYEFDTt/sf9PeMaZDHkUIldrDYMNTBZMIGaBgNVHSMEgZIwgY+AFAI4qxGj\r\n\tloCLDdMVKwiljjDastqooXSkcjBwMQswCQYDVQQGEwJVSzERMA8GA1UEChMIZVNj\r\n\taWVuY2UxEjAQBgNVBAsTCUF1dGhvcml0eTELMAkGA1UEAxMCQ0ExLTArBgkqhkiG\r\n\t9w0BCQEWHmNhLW9wZXJhdG9yQGdyaWQtc3VwcG9ydC5hYy51a4IBADApBgNVHRIE\r\n\tIjAggR5jYS1vcGVyYXRvckBncmlkLXN1cHBvcnQuYWMudWswGQYDVR0gBBIwEDAO\r\n\tBgwrBgEEAdkvAQEBAQYwPQYJYIZIAYb4QgEEBDAWLmh0dHA6Ly9jYS5ncmlkLXN1\r\n\tcHBvcnQuYWMudmT4sopwqlBWsvcHViL2NybC9jYWNybC5jcmwwPQYJYIZIAYb4QgEDBDAWLmh0\r\n\tdHA6Ly9jYS5ncmlkLXN1cHBvcnQuYWMudWsvcHViL2NybC9jYWNybC5jcmwwPwYD\r\n\tVR0fBDgwNjA0oDKgMIYuaHR0cDovL2NhLmdyaWQt5hYy51ay9wdWIv\r\n\tY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAS/U4iiooBENGW/Hwmmd3\r\n\tXCy6Zrt08YjKCzGNjorT98g8uGsqYjSxv/hmi0qlnlHs+k/3Iobc3LjS5AMYr5L8\r\n\tUO7OSkgFFlLHQyC9JzPfmLCAugvzEbyv4Olnsr8hbxF1MbKZoQxUZtMVu29wjfXk\r\n\thTeApBv7eaKCWpSp7MCbvgzm74izKhu3vlDk9w6qVrxePfGgpKPqfHiOoGhFnbTK\r\n\twTC6o2xq5y0qZ03JonF7OJspEd3I5zKY3E+ov7/ZhW6DqT8UFvsAdjvQbXyhV8Eu\r\n\tYhixw1aKEPzNjNowuIseVogKOLXxWI5vAi5HgXdS0/ES5gDGsABo4fqovUKlgop3\r\n\tRA==\r\n\t-----END CERTIFICATE-----\r\nX-SSL-cipher: AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1\r\nX-Forwarded-For: xxx.xxx.xxx.xxx\r\n\r\n" --- PARAMS: {"HTTP_X_SSL_NOTBEFORE"=>"Jun 19 12:10:30 2006 GMT", "HTTP_USER_AGENT"=>"curl/7.13.1 (powerpc-apple-darwin8.0) libcurl/7.13.1 OpenSSL/0.9.7i zlib/1.2.3", "HTTP_HOST"=>"127.0.0.1:3001", "HTTP_X_SSL_ISSUER"=>"C = UK, O eScience, OU = Authority, CN = CA, emailAddress ca-operator at grid-support.ac.uk", "REQUEST_PATH"=>"/", "HTTP_VERSION"=>"HTTP/1.1", "HTTP_X_SSL_CERTIFICATE"=>"-----BEGIN CERTIFICATE-----", "REQUEST_URI"=>"/", "HTTP_X_SSL_NOTAFTER"=>"Jun 19 12:10:30 2007 GMT", "HTTP_X_FORWARDED_PROTO"=>"https", "HTTP_PRAGMA"=>"no-cache", "HTTP_X_SSL_SERIAL"=>"8071", "HTTP_X_SSL_SUBJECT"=>"C = xx, O = xx, OU = xx, L = xx, CN = michael parkin", "HTTP_ACCEPT"=>"*/*", "REQUEST_METHOD"=>"GET"}
Hi Kris, On 10/12/06, Kris Leech <krisleech at interkonect.com> wrote:> Do you actually need to use the certificate down stream, if not and you > just need to know the original request was SSL''d then pound should add > X-FORWARD type header instead...Actually, no I don''t need the certificate downstream, but I do need the other SSL information Pound sends (like the X-SSL-Subject, for instance). I haven''t figured out how to remove just the X-SSL-certificate header - any ideas? Thanks, Michael.
On Thu, 12 Oct 2006 09:51:00 +0200 Aleksandar Lazic <al-mongrelusers at none.at> wrote:> Hi, > > On Mit 11.10.2006 17:17, Zed A. Shaw wrote: > >On Wed, 11 Oct 2006 16:06:34 +0100 > >"Michael Parkin" <michaelparkin at gmail.com> wrote: > > > >> ...with a carriage return between each line Mongrel, it seems, cannot > >> handle the line breaks in the header and with this header present > >> returns an internal server error ''500''. > >> > >> Looking at RFC 2616 it seems that whitespace such as this _is_ > >> allowed in the header block. Section 4.2 says "Header fields can be > >> extended over multiple lines by preceding each extra line with at > >> least one SP or HT" - which is exactly what Pound does. Therefore, I > >> think the problem may be with Mongrel. > > > >That is a horrible bastardization of the RFC and I''d consider it an > >abuse of the headers, especially since only Pound does this out of > >*all* the HTTP clients people have used. I''d almost tell them to screw > >off on principle (especially since they can encode this without the > >newlines). > > Let''s look at http://www.and.org/texts/server-http, I think it''s a nice > conclusion of the rfc. >Yeah, too bad guys like me who don''t have the baking of 400 such billion dollar companies get any say in these things. As I''ve said millions of times before, just because the damn RFC says it''s allowed doesn''t mean people should be allowed to do it. Just nasty. Then again, I also said that it''s a simple fix as long as I have a good test case. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
On Thu, 12 Oct 2006 11:18:37 +0100 "Michael Parkin" <michaelparkin at gmail.com> wrote:> Hi Zed, > > Thanks for the reply. I''m new to Ruby, Mongrel, Rails, etc. So please > bear with me... > > On 10/12/06, Zed A. Shaw <zedshaw at zedshaw.com> wrote: > > > You have some need to send the client''s certificate in a bizarre header? Ok, before I go about answer your question you should probably explain what it is you''re trying to do with this. There might be a simpler way. > > Actually, no - I don''t have any use for this header that Pound sends > Mongrel. But, AFAIK there''s no way to remove it from the headers Pound > sends (ok, I could go in an hack Pound''s source, but I want to have > standard code on my boxes...) >No, there''s gotta be a way to turn that off. If pound always sent this then people using pound would have yelled at me sooner. I''d have noticed it too since I test under pound. You''ve got a config telling pound to do this.> > Thanks for the USR1 tip: when I turn on USR1 I get the output at the > bottom of the email. Is it the \r\n\t''s in the "X-SSL-certificate" > header that''s the problem here?Ok, I can put this in a test as a raw send. Thanks I''ll let you know when I toss this fix in. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.