6 posts categorized "webseal"

07/22/2010

Disabling TLS Renegotiation in WebSEAL

The TLS Renegotiation vulnerability is getting more and more attention lately primarily because updates and patches have been coming out that supposedly "fix" the issue by disabling TLS Renegotiation.  IBM is no different from Oracle or Microsoft and has published this page to download updates to GSKit that contains the "fix".  (IBM Universal ID required to download updates).  SSL/TLS support in WebSEAL is through GSKit.

Once the update is applied, TLS Renegotiation will not work.  For most client connections, disabling TLS Renegotiation will not have an impact but stay tuned because later today I'll be publishing a post that details the types of connections that I think will be impacted (and problems that we'll see) when TLS Renegotiation is disabled.

Yes, I understand that this is a flaw in the TLS protocol itself and will take time to fix but I'm afraid that these interim fixes will cause me more production problems than those that will be averted.

Posted by Chris Mahns at 11:00 AM in ssl, tls renegotiation, webseal | Permalink | Comments (0) | TrackBack (0)

03/30/2010

WebSEAL: Enabling Trace Logging

There are going to be times when you will need to enable trace logging in WebSEAL in order to troubleshoot some kind of issue.  To enable, you will need to locate the routing file (typically located in the same directory as your webseald instance configuration file) and uncomment the entry that looks something like this:

 #*:*.9:TEXTFILE.10.1000:/path/to/webseald/message/logs/trace__%ld.trace.log:644:ivmgr:ivmgr

Restart the webseald process that you're looking to collect data on but be forewarned, it creates an awful lot of files!

Posted by Chris Mahns at 7:31 PM in logging, webseal | Permalink | Comments (0) | TrackBack (0)

06/27/2009

WebSEAL: Cheap and Easy Way to Rewrite HTTP to HTTPS

One common, but minor, bit of frustration after setting an SSL Quality-of-Protection (QOP) ACL on a webseal junction is that it is not second-nature for an end-user to enter 'https' in the browser bar. Our brains still default to http but once you set that QOP level on your junction, accessing it over an unencrypted link results in one of those relatively generic-looking, default WebSEAL error pages suggesting you re-try using HTTPS instead.

Well, for those of you looking to suppress that error and automatically redirect the browser to an encrypted channel instead, all you need to do is modify the custom error page for WebSEAL and enter some simple javascript that will redirect http to https.

Each webseal instance ships with it's own set of custom error pages, which are typically located in /opt/pdweb//lib/errors/C. The page in question that you'll want to back up and then edit is 38cf0434.html. Replace the head and body with the following:
<html><head><title>Error 403.4</title>

<meta name="robots" content="noindex">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"></head>

<body>

<script language="JavaScript">
var href = self.location.href;
var originalURL = href.substring(7,href.length);
self.location = 'https://' + originalURL;
</script>

</body>
</html>
This is pretty standard javascript that redirects requests to use https without modifying any other part of the original URL. Give it a try or post something in the comments if you've got something even cooler than this.

Posted by Chris Mahns at 12:00 AM in javascript, ssl, webseal | Permalink | Comments (5) | TrackBack (0)

Next »