2008/2/14, Peter Sylvester wrote:

> > Now the concern I have is related with the real world interoperability
> > state with existing servers that might simply close the connection if
> > they don't understand or properly handle client TLS extensions. This
> > is a good reason to allow the user to enable or disable at will client
> > TLS extensions.

> [...]
>
> I have not heard (but I am not listening very hardly) about servers that
> badly implement extensions. There are not that many ssl server
> implementions out in the wild, and the SNI patch based on openssl
> for the most deployed open source implementation was done in our
> office. :-)
>
> From 3546:
> The extensions are designed to be
> backwards compatible - meaning that TLS 1.0 clients that support the
> extensions can talk to TLS 1.0 servers that do not support the
> extensions, and vice versa.
>
> read also the second half of section 2.1 of rfc3546

Yep, which says...

"Thus the use of the extended client hello defined above should not
"break" existing TLS 1.0 servers."

I did understand that it is theoretically TLS back compatible and that
proper TLS server implementations _must_ be back compatible. That was
the reason for asking for some real world data. lib/curl as a
client-library/tool can not foresee if it will be used with properly
TLS implemented servers.

> > Does OpenSSL retry a connection with TLS extensions disabled if a
> > connection attempt with extensions enabled is remotely closed before
> > handshake is completed ?
>
> No. If the OpenSSL user, i.e. the application wants a feature,
> how can OpenSSL decide differently?
>
> Well, you want me to establish a secured connexion.
> But since no cipher is available the connexion will be in clear text?

Good, the SSL library must give back what the user asks for or nothing.

But now I go back to lib/curl reasoning and how TLS extensions as a
whole and each particular TLS extension in particular should affect
libcurl or curl users. In other words how the TLS client extensions
should or could be used in libcurl and curl.

And this is completely different than asking for an encrypted
connection and getting an unsecured one ;-)

I don't think that its an aberration to let lib/curl retry a
connection without TLS extensions, if when first tried with them the
connection has been remotely dropped. Most probably lib/curl user will
have no influence at all in forcing anyone to fix/upgrade their
deployed servers.

Ok, no matter what I've previously said, I told you that I could
change my opinion...

Now I'm ok with TLS extensions active as default, as long as there is
an option to disable all TLS extensions at once and simply use TLS 1.0
and when other extensions were introduced it would be nice to have
options to disable each TLS extension individually.

-- 
-=[Yang]=-