2

Update : (Accepted an answer and updated the question with useful links at the bottom)

Using

  • Java 7
    • Jetty server (Embedded)
    • Self Signed certificate installed on the server. Generated using the command:

      keytool -genkey -keyalg RSA -sigalg SHA256withRSA -alias selfsigned -keystore mykeystore.jks -validity 360 -keysize 2048

    • Chrome Browser as the client

enter image description here

The Certificate shows this when I view its details :

Certificate fingerprints: MD5: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX SHA1: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX SHA256: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Signature algorithm name: SHA256withRSA Version: 3

I have also done the following on the jetty side to ensure that I exclude some bad CipherSuites and avoid SSLV3 protocol (since chrome phased out SSLV3 due to recent POODLE attacks) :

            sslContextFactory.setIncludeCipherSuites(new String[] {
                    "TLS_DHE_RSA.*", "TLS_ECDHE.*", });
            sslContextFactory.setExcludeCipherSuites(new String[] { ".*NULL.*",
                    ".*RC4.*", ".*MD5.*", ".*DES.*", ".*DSS.*" });
            sslContextFactory.setExcludeProtocols(new String[] { "SSLv3" });
            sslContextFactory.setRenegotiationAllowed(false);

What am I missing here ?

What should be done to ensure that chrome doesn't complain with obsolete cryptography ?

I have digged into chromium code base to see this ? But I could not figure out the reason yet.

Chrome checks for the following before setting the obsolete cryptography message.


if (net::SSLConnectionStatusToVersion(ssl.connection_status) >=
        net::SSL_CONNECTION_VERSION_TLS1_2 &&
    net::IsSecureTLSCipherSuite(
        net::SSLConnectionStatusToCipherSuite(ssl.connection_status))) {
  site_connection_details_.assign(l10n_util::GetStringFUTF16(
      IDS_PAGE_INFO_SECURITY_TAB_ENCRYPTED_CONNECTION_TEXT,
      subject_name));
} else {
  site_connection_details_.assign(l10n_util::GetStringFUTF16(
      IDS_PAGE_INFO_SECURITY_TAB_WEAK_ENCRYPTION_CONNECTION_TEXT,
      subject_name));
}

bool IsSecureTLSCipherSuite(uint16 cipher_suite) {
  int key_exchange, cipher, mac;
  if (!GetCipherProperties(cipher_suite, &key_exchange, &cipher, &mac))
    return false;

  // Only allow forward secure key exchanges.
  switch (key_exchange) {
    case 10:  // DHE_RSA
    case 14:  // ECDHE_ECDSA
    case 16:  // ECDHE_RSA
      break;
    default:
      return false;
  }

  switch (cipher) {
    case 13:  // AES_128_GCM
    case 14:  // AES_256_GCM
    case 17:  // CHACHA20_POLY1305
      break;
    default:
      return false;
  }

  // Only AEADs allowed.
  if (mac != kAEADMACValue)
    return false;

  return true;
}

Useful links

Community
  • 1
  • 1
acthota
  • 557
  • 5
  • 22
  • 1
    http://goo.gl/LLgCjR, http://goo.gl/ueVl0e - Chromium Codebase – acthota Apr 12 '15 at 08:08
  • 1
    Update : Tried with a 4096 sized key as well. Still chrome says the same. – acthota Apr 12 '15 at 08:13
  • Edited to add java version in the environment I use. – acthota Apr 12 '15 at 09:58
  • 1
    It's the `SHA1`. You should use `SHA256` for message authentication. – Boris the Spider Apr 12 '15 at 16:35
  • 1
    @BoristheSpider : Any idea how I can avoid that ?.. -sigalg SHA256withRSA ... This is what I use in the keytool command.... Shall I explicitly exclude all CipherSuites that have SHA1 in the Jetty SSL Configuration ? What determines which algo is used for message auth ? – acthota Apr 12 '15 at 16:37
  • I will say what I said last time, read [this](http://security.stackexchange.com/questions/71330/jsse-recommended-cipher-suites). – Boris the Spider Apr 12 '15 at 16:37
  • Ok. Will do that. Did not read it fully yet. Thanks for the link. – acthota Apr 12 '15 at 16:39
  • @BoristheSpider : doing an sslscan showed that.. Accepted TLSv1 256 bits ECDHE-RSA-AES256-SHA Accepted TLSv1 256 bits DHE-RSA-AES256-SHA Accepted TLSv1 128 bits ECDHE-RSA-AES128-SHA Accepted TLSv1 128 bits DHE-RSA-AES128-SHA (Continued) – acthota Apr 12 '15 at 17:16
  • (continuation) Then I explicit took out the suites containing 128... Then the server is not able to negotiate SSL at all... I am on Java 7, 9.2.x Jetty. Need to explore further – acthota Apr 12 '15 at 17:17
  • I suppose you haven't installed the [Unlimited Strength Jurisdiction Policy Files](http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.htmlhttp://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html)? – Boris the Spider Apr 12 '15 at 17:20
  • 1
    I did. I have been using 256 bit keys for a long time. – acthota Apr 12 '15 at 17:48
  • @All : Accepted an answer and updated the question with useful links at the bottom – acthota Apr 13 '15 at 10:56

1 Answers1

3

As you pointed out in the code, toy need to use AES_128_GCM, AES_256_GCM or CHACHA20_POLY1305 as the cipher for the cryptography to be considered modern. This has nothing to do with the certificate but with the server configuration.

Chrome actually doesn't support AES_256_GCM yet, and java doesn't support CHACHA20_POLY1305 yet. Even AES_128_GCM is only supported in java 8. If you're not using java 8, "modern" cryptography isn't included by default. If you are using java 8, the jetty documentation explains how to configure the cipher suites.

If you don't have java 8, it seems you can use Bouncy Castle, set up as a provider (http://www.bouncycastle.org/wiki/display/JA1/Provider+Installation) to enable cipher suites using GCM. I haven't tested it myself though.

user2313067
  • 593
  • 1
  • 3
  • 8
  • 1
    Thanks for the answer. So, you are saying that it "might" be impossible to fix this if we are using Java 7 since cryptography support in Java doesn't support modern cryptography (in the eyes of chrome browser)... AKA.. ciphers with authentication and 256 bit key support (correct me if I' m incorrect) ? .... [All] : Can other experts in the field and those who have tried setting up SSL on JAVA 7 and JETTY SERVER corroborate this ? – acthota Apr 12 '15 at 15:31
  • 1
    @acthota After some searching, it seems Bouncy Castle provides support for older java versions. I have edited my answer accordingly. – user2313067 Apr 12 '15 at 19:26
  • @All : [ACCEPTANCE COMMENT] : The Official chrome link says : You may be seeing the message "Your connection to example.com is encrypted with obsolete cryptography." This usually means that the connection to the current website is using an outdated ciphersuite. [CONTINUED] – acthota Apr 13 '15 at 10:42
  • [CONTINUATION] The CipherSuites section in this link (http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider) also clearly shows that there are no GCM CipherSuites supported in Java 7. This answer (http://stackoverflow.com/questions/21289293/java-7-support-of-aes-gcm-in-ssl-tls) also seems to suggest the same. – acthota Apr 13 '15 at 10:45
  • Please incorporate my comments / links above in your answer if you think it will make it comprehensive. Accepting your answer. Thanks for your time. (Unable to upvote your answer since I do not have enough reputation :( ) – acthota Apr 13 '15 at 10:48
  • Got the reputation :) – acthota Apr 13 '15 at 10:56