Each of the three guarantees that SSL/TLS can make -- authentication,
data secrecy, and message integrity -- are completely independent from
each other.

Authentication comes from having an X.509 certificate issued by a
trusted root that has not been revoked.  (Or through other mechanism,
but X.509 is by far the most widely-deployed).

Data secrecy can be negotiated through the use of an ephemeral
Diffie-Hellmann key exchange -- neither party has a certificate, but
they both know how to perform the DH protocol, so they use that.

Message integrity is simply a matter of applying an MD5 (not
recommended) or SHA1 (also not recommended, but still more secure than
MD5 at the moment) to the data.  That integrity is checked by
validating the hash of the received data in the packet against the
hash that identifies the content of the packet.  If the hash matches,
message integrity has not been violated.  If the hash doesn't match,
message integrity has been violated, and the connection is terminated.

Note that the *NULL ciphers are not enabled by default because the
principle of least intelligence states that users will forget to
disable weaker ciphers; so, you need to explictly add them to the
cipher list.  But, as has been mentioned before, premature
optimization is the root of all evil.  Write the code, determine the
bottlenecks with a profiler, and optimize them.  Most of the time
you'll find the bottlenecks aren't in the SSL/TLS layer at all.

Oh... and all of these operations are supported by the BIO, SSL, and
SSL_CTX interfaces.

Cheers!

-Kyle H

On 5/14/06, gmu 2k6 <[EMAIL PROTECTED]> wrote:
great, so I can do full bi-directional authentication of server and client
cert but if someone insists on streaming performance being too slow
they can configure it so that I use eNULL without changing the rest of
the BIO operations. sounds nice if this is possible.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to