65

Google Chrome is showing new information in the certificate section.

image

Is this a big deal? If so how can I fix it on the server end?

EDIT: Thanks for the answers but I'm not skilled in cryptography so the only thing I can update with is this certificate was created by Shell in a Box, and I was also wondering if this was ruining the security of TLS/SSL communication with the application and if so, how I could fix it.

IMcPwn
  • 813
  • 1
  • 7
  • 9
  • 1
    Consider: http://security.stackexchange.com/questions/76993/now-that-it-is-2015-what-ssl-tls-cipher-suites-should-be-used-in-a-high-securit – rook Mar 15 '15 at 20:16
  • 1
    This has been coined 'security shaming'. It made the Financial Times http://www.ft.com/cms/s/0/f53fe1ae-c98a-11e4-b2ef-00144feab7de.html – Colonel Panic Mar 18 '15 at 16:45
  • You may also see "The site is using outdated security settings that may prevent future versions of Chrome from being able to safely access it." – Colonel Panic Mar 18 '15 at 16:47

5 Answers5

55

Your exact case is that RSA is used as the key exchange mechanism. Instead, you should use DHE_RSA or ECDHE_RSA.

To remove the "obsolete cryptography" warning, you'll need to use "modern cryptography" which is defined as:

  • Protocol: TLS 1.2 or QUIC
  • Cipher: AES_128_GCM or CHACHA20_POLY1305
  • Key exchange: DHE_RSA or ECDHE_RSA or ECDHE_ECDSA

Twitter discussion: https://twitter.com/reschly/status/534956038353477632

Commit: https://codereview.chromium.org/703143003

This has nothing to do with a certificate. There is a special "outdated security settings" warning when a certificate uses weak signature algorithm, but this is about authentication, not about encryption. Note that you are still getting a green lock, even in case of obsolete encryption.

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
Adm Selec
  • 666
  • 5
  • 4
  • 1
    So how do I generate my private/public keys using ECDHE_RSA? I'm getting the same error as OP, and I'm using this command to generate my keys `openssl req -x509 -newkey rsa:2048 -sha256 -keyout a.key -out a.crt -days 1000 -nodes -subj "..."`. I'm guessing I need to change the rsa:2048 param, but I can't find what I should be changing it to. – Rob May 04 '15 at 15:16
  • 16
    @Rob You do not need to generate new keys - you just have to modify some server settings to allow clients to use at least one of the listed ciphersuites. In apache, this can be done in your VirtualHost configuration file. There is an SSL config generator you can use to make this easier: https://mozilla.github.io/server-side-tls/ssl-config-generator/ – tlng05 May 06 '15 at 16:45
  • Hey! Thanks for your response! That makes a lot of sense since I didn't understand why the certificate would be the one to dictate this. Unfortunately, I'm not using Apache, I'm using my own web server which is based off of Civetweb, so I'll have to look into that! – Rob May 07 '15 at 19:03
  • Note for Tomcat, to change from AES_256_CBC to AES_128_GCM you'll have to upgrade from Java 7 to Java 8. See this answer: http://stackoverflow.com/a/21290409/57752 – Eddie Jul 02 '15 at 00:57
  • My understanding is that certificates vouch that a public key belongs to a certain entity. If you are going to change from RSA to, say, DHE_RSA, wouldn't the server need a DHE_RSA public key and thus a new certificate that will vouch for this new public key? – Kevin Wheeler Sep 08 '15 at 19:13
  • 2
    @Eddie Going from a 256 bit key to a 128 bit key seems like a big downgrade, why isn't 256 CBC just as good or better? – Michael Dec 01 '15 at 05:59
  • 2
    Windows: from https://www.nartac.com/Support/IISCrypto/FAQ ... your website is using obsolete cryptography if the cipher suite does not support forward secrecy and authenticated encryption (AEAD). The only two cipher suites that support this on Windows using RSA certificates are TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256. Unfortunately those cipher suites use 1024 bits for their Diffie-Hellman parameters which has long been considered weak. The only way to get rid of this warning is to use DSA certificates or wait until Windows 10 Server is released... – Matt Kemp Jan 12 '16 at 21:29
  • @Michael With a modern block cipher (e.g. AES), 128-bit keys are _good enough_ (in the sense that a brute-force attack is utterly infeasible). 256-bit keys just waste electricity and CPU time. This will change if quantum computers become practical, but we can worry about that then. Changing from CBC to GCM, however, really does increase your security. GCM is a newer, better-designed [mode of operation](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation) which avoids several known weaknesses in CBC (as used by TLS). – zwol Mar 30 '16 at 14:28
7

That message probably indicates you're

  • Using SSLv3, or
  • Have a certificate signed with SHA-1 or MD5

According to this page. The former is a configuration issue, the latter require you to get a certificate signed with a SHA-256 hash.

Community
  • 1
gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 2
    The image says that "The connection uses TLS 1.2.". –  Mar 16 '15 at 00:31
  • 8
    OP can rule out SSLv3. Anybody else who finds this because they're searching for that error message might not be able to, so it's worth mentioning. – gowenfawr Mar 16 '15 at 12:38
  • 1
    Your answer unfortunately is wrong. As Ricky Demer said you can see that the connection uses TLS 1.2. And if the server uses a certificate with an old SHA-1 hash Chrome tells you about this in another place. – HorstKevin Sep 03 '15 at 11:12
5

I had the same issue and used this free service to get a: SSL report.

The report scans your SSL configuration and tells you:

  • Information about the certificate (Common names, valid dates, key size, signature algorithm, issuer, ...)
  • Certification path
  • Enabled protocols (making sure SSL 2 and SSL 3 are disabled)
  • Cipher suites supported (where you can see what should be disabled)
  • Handshake simulations for different browsers and OS.
  • Protocol details (are you vulnerable ?)

It helped me get information about how my configuration was set, what could be improved or disabled and I ended up modifying the ssl_cipher directive from Nginx to support the Intermediate compatibility.

Maxime
  • 151
  • 3
2

Since the protocol version is good and AES_128-GCM is certainly not obsolete the remaining possibility is that something is wrong with the RSA key exchange. I'm not sure what google chrome understands as obsolete, but just the fact that key exchange is performed using RSA is not particularly good. Preferably RSA should only be used for authentication and the key exchange should be performed using DHE or ECDHE.

As someone pointed out you might also be having a problem with your certificate which is either signed with a bad hash function or the key might be too short (512 bits?) the latter is not very probably though.

DRF
  • 384
  • 3
  • 7
  • Good deduction. It is the KEX_RSA bit they don't like. However, I am surprised that PFS's "hackable in next round of LogJam" is so universally considered better than RSA's "hackable if server loses certificate in future". – user185953 Apr 24 '19 at 13:20
0

You can use openssl s_client -connect <server_name>:443 from linux to see the ssl handshake. Check the Peer signing digest, protocol, and cipher. Usally chrome has more details about the obselete configurations, you can try to update. Check if algorithm hash, ciphers, protocol are modern. 

No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4499 bytes and written 415 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: <id>
    Session-ID-ctx:
    Master-Key: <key>
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1579360646
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

Note: Openssl v 1.1.1 may fail to connect to server if the Peer signing digest: SHA1, you can try to reduce the security in /etc/ssl/openssl.cfn or /etc/pki/tls/openssl.cnf by setting the CipherString = DEFAULT@SECLEVEL = 1 and try again. With openssl you can set -ciphers -sigalgs and more to debug.

TicJit
  • 135
  • 6