On Mon, Nov 27, 2000 at 08:11:17PM -0800, David Schwartz wrote:
>
> > Right. I want to ensure that the library does not choose KRB5 if the
> > library was compiled with KRB5 support but the server was not
> > configured for KRB5 use. (ie, no Kerberos 5 keytab file is provided)
>
> I have a similar issue. I'd like to be able to prefer 128-bit ciphers
> first, 168-bit ciphers second, and 56-bit ciphers lowest. Perhaps we can
> come up with one solution that meets both of our requirements. I'd suggest
> adding two hooks, one to control what ciphers are advertised to the client
> and one to select which common cipher is actually used.
Please let me clear up some points. I am describing the TLS protocol (RFC2246)
here with special regards to the OpenSSL implementation. I don't have a
clue about Kerberos :-)
- The client specifies the ciphers it is willing to use in the the
CipherSuite contained in the Client Hello message. This is the first
message the client sends. At this time it has not yet received any
information from the server. RFC2246, Section 7.4.1.2
- The CipherSuite sent from the client should be sorted:
The CipherSuite list, passed from the client to the server in the
client hello message, contains the combinations of cryptographic
algorithms supported by the client in order of the client's
preference (favorite choice first). (7.4.1.2)
- The server then selects one cipher from this CipherSuite. (7.4.1.2)
Results:
- The client is responsible for only advertising ciphers in the CipherSuite
it is willing to handle. It is also responsible to provide a sufficient
sorting with its preferences.
- An OpenSSL server (and probably most other servers) will strictly follow the
clients preference and choose the first cipher in the CipherSuite it matches.
This is not actually enforced by the standard. The standard requires that
the servers makes its choice, nowhere is written that the server must follow
the clients preferences. OpenSSL however has no means to change this
behaviour.
* An OpenSSL server has its own list of ciphers with a preference.
* It should be possible (with a new option) to change the choosing strategy
from "client preference" to "server preference".
* A completely free choice could be performed with a callback function.
This callback function would however have to access internal (that means
undocumented and maybe changing) structures inside the SSL library.
Maybe this idea is not too good.
- An OpenSSL server chooses the first cipher for which it has the necessary
data available: a certificate (if not ADH) and DH parameters, if necessary.
The SSL library does not check the verification state of the certificate
supplied. There are many reasons for a certificate to fail, not only
expiry as has been pointed out in this thread. For a complete check, the
complete CA chain would be needed and a complete check as performed in
ssl/ssl_cert.c:ssl_verify_cert_chain() would be needed.
(Actually, a setup of an X509_CTX and a call to X509_verify_cert().)
This could also be done by the application itself, but it is some effort
to spend. Maybe one would even need a special verify_callback for the
treatment of problems arising, as would be different from errors when
checking the peer's certificate.
[I develop Postfix/TLS and from my logfiles communicating with people
running Postfix/TLS and from communications about problems I now, that
such an "integrated check" would help a lot. The consistency of the
private key and certificate is already there with
SSL_CTX_check_private_key() but having a SSL_CTX_check_cert_chain()
might make tracking down problems much easier. This is not a promise
that I am going to write such a beast (at least not within a guaranteed
schedule :-).]
I hope this clarifies things a bit,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
