SSLSocket and AES Encryption

Question

We need to use AES encryption to communicate with the client server, so when I enable Cipher Suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA in SSLServetSocket (using Java 6) and run the program, I get below the exception

There is no available certificate or key matching the SSL cipher suites that are included

My question is: can we encrypt AES via SSLSocket or should it be a regular socket. If we cannot use it, can you provide me with an example of interaction with a client server using AES encryption.

Here is the code

public class AESServerSocketTest { public static void main(String[] args) { SSLServerSocket serverSocket; try { SSLContext ctx = javax.net.ssl.SSLContext.getDefault(); serverSocket =(SSLServerSocket)ctx.getServerSocketFactory().createServerSocket(8181); serverSocket.setEnabledCipherSuites(new String[]{"TLS_DHE_RSA_WITH_AES_128_CBC_SHA"}); SSLSocket in = (SSLSocket)serverSocket.accept(); } catch (Exception e) { System.out.println("Exception " + e); } } } 

Thanks at Advance

Answer 1

Anonymous cipher suites do not authenticate. Even with encryption, you are talking on the encrypted channel with the remote side, but you cannot be sure who it is, so it can be the person in the middle (MITM). The TLS 1.1 specification says the following about anonymous ciphers:

The following encryption codes are used for the completely anonymous Diffie-Hellman, in which neither party is authenticated. Please note that this mode is vulnerable to man-in-the-middle attacks and is therefore not recommended.

In short, do not use them (except for testing) or if you are really sure that there will be no active MITM. (The TLS 1.2 specification is even more categorical regarding their use.)

If you want to use TLS securely, you will need a client to verify the identity of the remote user. In the vast majority of cases, this is done using an X.509 certificate. In particular, for the TLS_DHE_RSA_WITH_AES_128_CBC_SHA set for encryption, you will need a RSA public key certificate (which explains the error message received).

You must generate or request a certificate (self-signed or through CA, perhaps your own, depending on how the clients can be configured), which correctly identifies the server. Not only the certificate should be entrusted to the client (explicitly or through the established CA), but its identification information should correspond to the server under the name that the client is trying to connect to it.

It is not clear in your example whether you are using HTTPS (for example) or your own protocol over SSL / TLS. RFC 6125 is the latest specification in this area that combines practices around several protocols (e.g., HTTPS, LDAPS, IMAPS, ...). Since this is a fairly recent RFC, several libraries clearly implement it (although they can do it in practice, since it combines best practices). In doubt, it is generally wise to adhere to RFC 2818, section 3.1 (HTTP over TLS) on this topic:

If a subjectAltName extension of type dNSName is present, it MUST be used as an identity. Otherwise (the most specific) common name
the field in the Subject field of the certificate MUST be used. Although the use of the Common Name is an existing practice, it is outdated and it is recommended that Certification Authorities use dNSName.

Compliance is performed using the compliance rules specified in [RFC2459]. If more than one identifier of a given type of certificate is present in one instance (for example, more than one dNSName name, a match in any set is considered acceptable.) Names can contain a wildcard character *, which is considered to coincide with any one domain name of a component or a fragment of a component. For example, .a.com matches foo.a.com, but not bar.foo.a.com. f.com matches foo.com but not bar.com.

In some cases, the URI is indicated as an IP address rather than a host name. In this case, the iPAddress subjectAltName must be present in the certificate and must match the IP in the URI exactly.

( RFC 6125 explicitly prohibits the use of wildcard certificates .)

For practical reasons, the IP addresses in the certificates are not ideal (I don’t think that many commercial CAs will generate such certificates anyway). If you can, use the subject alternative name extension, otherwise adding a hostname to the CN= RDN of your Subject should be sufficient. There are notes on how to generate a CSR / certificate with SAN in this answer . In particular, it is possible to use the -ext option for Java 7 keytool (for example, -ext san=dns:www.example.com ); note that the keystore generated by the Java 7 key must be used in previous versions of the JRE.

In addition, if you have no code other than SSLContext.getDefault() (you can also use SSLServerSocketFactory by default in this case), you need to specify the keystore: JRE does not have a default value for this (unlike the trust store) . This can be done using javax.net.ssl.keyStore (and its related system properties). This answer (for example) has another topic: / questions / 38656 / trust-store-vs-key-store-creating-with-keytool / 280641 # 280641

Answer 2

There is no available certificate or key corresponding to the SSL cipher suites that are included

This error means:

Either that the private keys / certificates are not suitable / accepted by the included cipher suites (this most likely means, for example, a short key length), or that you did not configure the certificates.