>>> Note that above referred post to openssl-users discusses insufficient >>> buffer for CertificateRequest message (when server is configured for >>> client certificate authentication and collects *all* suitable root >>> certificates it can find in computer's certificate store). But here we >>> are talking about ServerHello message! The only possibility for blow-up >>> is extensions, which makes me really wonder what kind of extension is >>> it? Therefore I wonder if you, Massimiliano, can collect network traffic >>> capture (e.g. with Wireshark) when it works. >>> >> Perhaps someone is using an MPEG-of-cat extension but for ServerHello now? >> >> The output of -tlsextdebug option to s_client would be useful when it >> works too. >> > > Though thinking about this the violation is at the record layer and it > is using an illegal value for the fragment length. The actual contents > of the record could be multiple handshake messages, not just server hello.
Oh! I.e. it's not necessarily ServerHello, rather it's again excessive CertificateRequest that is responsible. Sorry about confusion. Yet I'd still insist on finding a way to keep record within specification(*), as opposite to increasing SSL3_RT_MAX_EXTRA. Specification allows to send larger list by fragmenting the message, so why favor non-compliant implementation? (*) By cleaning up "Trusted Root Certification Authorities" on server or not sending any list at all (by setting SendTrustedIssuerList to 0) as discussed elsewhere. Unfortunately it doesn't seem to be possible to hand pick CA cert[s] for client authentication. There is SslStream constructor with LocalCertificateSelectionCallback, but latter seems that it's meaningful only on client side. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
