Which algorithm is stronger for TLS:AES-256 or Camellia-256?




(4)

The OpenSSL cipherlist TLSv1:+HIGH is a really bad choice. The "+something" notation means move all the ciphers that match "something" to the end of the list. Therefore, you're using HIGH only as a last resort, with anything that's not HIGH preferred.

A much better choice is "DEFAULT:!MEDIUM:!LOW:!EXPORT:+3DES", which starts with sensible defaults, removes MEDIUM, LOW and EXPORT, and uses 3DES last (which it probably is anyway, but on some systems it comes before AES128 because it may be considered to be 168-bit strong).

Introduction: For my personal webserver I have setup apache with a self signed certificate to enable TLS security to learn and test. I have this line in virtualhost:

SSLProtocol -all -SSLv3 +TLSv1  
SSLCipherSuite TLSv1:+HIGH:!MEDIUM

With firefox, I get Camellia-256 encrypted connection, and with opera I get TLS v1.0 256 bit AES (1024 bit DHE_RSA/SHA) with the same config in same server.

That leads me to question, which is stronger, AES, or Camellia?

I noticed that if I disable camellia with SSLCipherSuite TLSv1:+HIGH:!MEDIUM:!CAMELLIA then, firefox takes the same suite than opera.

In my config, I also try to disable all SSL versions to enable only TLS (advise needed if I didn't do so correctly), but the original question still stands: Which one should be stronger?


It's hard to judge the strength of these algorithms. Camellia is considered roughly equivalent to AES in security (source). In any case, the difference probably won't matter. Either algorithm is secure enough to make your data channel no longer be the weakest link in your system, so you don't need to bother modifying any configuration.


I would be more worried about the fact that your SSL encryption is not secure because you are only using 1024 bit asymmetric encryption to protect your keys.

Adi Shamir (the 'S' in RSA) recommended moving to 2048 bit keys back in 2006, even the american standards institute (NIST) have made 2048 bit a required minimum strength since January 2011 (see NIST SP800-57 for recommended minumum key strengths -- this states 2048 bit for both RSA and DH/el-gamal).

In short, make sure your RSA encryption is strong enough first, as it is used to protect the symmetric keys (AES/Camellia). Never rely on a key which is protected by a weaker key (this is like using a secure 256 bit random WPA 2 key on a wireless access point and then trusting it to WPS which will reveal in in a few hours!)

Even if this is a test system, learn to use crypto the way you intend to go forward; do not compromise on certificate key strength (all CAs these days should reject 1024 bit requests or CSRs using MD5 on sight, if not don't use them; create your own test certs as you would a real request, and don't use default key sizes).

Difficult to compare strengths, both have received cryptographic analysis (AES more publicly) and are adequate for securing data.

At the risk of repeating myself, I’d be more worried about the 1024 bits used to secure the key negotiation.


Obsolete cryptography warning from Browser

From https://www.chromium.org/Home/chromium-security/education/tls#TOC-Deprecation-of-TLS-Features-Algorithms-in-Chrome

Obsolete Cipher Suites

You may see:

“Your connection to example.com is encrypted with obsolete cryptography.”

This means that the connection to the current website is using an outdated cipher suite (which Chrome still allows if the server insists on it).

In order for the message to indicate “modern cryptography”, the connection should use forward secrecy and either AES-GCM or CHACHA20_POLY1305. Other cipher suites are known to have weaknesses. Most servers will wish to negotiate TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

All this boils down to the following lines in your configuration, that determine which cipher suites are supported and prioritized for connections with clients.

SSLProtocol
SSLCipherSuite
SSLHonorCipherOrder

Per https://certsimple.com/blog/chrome-outdated-cryptography and https://mozilla.github.io/server-side-tls/ssl-config-generator/, you may want to give this a try:

SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder     on

See also:

[1] https://mozilla.github.io/server-side-tls/ssl-config-generator/ - Suggests security configurations

[2] https://www.ssllabs.com/ssltest/index.html -- Test your server's SSL configuration