Getting ready for iOS 9 and App Transport Security (ATS)

Much has already been written on the web about the upcoming iOS 9 release and how Apple is tightening security with App Transport Security (ATS) which basically only allows for HTTPS traffic using advanced and secure ciphers. Other voices in the community is staying on top and blogging much more about it and how it pertains to IBM Traveler and particularly if you are terminating your IBM Traveler connections on Domino. As it stands now (IBM Domino 9.0.1 FP4) IBM Domino cannot deliver the ciphers required for ATS. While the latest beta of iOS 9 can still connect insecurely I suggest you start to look for a right solution that is terminating your IBM Traveler traffic using TLS v. 1.2 using Elliptic Curve crypto and Diffie-Hellman key exchange.

For one of our OnTime Group Calendar demo servers we have IBM HTTP Server (IHS) in front which made the process pretty easy as IHS already support the required ciphers. As always configuring security is a mix of securing your server while keeping compatibility with older operating systems and browsers. For me this meant allowing both TLS v. 1.0, 1.1 and 1.2 and keeping some less secure ciphers for older operating systems and browsers while also enabling strong crypto to support ATS.

Below is our configuration from domino.conf which is used to configured IHS for IBM Domino (there are two ciphers supported by ATS that are not supported by IHS (based on SHA-1)).

Listen 0.0.0.0:443
<VirtualHost *:443>
ServerName demo.ontimesuite.com
SSLEnable
SSLProtocolDisable SSLv2 SSLv3
SSLCipherSpec ALL NONE
SSLCipherSpec TLSv12 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
SSLCipherSpec TLSv12 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
SSLCipherSpec TLSv12 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
SSLCipherSpec TLSv12 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
SSLCipherSpec ALL TLS_RSA_WITH_AES_128_GCM_SHA256
SSLCipherSpec ALL TLS_RSA_WITH_AES_256_GCM_SHA384
SSLCipherSpec ALL TLS_RSA_WITH_AES_128_CBC_SHA256
SSLCipherSpec ALL TLS_RSA_WITH_AES_256_CBC_SHA256
SSLCipherSpec ALL TLS_RSA_WITH_AES_128_CBC_SHA
SSLCipherSpec ALL TLS_RSA_WITH_AES_256_CBC_SHA
SSLCipherSpec ALL SSL_RSA_WITH_3DES_EDE_CBC_SHA

# Enable strict CBC padding (TLS Poodle)
SSLAttributeSet 471 1

</VirtualHost>
KeyFile C:/Lotus/Domino/ihs/key.kdb
SSLDisable

Making the above configuration changed will give you a A- score on ssllabs.com which is a pretty nice score while keeping backwards compatibility. If that kind of config isn’t needed turn off TLS v. 1.0 and 1.1 and remove the lines starting with “SSLCipherSuite ALL” – that will give you a score of A.

Listen 0.0.0.0:443
<VirtualHost *:443>
ServerName demo.ontimesuite.com
SSLEnable
SSLProtocolDisable SSLv2 SSLv3 TLSv10 TLSv11
SSLCipherSpec ALL NONE
SSLCipherSpec TLSv12 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
SSLCipherSpec TLSv12 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
SSLCipherSpec TLSv12 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
SSLCipherSpec TLSv12 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

# Enable strict CBC padding (TLS Poodle)
SSLAttributeSet 471 1

</VirtualHost>
KeyFile C:/Lotus/Domino/ihs/key.kdb
SSLDisable

Fixing IBM Connections help for IE users

At a customer site they were actually using the IBM Connections help documents (a first I know) but it didn’t work for the users in Internet Explorer. After some research it turned out to be due to a missing compatability statement in the generated HTML documents (this statement is present in HTML generated for other features). I’ve previously reported this issue to IBM but it still hasn’t been fixed in version 4.0 CR3 so I took it upon me to find a solution. The solution turned out to be simpel using a “sledgehammer approach”. I simply used one of the cool modules in IHS (Apache) to add a compatability header to force all document into IE7 mode.

Below are the steps – YMMV.

  1. Open your httpd.conf file for edit
  2. Uncomment the mod_headers module near the top by removing the hash-character at the beginning so the line simply reads “LoadModule headers_module modules/mod_headers.so”
  3. At the end of the file simply paste in the following command
    Header set X-UA-Compatible IE=7
  4. Save and close the file
  5. Restart the IHS

Remember to secure your IBM HTTP Server when implementing IBM Connections

In Security Now! episode 396 starting at 12:22 (to 25:25) Steve and Leo were talking about various SSL attacks and how one could verify sites. I decided to check out one of my own stock IBM Connections installs i.e. I verified the stock IBM HTTP Server (IHS) install. That was not a pleasant experience as the default IBM HTTP Server is very insecure in that it accepts SSL v.2 and hence some very weak ciphers. Using SSLLabs.com and their SSL Server Test it is very easy to test a SSL site.

Below is the results from a standard IHS install using a commercial SSL certificate. A grade of F isn’t nice.

After reading a bit on mod_ssl (the SSL module in Apache / IHS) I added the below lines to the mod_ssl section in the httpd.conf file.

## SSLv3 128 bit Ciphers
SSLCipherSpec SSL_RSA_WITH_RC4_128_MD5
SSLCipherSpec SSL_RSA_WITH_RC4_128_SHA

## FIPS approved SSLV3 and TLSv1 128 bit AES Cipher
SSLCipherSpec TLS_RSA_WITH_AES_128_CBC_SHA

## FIPS approved SSLV3 and TLSv1 256 bit AES Cipher
SSLCipherSpec TLS_RSA_WITH_AES_256_CBC_SHA

Now I’m not a SSL wizard by any means so I suggest you do your own research as well but when I restarted the IHS I got a rating of A. BAM!! How’s them apples!?

How secure is the SSL stack for your IBM Connections environment?

File not found when using IBM Connections Media Gallery

At a customer users were reporting that the media gallery in IBM Connections did not work. The error they were seeing was aneror message in the UI telling them that the file they just selected from their file system did not exist. Very strange. After diagnosing the issue it was caused by the media gallery not having been set up correctly as the default file types wasn’t imported into the configuration. Why these defaults are not set automatically is the topic for another day.

There are two templates which determine the file types you can upload
by default. You should also have these in your AppSrv01 profiles, or your
nodes, etc. The step is done by following the instructions in the info center.

Disabling HTTPS communication between IHS WAS Plugin and WAS servers

Many people believe that you have to have multiple servers to run IBM Connections – this simply isn’t true! There’s no reason why you cannot run everything of the same server which is what we do here at the office. When you do that, if all servers are inside the firewall – or if you simply doesn’t care about the security that it provides – you can disable the IHS WAS Plugin from communicating with the WAS server using SSL. A benefit from this is among other things that you do not have to care about certificates between the IHS WAS Plugin and the WAS server which simplifies installation and management.

Any way… For a while I’ve doing this configuration change manually directly in plugin-cfg.xml (by commenting the HTTPS transport out) until it bit us the other day. So I finally decided to find a proper, correct, solution. And of course there is a way to do this and it’s very well documented in IBM Technote 1452735. So if you want to make that change go ahead and do it – I did and it’s working flawlessly.

Installing Lotus Connections 2.5 on Windows 2008 Server

The last two weeks I have had the honor of installing Lotus Connections 2.5 on Windows 2008 Server 64 bit with Microsoft SQL Server 2005. Twice. And what a change from my normal Windows 2003 Server. In this blog post I’ll outline some of the issues I ran into and what I had to pay special attention to.

First off Tivoli Directory Integrator 6.1.1 (the component that move data from LDAP to the Profiles SQL database) isn’t supported and doesn’t run on Windows 2008 Server. The TDI scripts provided with Lotus Connections 2.5 doesn’t work with TDI 7 which leaves you at a dead stop. Only solution as of now is to find a Windows 2003 Server or other Windows platform to run TDI. Hopefully Lotus Connections NEXT will use TDI 7.

Next issue I had to address was that Websphere Applicaton Server (WAS) 6.1 should be at fixlevel 19 before you create any profiles on a Windows 2008 Server. This meant that the profile couldn’t be created as part of the WAS installer. This wasn’t too big of an issue as it’s a best practice not create the profile during setup anyway. A benefit of doing it this way is that it allows you to create the profile in another location than between your WAS binary directory.

So all was well and good? Not really as the GUI tool to manage profiles isn’t supported on Windows 2008 Server either. There is however a manageprofiles command to manage profiles which may be used. The command looks rather convoluted but it goes something like this (I ran it was admin):

manageprofiles.bat -create -profileName AppSrv01
   -profilePath d:WASProfilesAppSrv01
   -templatePath c:ibmwebsphereappserverprofileTemplatesdefault
   -nodeName LotusConnectionsNode01
   -cellName LotusConnectionsCell01
   -hostName lc.example.com
   -isDefault
   -winserviceCheck true
   -winserviceAccountType specifieduser
   -winserviceUserName username
   -winservicePassword password
   -winserviceStartupType manual

The last few arguments create the Windows service. I have had some success doing this but most times I leave the “winservice”-arguments out and use WASService.exe to create the service instead.

wasservice -add LotusConnections
   -serverName server1
   -profilePath d:wasprofilesappsrv01
   -startupType automatic

When I installed Lotus Connection I had to run install.bat as admin to avoid having the SQL connection check fail.

Generally in Windows 2008 Server I found that paying special attention to drive and folder security made my life a lot easier. That goes for both WAS and IBM HTTP Server IHS). Additionally on one IHS server I had to manually install GSKit to enable SSL as it wasn’t installed by the installer. I also had to put GSKit (C:IBMGSK7lib) on the PATH in Windows. To symptom was that IHS couldn’t access the SSL keystore.

I hope this will help someone.

SSL certificates and the WAS plugin

Had some issues yesterday morning with the SSL certificate used between the WAS IHS plugin and WAS for a Lotus Connections installation (Dannotes in case you were wondering why you couldn’t log in this morning). Again it turned out to be the all to well known “ERROR: lib_stream: openStream: Failed in r_gsk_secure_soc_init: GSK_ERROR_BAD_CERT(gsk rc = 414)” issue where the SSL certificate from WAS isn’t trusted by the IHS WAS plugin.

The issue were “easily” solved by help of Technote 1264477 (GSK_ERROR_BAD_CERT error configuring SSL between Plug-in and Application Server V6.1). The solution is of course to extract the certificate from WAS and import it into the IHS WAS plugin keystore.