> From: owner-openssl-us...@openssl.org On Behalf Of Erik Norgaard > Sent: Friday, 21 August, 2009 04:22
> I have been asked to study the possibility of using for > authentication without encryption, ie using TLS_RSA_WITH_NULL_SHA. > > Reading the RFC5246, it appears that the server > authentication is only possible through key negotiation, so, > for this to work, an encrypted connection would be > established, and then send a Change Cipher Spec message to > disable encryption? > I haven't gone through 5246 yet, but assuming this hasn't changed from 4346 1.1: sort of. Yes you must do the handshake and agree a master secret. Normally that master secret is used to derive separate session/working keys for encryption and authentication; if encryption is null, then only authentication is done. There is never an encrypted _connection_ until ChangeCipherSpec at the end of the handshake (or specifically the first handshake). Certain handshake steps individually are encrypted and/or signed; for RSA-keyagreement, the client to server premaster is RSA-encrypted. ChangeCipherSpec begins use of the negotiated suite; in this case the negotiated suite has null encryption, so it does not begin encrypting. It does allow sending data, with authentication, as you asked for. > Using TLS_RSA_WITH_NULL_SHA, does this ensure the subsequent > messages (application data) are authenticated as well, or > will it only ensure integrity? > Depends on exactly what you mean. It ensures integrity of the message _stream_ (prefix) -- i.e. all data received was HMACed in sequence by someone (else) with the shared session secret, which is only the party we completed the handshake with (unless they are compromised, which is outside the scope of comms security). How well you authenticated that party during handshaking is partly up to you. openssl checks that their cert verifies under (possibly indirectly) a CAcert you say you trust, and isn't expired, and possibly that it hasn't been revoked by the CA (I haven't used that part). openssl doesn't try to decide anything about whether the CA's practice is right (for you) including whether the cert correctly identifies the party. (And the possibility the CA was tricked by the now practical MD5 collision attack or I believe borderline SHA1 one.) ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
