[TLS] OpenSSL 0.9.8l diffs for draft-mrex-tls-secure-renegotiation-03

[Martin Rex <[e-mail]>]

Dear TLS,

Here is an implementation of draft-mrex-tls-secure-renegotiation-03:

ftp://ftp.sap.com/pub/ietf-work/tls/

ftp://ftp.sap.com/pub/ietf-work/tls/OpenSSL-0.9.8l-draft-mrex-tls-secure-renegotiation-03-20091207.diff
ftp://ftp.sap.com/pub/ietf-work/tls/OpenSSL-0.9.8l-draft-mrex-tls-secure-renegotiation-03-20091207.zip

It is a diff to OpenSSL-0.9.8l.

It should work for SSLv2-BC ClientHello, SSLv3 and TLS


Implementation notes:
 - it includes fallback for OpenSSL when compiled without TLS Extensions
 - It appears to work for DTLS as well, but I admit to have not yet
   understood how that works exactly.
 - for enabling renegotiation with old peers,
   I copied SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION from newer snapshot
   and removed that bit from SSL_OP_ALL
   since all OP-Bits are gone, the app must provide different OP-values
   for Server and Client SSL_CTX in order to distinguish client/server


I'm having slight troubles with OpenSSL's "s_client" and "s_server"
applications.

It appears that there is insufficient return-code chechking
for the SSL_renegotiate() calls in several places of OpenSSL.

- SSL_renegotiate() might need to reset "new_session" when the
  called renegotiation method fails (rc=0)

- both s_server and s_client call SSL_renegotiate(),
  but do _not_ check the return codes and write confusing/incorrect
  messages to the screen (in particular for 0.9.8l where renegotiation
  has been disabled by default).

- Since SSL_do_handshake() seems to always return "1", independent
  of whether renegotiation is performed or the request rejected,
  the output of "SSL_do_handshake()=1 by s_server is confusing.


-Martin