Posts tagged ‘java’

Poodle vulnerability

The Poodle vulnerability affects all Linux and Windows servers. This makes it unique – no other vulnerability has been this widespread.

Before I discuss fixes, I’d like to clarify some points:

  • Poodle is not ShellShock – it’s not related (I’ll cover ShellShock in a separate post)
  • Poodle is not a client-side vulnerability (your browser is safe) – it affects servers
  • Poodle won’t steal your credit card details
  • Poodle is not a virus
  • Poodle relies on protocol, not weak ciphers

* Technical bit – Protocol:

When a connection is made between a client (browser) and server (website), both sides must agree on the communication method. The most basic is http. This can be considered as visible to the world.

In 1995, Netscape “created” the SSL protocol (versions 1, 2 and then 3). This encrypts the messages once the communication method has been agreed between client and server. This can be considered as a step in the right direction.

In 1999, TLS was born (versions 1.0, 1.1, and 1.2 now exist). This is encryption at a “higher level”. The transport layer is encrypted rather than the socket layer. In layman’s terms, far more secure.

* More technical stuff:

– Ciphers – this is how the client and server agree to shake hands. I may want to acknowledge you with a firm handshake, and you want to high-five me. If we can’t agree on a handshake, we will not communicate.

As such, the server will tell the client what handshakes are acceptable. If the client disagrees with all of those, the connection will stop

– Fast-forward:

Truth is, many ciphers are weak. A thousand computers could work out your handshake if they focused on your handshake for 10 years. That’s called weak.

Other ciphers are strong. This would take a million computers a million years instead.

– But:

The *protocol* is the issue – SSLv3 is inherently flawed and it’s quite easy to bring down a server which accepts that protocol. It allows the client to run a remote program on a server. Because of the handshake agreement, it’s very easy for a client to only accept one handshake – one within the SSLv3 protocol. That is why it is critical that servers disable this.

And this happens to be almost every server on the internet. As such, the world is busy trying to disable that protocol, switch to TLS and not cause issues along the way.

– Fix (Tomcat):

I’ve been dealing with many servers over the last few weeks which needed patching. If you’re running Tomcat, then here’s how to patch your server (conf/server.xml – inside the Connector declaration):

— Tomcat 6:

sslProtocols = "TLSv1,TLSv1.1,TLSv1.2"

Note: That's undocumented but works for all Tomcat 6 instances I've tested it on

— Tomcat 7:

sslEnabledProtocols = "TLSv1,TLSv1.1,TLSv1.2"

Now you’ve disabled sslv3 your server is safe. While you’re at it, I’d add these which are what I consider “safe” ciphers:



Hope that helps!



November 6, 2014 at 5:08 am Leave a comment

Converting Ant to Maven in NetBeans

After a good couple of days spent converting ant projects over to maven, here is what I consider the easiest method. This is using NetBeans 6.5rc1 but probably works in 6.1.

Here are the steps for converting an ant project to a maven project in NetBeans.
This presumes your ~/.m2/settings.xml is already set up (not shown here for security purposes) and you have installed the Netbeans maven2 plugin:

1. Open ant project
2. Create new maven project using the “Maven Quickstart Archetype”
3. Properties -> Sources -> Change to 1.6
4. pom.xml -> Add distribution management

    <name>Internal Releases</name>

5. Files tab -> src/main -> add folder “resources”. This will create an “Other Sources/resources” entry in the project view
6. Delete existing source and test package stubs
7. Copy java sources and test sources across from ant project
8. Move all config xml files (such as applicationContext.xml) over to “Other Sources/resources”
9. If you have any hibernate .hbm.xml files, create a folder structure under “Other Sources/resources” identical to the package structure, and copy the files to there
10. Resolve dependencies. The easiest way to do this is go through red-underlined classes, copy the missing required classname, right-click the libraries node and hit “Find Dependency”
11. If a dependency is purely for a test class, add “<scope>test</scope>” to reduce the resulting jar filesize
12. mvn install or deploy

If the ant project exposes a WebService:
1. Add the following plugin to the pom.xml:


2. Change the wsdl location and packageName as necessary. Without the sourceDestDir, the generated sources live under target/ and code completion won’t work. Setting the package name to the same package as the ws-client solves this. Compilation works either way.

October 30, 2008 at 7:05 pm 1 comment

ehcache and spring

As used by Hibernate, ehcache is a great little caching implementation which ought to be part of every Java coders arsenal. Although its complexities may seem overwhelming, it’s very easy to use as a simple caching solution.

In my situation, I needed to prevent db hits when validating codes (ie seeing if they already exist in the db). This is how easy it is to set up.


<bean id="myDao" class="myDaoImpl" init-method="setupCache">
  <property name="cacheManager" ref="cacheManager">
<bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
  <property name="configLocation" value="classpath:ehcache.xml" />


  <diskStore path=""/>
  <cache name="myCacheName"

import net.sf.ehcache.Cache;
import net.sf.ehcache.CacheManager;
import net.sf.ehcache.Element;

public class {
  private CacheManager cacheManager;
  private Cache myCache = null;

  public void setCacheManager(CacheManager cacheManager) {
    this.cacheManager = cacheManager;

  private void setupCache() {
    String cacheName = "myCacheName";
    logger.debug("Fetching cache [" + cacheName + "]");
    myCache = cacheManager.getCache(cacheName);

ehcache.xml needs to be put alongside applicationContext.xml (especially in the case of jar packaging). If you’re packaging a war, you can place it anywhere on the classpath and don’t need to specify the configLocation (it’s the default config name).

To use the cache, do something like this:

Element cachedObject = myCache.get(key);
if (cachedObject != null) {
  return cachedObject;
} else {
  fetch object from db
  // add to cache
  myCache.put(new Element(key, object))
  return object;

And that's it!

Now you’ll only hit the db when needed. Of course, it’s worth reading the reference material to see the many ways you can configure the cache. My example is purely for a 1000 object permanent memory cache, but TTL and overflow-to-disk (for example) is just as easy to set up.

October 23, 2008 at 4:28 pm 4 comments