Archive

Posts Tagged ‘security’

Trust stores and Java versions

February 19th, 2012 1 comment

My debugging contest of the week happened to take place on a IBM AIX system. The bug happened when we upgraded from Java version 1.4 to version 6 (which I admit is a pretty big step). Suddenly, an old application stopped working and its log displayed NoSuchAlgorithmException.

A bit of context: when Java applications have to connect to hosts with SSL over HTTP, they must trust the host – it’s the same as when you browse a site with HTTPS. If the site can provide a SSL certificate that can proves its trustworthiness by tracing it back to a trust authority (Verisign and others), all is well. However, when browsing, you can always force the browser to trust a certificate that is not backed by a trusted authority. Such a luxury is not permitted when running an application, there’s no callback.

Therefore, you can add certificates to the JVM truststore, which is located under the $JRE_HOME/security/lib. Alternatively, you can also pass a truststorewith the -Djavax.net.ssl.trustStore=<path/to/store> Java launch parameter. Before this problem, I was foolish to think you could keep the same truststore between different Java versions without a glitch. This is not the case: going back and forth a few times, we finally located the root problem.

It seems that between Java version 1.4 and 6, the good people at IBM decided to completely change their security providers. This means that when a certificate is stored by a Java 1.4 JVM, the Java 6 JVM has no chance to read it.If you’ve had told me that before then, I would have laughed in your face. Reality is weirder than fiction.

Conclusion: for Ops, it may be a good idea to consider always using the same security provider regardless of the operating system. Bouncy Castle is one of such providers, others surely exist.

Note: Sun may be defunct, but their engineers kept the same security providers between Java 1.4 and 6

Send to Kindle
Categories: Java Tags:

SSL your Tomcat 7

July 3rd, 2011 3 comments

One thing I’m doing very often and always searching on the Internet is how to obtain a self-signed SSL certificate and install it in both my client browsers and my local Tomcat.

Sure enough there are enough resources available online, but since it’s a bore to go looking for the right one (yes, some do not work), I figured let’s do it right once and document it so that it will always be there.

Create the keystore

Keystores are, guess what, files where your store your keys. In our case, we need to create one that will be used by both Tomcat and for the certificat generation.

The command-line is:

>keytool -genkey -keyalg RSA -alias blog.frankel.ch -keystore keystore.jks -validity 999 -keysize 2048

The parameters are as follow:

Parameter Value Description
-genkey Requests the keytool to generate a key. For all provided features, type keytool -help
-keyalg RSA Wanted algorithm. The specified algorithm must be made available by one of the registered cryptographic service providers
-keysize 2048 Key size
-validity 999 Validity in days
-alias blog.frankel.ch Entry in the keystore
-keystore keystore.jks Keystore. If the keystore doesn’t exist yet, it will be created and you’ll be prompted for a new password; otherwise, you’ll prompted for the current store’s password

Configure Tomcat

Tomcat’s SSL configuration is done in the ${TOMCAT_HOME}/conf/server.xml file. Locate the following snippet:

<!--
	<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
           maxThreads="150" scheme="https" secure="true"
           clientAuth="false" sslProtocol="TLS" />
    -->

Now, uncomment it and add the following attributes:

  • keystoreFile="/path/to/your/keystore.jks"
  • keystorePass="Your password"

Note: if the store only contains a single entry, fine; otherwise, you’ll need to configure the entry’s name with keyAlias="blog.frankel.ch"

Starting Tomcat and browsing to https://localhost:8443/ will show you Tomcat’s friendly face. Additionnaly, the logs will display:

28 june 2011 20:25:14 org.apache.coyote.AbstractProtocolHandler init
INFO: Initializing ProtocolHandler ["http-bio-8443"]

Export the certificate

The certificate is created from our previous entry in the keystore.

The command-line is:

>keytool -export -alias blog.frankel.ch -file blog.frankel.ch.crt -keystore keystore.jks

Even simpler, we are challenged for the keystore’s password and that’s all. The newly created certificate is now available in the filesystem. We just have to distribute it to all browsers that will connect to Tomcat in order to bypass security warnings (since it’s a self-signed certificate).

Spread the word

The last step is to put the self-signed certificate in the list of trusted certificates in Firefox. For a quick and dirty way, import it in your own Firefox (Options -> Advanced -> Show certificates -> Import…) and distribute the %USER_HOME%"/Application Data/Mozilla/Firefox/Profiles/xzy.default/cert8.db file. It has to be copied to the %FIREFOX_HOME%/defaults/profile folder so that every single profile on the target machine is updated. Note that this way of doing will lose previously individually accepted certificates (in short, we’re overwriting the whole certificate database). For a more industrial process, look at the next section.

To go further:

Send to Kindle
Categories: JavaEE Tags: , ,

New declarative security features in Servlet 3.0

May 22nd, 2011 4 comments

Servlet 3.0 is not only about the replacement of the web.xml deployment descriptor by annotations. In this article, we’ll see what improvement it makes in the realm of security.

In Servlet 2.5 (and before that), declarative security was about the following features:

  • authentication method (BASIC, FORM, etc)
  • authorization to differents parts of the application (web application resources)
  • data confidentiality and integrity
  • session time-out

Servlet 3.0 adds standardized ways regarding two configuration items.

The first parameter is how the session id is sent from the client to the server, so as for the latter to recognize the same session. Earlier in my carreer, I learnt that the first time an application server sends a response back to the client, it passes a cookie back and also appends to the URL, both referencing the unique jsessionid. Now, as soon as the second request is passed to the server, the latter knows the client accepts cookie or not and uses the appropriate mechanism: in essence, the strategy can be sumed up by “cookies first but fallback to URL rewriting if not possible”. Granted, there was a time when you couldn’t count on your client’s browsers to have cookies allowed. Nowadays, URL rewriting is first seen as a way to makes session hijacking easy as pie – even with HTTPS – since the id belongs to the URL. Hell, you’ll even find it in the logs! Servlet 3.0 aims to allow us to force the cookie strategy. The web.xml fragment to take care of this is the following:

<session-config>
  <cookie-config>
    <secure>true</secure>
  </cookie-config>
</session-config>

Moreover, cookies themselves can be unsafe since they can be accessed by most browsers JavaScript engine, thus allowing client code to read it. Yet, a subset of browsers let us configure the engine so as to disable JavaScript access (read and/or write) for this cookie. Servlet 3.0 let compliant application server mark cookies as HttpCookie, which does the trick. Even if this feature is completely implementation dependent, it helps cover a part of our security worries. It’s achieved with the nex web.xml snippet:

<session-config>
  <cookie-config>
    <http-only>true</http-only>
  </cookie-config>
</session-config>

Need for security are most often rediscoverd at the end of the development phase, when it costs much to implement. Moreover, some (if not most) securing nodes are a sysadmin’s responsibilities (configuring the 3rd-party LDAP, HTTPS, etc.). For example, the two previous capabilities were implementation dependent. This leaves security a very obscure field for young (and not-so-young) developers. I think that enhancements such as those provided by Servlet 3.0 tend to increase mutual understanding between developers and sysadmins.

Send to Kindle
Categories: JavaEE Tags: ,

Next book review: Spring Security 3

June 23rd, 2010 No comments

My next book review will be on Spring Security 3 from Packt. I’ve heard of Spring Security since it was previously named Acegi Security but I hadn’t the chance to play with it. A book on the Spring Security model will let me dive into the subject, providing me with the means to see if it warrants further investigation on my part.

The shipment is on its way, the rest is on my shoulders!

Send to Kindle
Categories: Book review Tags: ,

Securing middleware products

February 9th, 2010 No comments

My work is IT architecture, meaning I focus on the early steps of a project. Once the application is in production, I usually leave it to systems and production engineers. For example, for JVM fine tuning, most of the clients I worked for have people that have the right skills to do that.

Nevertheless, I need sometimes to sully my nails. This happens in two cases: when the client is too small to have such dedicated teams or when its production team are not experienced enough to handle the problem at hand. Believe it or not, it happened to me that I had to show WebSphere administrators how to connect JAAC connectors to a LDAP server.

Anyway, I always value information on how to handle cases out of my usual scope: first, it never hurts to know more. Second, it is sometimes handy to sort what production teams tell you: some is real stuff, some is bulls. Likewise, I invite production teams to learn about development so that they may sort what is told to them too. Learning the other’s craft let you increase comprehension between different teams.

Free checklist audits

This week, I learned about a site that propose free benchmarks to audit your infrastructure’s security. This site is the Center for Internet Security. Proposed benchmarks are two-fold: part document about what is audited, part benchmarking tool. The former is freely downloadable; as for the second part, you must register. The rest of this article will focus on the document.

Though many subjects will always be beyond my reach (I will never accept to secure an Oracle Database), one document is of utmost interest to me: the benchmark on Apache  Tomcat.

This file include rules that, once you comply with them, will make your product more secure. Even if most of them are no-nonsense and you could think about it yourself, the document make a nice check-list. Some rules are really interesting in that I am afraid they are seldom enforced, some because of neglect, some because of lack of knowledge of the product.

Enhancements

Checklists provided by the CIS do lack some things though:

  • risk correlated to statistics. Some security holes aren’t used by many hackers. How should I prioritize?
  • risk correlated to damage. What’s the potential damage of not underdoing this action? For example, session hijacking will compromize users interactions with my application, not my server
  • trade-off. Many security features are not always desirable, and most have a trade-off, often in terms of performance. When I browse a merchant site, crypting my communications is overkill. Only during the payment phase is a real need to keep information secret.

Rules examples

For Tomcat, here’s is a sample of the audited rules.

Separate Web content directory from Tomcat’s system files

Tomcat comes with its own file structure, including a webapp directory where webapps should reside. Yet, nothing prevents webapps to be outside this directory, even on another partition. From a security point-of-view, this will avoid directory traversal exploits: if a malicious user gains access to the webapps directory, he will not have access to the server.

Moreover, from a maintenance point-of-view, you are able to upgrade Tomcat without redeploying your applications.

Disable session façade recycling

Tomcat’s model is to use façade on every entity of the HTTP model: request, response, session, etc. By default, Tomcat’s façades over sessions are reused when processing new requests in order to optimize memory use. Thus, this could lead a new request to have access to informations on sessions that are not tied to it. This is a security risk and should be turned off if one’s want to secure the server.

Disable auto-deployment

Tomcat’s default behaviour is to have a running thread that watches the webapps directory. Once a new war is detected by this thread, it deploys it automatically. Such action is very enjoyable in a development environment. In a production environment, users that have access to the directory could potentially put malicious webapps in it and have it deployed automatically. Thus, disabling auto-deployment increases the security of the Tomcat’ server.

Conclusion

Checklists provided by the CIS are very nice to have for production and security engineers. However, one should carefully evaluate the cost of enforcing the rule agains the risk of not enforcing it. Those are either not detailed enough in the documentation, or not provided at all.

To go further:

Send to Kindle
Categories: Technical Tags: ,

Custom LoginModule in Tomcat

April 3rd, 2009 11 comments

Tomcat manages application security through the concept of realm. A realm is a coherent package of name password pairs that identify valid users for a web application.

Tomcat’s default realm is MemoryRealm. This realm reads the famous conf/tomcat-users.xml file and uses it check for name password pair validity. Tomcat also provides realms to check against pairs stored in a database, either through a direct connection, or through a configured datasource. The main disadvantage of these all these realms is that they force you to adopt Tomcat’ expected data structure. In most organizations, these constraints will be enough for the architect to rely upon custom or 3rd-party security components.

In order to use your enterprise database structure, you would code a custom realm. Tomcat provides the org.apache.catalina.Realm interface. The drawback of implementing your own realm is that if you change your application server afterwards, all of your code would have been for naught. Yet, if you check Tomcat documentation thoroughly, you will see Tomcat also provides a JAASRealm. JAAS is the Java security feature and enable you to write custom security modules in a portable way. Tomcat’s JAASRealm performs as a adapter between realms and login modules so you only have to write a LoginModule and Tomcat will know how and when to call it. Read more…

Send to Kindle
Categories: JavaEE Tags: , , , ,