7
$\begingroup$

In specific implementation we're using TLS 1.0, open ssl 0.9.8 but i'm referring to RFC 5246.

For performance reasons, I'm being asked if we can use TLS without encryption. The hope is that the perfomance cost of using TLS will be less. The implementation will retain authentication and integrity of communication, but there will be no confidentiality.

The RFC does seem to say in Appendix C that where we see 'SHA' in a cipher suite we should understand HMAC-SHA1. So I'd interpret the NULL_SHA in e,g, TLS_RSA_WITH_NULL_SHA as HMAC-SHA1 rather than a digest. In Section 6.2.3.1 we see that even with a NULL cipher a mac can be calculated. So in theory we can get integrity from TLS without encryption.

However, nobody seems to be using TLS this way, existing TLS tools (e.g. socat, openssl in default configurations) do not seem to want to negotiate null ciphers,

So my questions

  • Can TLS assure authentication and integrity with a NULL cipher ? Is this a reasonable optimisation to make, it seems to hold water but i'm not confident..
  • What is this optimisation likely to be worth ? The SHA must still be computed and HMAC'd even if AES-CBC is no longer calculated. I'm not sure how SHA compares to AES, can someone estimate what % reduction in operations there will be to calculate TLSCiphertext ? e.g could be we expect a 50% reduction in an SSL_write / SSL_read comapred to a TLS session with AES 256 encryption

Then some less important questions

  • the cipher suites in the RFC dont include a NULL cipher is the NULL cipher e.g. there's no DHE_RSA_NULL_SHA. Openssl headers e.g. tls1.h does provide for a lot of cipher suites with NULL ciphers which dont figure in the RFC. However, they dont get built into the configuration on my platform which may indicate this is not a normal things to use. Similarly tools like socat dont seem to negotiate cipher suites with null ciphers.. So I'm wondering if interoperability wise this kind of optimisation is thin ice even if the eco-system is partly controlled.
  • There's a load of stuff that doesnt get defined in the RFC, like what the possible values are for SecurityParameters.mac_algorithm, validating the MAC on incoming message. People implementing TLS have a more detailed standard or am i missing something ?
Improve this question
$\endgroup$
4
  • $\begingroup$ most processors accelerate AES but not SHA, so in terms of CPU usage the reduction by going to NULL cipher should be minimal unless you are maxing out a 10G ethernet card. AES-128 has 40% fewer computation resources compared to AES-256. $\endgroup$
    – Richie Frame
    Jan 21, 2014 at 10:22
  • $\begingroup$ is that acceleration done in the network hardware ? so i'd need to look at those hardware specs and check that driver implementation... this is an embedded platform.. in current tests, excluding connection / handshake, for non blocking sockets I meaure that for a given data size that TLS-DHE-RSA2048-AES256-SHA takes 3ms longer than a clear channel. E.g. clear protocol takes 300us, TLS 3300us. I'm measure that across an SSL_write to a non-blocking socket and I take the resulting time to include encryption, mac, handoff to hw but not the transmission time. $\endgroup$
    – dancl
    Jan 21, 2014 at 10:35
  • $\begingroup$ 1) How much data do you send per connection? For short connections the handshake cost will dominate. Switching to ECDHE-ECDSA should reduce the cost of the initial handshake. 2) Do both server and client support some form of session resumption? Session resumption allows you to omit the handshake when establishing multiple connections. 3) What CPU are you using? On CPUs with AES-NI, AES is very fast, consider using TLS 1.2 with AES-GCM on those CPUs. $\endgroup$
    – CodesInChaos
    Jan 21, 2014 at 12:23
  • $\begingroup$ CPU is arm7. I'm not worried about the handshake here, i agree with everything you say, there are things we can optimise in the handshake for sure and we need to study that too. The question applies to the communication after the handshake. Specifically, can we have integrity if there is no session encryption and is that a reasonable optimisation. $\endgroup$
    – dancl
    Jan 21, 2014 at 12:42

1 Answer 1

Reset to default
6
$\begingroup$

To answer your main question. Yes, NULL ciphersuites do provide authenticity and integrity checks but not confidentiality for the TLS traffic.

There is still a specified key exchange algorithm (e.g. RSA) for the TLS handshake protocol. The client will generate a pre-master secret and encrypt it with the server's public key for server authentication. The session key is then derived and the MAC keys are generated from it. Authentication of messages is provided by demostrating knowledge of the MAC keys.

However, the toolkit Openssl warns that NULL ciphersuites offer no encryption at all and are a security risk. They are disabled unless explicitly included.

RFC 4785 classifies them as authentication-only ciphersuites (with no encryption). Not sure about the your other question.

Improve this answer
$\endgroup$
1
  • $\begingroup$ ok trhanks, one of the other commenters mentioned AES hw acceleration is such that this is likely not a worthwhile optimisation and that made a lot of sense too $\endgroup$
    – dancl
    Jan 24, 2014 at 8:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.