A Portal to a Portal: IBM HTTP Server - Fun with Transport Layer Security

I've been experimenting with encryption in the context of IBM HTTP Server (IHS), specifically in terms of enforcing Transport Layer Security (TLS) 1.2 and a tight set of ciphers.

Firstly, I generated a signer certificate using the IBM Global Security Toolkit (GSK) with a key length of 2048 bits using the Secure Hashing Algorithm (SHA) as the signature algorithm and Rivest-Shamir-Adleman (RSA) as the encryption algorithm.

This is how I did it: -

/opt/ibm/HTTPServer/bin/gskcapicmd -cert -create -db /opt/ibm/HTTPServer/ssl/keystore.kdb -pw passw0rd -size 2048 -dn "cn=wasdemo.uk.ibm.com,dc=uk,dc=ibm,dc=com" -label "wasdemo.uk.ibm.com" -default_cert yes -sigalg SHA256WithRSA

Having done this, and validated it: -

/opt/ibm/HTTPServer/bin/gskcapicmd -cert -details -db /opt/ibm/HTTPServer/ssl/keystore.kdb -pw passw0rd -label "wasdemo.uk.ibm.com"

...

Key Size : 2048
Version : X509 V3
...

Public Key Type : RSA (1.2.840.113549.1.1.1)
Fingerprint : SHA1 :
  41 BB 35 E5 6B 21 01 01 4E B4 5E 4B FC 09 BE B5
  B2 FD 7B A2
Fingerprint : MD5 :
  AC D8 C2 E0 2B E1 23 24 3A DF E8 4A 5E 74 CC CA
Fingerprint : SHA256 :
  4D 6D A5 5F 72 6E 35 32 AC DA DE AD 65 E9 6A A1
  F8 3B AB A3 B3 08 DC 43 4D 15 4C 3E 78 23 F5 A6
...

Signature Algorithm : SHA256WithRSASignature (1.2.840.113549.1.1.11)
...

I then reconfigured the IHS configuration - httpd.conf - for TLS: -

...

LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
Listen 8443
<VirtualHost *:8443>
SSLFIPSEnable
SSLProtocolEnable TLSv12
SSLProtocolDisable SSLv2 SSLv3 TLSv10 TLSv11
SSLCipherSpec TLSv12 TLS_RSA_WITH_AES_256_CBC_SHA256SSLEnable
</VirtualHost>
KeyFile /opt/ibm/HTTPServer/ssl/keystore.kdb
SSLCacheErrorLog /opt/ibm/HTTPServer/logs/sidd_log
SSLCachePortFilename /opt/ibm/HTTPServer/logs/siddport
ScriptSock logs/cgisock
SSLDisable
...

I've highlighted the four pertinent lines, one of which enforces a specific cipher - TLS_RSA_WITH_AES_256_CBC_SHA256.

I then validated the SSL/TLS configuration: -

/opt/ibm/HTTPServer/bin/apachectl -DDUMP_SSL_CONFIG

SSL configuration:
Default server
Server name: wasdemo.uk.ibm.com:8080
SSL enabled: NO

SSL server defined at: /opt/ibm/HTTPServer/conf/httpd.conf:858
Server name: wasdemo.uk.ibm.com:8443
SSL enabled: YES
FIPS enabled: 1
Keyfile: /opt/ibm/HTTPServer/ssl/keystore.kdb
Protocols enabled: TLSv12
Ciphers for SSLV2: (protocol disabled)
Ciphers for SSLV3: (protocol disabled)
Ciphers for TLSv10: (protocol disabled)
Ciphers for TLSv11: (protocol disabled)
Ciphers for TLSv12: TLS_RSA_WITH_AES_256_CBC_SHA256(3D)

Syntax OK

which looked A-OK.

I then started IHS: -

/opt/ibm/HTTPServer/bin/apachectl -k start -f /opt/ibm/HTTPServer/conf/httpd.conf

I then monitored the error log: -

tail -f /opt/ibm/HTTPServer/logs/error_log

[Mon Oct 05 13:55:36 2015] [notice] Using GSKit version 8.0.50.34
[Mon Oct 05 13:55:36 2015] [notice] WebSphere Plugins loaded.
[Mon Oct 05 13:55:36 2015] [notice] Bld version: 8.5.5
[Mon Oct 05 13:55:36 2015] [notice] Bld date: Oct 30 2014, 11:39:36
[Mon Oct 05 13:55:36 2015] [notice] Webserver: IBM_HTTP_Server
[Mon Oct 05 13:55:36 2015] [notice] Using config file /opt/ibm/HTTPServer/conf/httpd.conf
[Mon Oct 05 13:55:36 2015] [notice] IBM_HTTP_Server/8.5.5.4 (Unix) configured -- resuming normal operations
[Mon Oct 05 13:55:36 2015] [notice] Core file limit is 0; core dumps will be not be written for server crashes

and tested IHS using a variety of browsers ( on my Mac, whilst IHS runs on Linux ): -

https://wasdemo.uk.ibm.com:8443

Interestingly, I got a variety of responses, none of them good: -

Firefox 41.0.1

An error occurred during a connection to wasdemo.uk.ibm.com:8443. Cannot communicate securely with peer: no common encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap)

Chrome 45.0.2454.101
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Opera 32.0

This webpage is not available

A secure connection cannot be established because this site uses an unsupported protocol.

Interestingly, Apple Safari had a completely different result: -

Safari Version 9.0 (10601.1.56.2)

It just worked :-)

I checked the IHS error log, and saw: -

[Mon Oct 05 13:58:41 2015] [warn] [client 192.168.1.77] [7fd9780028d0] [123070] SSL0222W: SSL Handshake Failed, No ciphers specified.  [192.168.1.77:51689 -> 192.168.1.80:8443] [13:58:41.000261206] 0ms
[Mon Oct 05 13:58:41 2015] [warn] [client 192.168.1.77] [7fd9800028d0] [123106] SSL0222W: SSL Handshake Failed, No ciphers specified.  [192.168.1.77:51690 -> 192.168.1.80:8443] [13:58:41.000268287] 0ms
[Mon Oct 05 13:58:41 2015] [warn] [client 192.168.1.77] [7fd97c0008c0] [123070] SSL0222W: SSL Handshake Failed, No ciphers specified.  [192.168.1.77:51691 -> 192.168.1.80:8443] [13:58:41.000611417] 0ms
[Mon Oct 05 13:58:41 2015] [warn] [client 192.168.1.77] [7fd9840008c0] [123106] SSL0222W: SSL Handshake Failed, No ciphers specified.  [192.168.1.77:51692 -> 192.168.1.80:8443] [13:58:41.000632584] 0ms

After some digging, consideration and further digging, I concluded that it's all my fault :-)

In essence, I've chosen a cipher that the three "failing" browsers do not support, and I've "told" IHS to only use that one cipher.

There were a few mitigations: -

(1) Amend httpd.conf and relax the need to only use that one cipher: -

SSLCipherSpec TLSv12 +TLS_RSA_WITH_AES_256_CBC_SHA256

( in other words, I added a single plus + character to the beginning of the cipher name )

This is validated thusly: -

/opt/ibm/HTTPServer/bin/apachectl -DDUMP_SSL_CONFIG

(2) Choose another cipher IF I wish to only offer one up: -

SSLCipherSpec TLSv12 TLS_RSA_WITH_AES_256_CBC_SHA

Note how similar that is to the one that I had previously chosen: -

Old / non-working TLS_RSA_WITH_AES_256_CBC_SHA256

Working TLS_RSA_WITH_AES_256_CBC_SHA

/opt/ibm/HTTPServer/bin/apachectl -DDUMP_SSL_CONFIG

SSL configuration:
Default server
Server name: wasdemo.uk.ibm.com:8080
SSL enabled: NO

SSL server defined at: /opt/ibm/HTTPServer/conf/httpd.conf:858
Server name: wasdemo.uk.ibm.com:8443
SSL enabled: YES
FIPS enabled: 1
Keyfile: /opt/ibm/HTTPServer/ssl/keystore.kdb
Protocols enabled: TLSv12
Ciphers for SSLV2: (protocol disabled)
Ciphers for SSLV3: (protocol disabled)
Ciphers for TLSv10: (protocol disabled)
Ciphers for TLSv11: (protocol disabled)
Ciphers for TLSv12: TLS_RSA_WITH_AES_256_CBC_SHA(35b)

Syntax OK

My conclusion is four-fold: -

(i) Obviously Firefox, Chrome and Opera don't support TLS_RSA_WITH_AES_256_CBC_SHA256 whereas TLS_RSA_WITH_AES_256_CBC_SHA is OK

(ii) Do I really need to only expose a single cipher ? What happens if a client pitches up who just can not support that ?

(iii) If not (ii), then the use of the + symbol allows the browser to negotiate an agreed cipher within a fairly limited range

(iv)  Safari rocks :-)

Interestingly, there was obviously nothing wrong with TLS_RSA_WITH_AES_256_CBC_SHA256 as I was able to successfully validate the configuration: -

/opt/ibm/HTTPServer/bin/apachectl configtest

Syntax OK

However, once I moved to a single AND supported/working cipher - - the browsers were all happy: -

Opera

Chrome

Firefox

Safari

So I couldn't find a way to get Safari to display a padlock for certain sites, including this one :-(

And Finally

For the record, I also validated the secure connection using openssl from the Red Hat CLI, as follows: -

openssl s_client -connect wasdemo.uk.ibm.com:8443

CONNECTED(00000003)
depth=0 DC = com, DC = ibm, DC = uk, CN = wasdemo.uk.ibm.com
verify error:num=18:self signed certificate
verify return:1
depth=0 DC = com, DC = ibm, DC = uk, CN = wasdemo.uk.ibm.com
verify return:1
---
Certificate chain
0 s:/DC=com/DC=ibm/DC=uk/CN=wasdemo.uk.ibm.com
i:/DC=com/DC=ibm/DC=uk/CN=wasdemo.uk.ibm.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDfjCCAmagAwIBAgIIWz28JlZ2dN4wDQYJKoZIhvcNAQELBQAwXTETMBEGCgmS
JomT8ixkARkTA2NvbTETMBEGCgmSJomT8ixkARkTA2libTESMBAGCgmSJomT8ixk
ARkTAnVrMR0wGwYDVQQDExRuZW1kZW1vLm5ic25ldC5jby51azAeFw0xNTEwMDIw
NTU4MDlaFw0xNjEwMDIwNTU4MDlaMF0xEzARBgoJkiaJk/IsZAEZEwNjb20xEzAR
BgoJkiaJk/IsZAEZEwNpYm0xEjAQBgoJkiaJk/IsZAEZEwJ1azEdMBsGA1UEAxMU
bmVtZGVtby5uYnNuZXQuY28udWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDDYlZ/rqMSk8VYTSc0SjaReE75vK5wE+Bn7UAk4tU4VOGV760Gb66norBt
YK/RaoSqfrpxXFapNwXl6w1N37a4tECbtN+hn/6cS312DD4fXVR/bTBJwbxb9Jy3
N2SUlfzEgCfWyopTtNa0BID7M4aWS3F5/D52eCRMVszfJhpm/NCDF1FWCSk+UN1I
dbHnv91tMAGLGVrZ79YMhQH9wyU8Wpujr3/mGU3JuejCDFAXLhtxe7/59FvRLsWw
DGbIrEGbwp9tiGpKUBQT7xt3tr4j/DhZNLz1seS+I3jgFcuF416u3HsVj6Iv4C1j
OAEaC7Jvnkv0p++ceNGW/7ipkBWNAgMBAAGjQjBAMB0GA1UdDgQWBBS+o2rAAIZl
ydjc3Tvr2GssMllXdDAfBgNVHSMEGDAWgBS+o2rAAIZlydjc3Tvr2GssMllXdDAN
BgkqhkiG9w0BAQsFAAOCAQEAaSa8+jdSnp6YaMqjtRtJmRBKkXgFRnvM+/CBEZGg
EP26wmg7QJHmcou8neL9sQoE+73JuBiW4WlUfb2Ah/So5RJIGJJT4dXemj0DFaSN
7FtZBIIeeQosBYkddqR7Hs5AvKtUK3m0l9axlLRPRIMcgzGrtw81A9BhJjTo+2J6
YmFF6aSOHIoYbFLfjxdswGVxR//nomikQCIp+MEBvMKC9yvj/mIR6MN0ajJhspNc
nS9+9M1pPJoakxaEwJvH7J2m78PaCelZKmJIT/tuYQyvFkkY7wPa5wKhEM3ygyCK
wCYU3gndC/O649huI6PqvNeXIaYZW4UNTerMK+yN+RjUuA==
-----END CERTIFICATE-----
subject=/DC=com/DC=ibm/DC=uk/CN=wasdemo.uk.ibm.com
issuer=/DC=com/DC=ibm/DC=uk/CN=wasdemo.uk.ibm.com
---
No client certificate CA names sent
---
SSL handshake has read 1073 bytes and written 591 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
  Protocol  : TLSv1.2
  Cipher   : AES256-SHA   Session-ID: E3E101009910CB491F45C7B8645FBE55D98F6B0258585858AC87125600000042
  Session-ID-ctx:
  Master-Key: DFB1AE0092F7EE2A0815C803E0BF80DC9520E9657B4670F8311DAF40B79170F5D91D4D8B4C389BE110CED221F090FB7E
  Key-Arg   : None
  Krb5 Principal: None
  PSK identity: None
  PSK identity hint: None
  Start Time: 1444054956
  Timeout   : 300 (sec)
  Verify return code: 18 (self signed certificate)
---

*UPDATE 6 October 2015*

This section of the IBM Knowledge Center: -

SSL cipher specifications

was also extremely useful.

*UPDATE 6 October 2015*

A Portal to a Portal

Monday, 5 October 2015

IBM HTTP Server - Fun with Transport Layer Security

No comments:

Note to self - use kubectl to query images in a pod or deployment

Search This Blog