Victor Duchovni wrote:
> On Fri, Dec 14, 2007 at 11:06:58AM +0100, Lutz Jaenicke wrote:
>
>
>>> else if (ret < 0) {
>>> switch(SSL_get_error((SSL *)s, ret)) {
>>> case SSL_ERROR_WANT_READ:
>>> case SSL_ERROR_WANT_WRITE:
>>> break;
>>> default:
>>> msg_info("%s:error in %s",
>>> str, SSL_state_string_long((SSL *) s));
>>> break;
>>> }
>>> }
>>> }
>>>
>>> What is new here is the call to SSL_get_error() to skip the WANT_READ
>>> and WANT_WRITE cases, only logging other (unexpected) errors. Is this
>>> approach sound? Is it safe to call SSL_get_error() from the info callback,
>>> or might it modify the SSL state in some unsupported fashion.
>>>
>>> I am hoping this is a correct analysis and sensible solution..
>>>
>> Hi Victor,
>>
>> your analysis is correct. The info callback is not very sensible when it
>> comes to the non-blocking case.
>> Your approach comes with an upside and a downside. What you are
>> seeing with your approach is more a view to the SSL handshake
>> state (which may be better understandable for the users).
>> You are however (as a developer) loosing the information about
>> additional calls being necessary to complete read/write operations.
>>
>
> Provided SSL_get_error() has and continues to have no side-effects,
> I am inclined to implement this.
>
It better should not have side-effects. Applications need SSL_get_error()
to learn about WANT_WRITE and WANT_READ states to act accordingly.
> The purpose of the detailed handshake logging is I think to let *users*
> understand the protocol interactions with the remote system, and identify
> where the handshake breaks down. This is not a developer tool, I can
> always comment out the first "break;" and get the old behaviour when
> testing new code.
>
Ack.
> Users can of course get very detailed protocol insight with "ssldump"
> (abandoned) or wireshark (actively maintained), but providing info
> callback logging is a basic first step.
>
Using a tool like the above is better. There was a time when I was the
developer of the component we are talking about :-) I implemented the
informational/debug output because doing so was "state of the art".
I never used it myself but preferred ssldump.
I was even thinking about removing it altogether...
> Real-world testing of this is a bit tricky, because real-world systems
> are not configured with this level of logging, almost everyone has
> the info-callback turned off. Only people debugging issues (and a few
> clueless newbies who crank the log level to "debug" for no reason at all)
> have the info callback enabled.
>
> My "lab testing shows no adverse effects on TLS sessions that work
> flawlessly (that's what happens in the lab). Instrumenting a server
> or client to misbehave in interesting ways is a lot of work.
>
Before writing the statement about SSL_get_error() having no side
effects, I did perform a code review just to be sure. I would thus be
surprised if anything pops up.
Best regards,
Lutz
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
