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.
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.
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.
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.
Just setting up mutually incompatible ciphers yields:
SSL_accept:before/accept initialization
SSL3 alert write:fatal:handshake failure
SSL_accept:error in SSLv3 read client hello C
while the original callback yields:
SSL_accept:before/accept initialization
SSL_accept:error in SSLv2/v3 read client hello A
SSL_accept:error in SSLv3 read client hello B
SSL_accept:error in SSLv3 read client hello B
SSL3 alert write:fatal:handshake failure
SSL_accept:error in SSLv3 read client hello C
so I am not missing out on the important errors, seems to be working
fine. Can anyone suggest any additional interesting and not too burdensome
to implement test cases?
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
