Rene G. Eberhard wrote:
>
> > 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.
>
OpenSSL currently does abort the handshake with a fatal alert: thats why
MS SGC wont work. However this isn't TLS RFC2246 its SSLv3 but its the
same wording. The relevant portion of the spec is:
> 7.4.1.2. Client hello
>
> When this message will be sent:
> When a client first connects to a server it is required to send
> the client hello as its first message. The client can also send a
> client hello in response to a hello request or on its own
> initiative in order to renegotiate the security parameters in an
> existing connection.
It depends on how the term "existing connection" is interpreted. If it
means an established SSL session then yes sending client hello after a
server certificate message is a violation of the protocol.
Alternatively it be interpreted to mean that the client can send a
client hello at any time: including during the initial handshake. If
this is the case then it is acceptable.
> >
> > 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!
If it is a violation of the protocol then its yet another workaround...
> In the meantime most browsers offer a EXPORT1024 cipher suite
> too. So there's no need to sign a temp public key.
>
Not sure if MSIE does this or if OpenSSL includes these. If it can avoid
the temp key signing then this avoids the need for any further hackery.
> > 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?
> >
>
> 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.
>
Not only inappropriate but not possible. We have no control over what
MSIE sends and MS isn't likely to change it just to be friendly
particularly if their servers and clients seem to have better
performance as a result.
What I was wondering was if MS servers can actually determine from some
info in the handshake that it is an export version of MSIE and it will
send the second client hello and thus expect it.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
