On Tue, May 23, 2000 at 01:21:51PM +0100, Dr Stephen Henson wrote:
>> [...] If compatibility with broken servers is desired, you have to
>> reconnect with different settings.
> Such as disabling TLSv1.0? Or should we add another bug option? A bug
> option might be desirable if some servers require this broken behaviour
> and none (or very few) choke on it.
Applications would have to try again with TLS 1.0 disabled. A bug
option for this would be bad because bug options are for having
OpenSSL *tolerate* bugs, not for invoking buggy behaviour -- there's
no need to do so, if the server talks TLS 1.0 the problem does not
occur anyway, and if it doesn't, connecting with TLS 1.0 enabled
can't hurt. (Except that version rollback attacks become possible,
so applications preferrably should have a configuration flag for this
in case anyone really notices an SSL 3.0 weakness that does not
also apply to TLS 1.0.)
>> Actually there's no security problem for servers to accept a
>> PreMasterSecret that contains the negotiated protocol version instead
>> of the client_version from the ClientHello if these don't match;
>> so it's possible for servers to adopt to both correct and broken
>> clients, in case there are already TLS 1.0-aware clients that send
>> incorrect PreMasterSecret messages as expected by those broken SSLv3
>> servers.
> Yes I was thinking we should make OpenSSL tolerate this, either by
> default or a bug option. The only way you'll see this though is by
> connecting with a broken client on an OpenSSL server that disables TLS.
Not as default (it's wrong after all), just as a bug option.
But first I'd like to see any client that actually shows this behaviour
-- note that for clients that don't come with TLS 1.0 support,
all this is not an issue.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
