Blogging Techstacks

SSL is a Pain in the Ass

While logging into my TypePad account tonight, I was greeted in Safari 5 with one thing that I, as a web site administrator, hate to see:

Yep.  TypePad's SSL certificate must have been up for renewal, they renewed it with a cert from GoDaddy, and Safari is freaking out about it. When these kind of things happen, it reminds me how sucky SSL can be and how we web site administrators end up looking silly to our bosses and customers for things that are often out of our control.  If you are a customer of TypePad and seeing this message like I am, don't go giving them a hard time about it.  It happens.  It sucks when it does but it happens and sometimes we can't do anything about it.

If any of TypePad's site administrators are reading this, let me just take this time to say that I get it.  I really, really do.  I've been there.   Forces are against us.  SSL is a pain in the ass.  Certificates expire in the middle of the week.  CA's advertise $29 certificates that we dare not use otherwise the security folks will be in our cubes slamming us for buying domain-validated certs.  Certificate vendors change their root or intermediate certificates all the time.  Browser vendors implement their own certificate stores populated with whatever root and intermediate certs the CA's paid them to include.  OpenSSL and JSSE have their own keystores.  Keys go away and new ones get added in when updates are applied.  Application servers often have their own keystores as well.  Some browsers display problems while other browsers do not.  I've been a long-time customer of one particular CA for over a decade and one time I remember seeing emails from them stating that sometime in the first or second quarter of next year, they will be signing newly ordered certificates with a new intermediate cert.  Sometime over the course of a future six month period?  Really??  Will I find out which one I should be chaining when I implement it and get all those Unknown CA warnings?

In todays case with TypePad, Chrome and Safari 5 burp up a warning that the certificate is not trusted.  Firefox and Opera, however, let it go.  As a technical user, I wonder if I'm seeing a TypePad configuration problem or is it simply that Chrome and Safari's (or my operating system's) keystores lack the proper CA certificate?  How should a user react?  It's not something that one can simply say "ah ha!" to and thereby know whether or not you should trust the connection.  Should my trust in Apple or Google be shaken now?  Is my trust in Opera strengthened because of this incident?  Should I be trusting TypePad?  Why isn't Firefox warning me?  Is it broken or is it working?  Why is IE6 letting everything through?  SSL is supposed to be about trust but when you actually think about all the problems that can and do arise, how can we trust it?   A green bar?

Browser writers and ssl library developers should not be placing this much technical responsibility in the hands of the average end-user.  They should not be putting up some vague message that says "This certificate was signed by an unknown authority."  There aren't too many people who know what that means.  The message should be something like, "The certificate in use on this web site is not recognized by this browser.  This could actually be this browser's fault for not having the latest certs.  Or the operating system's fault.  This could also be a self-signed cert.  Or the site's configured incorrectly.  Or the site's been hacked.  Or school is out and some junior in high school is intercepting your connection.  Do you still trust SSL?"  Chrome does a somewhat better job informing the user about what happened but then ruins it by painting everything red and placing that "Back to Safety" button on the page, which is ironic because the page you're fleeing back to safety to is likely not an SSL encrypted page.

A side note to GoDaddy:  What the heck is up with that expiration timestamp?  6:32:47 PM Eastern time?  Seriously?  Couldn't you have at least cut them a break and rounded it up to 7 PM?  I can see the discussion clearly in my mind with the finance people.  "We need this PO cut because at 32 minutes, 48 seconds after the 18th hour of the day, we'll be down!"

Scanning for Unsafe URLs

One thing that I have noticed in recent PCI Compliance scans is that some scanning vendors are now starting to scan for "unsafe" urls exposed to the Internet on web sites.  Typically, an "unsafe" URL could be a tomcat status page, a jboss management console, an apache mod_status page, or similar URL that you do not want exposed to the Internet--not necessarily because of a vulnerability that may exist within that URI but because it may disclose information that you wouldn't want the general public to view. 

Take a look at the Apache Software Foundations server status page.  The ASF doesn't sell anything online, so they probably do not need to be bothered with PCI scans but take a look at some of the information the server status page provides.  You get the apache version number, a general overview of whether the site is running openssl, mod_perl, mod_php, etc., and you get a nice listing of all the client IP addresses currently accessing the site.  If you are running an electronic commerce site, you don't want this kind of information displayed to the Internet-at-large, (although you may want to be able to view this information yourself--hence the BigIP iRule also references in this post).

So, I've put a small perl script together that people can use as a starting point that will scan for specific URLs on a web site and report back on whether or not an "unsafe" URL has been found.  The script is intended to be used as a remediation validation tool by an individual who is responsible for maintaining the security of their web sites.  I'm also including a basic irule that can be placed on your BigIP LTM (if you use one) that will reject requests for these URLs if they hit the BigIP--and you can drop them before passing them along to the web or application server for your site.  Placing them on your BigIP allows you to keep the functionality that this information provides to the administrator while restricting it from public view.

The list of URLs in these scripts is intentionally meant to be short and is not complete.  It only is meant to serve as a starting point and to keep this post relatively short.  ColdFusion shops may want to tweak the script and irule to include the ColdFusion administrator, for example.  You could tweak it to scan or reject access to those scary FrontPage URLs.  The list of URLs that will get you flagged during a PCI scan will, unfortunately, grow quite large in a heterogeneous network. 

Below is a started irule to get started with:

when HTTP_REQUEST {
    switch -glob [HTTP::uri] {
        "/server-info*" {
            reject }
        "/jk-status*" {
            reject }
        "/server-status*" {
            reject }
        "/balancer-manager*" {
            reject }
        "/IISSamples*" {
            reject }
        "/MSADC*" {
            reject }
        "/IISHelp*" {
            reject }
        "/IISAdmin*" {
            reject }
        "/manager/html*" {
            reject }
        "/jsp-examples*" {
            reject }
        "/servlets-examples*" {
            reject }
        "/jmx-console*" {
            reject }
        "/status*" {
            reject }
        "/web-console*" {
            reject }
        "/admin-console*" {
            reject }
    }
}

Below is the perl script I wrote that will scan for these URLs and report the results, color-coded red for failures and green for successes.

#!/usr/bin/env perl
# Usage:  ./badurlscan.pl --host <host>  --port <port>

use Modern::Perl;
use Term::ANSIColor qw(:constants);
use Tie::Hash::Indexed;
use Net::SSLeay;
use LWP::UserAgent;
use Getopt::Long;

my ( $host, $port, $scheme );
my $useragent = 'techstacks.com-bad-url-scanner/v0.1.1';

my $key;
my $value;

sub usage{
  say "Usage:  badurlscan.pl --host HOSTNAME  --port PORT";
  exit;
}

usage() if ( ! GetOptions("host=s" => \$host, "port=s" => \$port,) or ( ! defined $host) or ( ! defined $port) );

if ( $port eq 443 ) {
  $scheme = 'https';
  }
elsif ( $port eq 8443 ) {
  $scheme = 'https';
  }
else {
  $scheme = 'http';
  }

tie my %bad_urls, 'Tie::Hash::Indexed';

%bad_urls = (
  'Apache mod_status page' => 'server-status',
  'Apache mod_info page' => 'server-info',
  'Apache mod_jk status page' => 'jk-status',
  'Apache mod_proxy_balancer' => 'balancer-manager',
  'IIS Samples' => 'IISsamples/',
  'IIS MSADC Directory' => 'MSADC/',
  'IIS Help' => 'IISHelp/',
  'IIS Admin' => 'IISAdmin/',
  'Tomcat Manager' => 'manager/html',
  'Tomcat JSP Examples' => 'jsp-examples/index.html',
  'Tomcat Servlet Examples' => 'servlets-examples/index.html',
  'JBoss JMX Console' => 'jmx-console',
  'JBoss Tomcat Status Page' => 'status',
  'JBoss Web Console' => 'web-console',
  'JBoss 5.x Admin Console' => 'admin-console',
  'ColdFusion Administrator' => 'CFIDE/administrator/index.cfm',
  );

sub scan_for_unsafe_urls{
  print "\n";
  say "Scanning for 'Unsafe' URLs....";
  sleep 2;
  my $response;
  my $request;

  while (($key,$value) = each(%bad_urls)) {
    my $url = "$scheme://$host:$port/$value";
    my $ua = LWP::UserAgent->new;
      $ua->timeout(10);
      $ua->max_redirect(0);
      $ua->env_proxy;
      $ua->agent( $useragent );

    my $request = HTTP::Request->new( GET => $url );
    my $response = $ua->request($request);

  if ($response->code == '200') {
    print RED, "  " . $key . " -- /". $value . " found." . "\n", RESET;
    }
    else {
      print GREEN, "  " . $key . " -- /" . $value . " not found." . "\n", RESET;
      }
  }
}

scan_for_unsafe_urls();

Thanks for taking the time to look through this. Let me know if it was helpful or has any glaring errors!

Safari 5 Is Out

Apple released Safari 5 today for Windows and OS X.  Get it at the download page.  The What's New page lists all the new features (that were still not cool enough to get a mention during today's WWDC keynote) but some of them include:

• Safari Reader - This looks like Apple's answer to ad-blocking while simultaneously providing something that will make the bloggers all upset.  Implemented as a toolbar button, once clicked, all sidebars will be dimmed and an on-screen display will pop up offering print, email, and font size control options.  Presumably, Safari Reader will work best with the new html5 article tag.
• HTML 5 - Safari 5 is adding more HTML 5 support including Full Screen views and closed captioning. 
• Faster - Performance improvements to the Nitro JavaScript engine and DNS Prefetching hopes to make things snappier.
• Plugins/Extensions - Safari now adds supports for third-party developed extensions.  The new, free Safari Developer Program provides technical resources, a code signing facility, and developer forums.