A handshake_failure on ClientHello and TLS vulnerability

Recently, while integrating web services between two servers, we had a situation with TLS handshake when our server acted as client. In order to establish a TLS session with a server, the client would first send ClientHello message. The server immediately terminated the handshake with the alert handshake_failure. The solution involved a bit of guesswork on our side since there was no support on the server side who could debug on their side and provide some feedback. Following log snippet shows the situation (line #32) with debug enabled (on Tomcat/JBoss).
Studying the debug, we realized that perhaps the cipher suites used (line #21) to start the handshake were not negotiated by the server. In TLS, the handshake_failure alert is only used when no common cipher can be negotiated [5]. The developers of the server sent us a web service client project in SOAPUI to prove that their web services are up and running and could be tested remotely using SOAPUI using transport level security. Enabling the SSL debug in SOAPUI, we found that the cipher suite used was indeed different and was also a superset of the cipher suite our HTTPS client used to start the negotiation. Indeed, cipher suite sent for negotiation is composed with lowest common denominator in mind with with 40 bit encryption as shown below with assumption that negotiation would bring agreement between the client and the server.
However, if the server terminates the handshake with alert handshake_failure, the server might perhaps be looking for different ciphers, compression algorithm or version since this happens in response to ClientHello. There could be a reason for such behavior. Doing a bit of digging, we found that a couple of years back a vulnerability was found in the TLS protocol that could be exploited during the renegotiation phase. When this vulnerability was detected, as a first line of defense, it was suggested to turn off the renegotiation and a solution [4] was proposed to fix the problem in the protocol. Our server used a version of Java with the fix which is listed on JSSE Reference Guide.

Our suspicion was that perhaps the other server was not set up for renegotiation. So, we changed our HTTPS client code to use the cipher suite that incorporated much larger suite as follows.
This cipher suite was accepted by the server. In fact, it was SSL_RSA_WITH_RC4_128_MD5 that was picked up by the server.

1. JSSE Reference Guide 
2. Authentication Gap in TLS negotiation
3. Understanding the TLS Renegotiation Attack
4. RFC 5746 - TLS Renegotiation Extension 
5. SSL and TLS Designing and Building Secure Systems, Eric Rescorla

Bypassing security on web application by using unlisted HTTP method

Typically web environments allow to configure authentication and access control over a web resource for a list of HTTP methods. For example, a Java Servlet descriptor (web.xml) for a J2EE web application allows to configure security constraints as following : Here, the web application developer would expect that HTTP GET and POST methods invoked on any web resource (/*) of the application would be subject to authentication constraints as defined and it is also expected that the rest of the HTTP methods would not be allowed to be accessed. In other words, any GET or POST requests without proper authentication to the JBossAdmin realm would be blocked and would get a 401 error.

Vulnerability 

The HTTP protocol also supports other methods such as HEAD, PUT, DELETE, etc. Here is the catch. As these methods are not listed in the security constraint shown in above example, the HTTP requests with these methods are still allowed to pass through (by vulnerable web environments) without any authentication or authorization(!). Such requests are typically handled by the default GET handler if no method specific handler is specified. Exactly this vulnerability is exploited by a worm in order to launch a denial of service (DoS) attack. It also seems to have affinity to JBoss's jmx-console :(. It uses HTTP HEAD method on jmx-console to plant seeds of one or more DoS attacks on the infected environment as well as out on the net.


What is (known) to be affected?

According to RedHat/JBoss advisory CVE-2010-0738, this vulnerability is applicable to the following JBoss software.

• JBoss Application Server (AS) 4.0.x, 5.1.x
• JBoss Communications Platform 1.2
• JBoss Enterprise Application Platform (EAP) 4.2, 4.3, 5.0
• JBoss Enterprise Portal Platform (EPP) 4.3
• JBoss Enterprise Web Platform (EWP) 5.0
• JBoss SOA-Platform (SOA-P) 4.2, 4.3, 5.0

The advisory says that the default setup of the out of the box web applications such as jmx-console, web-console, etc. of JBoss products listed above enforces incomplete security constraints to ensure authenticated access to the administration user id, defined within these products. A remote attacker, without having access to usernames and passwords, could misuse this setting to trigger arbitrary actions in the context of the operating system user running the Java process and potentially harm confidentiality integrity and availability.
According to Bypassing Web Authentication and Authorization with HTTP Verb Tampering from Aspect Security, this vulnerability might exist in the following since these are known to silently transfer all HTTP HEAD requests to GET handler.

• IIS 6.0
• WebSphere 6.1
• WebLogic 8.2
• JBoss 4.2.2
• Tomcat 6.0
• Apache 2.2.8

Solution

The best solution for any Java web applications is to either remove all __ from the __ and thus trigger security constraints on all HTTP methods or to list all HTTP methods in the security-constraint as shown in the following example.
Better or

Fall 2010

Colors, Fall 2010, Vermont and Massachusetts.

Avoiding browser popup for 401

If you are writing a web application that consumes RESTful web services which enforce HTTP basic authentication, you may face a problem where the browser may pop up a dialog box on the authentication failure (HTTP status: 401) before even your error handler code is called. This happens especially when the web application does not have any controller on the server side. For example, an application written using a client-side JavaScript framework such as Ext-JS.

The browser's HTTP user-agent obviously follows the HTTP protocol which says the following for 401.

The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource.

14.47 WWW-Authenticate

The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI.

where the contents of a challenge may itself contain a comma-separated list of authentication parameters. The authentication parameter realm is defined for all authentication schemes:

With some trial and error, we found that the pop up is triggered not due to the presence of 401 but due to the presence of the challenge.



So, as a web service developer, if you want to help service consumers disable the pop up and still send 401, you could use a trick. Replace Basic with your own scheme, e.g. xBasic as shown below.



To do this with Spring Security, you would want to override the commence method of the default
BasicAuthenticationEntryPoint.



Write your own entry point, e.g. MyBasicAuthenticationEntryPoint as shown below.



Then plugin your entry point into the basic authentication filter as follows:



Thanks to Venkat Mantirraju in helping figure this out.

Bulk delete

Sometimes there is a need to send an entity body for HTTP DELETE. The use case is that of applying DELETE on one or more entity of the resource in one shot. For example, a Web GUI (consumer of a web service) might list one more entity of a resource and allow the user to select one or more of these for delete. If you are using Gmail, it allows you to select one or more email and offers a DELETE action on the selected emails.

Typically DELETE works as follows


where id is the id of the email entity.

If you are using Apache HTTP Client, it will not allow to send entity body with DELETE operation, correct me if I am wrong. In that case, you have to overload POST with query parameter such as following:



and then you could send entity body with the request.

On the server side, if you are using a JAX-RS container, based on which container you are using, the annotations you use would differ.

Apache CXF JAX-RS

Apache CXF automatically dispatches requests with query _method=delete to a method on the resource that is annotated with @DELETE. More on this could be found at Overriding HTTP methods.

RESTEasy
If you are using JBoss RESTEasy, you would need to write POST as follows



Note that EmailCollection could very well have just ids of emails to be deleted. It is received as an entity body.

Response

Typically, for POST, a location header is sent back with the URI that points to the id of the newly created resource. There would be deliberated departure from that style in this case. Because, it is a bulk delete operation tunneled over POST, we would not send any location header. Also, we would not respond back with 201 on success, instead we would send 200 assuming that a transaction was applied to delete all the entities. If the transaction fails, 500 should be sent and transaction should be rolled back. More on this later...

SEDA in Streametics

Recently, I came across Matt Welsh's "A Retrospective on SEDA". Matt writes

If I were to design SEDA today, I would decouple stages (i.e., code modules) from queues and thread pools (i.e., concurrency boundaries). Stages are still useful as a structuring primitive, but it is probably best to group multiple stages within a single "thread pool domain" where latency is critical.

SEDA was one of the research projects that had influenced Streametics' technology. Streametics was the company I had co-founded in 2006. To jump start on the SEDA based implementation, I had started with the code base of Commons Pipeline and made several modifications to it. One change relevant to the above discussion was that of an application handler. This handler was introduced to separate out the application logic from a queue and thread pool of the stage. The stage driver would call out to the application and pass on the event.

Second modification was about allowing the stage designer to receive events synchronously from the previous stage without the queue -> thread pool route. This was done to allow the application designer to group multiple stages such that the processing of the event passing through these stages happens in the same thread without any context switch.

We had also externalized the pipeline (or route) configuration in XML. One could design the whole Streametics application by designing pipelines of stages and connecting these with endpoints and adapters. This way, one could form a graph of stages in the application using a tool. We had a library of stages, endpoints and adapters. The application developers could also use simple APIs to write these components on their own. We used typed XML-Java binding (XMLBeans) at the time of deployment. In a hindsight, we could have used Spring beans framework to wire-in these components.

When we were developing Streametics' event engine, Apache Camel was in very early stage.Camel supports SEDA. However, it required writing routes in Java then. Since then it now allows to do the wiring using Spring Beans. Oh well, there goes a little retrospective on Streametics...

 

RESTful web services in CollectionSpace

I have left the CollectionSpace project. However, I occasionally check out what my former colleagues there are up to. We had started work on an early draft for RESTful API documentation a few months ago. Subsequent versions are getting better, you could find it over at here. Because we had to support schema extensibility, you may find multi part payloads in examples cited. However, the draft does a nice job in describing the request and response payloads as well as error codes.

Thanks to Aron Roberts who has been diligently maintaining and updating it regularly and to Patrick Schmitz in shepherding the work. I hope it becomes a good reference for other projects using the RESTful web services.