> Dr Stephen Henson wrote:
> >
> > Adrian Peck wrote:
> > >
> > > The basic problem is that IE4 or 5 will issue a client hello message
> > > immediately after receiving the server hello and server
> certificate if it
> > > finds that this certificate was a Server Gated Crypto ( SGC )
> certificate.
> > > The 'point' of this is to change the cipher suites that are
> offered to the
> > > server without starting a new SSL session. My code peeks at the client
> > > message to check for a client hello and resets the SSL state to
> > > SSL_ST_ACCEPT if it spots one. The code is only visited if
> the SSL mode
> > > SSL_MODE_NCIPHER_SGC_HACK is set.
Am I right in understanding that this is not according to RFC2246?
A proper implementation should abort the handshake with a fatal alert.
> > I'm not sure what the MSIE logic of not starting a new session is
> > though. At this point no cryptographic operations have been performed so
> > there isn't much overhead.
> >
>
> Ah I see the point now. The server doesn't have to generate the RSA
> temporary key and more importantly sign it with the certified key: this
> is likely to be an expensive operation.
But only if the server sends the ServerHello and Certificate messages
and waits for a new ClientHello. After a timeout the server may continue
with the ServerKeyExchange and ServerHelloDone message... strange and
not very efficient.
> The next problem is how can the server in general determine whether to
> expect the second client hello?
>
> I can think of lots of possible solutions.
>
> One simple way is for it to accept the client hello after it has sent
> the server done message and then restart. This will however mean that it
> must perform the expensive private key operations on the initial
> handshake.
You're right but this violates the protocol!
In the meantime most browsers offer a EXPORT1024 cipher suite
too. So there's no need to sign a temp public key.
> This will at least work and is I believe what the patch does
> when a memory BIO is present. I'll look into checking in a fix that
> works in all circumstances.
>
> Trickier solutions might involve attempting to read the second client
> hello if we have an SGC certificate and timing out otherwise. Getting
> this going cross platform could be nasty.
>
> What I suspect is going on is that somehow the server can determine that
> it is an MSIE client and that it can do SGC. Maybe something naughty in
> the client hello message?
>
> Steve.
Consider the layering. HTTP is on top of TLS. TLS has no idea that it's
upper protocol is HTTP. I suggested to extend the ClientHello message
for solving the virtual hosting problem. (This is allowed according
to RFC2246). But no one was interested in my suggestion. (although
it had solved the problem =).
I think extending the ClientHello message just because of the strange
behavior of MS clients is not appropriate.
Regards Rene
--
-----------------------------------------------------------
Rene G. Eberhard
Mail : [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
