Often while diagnosing problems between web servers and clients it is useful to observe the requests and responses that take place between the server and some known client (such as web browsers) and/or to directly act as a client and send handcrafted requests for testing.

As long as SSL/TLS is not in use this is quite easy. All you need to act as a client is telnet. For capturing requests & responses between another client and the server you can use any network capture tool such as ethereal wireshark.

When SSL/TLS is used it becomes a bit more difficult since it’s no longer possible to simply telnet to the HTTP port nor to observe the traffic with the most common tools.

The good news is that there are many tools that provide equivalent functionality, it just seems that these are less well known so I’m often asked how to diagnose anything when SSL is in use. I’ll cover a few of the ones I use most in this and later blog entries.

I’ll look at the telnet replacements first. Most often I use openssl s_client
or sometimes the tstclnt from NSS (while most of the NSS tools can be found in the SUNWtlsu package for Solaris, tstclnt is not there).

Starting with openssl, check the available options (showing the path in Solaris here):

% /usr/sfw/bin/openssl s_client -h

If all you need is a SSL-enabled ‘telnet replacement’ and are not looking for info about the SSL connection itself simply run the following and (assuming a successful connection) enter the HTTP request as desired.

% openssl s_client -host localhost -port 8080 -quiet

Using the same command above but omitting the -quiet flag you can see information about the connection, such as the server DN and certificate, negotiated cipher suite and so forth. There are additional flags such as -showcerts, -debug and -msg which will produce additional output.

For testing particular cipher suites, check the -cipher option for tuning the list of ciphers openssl will negotiate with the server. For example:

% openssl s_client -host localhost -port 8080  -cipher DES-CBC-SHA

Be sure to check the manpage for s_client for additional details.

As I mentioned, NSS also has a similar tool, called tstclnt. Run the command with no options for a description of all options.

% tstclnt
Usage:  tstclnt -h host [-p port] [-d certdir] [-n nickname] [-23BTfosvx]
                   [-c ciphers] [-w passwd] [-q]
[.. additional output omitted ..]


% tstclnt -h localhost -p 8080

You may have to provide the -o option in order to be able to connect if the server certificate chain can’t be verified (such as for a self-signed cert). Similar to openssl s_client you can specify which specific cipher suites to negotiate.

So that’s it.. either of these tools will allow you to connect to an SSL/TLS-enabled web server and issue requests as well as obtain diagnostics about the SSL handshake itself.

Recently I’ve been working on adding ECC (Elliptic Curve Cryptography) support for the upcoming JES Web Server 7.0. It was nice to see some coverage of this at the RSA Conference last week.

Sun had a press release describing the upcoming ECC support. I’ve also seen articles from news.com, infoworld.com, java.ittoolbox.com, governmententerprise.com, hardwarezone.com, vnunet.com, networkworld.com, eetimes.com, zdnet.com and internetnews.com.

You can watch the keynotes at the conference web site and the Sun Labs ECC page has pointers to technical information.

JES Web Server has a built-in Java Servlet engine for running Java web applications. When running Java webapps there are basically two choices for access control – ACL-based (or so-called native) or J2EE/Servlet-based. These choices are described in the product documentation.

I’ll start with a very simple Java webapp hello.war consisting of the only following content:

  ./WEB-INF/sun-web.xml
  ./WEB-INF/web.xml
  ./index.html

I want to limit access to the content (what little there is..) of this webapp. First I will use servlet container-based authentication (as defined by the Java Servlet specification, which is definitely recommended reading if you wish to work the Servlets). The access control requirements are specified in the web.xml file, mine contains:

  <security-constraint>
    <web-resource-collection>
      <web-resource-name>Protected Area</web-resource-name>
      <url-pattern>/*</url-pattern>
      <http-method>DELETE</http-method>
      <http-method>POST</http-method>
      <http-method>GET</http-method>
      <http-method>PUT</http-method>
    </web-resource-collection>
    <auth-constraint>
      <role-name>TestRole</role-name>
    </auth-constraint>
  </security-constraint>

  <login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>file</realm-name>
  </login-config>
  <security-role>
    <role-name>TestRole</role-name>
  </security-role>

The key bit above is that I want the servlet container to use HTTP BASIC authentication as the <auth-method> and I want the client to be authenticated against the ‘file’ realm.

I should also point out that the role name TestRole must be mapped to one or more user(s) and/or group(s) in that realm (in this case, ‘file’). This mapping occurs in sun-web.xml, where I chose to map it to a single user, user1:

<security-role-mapping>
   <role-name>TestRole</role-name>
   <principal-name>user1</principal-name>
</security-role-mapping>

Going back to <realm-name> which has the value ‘file’; this must map to a realm which exists in the server’s configuration file server.xml. There I have an <AUTHREALM> entry with attribute name=’file’ (in fact, this is the default file auth realm entry, I didn’t modify it from the out-of-box setting):

<AUTHREALM name="file" classname="com.iplanet.ias.security.auth.realm.file.FileRealm">
  <PROPERTY name="file" value="/tmp/https-hostname/config/keyfile"/>
  <PROPERTY name="jaas-context" value="fileRealm"/>
</AUTHREALM>

I also created a user called user1 to populate the user list contained in /tmp/https-hostname/config/keyfile, since that is the user name I mapped to the role back in sun-web.xml (your server is probably not installed in /tmp.. I just used that as an example).

With that, I’m done. After deploying hello.war onto this server I can now access it only after succesfully authenticating as user1.

This is a minimal example that shows the basics, there are certainly more possibilities. If you’re interested in more please read the product documentation, in particular the section on securing Java web applications in addition to the Servlet specification previously mentioned. I also recommend reading an article I wrote some time back, Application Server 7 Access Control Guide for more background on this general topic. While that article focuses on a different product, the access control mechanism defined by the Java Servlet specification is standard and applies equally to Web Server 6.1. Moreover, while there are differences in syntax between the configuration files of the two products, the underlying logic is very similar.