Brief primer on SSL/TLS: 1) Server has a public and private key pair. Optionally, the client has a public and private key pair. Any public key is authenticated by a 'certificate', which is a set of data attached to the public key, the entirety of which has a hash encrypted by the private key of a trusted third party. 2) [Different versions of the protocol modify this part; this is a 10,000 foot view] On connection, server sends client its certificate (and perhaps a random number encrypted with its private key that the client can decrypt with the public key in the certificate). Client decrypts the random number, generates its own random number, and encrypts that with the server's public key (perhaps combining it with the server's random number in some fashion), and sends it back. [this assumes that the client trusts the signer of the certificate.] 3) Server decrypts what the client sent, removes its own randomness, and uses this as the generator for the base key for the session. (if the client sends information that the server can't decrypt, then the server doesn't have the private key for the certificate that it has presented.) The client already has this knowledge, so it has already generated this key. 4) Server can optionally ask the client to authenticate itself, by essentially performing the exchange in reverse. 5) In this exchange, there is also a list of "cipher suites" that are acceptable to each side. The cipher suite chosen is the highest-security one that both sides support. (Highest-security means 'highest bulk cipher bit security'.) The generated keys (from step 3) are used for bulk cipher encryption, as well as being the means of encrypting the message authentication code for verification. 6) It's possible (and, indeed, legally necessary in France) for there to be no bulk cipher applied; in this case, the generated key material from step 3 is used only for message authentication, to show that it actually came from the other side and wasn't injected into the TCP stream.
The hashing occurs regardless of whether there's a bulk cipher in use. A bulk cipher only adds a little bit of overhead to the end, just before the data is transmitted and as soon as the data is received. In France (unless the laws have changed) it's illegal to use cryptography to encrypt data payload, but not illegal to use cryptography as a means of identification. This is, if I understand Netscape's and the IETF's motives correctly, the only reason why the NULL cipher suites exist in the SSL/TLS specifications. -Kyle H ...who now waits for other people to nitpick over the details of his explanation, since it's based primarily on SSL2 and 3, and not TLS. On 1/24/06, Alain Damiral <[EMAIL PROTECTED]> wrote: > Hi and welcome, > > I haven't thought hardly about what you're trying to do but my first > intuition tells me that encryption also has some part to play in > authentication that you're missing. My knowledge of SSL is limited but I > think it is safe to say that private/public key (assymetric) encryption > is used to guarantee certificate authenticity, and to agree on the > secret (symetric) key that will be used for the actual communication. > > If you use no secret key, you have no guarantee that the guy you're > talking with really is the same guy that you did your handshake with > (who showed you his certificate and knows the shared secret). So even if > you don't want your data encrypted, there must be some signature for > each message sent to guarantee authenticity, based on that shared secret. > > So if what I said is correct, even if you don't use encryption you will > still need a signature of each message - probably in the form of a > cryptographic hash based on the shared secret. I'm really not sure that > such an operation is significantly cheaper than symmetric encryption. > > > > Urjit Gokhale wrote: > > > Hi all, > > > > I am planning to use SSL for the communication between my client and > > server. The idea is to use SSL *mainly* for peer authentication and > > validation (Both server and client authentication by means of > > certificates). Regarding the data encryption, I would like to have it > > as an optional feature. > > > > The motivation behind this desirable feature is that in a particular > > environment, I am not really worried about the data, but the client > > talking to my server. I would like to give up on encryption in favor > > of performance. > > > > So the questions are: > > 1) Is it possible to use SSL only for the sake of peer authentication > > + validation and transfer un-encrypted data over this channel ? > > > > 2) Would sacrificing on encryption *really* improve the performance ? > > > > Thanks, > > > > ~ Urjit > > > > PS: This is my first mail to this list. So, in case, you think that my > > questions are out of the scope of this group, or you know of some > > other group which can yield me better answers, could you please point > > me to such groups ? > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
