Which Cipher Suites to enable for SSL Socket?
Asked Answered
V

3

21

I'm using Java's SSLSocket to secure communications between a client and a server program. The server program also serves up HTTPS requests from web browsers.

According to "Beginning Cryptography with Java", page 371, you should always call setEnabledCipherSuites on your SSLSocket / SSLServerSocket to ensure that the cipher suite that ends up being negotiated is sufficiently strong for your purposes.

That being said, a call to my SSLSocketFactory's getDefaultCipherSuites method yields some 180 options. These options range from TLS_RSA_WITH_AES_256_CBC_SHA (which I think is fairly secure) to SSL_RSA_WITH_RC4_128_MD5 (not so sure if that's secure, given MD5's current status) to SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (not entirely sure what that does).

What's a sensible list of cipher suites to restrict the sockets to?

Note that the client and server have access to the Bouncy Castle service provider, and that they may or may not have unlimited cryptographic policy files installed.

Vitavitaceous answered 24/6, 2009 at 10:41 Comment(3)
TLS_RSA_WITH_AES_256_CBC_SHA ... - you should probably avoid the RSA key transport schemes (or place them at the bottom of your advertised list). Instead, favor the ephemeral key exchanges, like DHE, for forward secrecy. In fact, TLS 1.3 is discussing their removal because they lack the property.Upraise
SSL_RSA_WITH_RC4_128_MD5 ... - RC4 is the problem child now. See On the Security of RC4 in TLS and WPA. An attacker probably cannot forge a HMAC-MD5 signature in the network's 2MSL time window. However, an attacker can statistically correlate bits in the cipher stream. (And MD5 is dead for long term use, like certificates and digital signatures).Upraise
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA ... - burn it. Avoid it like the plague.Upraise
E
7

Don't use anything with export in it. That's crippleware due to export restrictions on strong cryptography.

EDIT: Changed to use 2009 document.

A 2009 NIST recommendation lists the following, incluing TLS_RSA_WITH_AES_256_CBC_SHA (which you mentioned):

TLS_RSA_WITH_NULL_SHA (don't use this unless you're sure you don't need any privacy/confidentiality).

TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_PSK_WITH_3DES_EDE_CBC_SHA
TLS_PSK_WITH_AES_128_CBC_SHA
TLS_PSK_WITH_AES_256_CBC_SHA
TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA
TLS_DHE_PSK_WITH_AES_128_CBC_SHA
TLS_DHE_PSK_WITH_AES_256_CBC_SHA
TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA
TLS_RSA_PSK_WITH_AES_128_CBC_SHA
TLS_RSA_PSK_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 
Extensive answered 24/6, 2009 at 11:11 Comment(4)
I'm a bit confused about TLS_RSA_WITH_NULL_SHA - doesn't that specify no encryption? In this context does this mean no or any encryption?Vitavitaceous
Zarkonnen, I think you're correct that TLS_RSA_WITH_NULL_SHA means no encryption. p. 34 of the draft I linked says NULL encryption is for, "cases where integrity protection is required but not encryption."Extensive
I doubt he needs Preshared Key (PSK) ciphers like TLS_PSK_WITH_3DES_EDE_CBC_SHA. TLS_RSA_WITH_AES_256_CBC_SHA uses RSA key transport. He should probably be using DHE or ECDHE for forward secrecy.Upraise
A good explanation of the subparts of the cipher suite specification and what you should avoid is here: blog.eveoh.nl/2014/02/tls-ssl-ciphers-pfs-tomcatPrevaricator
U
19

Below is the Java class I use to enforce cipher suites and protocols. Prior to SSLSocketFactoryEx, I was modifying properties on the SSLSocket when I had access to them. The Java folks on Stack Overflow helped with it, so its nice to be able to post it here.

SSLSocketFactoryEx prefers stronger cipher suites (like ECDHE and DHE), and it omits weak and wounded cipher suites (like RC4 and MD5). It does have to enable four RSA key transport ciphers for interop with Google and Microsoft when TLS 1.2 is not available. They are TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA and two friends. If possible, you should remove the TLS_RSA_* key transport schemes.

Keep the cipher suite list as small as possible. If you advertise all available ciphers (similar to Flaschen's list), then your list will be 80+. That takes up 160 bytes in the ClientHello, and it can cause some appliances to fail because they have a small, fixed-size buffer for processing the ClientHello. Broken appliances include F5 and Ironport.

In practice, the list in the code below is paired down to 10 or 15 cipher suites once the preferred list intersects with Java's supported cipher suites. For example, here's the list I get when preparing to connect or microsoft.com or google.com with an unlimited JCE policy in place:

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
  • TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_DSS_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA

The list omits weak/wounded algorithms, like RC4 and MD5. If they are enabled, then you will likely get a Obsolete cryptography warning from Browser on occasion.

The list will be smaller with the default JCE policy because the policy removes AES-256 and some others. I think its about 7 cipher suites with the restricted policy.

The SSLSocketFactoryEx class also ensures protocols TLS 1.0 and above are used. Java clients prior to Java 8 disable TLS 1.1 and 1.2. SSLContext.getInstance("TLS") will also sneak in SSLv3 (even in Java 8), so steps have to be taken to remove it.

Finally, the class below is TLS 1.3 aware, so it should work when the provider makes them available. The *_CHACHA20_POLY1305 cipher suites are preferred if available because they are so much faster than some of the current suites and they have better security properties. Google has already rolled it out on its servers. I'm not sure when Oracle will provide them. OpenSSL will provide them with OpenSSL 1.0.2 1.1.0.

You can use it like so:

URL url = new URL("https://www.google.com:443");
HttpsURLConnection connection = (HttpsURLConnection) url.openConnection();

SSLSocketFactoryEx factory = new SSLSocketFactoryEx();
connection.setSSLSocketFactory(factory);
connection.setRequestProperty("charset", "utf-8");

InputStream input = connection.getInputStream();
InputStreamReader reader = new InputStreamReader(input, "utf-8");
BufferedReader buffer = new BufferedReader(reader);
...

class SSLSocketFactoryEx extends SSLSocketFactory
{
    public SSLSocketFactoryEx() throws NoSuchAlgorithmException, KeyManagementException
    {
        initSSLSocketFactoryEx(null,null,null);
    }

    public SSLSocketFactoryEx(KeyManager[] km, TrustManager[] tm, SecureRandom random) throws NoSuchAlgorithmException, KeyManagementException
    {
        initSSLSocketFactoryEx(km, tm, random);
    }

    public SSLSocketFactoryEx(SSLContext ctx) throws NoSuchAlgorithmException, KeyManagementException
    {
        initSSLSocketFactoryEx(ctx);
    }

    public String[] getDefaultCipherSuites()
    {
        return m_ciphers;
    }

    public String[] getSupportedCipherSuites()
    {
        return m_ciphers;
    }

    public String[] getDefaultProtocols()
    {
        return m_protocols;
    }

    public String[] getSupportedProtocols()
    {
        return m_protocols;
    }

    public Socket createSocket(Socket s, String host, int port, boolean autoClose) throws IOException
    {
        SSLSocketFactory factory = m_ctx.getSocketFactory();
        SSLSocket ss = (SSLSocket)factory.createSocket(s, host, port, autoClose);

        ss.setEnabledProtocols(m_protocols);
        ss.setEnabledCipherSuites(m_ciphers);

        return ss;
    }

    public Socket createSocket(InetAddress address, int port, InetAddress localAddress, int localPort) throws IOException
    {
        SSLSocketFactory factory = m_ctx.getSocketFactory();
        SSLSocket ss = (SSLSocket)factory.createSocket(address, port, localAddress, localPort);

        ss.setEnabledProtocols(m_protocols);
        ss.setEnabledCipherSuites(m_ciphers);

        return ss;
    }

    public Socket createSocket(String host, int port, InetAddress localHost, int localPort) throws IOException
    {
        SSLSocketFactory factory = m_ctx.getSocketFactory();
        SSLSocket ss = (SSLSocket)factory.createSocket(host, port, localHost, localPort);

        ss.setEnabledProtocols(m_protocols);
        ss.setEnabledCipherSuites(m_ciphers);

        return ss;
    }

    public Socket createSocket(InetAddress host, int port) throws IOException
    {
        SSLSocketFactory factory = m_ctx.getSocketFactory();
        SSLSocket ss = (SSLSocket)factory.createSocket(host, port);

        ss.setEnabledProtocols(m_protocols);
        ss.setEnabledCipherSuites(m_ciphers);

        return ss;
    }

    public Socket createSocket(String host, int port) throws IOException
    {
        SSLSocketFactory factory = m_ctx.getSocketFactory();
        SSLSocket ss = (SSLSocket)factory.createSocket(host, port);

        ss.setEnabledProtocols(m_protocols);
        ss.setEnabledCipherSuites(m_ciphers);

        return ss;
    }

    private void initSSLSocketFactoryEx(KeyManager[] km, TrustManager[] tm, SecureRandom random)
    throws NoSuchAlgorithmException, KeyManagementException
    {
        m_ctx = SSLContext.getInstance("TLS");
        m_ctx.init(km, tm, random);

        m_protocols = GetProtocolList();
        m_ciphers = GetCipherList();
    }

    private void initSSLSocketFactoryEx(SSLContext ctx)
    throws NoSuchAlgorithmException, KeyManagementException
    {
        m_ctx = ctx;

        m_protocols = GetProtocolList();
        m_ciphers = GetCipherList();
    }

    protected String[] GetProtocolList()
    {
        String[] preferredProtocols = { "TLSv1", "TLSv1.1", "TLSv1.2", "TLSv1.3" };
        String[] availableProtocols = null;

        SSLSocket socket = null;

        try
        {
            SSLSocketFactory factory = m_ctx.getSocketFactory();
            socket = (SSLSocket)factory.createSocket();

            availableProtocols = socket.getSupportedProtocols();
            Arrays.sort(availableProtocols);
        }
        catch(Exception e)
        {
            return new String[]{ "TLSv1" };
        }
        finally
        {
            if(socket != null)
                socket.close();
        }

        List<String> aa = new ArrayList<String>();
        for(int i = 0; i < preferredProtocols.length; i++)
        {
            int idx = Arrays.binarySearch(availableProtocols, preferredProtocols[i]);
            if(idx >= 0)
                aa.add(preferredProtocols[i]);
        }

        return aa.toArray(new String[0]);
    }

    protected String[] GetCipherList()
    {
        String[] preferredCiphers = {

            // *_CHACHA20_POLY1305 are 3x to 4x faster than existing cipher suites.
            //   http://googleonlinesecurity.blogspot.com/2014/04/speeding-up-and-strengthening-https.html
            // Use them if available. Normative names can be found at (TLS spec depends on IPSec spec):
            //   http://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305-01
            //   http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-02
            "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305",
            "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305",
            "TLS_ECDHE_ECDSA_WITH_CHACHA20_SHA",
            "TLS_ECDHE_RSA_WITH_CHACHA20_SHA",

            "TLS_DHE_RSA_WITH_CHACHA20_POLY1305",
            "TLS_RSA_WITH_CHACHA20_POLY1305",
            "TLS_DHE_RSA_WITH_CHACHA20_SHA",
            "TLS_RSA_WITH_CHACHA20_SHA",

            // Done with bleeding edge, back to TLS v1.2 and below
            "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
            "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384",
            "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
            "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",

            "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
            "TLS_DHE_DSS_WITH_AES_256_GCM_SHA384",
            "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
            "TLS_DHE_DSS_WITH_AES_128_GCM_SHA256",

            // TLS v1.0 (with some SSLv3 interop)
            "TLS_DHE_RSA_WITH_AES_256_CBC_SHA384",
            "TLS_DHE_DSS_WITH_AES_256_CBC_SHA256",
            "TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
            "TLS_DHE_DSS_WITH_AES_128_CBC_SHA",

            "TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
            "TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA",
            "SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA",
            "SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA",

            // RSA key transport sucks, but they are needed as a fallback.
            // For example, microsoft.com fails under all versions of TLS
            // if they are not included. If only TLS 1.0 is available at
            // the client, then google.com will fail too. TLS v1.3 is
            // trying to deprecate them, so it will be interesteng to see
            // what happens.
            "TLS_RSA_WITH_AES_256_CBC_SHA256",
            "TLS_RSA_WITH_AES_256_CBC_SHA",
            "TLS_RSA_WITH_AES_128_CBC_SHA256",
            "TLS_RSA_WITH_AES_128_CBC_SHA"
        };

        String[] availableCiphers = null;

        try
        {
            SSLSocketFactory factory = m_ctx.getSocketFactory();
            availableCiphers = factory.getSupportedCipherSuites();
            Arrays.sort(availableCiphers);
        }
        catch(Exception e)
        {
            return new String[] {
                "TLS_DHE_DSS_WITH_AES_128_CBC_SHA",
                "TLS_DHE_DSS_WITH_AES_256_CBC_SHA",
                "TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
                "TLS_DHE_RSA_WITH_AES_256_CBC_SHA",
                "TLS_RSA_WITH_AES_256_CBC_SHA256",
                "TLS_RSA_WITH_AES_256_CBC_SHA",
                "TLS_RSA_WITH_AES_128_CBC_SHA256",
                "TLS_RSA_WITH_AES_128_CBC_SHA",
                "TLS_EMPTY_RENEGOTIATION_INFO_SCSV"
            };
        }

        List<String> aa = new ArrayList<String>();
        for(int i = 0; i < preferredCiphers.length; i++)
        {
            int idx = Arrays.binarySearch(availableCiphers, preferredCiphers[i]);
            if(idx >= 0)
                aa.add(preferredCiphers[i]);
        }

        aa.add("TLS_EMPTY_RENEGOTIATION_INFO_SCSV");

        return aa.toArray(new String[0]);
    }

    private SSLContext m_ctx;

    private String[] m_ciphers;
    private String[] m_protocols;
}
Upraise answered 29/4, 2014 at 13:6 Comment(6)
Thanks for sharing the code. I have two issues. First, what I do not understand is why the code contains 2 createSocket functions each with different arguments? I got an error becaus eof this. If I changed the name of one, I do not know the in-code calling is actually for which one of them. Second, I get an error in List<String> aa = new ArrayList<String>(); saying `the type List is not generic; it can not be parametarized with arguments <String>.Meeting
Also, is this code using Bouncy Castle provider? Because the Java Crypto libraries does not contain algorithms such as: CHACHA20 I do not see where I should call the Bouncy Castle provider in my code. Another issue, I see in the code ciphers such as: "TLS_ECDHE_ECDSA_WITH_CHACHA20_SHA", and "TLS_ECDHE_RSA_WITH_CHACHA20_SHA", is this SHA256? because what I acyually need is CHACHA256.Meeting
@Meeting - "why the code contains 2 createSocket functions each with different arguments?" - there's actually 4 or 5 of them. Because the class is a replacement for Java's SSLSocketFactory, it had to provide all of the methods the original one does.Upraise
@Upraise : nice explanation, @Meeting : " I do not see where I should call the Bouncy Castle provider in my code...", I've imported import org.bouncycastle.jce.provider.BouncyCastleProvider; in my class file with the jar in project and before building custom sslContext included this line Security.addProvider(new BouncyCastleProvider()); which helped me to get required ciphers, but to exclude un-necessary ciphers the above are good explanations/examples !!Bb
Thanks You saved me !Ashleighashlen
How do I build my custom sslContextCedrickceevah
E
7

Don't use anything with export in it. That's crippleware due to export restrictions on strong cryptography.

EDIT: Changed to use 2009 document.

A 2009 NIST recommendation lists the following, incluing TLS_RSA_WITH_AES_256_CBC_SHA (which you mentioned):

TLS_RSA_WITH_NULL_SHA (don't use this unless you're sure you don't need any privacy/confidentiality).

TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_PSK_WITH_3DES_EDE_CBC_SHA
TLS_PSK_WITH_AES_128_CBC_SHA
TLS_PSK_WITH_AES_256_CBC_SHA
TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA
TLS_DHE_PSK_WITH_AES_128_CBC_SHA
TLS_DHE_PSK_WITH_AES_256_CBC_SHA
TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA
TLS_RSA_PSK_WITH_AES_128_CBC_SHA
TLS_RSA_PSK_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 
Extensive answered 24/6, 2009 at 11:11 Comment(4)
I'm a bit confused about TLS_RSA_WITH_NULL_SHA - doesn't that specify no encryption? In this context does this mean no or any encryption?Vitavitaceous
Zarkonnen, I think you're correct that TLS_RSA_WITH_NULL_SHA means no encryption. p. 34 of the draft I linked says NULL encryption is for, "cases where integrity protection is required but not encryption."Extensive
I doubt he needs Preshared Key (PSK) ciphers like TLS_PSK_WITH_3DES_EDE_CBC_SHA. TLS_RSA_WITH_AES_256_CBC_SHA uses RSA key transport. He should probably be using DHE or ECDHE for forward secrecy.Upraise
A good explanation of the subparts of the cipher suite specification and what you should avoid is here: blog.eveoh.nl/2014/02/tls-ssl-ciphers-pfs-tomcatPrevaricator
K
1

Here you can check how secure a cipher is: https://ciphersuite.info/cs/

Here is a method to check the cipher via API:

 public static boolean isCipherSecure(String cipher) throws Exception
  {
    URL url = new URL("https://ciphersuite.info/api/cs/");
    URLConnection request = url.openConnection();
    request.connect();

    JsonElement root = JsonParser.parseReader(new InputStreamReader((InputStream) request.getContent())); 
    JsonObject rootobj = root.getAsJsonObject();
    JsonArray suits = rootobj.getAsJsonArray("ciphersuites");
    for (JsonElement el : suits)
    {
      Set<Map.Entry<String, JsonElement>> entries = el.getAsJsonObject().entrySet();
      for (Map.Entry<String, JsonElement> entry : entries)
      {
        if (entry.getKey().contentEquals(cipher) || entry.getValue().getAsJsonObject()
            .getAsJsonPrimitive("openssl_name").getAsString().contentEquals(cipher))
        {
          String sec = entry.getValue().getAsJsonObject().getAsJsonPrimitive("security").getAsString();
          System.out.println(entry.getKey() + ": " + sec);
          if (sec.contentEquals("recommended") || sec.contentEquals("secure"))
          {
            return true;
          }
          else
            return false;
        }
      }
    }
    throw new Exception("Can't find cipher: " + cipher);
  }

The call:

 SSLServerSocketFactory ssf = (SSLServerSocketFactory) SSLServerSocketFactory.getDefault();
    for (String cipher : ssf.getSupportedCipherSuites())
    {
        if (isCipherSecure(cipher))
        {
          //your code
        }
    }
Keffer answered 10/4, 2022 at 19:28 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.