httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: Patch for bug 18757 breaks TLS upgrade - [Content-Length is removed from HEAD requests]
Date Tue, 07 Dec 2004 22:00:52 GMT
   So what are you suggesting that the appropriate fix should be?  Even
though the protocol.c patch was bogus, it sounds like might have exposed
something else.  In fact I am still not seeing where the problem is. 
The protocol.c patch was just allowing a bad response to happen that
should never have happened in the first place.  It seems like the
appropriate OPTIONS response should include C-L:0.  Anything else that
actually has content would also contain the appropriate C-L: header.

Brad

>>> jorton@redhat.com Tuesday, December 07, 2004 12:51:15 PM >>>
On Tue, Dec 07, 2004 at 11:01:13AM -0700, Brad Nicholes wrote:
> >I tested the TLS upgrade stuff last week and it failed because the
> >zero-length chunk to terminate the OPTIONS response was not sent
> through
> >the mod_ssl output filter; is that the same problem you see?
> 
> I don't think so.  I can make everything work again by simply
allowing
> the "Content-Length: 0" header to be sent through.  I'm not sure
what
> impact that header has on the rest of mod_ssl.  Obviously by
removing
> it, it causes mod_ssl to *not* do something it was suppose to.  My
guess
> is that if the zero-length chunk that terminates the OPTIONS response
is
> not being sent, it is probably a result of mod_ssl not seeing a
> content-length header.

I think we are seeing the same problem.  Before, a zero-length OPTIONS
response would be sent with t-e: chunked and a single
zero-terminator-chunk. The "0\r\n\r\n" packet was being sent
unencrypted
and breaking the SSL connection.  After you reverted the protocol.c
change, a zero-length OPTIONS response is sent with C-L: 0 and hence
terminates after the headers.  Subsequent requests on the connection
get
the right filter stack.

So you have successfully hidden the mod_ssl bug for upgrades with
zero-length responses.  The fact that mod_ssl (incorrectly) refuses to
upgrade anything other than an OPTIONS request makes the bug less
obvious since OPTIONS responses are rarely anything but zero-length,
but
I'll fix that.

For an upgrade on GET the strace now looks like:

send(3, "GET / HTTP/1.1\r\nHost"..., 173, 0) = 173
recv(3, "HTTP/1.1 101 Switchi"..., 4096, 0) = 85
read(4, "*J\204\17\342g l\327U\323/\271"..., 32) = 32
write(3, "\200|\1\3\1\0c\0\0\0\20\0\0009"..., 126) = 126
<SSL negotiation and response headers>
read(3, "\26\3\1\0000", 5)              = 5
read(3, "a\20\363\37{\372\347\205\350\36"..., 48) = 48
read(3, "<html", 5)                     = 5

         ^^^^^ uh-oh!

> BTW, what are you using to test TLS Upgrade with?

A hacked up version of neon.


Mime
View raw message