Blogging Techstacks

Apache: Forcing the Server's SSL Cipher on the Client

Normally, in an SSL conversation, the client presents its preferred cipher to use and as long as the server that the client is negotiating a connection with supports it, that cipher will be used.  Suppose though that there are cases where you don't want to leave this up to the client to decide and you want the strongest encryption available between client and server.  A little-known apache configuration directive, and by little-known I mean I just started playing with it a few days ago, called SSLHonorCipherOrder will allow you to do just that.

Simply set the value of the directive to On and you are all set. Be wary however because Apache's preferred ssl cipher appears to be DHE-RSA-AE256-SHA; a 256 bit cipher could be costly in terms of cpu. 

When connecting with Safari 4 prior to making this change, the cipher Safari used was AES128-SHA—after making the change, I started using the 256 bit cipher. (Interestingly, with the 3.5 version of Firefox, the client's preferred cipher and apache's preferred cipher seem to be the same: DHE-RSA-AE256-SHA).

TRACE Method Handling - Disabling TRACE

I have many articles posted on this blog for handling http trace methods. Since they are amongst the most popular on this site, I thought it would be helpful to consolidate them into something better suited for reference. Also, since it is a vulnerability that frequently turns up on PCI Compliance scans, I thought it would be useful to provide one base page that searches can be directed to. Less page views for me but hopefully easier searching for everyone else.

To start, I updated the ruby script I wrote to test to see how a site responds to HTTP TRACE requests. The previous script can be found here and below is the update:

#!/usr/bin/env ruby
require 'net/http'

puts "\nEnter the URL for the site"
puts "(Format should be 'http://siteURL/')"
name = gets 

url = URI.parse(name)
begin
req = Net::HTTP::Trace.new(url.path)
resp = Net::HTTP.start(url.host, url.port) {|http|
 http.request(req) 
}
rescue Errno::ECONNRESET, Errno::ECONNABORTED
 puts "Your iRule Works!! Connection Dropped!"
 exit
end

# Case statement - delivers response based on status code
# returned from site assuming irule not used or needed
statuscode = resp.code
result = case statuscode
 when "200": "TRACE is **probably** enabled"
 when "301": "Site is responding with a 301 - Redirect for \"/\""
 when "302": "Site is responding with a 302 - Redirect for \"/\""
 when "403": "TRACE is disabled. 403 Forbidden"
 when "404": "TRACE is probably disabled. 404 Not Found"
 when "405": "TRACE is disabled. 405 Method Not Allowed Response"
 when "501": "TRACE is disabled. 501 Not Implemented Response."
 else "Unexpected Response."
end

From what I've learned in my research over the past few months as well as experimentation on my own sites, you can expect several different types of responses to TRACE requests based upon site platform and site layout architecture.

If you are running IIS4 or IIS5 or any version of Apache, by default the TRACE method is enabled. The best way you can disable it in IIS4 and IIS5 is by installing URLScan. Remediation in apache can be done in two different ways. One method involves setting the TraceEnable directive to Off. This only works if you are running a more recent version, (Apache 1.3.34, 2.0.55 and later). The other mechanism that works on all apache versions that support mod_rewrite involves writing a condition and rule to forbid trace requests:

RewriteEngine on 
RewriteCond %{REQUEST_METHOD} ^TRACE 
RewriteRule .* - [F]

If you are running IIS6 or IIS7, the TRACE method is disabled. If you are running Tomcat, Glassfish, or JBoss Application Server as the front-end for your sites, the TRACE method is disabled by default. The status code returned by IIS6/7 is different from tomcat, however. IIS responds with a 501 status code while tomcat responds with a 405 status code.

If you load-balance your websites with a BigIP, you can write an iRule that will discard all TRACE methods and assign that rule to all of your VIPs. A basic iRule that drops TRACE requests looks something like this:

when HTTP_REQUEST {
set default_pool [LB::server pool]
if { [HTTP::method] equals "TRACE" } {
reject
} else {
pool $default_pool
}
}

The action that the rule takes when the condition is met is to drop the packet. From a network sniffer standpoint, you will see the BigIP issue a connection reset when a TRACE request is sent to a VIP that is utilizing this particular iRule.

The script above allows me to determine which of my sites are vulnerable to TRACE requests and, depending upon the remediation steps taken, gives me a mechanism for validating those changes. Since all of my sites are front-ended with a BigIP, I can simply utilize the iRule to drop those requests and validate by trapping the connection reset but with the addition of better handling of responses pre- and post-remediation, the script becomes more portable to validate remediation actions for a larger number of possible site configurations. Want to validate that apache is responding as expected after setting TraceEnable to Off? This should do it. Do you want to verify that URLScan is working? This script should do it.

The script should not follow redirects, which is helpful in false-positive determination. However, when a redirect is issued, you should re-run the script against the redirect target. In other words, if "http://yoursite.yourdomain.com/" redirects to "http://yoursite.yourdomain.com/home/", running the script against the former should result in either a 301 or 302 response. So, execute the script against "http://yoursite.yourdomain.com/home/" directly instead.

Instead of coming out with a page for each platform and another page for updates, this page will serve as the anchor page for TRACE and any updates will be made directly to this page instead. All the other pages will be updated to link to this one.

Perils of Production: Moving Content Between Staging and Production

A well known children's television web site recently went live with a new service for kids. As part of the login account creation process, a parent or guardian needs to fill out a basic sign up form (which only required an email address and a password). An email verification gets sent to the email address on record and, once verified by clicking the embedded link in the message, the account creation process setup is complete. This is all a fairly standard practice. All kinds of sites have been doing this for years but when my wife started the sign up process, she kept getting a basic authentication sign-on message box when trying to complete the verification process and nothing she tried would work to sign in. She would try multiple types of email accounts and browsers over the course of the next few days to no avail and wound up walking away extremely frustrated.

After thinking about this off and on for a day or so, if finally occurred to me that maybe the problem wasn't with the site but with the link that was embedded in the verification email. Guessing that the site that was embedded in the email verification was a staging site, I simply copied and pasted the URL in the browser and swapped the hostname with the regular site address and everything worked great. Had the embedded URL been obvious like "staging.testsite.com", it probably would have occurred to me sooner but the site name wasn't that obvious. Now my wife thinks I'm a hero and my youngest kids get to think for another few days that their Dad can do anything.

Sending out the wrong email address in a link to customers and potential users though is not a unique problem. I've seen it happen many times over the years with several companies that I've worked for and it got me thinking that the process of moving something between environments is not really something that I've seen automated well--some manual intervention is always required and it is this manual intervention that has the most room for error. One can certainly mitigate errors by using relative URLs as much as possible everywhere but in customer communications and when switching between secured and unsecured modes on your sites, absolute URLs become a necessity.

I'm very interested in hearing what other folks have done when it comes to moving content between environments and making sure that all the URLs and hostnames stored in application configuration files point to the right places.