On Sun, Mar 19, 2000 at 07:51:38PM -0800, Claus Assmann wrote:
> I'm trying to write a server (using OpenSSL) that doesn't use
> patented algorithms, which means I have to restrict my server to
> TLSv1 or SSLv3 (right?), so I would like to use TLSv1 only, but
> then a "default" client (SSL23_method) does not talk to my server.
If you want to allow only TLSv1 in a server (which you actually don't
explicitly have to do if you want to avoid RSA -- configuring the
library with "no-rsa" is enough, as you can see by running "make test"
for the new beta release), you should use SSLv23_[server_]method and
disable the other protocol versions by setting the SSL_OP_NO_SSLv2
and/or SSL_OP_NO_SSLv3 options.
The reason is that only SSLv23_[server_]method includes support for
backward-compatible client hello messages (SSL 3.0 or TLS 1.0 in SSL 2
format, and TLS 1.0 in SSL 3.0 format; the latter did not work in
OpenSSL 0.9.4 or earlier, but should work now). If you use
TLSv1_[server_]method, the server will understand only pure TLS and
will not be able to communicate with clients that try to be
backward-compatible with older protocol versions, which is usually
the default for clients even though they may be able to speak TLS.
For clients, it's safe to use TLSv1_[client_]method if it's not
necessary to be able to interoperate with SSL 2 or SSL 3.0 servers.
This is because after the initial message from the client, both
parties know which exact procol version to use.
SSLv23_method always uses the SSL 2.0 format for client hello messages
(except when you're reusing an SSL object for an additional connection
-- this is because the object's method is changed when the protocol
version is negioated during the initial handshake), so it works only
with servers that either are SSL 2 servers or are backward-compatible
with the SSL 2 client hello format.
There *should* be a way to generate TLS 1.0 client hello messages
in the SSL 3.0 record format (the only difference is a version
byte in the record header), but this is not possible with OpenSSL
clients at the moment -- and it would be a problem because,
as noted above, earlier versions of the server were not able
to handle this case correctly.
> Is there a description which versions of TLS and SSL should be able
> to "talk" with each other? Here is my table of testing with openssl
> s_server/s_client; please let me know whether this is expected
> behaviour, and how I can solve my problem with "normal" clients.
>
> server tls1 ssl3 ssl2 no_tls1 no_ssl3 no_ssl2 default
> client
> tls1 + -1 -2 -1 + + +
> ssl3 -3 + -2 + -4 + +
> ssl2 -5 -5 + + + -4 +
> no_tls1 -6 -7 + + + + +
> no_ssl3 -6 -6 + -8 + + +
> no_ssl2 -9 -9 -8 + + + +
> default -9 -9 + + + + +
>
> Explanation: +: works, -: fails, the number referst to the list
> below, [...]
All this should be clear from the above explanation: tls1, ssl3, ssl2
servers accept only that one protocol; ssl2 can communicate with most
clients using SSLv23_[client_]method because such clients use the SSL
2 client hello data format. no_tls1, no_ssl3, no_ssl2 servers
are compatible with about everything; obviously the handshake
cannot succeed if the client speaks *only* the disabled protocol,
and the combination of a no_tls1 server and a no_ssl3 client fails
because the server has no way to know that the client, which uses
the SSL 2 data format to request a TLS 1.0 connection, does not
support SSL 3.0. (A more sensible client configuration
would be to combine no_tls1 and no_ssl3 instead of just using the latter.)
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
