Ralf S. Engelschall wrote:
>
> On Tue, Nov 03, 1998, Matthias Loepfe wrote:
>
> > I played around with NS-Browser and the 128 bit step-up.
>
> What exactly do you mean here? The fact that you used a Fortify'ed NS or that
> you disabled some ciphers or that you used some special certs?
special certs.
>
> > Because the browser
> > does a second SSL negotiation it is necessary to handle this kind of error
> > condition (renegotiation).
>
> Wait, let it me understand it correctly, please. Usually there is a SSL
> negotiation phase when there is no already known session. Then on subsequent
> connects this session can be reused, so there is no full-featured negotation.
> Then when the session expires a re-negotation takes place to establish a new
> SSL session. This is my knowledge of the SSL handshake phase.
>
> But what you're talking about sounds like a different type of re-negotation.
> It sounds more like a second ChangeCipher message, right?
If an export NS browser connects to a server with a global-ID it first does a
normal 40-bit SSL negotiation. Then because it got the servers global-ID cert
it does a second full negotiation with export strength, that means it begins
again with a 'Client Hello'.
>
> > The following patch does work, but most probably
> > it is not the whole truth, that means there are probably other conditions
> > which should be handled (also after SSL_write ?).
> >
> > buff.c
> > ------
> > ...
> > #ifdef APACHE_SSL
> > if (fb->ssl) {
> > rv = SSL_read(fb->ssl, buf, nbyte);
> >
> > /** support for 128 bit stepup **/
> > if ((rv < 0) && (SSL_get_error(fb->ssl, rv) == SSL_ERROR_WANT_READ)) {
> > errno = EINTR;
> > }
> > }
> > else
> > #endif
> > rv = read( fb->fd_in, buf, nbyte );
> > ...
>
> This is inside the Apache buffer code and now totally confuses me. You talked
> about a re-negotation at the SSL handshake phase. At this time the Apache
> buffer code is still not used. So I don't understand why enhancing the
> SSL_read/write() phase adds support for your 128 bit situation.
>
> Please give us some more details about what 128Bit-situation you are talking
> about and want to fix. Then we can search for the correct solution together
> more easily.
>From the server point of view after the first SSL negotiation everything looks
fine and it tries to read the request header. Thats why the problem shows up
in SSL_read, because thats the moment the browser send a 'Client-Hello'.
I tried the whole stuff with the s_server and s_client programms from SSLeay,
which work as expected. I had a look at the s_server code and found the extra
'error' handling after SSL_read and SSL_write.
> Ralf S. Engelschall
> [EMAIL PROTECTED]
> www.engelschall.com
Hope this helps to better understand my previous mail.
regards,
Matthias
-------------------------------------------------------------------------------
Matthias Loepfe, AdNovum Informatik AG, Roentgenstr. 22, CH-8005 Zurich
Email: [EMAIL PROTECTED] Voice: +41 1 272 6111 Fax: +41 1 272 6312
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
