Using Heroku Postgres from local development setup

When developing locally against a Heroku Postgres database (hosted on Heroku) you quickly realize you cannot connect due to a self-signed certificate (or rather Heroku signed certificate). The solution is to ensure that you use the non-validating SSL factory for the connection pool. This is easily done by appending “ssl=true” and “sslfactory=org.postgresql.ssl.NonValidatingFactory” to the database URL i.e. something like the following with the addition in bold:

DATABASE_URL=postgres://foo:bar@ec2-55-222-96-152.eu-west-1.compute.amazonaws.com:5432/baz?ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory

Simple tool to save certificate chain certificates as PEM files

It’s been increasingly frustrating to support our OnTime Group Calendar for Microsoft customers with on-prem Exchange as they usually use a self-signed certificate for TLS resulting in Java throwing a fit. Getting the certificate chain using a browser or OpenSSL is easy enough but for some customers that still prove too difficult. I couldn’t find a tool to automate the export so I wrote a small tool in Java. The tool simply takes the address of the site to contact and saves the certificate chain as individual PEM files ready for import into the Java keystore. Now there is no fingerprint check so use at your own risk. Using the tool is like so:

java Main http://www.ibm.com

The code is available on Github and doubles as an example of how to accept all certificates using a custom TrustManager and HostNameVerifier. I even threw in some Java 8 to make Rene happy 😦

YMMV…

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

IBM announce dates for bringing TLS v. 1.2 to IBM Domino

So in October of 2014 I wrote about the upcoming TLS (transport layer security) enhancements that IBM was planning to bring to IBM Domino as part of the industry wide panic about the POODLE attack which I still consider mainly theoretical. I was a bit critical towards IBM as they chose to patch their seriously lacking SSL v. 1.3 implementation and implement TLS v. 1.0 on top of IBM Domino v. 9.0.x (IBM Domino, POODLE, SHA-1 and why it’s also sad when IBM decides to update the security stack). The reason I was critical was that I thought that you either take security serious and bring the stack to the front of the line (TLS v. 1.2, v. 1.3 in draft) or get out of the game.

Since then I have been pleasantly surprised to hear about the initiatives IBM has going on. At IBM ConnectED 2015 I attended a very nice session by David Kern from IBM and Daniel Nashed (IBM Business Partner) on the TLS and security improvements planned for IBM Domino. Among others was massive cipher suite updates incl. upcoming support for Diffie-Hellman and perfect-forward-secrecy. Cool stuff! Yesterday I was very pleased to see that IBM now has announced the support for TLS v. 1.2 coming in Q1/Q2 of 2015 (the technote is a bit confusing as to when it will be out).

So all appears to be good and IBM is moving in the right direction with this. Very nice.

An important tool results from the whole POODLE/SHA-2 debacle

My stance on the POODLE / SHA-2 issues with Domino is well known and I haven’t been holding anything back. And now – after a while – IBM is starting to release the promised tools to lay the foundation for SHA-2 signature support and TLS 1.0 support on IBM Domino. As part of my IBM Support Updates today I saw and entry called “Planned SHA-2 deliveries for IBM Domino 9.x“. This is a technote outlining how IBM is bringing TLS 1.0 and SHA-2 support. This is all well and good and great that IBM starts to deliver on its promises.

But that’s not all… And by far the most interesting thing to find in that technote.

Burried within this technote is a mention of a tool called kyrtool which replaces iKeyman as the way to work with the KYR keystore file used by IBM Domino. It’s a command line tool and allows for import of standard x509 certificates generated using OpenSSL or similar and produces a KYR and a STH (stash) file as the result. There is documentation about the tool in the wikis (Generating a keyring file with a self-signed SHA-2 cert using OpenSSL and kyrtool). As an added bonus the examples with OpenSSL is done on Dave Kerns paranoia Linux box (dskern@paranoia).

The release of this tool is very good news and cannot be overstated and in my eyes far overshines the support for TLS 1.0 and SHA-2 as it allows administrators to work with the KYR files on Windows versions newer than Windows XP. It ever supports win32, win64, linux32 and linux64. How do you like them apples?

Thank you IBM.

IBM Domino, POODLE, SHA-1 and why it’s also sad when IBM decides to update the security stack

Over the last few weeks the news hit about the PODDLE attack and the withdrawal of SHA-1 as an acceptable hash algorithm by Google Chrome. This is turn has prompted IBM to update the security stack in IBM Domino for all web protocols incl HTTP, LDAP and SMTP. While this is VERY good news and it will be very welcomed that we do no longer have to resort to fronting IBM Domino by IBM HTTP Server or Apache to get adequate TLS protocol support I find the whole situation a bit sad. In full disclosure I have to say that I get most of my security updates these days from the Security Now! podcast on the TWIT network and the discussion on both POODLE and the SHA-1 debacle as opened my eyes. The sad part about these updates to IBM Domino is that it has taken a theoretical attack on SSL v. 3 (POODLE) and a premature hash algorithm withdrawal by a single browser vendor (SHA-1 and Google) to have IBM update the stack. To be fair Microsoft is also removing SHA-1 support from their security stack in their OS’es but from 2017 giving customers ample time to fix it.

In other words if these attacks hadn’t come out IBM would have left IBM Domino customers with ancient protocols and keystore formats – remember it takes Windows XP to run an iKeyman old enough to edit the .key files used in Domino.

Besides being good marketing and blowing some life into the dying embers of IBM Domino it’s almost a sad move when it’s done so late. And then IBM doesn’t even take it seriously enough to go all the way. Instead they outlines their “plan to deliver SHA-2 support for Domino 9.x” and promises a fix to bring TLS 1.0 to IBM Domino. Version 1.0 – seriously?! TLS is in version 1.2 at present and the draft for v. 1.3 is out. Now I know that implementing TLS for SMTP is much different from doing so for HTTP but security cannot be done half heartedly so if you want to make it a priority do that. Do not stop short and plug a hole by not going all the way. In all honesty I would rather have IBM discontinue SSL/TLS all together on Domino than doing this. I know it’s sad but it’s how I feel about it right now.

For a very nice discussion of the PODDLE attack, and why it’s a theoretical attack, do listen to Security Now! episode 478 from 33:22 minutes in.

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?