Re: [naviserver-devel] naviserver with connection thread queue

[Gustaf N. <ne...@wu...>]

Am 04.12.12 20:25, schrieb Stephen Deasey:
> I found this nifty site the other day:
>
>      https://www.ssllabs.com/ssltest/analyze.html?d=next-scripting.org
>
> It's highlighting a few things that need fixed in the nsssl module,
> including a couple of security bugs. Looks like relatively little code
> though.
The report is already much better: now everything is green. Most of the 
complaints could be removed via configuration, just two issues required 
code changes (requires a flag, which is not available in all current 
OpenSSL implementation, such as that from Mac OS X, and adding a 
callback). The security rating is now better than from nginx.

Today, i was hunting another problem in connection with nsssl, which 
turns out to be a weakness of our interfaces. The source for the problem 
is that the buffer management of OpenSSL is not aligned with the buffer 
management in naviserver. In the naviserver driver, all receive requests 
are triggered via the poll, when sockets are readable. With OpenSSL it 
might be as well possible that data as a leftover from an earlier 
receive when a smaller buffer is provided. Naviserver requested during 
upload spool reveive operations with a 4KB buffer. OpenSSL might receive 
"at once" 16KB. The read operation with the small buffer will not drain 
the OpenSSL buffer, and later, poll() will not be triggered by the fact, 
that the socket is readable (since the buffer is still quite full). The 
problem happened in NaviServer, when the input was spooled (e.g. file 
uploads). I have doubts that this combination ever worked. I have 
corrected the problem by increasing the buffer variable in the driver.c. 
The cleaner implementation would be to add an "Ns_DriverReadableProc 
Readable"  similar to the "Ns_DriverKeepProc Keep", but that would 
effect the interface of all drivers.

-gustaf neumann