Tag: ssl

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?

Using the IBM Connections API from other languages using custom certificates

I was reading up on some stuff in the IBM Connections REST API during the weekend and came across a post titled Using IBM Connections API in different programming languages on how to use the REST API from other languages than JavaScript from within IBM Connections. The approach there is very nice and quite valid but it fails to mention what to do if the SSL certificate of the API endpoint either isn’t trusted or isn’t certified using a “known” root certificate. In this case “known” means to the Java runtime you’re using or the runtime of any other language for that matter. Here I’m only dealing with Java though.

By default the java.net classes will not allow a SSL connections to a server using a unknown/untrusted certificate but there are ways around that. Of course the best is always to make sure that the certificate of the server may be validated by the Java keystore (including intermediate certificates) but for testing – or if you know what you’re doing – simply ignoring the certificate test can be beneficial. Below is some code showing how to configure the SSL runtime to ignore the certificate and hostname checks. The code is a static configuration method and I deem it pretty readable. The code allows *all* certificates but could pretty easily be locked down to be more restrictive if need be.

private void enableSelfSignedCerts() throws Throwable {
  TrustManager[] trustAllCerts = new TrustManager[] {
    new X509TrustManager() {
      public java.security.cert.X509Certificate[]
        getAcceptedIssuers() {
        return null;
      }
      public void checkClientTrusted(X509Certificate[] certs,
          String authType) {
      }
      public void checkServerTrusted(X509Certificate[] certs,
        String authType) {
      }
    }
 };

 SSLContext sc = SSLContext.getInstance("SSL");
 sc.init(null,
         trustAllCerts,
         new java.security.SecureRandom());
  HttpsURLConnection.
    setDefaultSSLSocketFactory(sc.getSocketFactory());

  // Create all-trusting host name verifier
  HostnameVerifier allHostsValid = new HostnameVerifier() {
    public boolean verify(String hostname,
      SSLSession session) {
      return true;
    }
  };

  // Install the all-trusting host verifier
  HttpsURLConnection
    .setDefaultHostnameVerifier(allHostsValid);
}

http://./files/prettyprint/prettify.js

prettyPrint();

Using a non self-signed certificate with Lotus Connections

When you deploy Lotus Connections you find out that the login has to be done using SSL and hence you need a SSL certificate. When Lotus Connections is installed a self-signed certificate is generated but you’ll probably want to use a “real” certificate whether this be one signed by a public CA or one signed by a corporate CA. Doing this is quite simple if you only swap out the IBM HTTP Server certificate as this only requires change to httpd.conf and using the ikeyman application.

Although the ikeyman application looks like something from another century it works and does its job. To launch it go to c:websphereappserverprofilesappserver1bin and invoke ikeyman.bat (substitute the path as appropriate). Once this is done follow the documentation to create a new keystore database (KDB format) and create a stash file. Then generate a new key pair and submit the keys for certification at your CA (again follow the documentation). The stash file is used by the web server to open the otherwise encrypted keystore without a password.

When you receive the reply please bear in mind that the certifying certificate must be in the keystore before accepting the reply. For most CA’s this will require you to import a certificate before proceeding. This goes for Equifax as well as Verisign. The easiest way to find these is to surf to your CA and search for “intermediate”.

Once this is done you can import the certificate reply, update httpd.conf, restart IHS and you’re laughing…