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.
