Java + HTTPS: Handling ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY

PROBLEM

When accessing HTTPS links from a local application server, the modern browser throws the following error message(s):-

  • SSL received a weak ephemeral Diffie-Hellman key in Server Key Exchange handshake message. (Error code: ssl_error_weak_server_ephemeral_dh_key)
  • Server has a weak ephemeral Diffie-Hellman public key

SOLUTIONS

There are multiple solutions to this problem.

SOLUTION 1: Disable browser check

One way is to completely disable this check on the browser.

For example, in Firefox, go to about:config and set security.ssl3.dhe_rsa_aes_128_sha and security.ssl3.dhe_rsa_aes_256_sha to false.

The downside is the browser is exposed to Logjam attacks.

SOLUTION 2: Use Java 8

The easiest solution is to use Java 8 because it has better cipher support.

The downside is sometimes using Java 8 is not an option if you don’t have control on the application server.

SOLUTION 3: Use Bouncy Castle

If you are using Java 6 or Java 7, you can download Bouncy Castle crypto implementation and store them in $JAVA_HOME/jre/lib/ext.

Then, register this provider in $JAVA_HOME/jre/lib/security/java.security, for example:-

#
# List of providers and their preference orders (see above):
#
# MacOSX added com.apple.crypto.provider.Apple as #3
security.provider.1=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/sunpkcs11-macosx.cfg
security.provider.2=sun.security.provider.Sun
security.provider.3=com.apple.crypto.provider.Apple
security.provider.4=sun.security.rsa.SunRsaSign
security.provider.5=com.sun.net.ssl.internal.ssl.Provider
security.provider.6=com.sun.crypto.provider.SunJCE
security.provider.7=sun.security.jgss.SunProvider
security.provider.8=com.sun.security.sasl.Provider
security.provider.9=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.10=sun.security.smartcardio.SunPCSC
security.provider.11=org.bouncycastle.jce.provider.BouncyCastleProvider

The downside is if your team is doing local application development, all team members have to perform these steps on their machines too.

SOLUTION 4: Disable all weak Diffie-Hellman ciphers

Another solution is to configure the server by disabling all the weak Diffie-Hellman ciphers.

You can either enable the strong ciphers or disable the weak ciphers.

However, it is preferable (in my opinion) to disable weak ciphers so that newer (and stronger) ciphers will automatically be included when Java version is updated in the future.

Here is a working example for Jetty server:-

<plugin>
    <groupId>org.mortbay.jetty</groupId>
    <artifactId>jetty-maven-plugin</artifactId>
    <version>8.1.16.v20140903</version>
    <configuration>
        <stopKey>jetty-stop-key</stopKey>
        <stopPort>7778</stopPort>
        <scanIntervalSeconds>1</scanIntervalSeconds>
        <requestLog implementation="org.eclipse.jetty.server.NCSARequestLog">
            <extended>true</extended>
            <logTimeZone>CST</logTimeZone>
        </requestLog>
        <webApp>
            <contextPath>/${project.artifactId}</contextPath>
            <webInfIncludeJarPattern>.*/.*jsp-api-[^/]\.jar$|./.*jsp-[^/]\.jar$|./.*taglibs[^/]*\.jar$</webInfIncludeJarPattern>
        </webApp>
        <connectors>
            <connector implementation="org.eclipse.jetty.server.bio.SocketConnector">
                <port>7777</port>
            </connector>
            <connector implementation="org.eclipse.jetty.server.ssl.SslSocketConnector">
                <port>7443</port>
                <keystore>${project.basedir}/src/main/config/keystore.jks</keystore>
                <keyPassword>jetty8</keyPassword>
                <password>jetty8</password>
                <excludeCipherSuites>
                    <excludeCipherSuites>SSL_RSA_WITH_DES_CBC_SHA</excludeCipherSuites>
                    <excludeCipherSuites>SSL_DHE_RSA_WITH_DES_CBC_SHA</excludeCipherSuites>
                    <excludeCipherSuites>SSL_DHE_DSS_WITH_DES_CBC_SHA</excludeCipherSuites>
                    <excludeCipherSuites>SSL_RSA_EXPORT_WITH_RC4_40_MD5</excludeCipherSuites>
                    <excludeCipherSuites>SSL_RSA_EXPORT_WITH_DES40_CBC_SHA</excludeCipherSuites>
                    <excludeCipherSuites>SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA</excludeCipherSuites>
                    <excludeCipherSuites>SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA</excludeCipherSuites>
                    <excludeCipherSuites>SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA</excludeCipherSuites>
                    <excludeCipherSuites>TLS_DHE_RSA_WITH_AES_256_CBC_SHA256</excludeCipherSuites>
                    <excludeCipherSuites>TLS_DHE_DSS_WITH_AES_256_CBC_SHA256</excludeCipherSuites>
                    <excludeCipherSuites>TLS_DHE_RSA_WITH_AES_256_CBC_SHA</excludeCipherSuites>
                    <excludeCipherSuites>TLS_DHE_DSS_WITH_AES_256_CBC_SHA</excludeCipherSuites>
                    <excludeCipherSuites>TLS_DHE_RSA_WITH_AES_128_CBC_SHA256</excludeCipherSuites>
                    <excludeCipherSuites>TLS_DHE_DSS_WITH_AES_128_CBC_SHA256</excludeCipherSuites>
                    <excludeCipherSuites>TLS_DHE_RSA_WITH_AES_128_CBC_SHA</excludeCipherSuites>
                    <excludeCipherSuites>TLS_DHE_DSS_WITH_AES_128_CBC_SHA</excludeCipherSuites>
                </excludeCipherSuites>
            </connector>
        </connectors>
    </configuration>
</plugin>

The downside is the server configuration gets a little lengthy.

Maven: Bundling and Unpacking Native Libraries

Introduction

Steps to bundle the native libraries to be pushed to Nexus, and to unpack the native libraries on mvn package.

Bundling Native Libraries into a JAR File

Let’s assume we have the following native libraries for multiple platforms:-

➜  tree native 
native
├── linux
│   ├── x86
│   │   └── libnative_synchronization.so
│   └── x86_64
│       └── libnative_synchronization.so
├── macosx
│   └── libnative_synchronization.jnilib
└── win32
    ├── x86
    │   └── native_synchronization.dll
    └── x86_64
        └── native_synchronization.dll

Create a jar that contains these native libraries. The -C options prevents the native folder from being created in the JAR file.

➜  jar cMf my-project-native.jar -C native .   

Pushing JAR to Nexus

When pushing this native JAR file to Nexus, make sure to use the natives-* classifier. In this example, I called it natives-all.

<dependency>
	<groupId>my.project</groupId>
	<artifactId>native</artifactId>
	<version>1.0</version>
	<classifier>natives-all</classifier>
</dependency>

Configuring pom.xml

First, add LWJGL and the native JAR dependencies.

<dependencies>
    <dependency>
        <groupId>org.lwjgl.lwjgl</groupId>
        <artifactId>lwjgl</artifactId>
        <version>2.9.3</version>
    </dependency>
    <dependency>
		<groupId>my.project</groupId>
		<artifactId>native</artifactId>
		<version>1.0</version>
		<classifier>natives-all</classifier>
    </dependency>
</dependencies>

Then, add the following plugin:-

<build>
    <plugins>
		<plugin>
		    <groupId>com.googlecode.mavennatives</groupId>
		    <artifactId>maven-nativedependencies-plugin</artifactId>
		    <version>0.0.7</version>
		    <executions>
		        <execution>
		            <id>unpacknatives</id>
		            <phase>generate-resources</phase>
		            <goals>
		                <goal>copy</goal>
		            </goals>
		        </execution>
		    </executions>
		</plugin>
    </plugins>
</build>

This plugin searches for dependencies with natives-* classifier and unpacks the content to target/natives folder.

Testing

Run mvn clean package.

Inspect target/natives. The native libraries should be unpacked here:-

target/natives
├── META-INF
│   └── MANIFEST.MF
├── OpenAL32.dll
├── OpenAL64.dll
├── jinput-dx8.dll
├── jinput-dx8_64.dll
├── jinput-raw.dll
├── jinput-raw_64.dll
├── jinput-wintab.dll
├── libjinput-linux.so
├── libjinput-linux64.so
├── libjinput-osx.jnilib
├── liblwjgl.dylib
├── liblwjgl.so
├── liblwjgl64.so
├── libopenal.so
├── libopenal64.so
├── linux
│   ├── x86
│   │   └── libnative_synchronization.so
│   └── x86_64
│       └── libnative_synchronization.so
├── lwjgl.dll
├── lwjgl64.dll
├── macosx
│   └── libnative_synchronization.jnilib
├── openal.dylib
└── win32
    ├── x86
    │   └── native_synchronization.dll
    └── x86_64
        └── native_synchronization.dll

IntelliJ IDEA: Configuring Default Project Settings

PROBLEM

When creating or checking out a project for the first time in IntelliJ IDEA, we may need to reconfigure the project settings. My biggest pain is IntelliJ IDEA will always use the wrong Maven version when I check out the project from the source control.

SOLUTION

The good news is there is a way to set up default project settings in IntelliJ IDEA.

In the Welcome dialog, select Configure -> Project Defaults.

From here, we can create all the default project settings, such as JDK version, Maven version, code style formatter and so on.

Rest Template: Could Not Extract Response – No Suitable HttpMessageConverter Found for Response Type [X] and Content Type [application/json;charset=UTF-8]

PROBLEM

When invoking a web service using RestTemplate:-

restTemplate.getForObject("http://server/api", MyBean[].class));

… the following exception occurs:-

Exception in thread "main" org.springframework.web.client.RestClientException: 
Could not extract response: no suitable HttpMessageConverter found for response 
type [class [LMyBean;] and content type [application/json;charset=UTF-8]
	at org.springframework.web.client.HttpMessageConverterExtractor.extractData(HttpMessageConverterExtractor.java:110)
	at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:572)
	at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:530)
	at org.springframework.web.client.RestTemplate.getForObject(RestTemplate.java:237)

SOLUTION

If the content type is JSON, add the following dependency:-

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.6.0</version>
</dependency>

Spring Data JPA: Requested bean is currently in creation: Is there an unresolvable circular reference?

PROBLEM

Let’s assume we have the following Spring Data JPA repository…

public interface ProjectRepository extends JpaRepository<Project, Long>, ProjectRepositoryCustom {
    Project findByName(String name);
}

… this repository has some custom implementation…

public interface ProjectRepositoryCustom {
    Project doCustom(String name);
}

… this custom implementation depends on the original repository to reuse existing APIs…

public final class ProjectRepositoryImpl implements ProjectRepositoryCustom {
    private final ProjectRepository projectRepository;

    @Autowired
    public ProjectRepositoryImpl(final ProjectRepository projectRepository) {
        this.projectRepository = projectRepository;
    }

    @Override
    public Project doCustom(final String name) {
        final Project project = projectRepository.findByName(name);
        return ...
    }
}

When we run the code, we get the following exception:-

Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: 
Error creating bean with name 'projectRepositoryImpl': Requested bean 
is currently in creation: Is there an unresolvable circular reference?
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.beforeSingletonCreation(DefaultSingletonBeanRegistry.java:347)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:299)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:293)

SOLUTION

To fix the circular reference problem, instead of auto-wiring ProjectRepository using the constructor, auto-wire using the field or setter method:-

public final class ProjectRepositoryImpl implements ProjectRepositoryCustom {
    // this field cannot be `final` anymore
    private ProjectRepository projectRepository;

    @Autowired
    public void setProjectRepository(final ProjectRepository projectRepository) {
        this.projectRepository = projectRepository;
    }

    @Override
    public Project doCustom(final String name) {
        final Project project = projectRepository.findByName(name);
        return ...
    }
}

Akka: Spring Integration

PROBLEM

To create Spring-managed prototype-scoped actors.

SOLUTION

The key to this solution is to create a custom implementation of IndirectActorProducer. From the documentation:-

“…This interface defines a class of actor creation strategies deviating from the usual default of just reflectively instantiating the Actor subclass. It can be used to allow a dependency injection framework to determine the actual actor class and how it shall be instantiated…”

First, create an implementation of IndirectActorProducer that creates the actor using Spring’s ApplicationContext.

public final class SpringActorProducer implements IndirectActorProducer {
    private final ApplicationContext applicationContext;
    private final Class<? extends Actor> actorClass;

    public SpringActorProducer(final ApplicationContext applicationContext, 
                               final Class<? extends Actor> actorClass) {
        this.applicationContext = applicationContext;
        this.actorClass = actorClass;
    }

    @Override
    public Actor produce() {
        return applicationContext.getBean(actorClass);
    }

    @Override
    public Class<? extends Actor> actorClass() {
        return actorClass;
    }
}

To prevent tedious auto-wiring ApplicationContext in every actor class to be passed to SpringActorProducer above, create a Spring-managed service that will do just that.

@Component
public final class SpringProps {
    private final ApplicationContext applicationContext;

    @Autowired
    public SpringProps(final ApplicationContext applicationContext) {
        this.applicationContext = applicationContext;
    }

    public Props create(final Class<? extends Actor> actorClass) {
        return Props.create(SpringActorProducer.class, 
                            applicationContext, 
                            actorClass);
    }
}

Now, instead of creating the actors like this….

ActorRef master = actorSystem.actorOf(
                      Props.create(Master.class), "master");

ActorRef workerRouter = getContext().actorOf(
                            Props.create(Worker.class)
                                 .withRouter(new RoundRobinPool(5)),
                            "workerRouter");

… we will use the auto-wired SpringProps to create the actors…

@Autowire
private SpringProps springProps;

...

ActorRef master = actorSystem.actorOf(
                      springProps.create(Master.class), "master");
												 
ActorRef workerRouter = getContext().actorOf(
                            springProps.create(Worker.class)
                                       .withRouter(new RoundRobinPool(5)),
                            "workerRouter");

Make sure all actor classes are Spring-managed with prototype-scoped by annotating them with @Component and @Scope("prototype").

To see the full example, visit https://github.com/choonchernlim/test-akka-spring

Neo4j: WHERE Clause vs Curly Braces in MATCH Clause

PROBLEM

With Cypher Query Language, you can write similar queries that yield the same result.

For example:-

MATCH (p:Person)-[:loves]->(b:Beverage) 
WHERE b.name = 'Dark Roast' 
RETURN p.name as PERSON

… AND …

MATCH (p:Person)-[:loves]->(b:Beverage{name:'Dark Roast'}) 
RETURN p.name as PERSON

… returns the same result.

So, which one is better in terms of performance?

SOLUTION

Neo4j provides a very helpful command called EXPLAIN that allows us to do some investigation ourselves.

The EXPLAIN command displays the query plan without actually executing the query.

To use it, just add EXPLAIN in front of the query.

In this example, both queries produce exactly the same query plan.

In another word, while both queries look slightly different, they perform exactly the same.