I had asked IBM to get out a head for Windows 10 but alas nothing came of it. So then yesterday I went the public route (strange how that works but the "official channels" don't eh?):




So today the fine folks that run the @IBM_ICSsupport account responded:




Basically here's the scoop from that link:

For Notes, Windows 10 is supported today starting with release 9.0.1 Fix Pack 4
For iNotes and Notes Browser Plug-in, support for Windows 10 will be introduced in release 9.0.1 Fix Pack 5


I have to admit, I'm pleasantly surprised that the full Notes client is good to go. Kudos to IBM.
Darren Duke   |   July 30 2015 12:41:00 PM   |     |   Comments [0]

In my last post I made a mistake. I made the mistake of believing that R9 changed something for the better that it apparently does not, and that when the product gets updated. so do the tools. My bad. Basically I'm moron.

First the good news, Domino 9.0.1 FP4 does work with Active Directory 2012 with TLS1.2. Woohoo.

I was under the impression that you could now cross certify an internet certificate into the Domino Directory and it would now be trusted. I could have sworn I read this somewhere, but for the life of me I can't find it. See, previously you'd have to add the Active Directory's root certificate (in this case the Windows CA certificate) directly into your Domino key file using the certsrv.nsf application. But SHA2 Domino certificates make that approach irrelevant.

With the advent of SHA2 for Domino and my misplaced belief (at least for LDAP, other protocols may work this way for all I know) that the cross certificate would allow the LDAPS connection to work I was actually looking in the wrong place.

This snippet from the original post was actually correct, but my actions were not:

Image:SOLUTION - Domino Directory Assistance to Active Directory when using SSL DOES NOT break with 9.0.1 FP4

It seems you still do need the AD root CA in your Domino key file, whether you need to actually cross-certify is debatable (for the record I left the cross-certificate in the Domino Directory).
Doh on my part for not actually trying this out earlier. Now you can't do this with certsrv.nsf so I gambled on this and added the AD CA directly to the SHA2 Domino SSL key file. Here is how I did that:

1. Export your Windows CA root public certificate

2. Convert your CA public certificate into PEM format (either using OpenSSL or this site https://www.sslshopper.com/ssl-converter.html)

3. Using the krytool.exe application import  the PEM CA public certificate into your Domino SSL key file like this:

kyrtool ="e:\Program Files\IBM\Domino\notes.ini" import roots -i c:\ca_forWin.crt -k f:\Domino\data\keyring_sha2_wildcard.kyr


4. Ensure your new CA certificate is in the key ring:

kyrtool ="e:\Program Files\IBM\Domino\notes.ini" show roots -k f:\Domino\data\keyring_sha2_wildcard.kyr


which should give something like this:

Using keyring path 'f:\Domino\data\keyring_sha2_wildcard.kyr'

Trust Anchors:

Anchor 0 (name)

CN=blah-CA-PW-CA/DC=blah/DC=local

Anchor 0 (cert)

Subject:            CN=blah-CA-PW-CA/DC=blah/DC=local
Issuer:             CN=blah-CA-PW-CA/DC=blah/DC=local
Not Before:        04/13/2015 11:13:00 AM
Not After:        04/13/2035 11:23:00 AM
Key length:         2048 bits
Signature Alg:        sha256WithRSAEncryption


5. Add the new Domino key file to the server and voila, No more errors when Domino tries to make a TLS1.2 LDAPS connection to AD using SSL:

Here is the actual log on the server showing the connection, is indeed TLS1.2:

[1178:000B-0F58] 07/15/2015 06:10:11.36 PM SSL_Handshake> Protocol Version = TLS1.2 (0x303)
[1178:000B-0F58] 07/15/2015 06:10:11.36 PM SSL_Handshake> KeySize 256 bits
[1178:000B-0F58] 07/15/2015 06:10:11.36 PM SSL_Handshake> Current Cipher = 0x009F (DHE_RSA_WITH_AES_256_GCM_SHA384)
[1178:000B-0F58] 07/15/2015 06:10:11.36 PM SSL_Handshake> SSLErr = 0
[1178:000B-0F58] 07/15/2015 06:10:11.36 PM SSL_Handshake> TLS/SSL Handshake completed successfully
[1178:000B-0F58] 07/15/2015 06:10:11.36 PM SSL_Handshake> Exit Status = 0


Here is the mea culpa, I was only testing with the LDAPSearch utility and it was only yesterday when the server change window kicked in (thanks Windows Update!...never thought I'd say that. Ever.) that I was able to test the earlier findings in production. But that failed. WTF? LDAPSearch works, Domino fails....that's what sent me back to the drawing board and actually figured out the root cause (no pun intended) was a missing certificate in the key ring file.

So lesson of the day, an error is an error but the error message is not necessarily the error message. And even though the product may get updates, don't necessarily think that the tools get updated as well. In fact, even after the solution I implemented LDAPSearch still fails even though DA using TLS1.2 actually does work.

DA working:


Image:SOLUTION - Domino Directory Assistance to Active Directory when using SSL DOES NOT break with 9.0.1 FP4

LDAPSearch breaking:



[0D70:0002-16CC] 07/15/2015 06:08:21.78 PM SSL_Handshake> Enter
[0D70:0002-16CC] 07/15/2015 06:08:21.78 PM SSL_Handshake> Current Cipher 0x0000 (Unknown Cipher)
[0D70:0002-16CC] 07/15/2015 06:08:21.78 PM SSL_Handshake> outgoing ->protocolVersion: 0303
[0D70:0002-16CC] 07/15/2015 06:08:21.78 PM SSLEncodeClientHello> We offered SSL/TLS version TLS1.2 (0x0303)

... snip ...

[0D70:0002-16CC] 07/15/2015 06:08:21.80 PM S_Write> Switching Endpoint to sync
[0D70:0002-16CC] 07/15/2015 06:08:21.80 PM S_Write> Posting a nti_snd for 7 bytes
[0D70:0002-16CC] 07/15/2015 06:08:21.81 PM SSL_EncryptData> SSL not init exit
[0D70:0002-16CC] 07/15/2015 06:08:21.81 PM S_Write> Switching Endpoint to async
[0D70:0002-16CC] 07/15/2015 06:08:21.81 PM SSL_EncryptDataCleanup> SSL not init exit
[0D70:0002-16CC] 07/15/2015 06:08:21.81 PM S_Write> nti_done return 0 bytes rc = 9
[0D70:0002-16CC] 07/15/2015 06:08:21.81 PM S_Write> nti_done return 0 bytes rc = 9 Event = 0x100
[0D70:0002-16CC] 07/15/2015 06:08:21.81 PM SSL_Handshake> After handshake2 state 2
[0D70:0002-16CC] 07/15/2015 06:08:21.81 PM SSL_Handshake> SSL Error: -6989
[0D70:0002-16CC] 07/15/2015 06:08:21.81 PM int_MapSSLError> Mapping SSL error -6989 to 4165 [SSLConnectionClosedError ]


ldap_bind_s( dn=cn=fppw ldap,cn=users,dc=blah,dc=local, pw=password, method=128 ) failed, error
: Not an LDAP errno 7289


SSL invalid certificate, may need to cross-certify.


Something else that just occurred to me while writing this that someone maybe able to shed some light on, maybe the AD CA root cross-certificate in the Domino Directory only works when you have a Domino CA enabled. At some point I need to test the theory.....again I swear I read this somewhere.....*grumble*


Darren Duke   |   July 16 2015 07:20:17 AM   |    domino  activedirectory  ldap  ssl    |   Comments [2]

UPDATE - Apparently LDAPSearch is broken, not TLS1.2 to AD. Go read this post instead and see how to do it with SHA2 certs : SOLUTION - Domino Directory Assistance to Active Directory when using SSL DOES NOT break with 9.0.1 FP4

DA and AD's....how could this not get confusing?

Over the past few days I've been working to figure out why 9.0.1 FP4 can no longer connect to Active Directory when using a SSL connection for the LDAP connection from Domino. Specifically this is AD 2012 but I would guess the same issues hit 2012 R2. Not sure about 2008. Like this:


Image:Domino Directory Assistance to Active Directory when using SSL breaks with 9.0.1 FP4

Anyway, what worked in 9.0.1 FP3 no longer worked after an upgrade to 9.0.1 FP4. After much testing it appears that Windows 2012 servers really doesn't like TLS1.2 when using Domino. A quick Google will show you than OpenSSL seems to have the same issue so it would seem this is a Windows Server issue as opposed to a Domino issue but that is pure speculation on my part.


Here's the testing I did to figure this out. I knew AD SSL was working thanks the LDP.exe tool on my PC. The connection to the domain controller over port 636 (the SSL) port came back fine.

On a server not running 9.0.1 FP3 (not FP4) I turned up SSL logging using these notes.ini settings:


DEBUG_SSL_HANDSHAKE=1
DEBUG_SSL_CIPHERS=1

DEBUG_SSL_ALL=1



I then fired up LDAPSearch.exe on the server, piped the query out to a text file and ran this query:


ldapsearch -h dc2-pw.blah.local -p 636 -D "cn=darren duke,cn=users,dc=blah,dc=local" -w password -b "dc=blah,dc=local" "objectClass=*"


On the working server (FP3) this was returned in the text file:


[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM SSLProcessServerHello> Server chose SSL/TLS version TLS1.0 (0x0301)
[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM SSLAdvanceHandshake> A certificate has been requested

[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM SSLAdvanceHandshake> An X509 certificate has been requested

[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM SSLAdvanceHandshake> Empty Server DN List

[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM SSLEncodeCertificate> Generating a certificate message with 0 certs

[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM SSL_Handshake> After handshake state= 13 Status= -5000

[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM SSL_Handshake> Exit Status = -5000

[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM int_MapSSLError> Mapping SSL error -5000 to 4176 [SSLHandshakeNoDone]

[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM SSL_Handshake> Enter

[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM SSL_Handshake> Current Cipher 0x002F (RSA_WITH_AES_128_CBC_SHA)



OK so FP3 is using TLS1.0 and the RSA_WITH_AES_128_CBC_SHA (the 2F) cipher. Lets see what the same query from a FP4 server does:


[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLEncodeClientHello> We offered SSL/TLS version TLS1.2 (0x0303)

...snip...


[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 0 Available cipherspec: 0x009F

[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 1 Available cipherspec: 0x009E

[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 2 Available cipherspec: 0x006B

[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 3 Available cipherspec: 0x0039

[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 4 Available cipherspec: 0x0067

[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 5 Available cipherspec: 0x009D

[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 6 Available cipherspec: 0x009C

[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 7 Available cipherspec: 0x003D

[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 8 Available cipherspec: 0x0035

[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 9 Available cipherspec: 0x003C

[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 10 Available cipherspec: 0x002F

[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 11 Available cipherspec: 0x0033


... snip ....


[0824:0002-0C34] 07/15/2015 07:42:56.38 AM SSLSendAlert> Sending an alert of 0x0 (close_notify) level 0x2 (fatal)

[0824:0002-0C34] 07/15/2015 07:42:56.38 AM SSL_Handshake> Changing SSL status from -6989 to -5000 to flush write queue

[0824:0002-0C34] 07/15/2015 07:42:56.38 AM SSL_Handshake> After handshake state= 2 Status= -5000

[0824:0002-0C34] 07/15/2015 07:42:56.38 AM SSL_Handshake> Exit Status = -5000

[0824:0002-0C34] 07/15/2015 07:42:56.38 AM int_MapSSLError> Mapping SSL error -5000 to 4176 [SSLHandshakeNoDone]

[0824:0002-0C34] 07/15/2015 07:42:56.38 AM SSL_Handshake> Enter

[0824:0002-0C34] 07/15/2015 07:42:56.38 AM SSL_Handshake> Current Cipher 0x0000 (Unknown Cipher)

[0824:0002-0C34] 07/15/2015 07:42:56.38 AM S_Write> Enter len = 7

[0824:0002-0C34] 07/15/2015 07:42:56.38 AM SSL_Xmt> 00000000: 15 03 03 00 02 02 00  


.... snip ....




ldap_bind_s( dn=cn=darren duke,cn=users,dc=blah,dc=local, pw=password, method=128 ) failed, error

: Not an LDAP errno 7289



SSL invalid certificate, may need to cross-certify.



Hum. So the 2F cipher is there but this is a TLS1.2 transaction. Also that last line threw me for a curve. Why would FP3 not care about a cross cert by FP4 does? I even added the root signing certificate from AD to Domino as an Internet Cross Certificate. No joy.

Next swing at this, I wondered if it was a TLS1.2 issue so I Googled the shit out of changing the ciphers in AD to test it. Argh, registry hacks,,,,more searching and I found this fantastic free tool to view/adjust Windows ciphers used by Schannel
https://www.nartac.com/Products/IISCrypto/Download.

With this tool I adjusted the domain controller to the following (basically I selected "Best Practice, then disabled TLS1.1 and TLS1.2......oh, Domino does not like seeing TLS1.1 from the DC either):


Image:Domino Directory Assistance to Active Directory when using SSL breaks with 9.0.1 FP4

Once I did that and rebooted the DC, voila, Domino 9.0.1 FP4 could now connect.

Again, I am not 100% certain here but this smells like a AD issue, but it is Domino that doesn't work. A Sonicwall VPN using LDAPS to the AD controller worked fine with TLS1.2, so maybe it is Domino. I did PMR this and after I'd already figured out my work around support suggested I add this to Domino server notes.ini:


SSL_DISABLE_TLS_12=1


So that is basically the same workaround but from the Domino side. This suggests one side or the other is either not handshaking correctly or cannot decide on a cipher when using TLS1.2.


It sure would be nice to have TLS1.2 everywhere. Some day perhaps. Someday.











.
Darren Duke   |   July 15 2015 07:19:59 AM   |    domino  activedirectory  ldap  ssl    |   Comments [4]

IBM apparently have unlimited budget for renaming, re-branding products and acquiring analytics cloud companies, but  as we all know if you put in a PMR and it gets routed to the Philippines then you basically give up They no longer value support. Now it seems as if basic testing has gone the way of Filipino support.

While there have been some epic FUBAR's by IBM of late (renaming the Android Traveler app to Verse for example) this is a more basic problem. Installing their software. Now, I'm not talking about the all-by-uninstallable Websphere and Filenet stuff coming out of Lotus/ICS/ESS but something much simpler, IBM Mobile Connect (or Lotus Mobile Connect, or IMC).

Now this is not a necessarily a simple product to get working but the install was always pretty easy. Until I tried to install IBM 6.1.5.2 that is. And it's obvious not one single person tested this before it was launched.

So here goes. When I install IMC I get asked what I want the SQL databases to named (in this case I am using MS SQL Server, which may explain why IBM doesn't give a shit....ignore the by-far-largest-install-base-RDBMS-system is always a good move right?). I already have a working IMC so I'm going with a new SQL database, wgdatanew and wgacctnew:

Image:Do IBM test any of their stuff anymore? IBM Mobile Connect installation woes


Nothing too special there. A simple text box. Off goes the installer and the SQL databases do indeed get created. A few minutes later it is time to configure the Gatekeeper portion of IMC (basically the GUI client for the uninitiated). This is where the issue arises as soon as the wizard starts you hit this screen:

Image:Do IBM test any of their stuff anymore? IBM Mobile Connect installation woes

WTF? The installer seems to think my MS SQL database is named wgdatanewSQL. Where the hell did the appended "SQL" part of that name come from? Off we go to SQL Server to check:

Image:Do IBM test any of their stuff anymore? IBM Mobile Connect installation woes

Hum, no, the installer created the SQL databases like I wanted. (begin outrage) So how did this ever make it through QA and testing? How? The only plausible answer is that is wasn't tested. I can think of no other way to explain this.

I could PMR this, but really, do I need my question asked back to me in 4 different times in emails over 4 different days by 4 different "engineers"? No. I'll just fix it myself and let IBM be mis-led into thinking they create great software and have a great support arm.

Dear IBM, keep this up and you will lose customers (in fact we've seen one go because of Sametime meetings and it's complexity, so maybe that ship has already sailed).

Anyhow, I did come up with a work around. Simply rename the SQL Database and prepend the "SQL" to it, but do this before you close the Gatekeeper wizard as IMC gets really confused:

Image:Do IBM test any of their stuff anymore? IBM Mobile Connect installation woes

After that "fix" I'm able to finally install and use IMC. Not to harp on a point (OK, I'm harping on a point), but how can something this simple and this bad be let out into the world?
Darren Duke   |   July 8 2015 07:34:43 AM   |    misc  lmc    |   Comments [6]

That's right, it's only eight weeks away. And it's in Atlanta, so it'll be very, very easy to get to. Not only do you get over 50 sessions for $50 (yeah, $50....not. a. typo) but you will get to see, in person, two of the best presenters IBM have (not to mention an OGS guest speaker who I can't name right now, but who knock your socks off).

Richard has already mentioned he OGS IBM speakers, we've all seen Kramer (not to disrespect Kramer though), but the one of the two speakers I'm excited to see is Mr Phil Gilbert. He's the head of IBM Design (I know, IBM have design now....who'd have thought that a few years ago, right?). While I've never seen him present yet, everyone I know who has raves about it for days afterwards.

The other is Louis Richardson, and if his session is on the same time as mine, I may have to cancel my session and go to his. Seriously. I have a massive presenters crush on Louis (don't judge, I'm hoping SCOTUS will legalize this soon too), and while I do not know what his session is, I would literally go and watch Louis present on the advantages of IBM's certification program or on rules of cricket.....for those now wondering, start here https://en.wikipedia.org/wiki/Cricket (sorry I couldn't find reasonable links in the advantages of being certified).

In other possible, my happen, Magic 8 balls says "not in all likelihood", there may or may not be a This Week In Lotus recorded during the event. A whole lot of stars have to align for this to happen and I'm not sure I need the kind of anger and attack IBM like to level at people who differ in opinion to them. Still, it's not like that has ever stopped me in the past right? ;)

Finally, and I know I've said this before, but I'm still kicking about doing a "World According to Darren - part 2". I've got a few ideas and if I can string together enough irritating things it may make the light of day possibly on Friday of the MWLUG session week.

And finally, finally...no, really finally this time, this is your opportunity to come thank and buy a drink for none other than THE Susan Bulloch (she's actually presenting, so if you get a change go see her). There is a good chance that if you've ever had a C&S related PMR in the last *cough* number of years, then Susan most likely had a hand in getting it fixed.

So after all of that, what are you waiting for? Go register (places are going fast) over at the MWLUG site for the event that takes place on August 19th to the 21st at the Ritz-Carlton in Atlanta.
Darren Duke   |   June 29 2015 07:50:17 AM   |    mwlug    |   Comments [1]

I'd forgot about the LastPass hack until I read Mitch's post this morning. I also had this appear in my Twitter stream the other day:




I didn't give it much though. I use a password manager but it ain't the famous ones. I don't like the idea of someone else storing my list of God-like credentials. OK, I use two services like OneDrive and Google Drive but I'll get to why I don't have an issue with that until later....

I use the open source KeePass project.

Image:I don’t use LastPass, I use the open source KeePass for password creation and management

What is KeePass?
Today you need to remember many passwords. You need a password for the Windows network logon, your e-mail account, your website's FTP password, online passwords (like website member account), etc. etc. etc. The list is endless. Also, you should use different passwords for each account. Because if you use only one password everywhere and someone gets this password you have a problem... A serious problem. The thief would have access to your e-mail account, website, etc. Unimaginable.

KeePass is a free open source password manager, which helps you to manage your passwords in a secure way. You can put all your passwords in one database, which is locked with one master key or a key file. So you only have to remember one single master password or select the key file to unlock the whole database. The databases are encrypted using the best and most secure encryption algorithms currently known (AES and Twofish). For more information, see the features page.




Is it really free?

Yes, KeePass is really free, and more than that: it is open source (OSI certified). You can have a look at its full source and check whether the encryption algorithms are implemented correctly.


What I like about KeePass is that I get to decide where my database file of password is stored. Said database is encrypted with 256 bit  AES and mine is stored in a file sync service like Google Drive (as the KeyPass database is already encrypted with my chosen key I have no issues storing it in a file sync service). Additionally, KeePass allows two form factor to be enabled, so I also have my KeePass setup to require a  key file that is required in addition to my password and that is shared with my PC's via another different file sync service (say MS One Drive). Yes I could keep in on some other form factor like a USB thumb drive, but that is a tad unwieldy for me. Anyway whenever I need to start KeePass or unlock it, I need both:

Image:I don’t use LastPass, I use the open source KeePass for password creation and management

Other things I like is integration (via plugins, and there a lot of plugins) to Firefox and Chrome, personally for Firefox I use PassIFox (which also requires KeyPassHttp):

Image:I don’t use LastPass, I use the open source KeePass for password creation and management

It also has a great password generator built right in:

Image:I don’t use LastPass, I use the open source KeePass for password creation and management

Which will create a password like this example:

Image:I don’t use LastPass, I use the open source KeePass for password creation and management

How guessable is that? Yeah, I know right....I also use the maximum number of characters a web site allows for passwords, so if a site is limited to 24 characters that's what I use. That alone is great for your security. For example using A-Z and a-z is 52 characters in total. A 24 character password is therefore 52^24. That's a big, big number (1111010^2 I think, but don't quote me on that), then add in numbers, special symbols and spaces (if the website allows it) and you have a pretty awesome password generated for you,

So what is the down side? Yeah, there's always a down side and that is mobile. Now there are iOS and Android implementations of KeePass and I use the iOS one on occasion but it's read only (you can't create password entries on the device) and it's not a simple matter to type (my admittedly complex) password on a small phone keyboard. Still it works but it's not too suave and sexy. Again I use the file sync iOS app to sync the KeePass database to the device.

So there you have it. If your looking for a pretty good (actually I'd say great) password manager and creation tool and you want complete control of your password database give KeePass a try. I love it (and it's probable that this was one of my TWiL tips back in the day, that's how long I've been using this).











Darren Duke   |   June 17 2015 08:06:20 AM   |    misc    |   Comments [2]

Another week, another SSL/TLS security vulnerability. This one is termed Logjam (read about it here http://www.theregister.co.uk/2015/05/20/logjam_johns_hopkins_cryptoboffin_ids_next_branded_bug).

Luckily a site has already been created to test your web servers, it is available at https://weakdh.org/sysadmin.html.

A quick test of a Domino 9.0.1 server with the latest FP & IF and the perfect forward secrecy server-side notes.ini settings enabled (see this previous blog post for those settings) you get this result:

Image:Good news - Domino (at least 9.0.1) does not seem to be affected by the LogJam TLS vuln

Using my free Apache reverse proxy you'll get this (which is slightly better as Domino doesn't support ECDHE):

Image:Good news - Domino (at least 9.0.1) does not seem to be affected by the LogJam TLS vuln

Either way, using the latest version of Domino with the right cipher list you should be OK. Again I ask.....when will Domino get ECDHE? I don't think this a "nice to have" any longer.
Darren Duke   |   May 20 2015 02:06:44 PM   |     |   Comments [1]

I swear I voted for somewhere other than Atlanta.....no, really I did.

Anyway, even though it is technically called the Midwest User Group anyone can (and should) attend. So if you are in the Southeast you have no rational reason to not attend.

If you use any of the IBM collaboration technologies this a conference you should have on your schedule. "But Darren, I can't get $1,500 approved to attend a conference". That's fine. It's only $50. Yes Fifty. I didn't miss off a zero. So now what's your excuse? Unless they are sold out when you register you really don't have one (oh, and they do dell out, so register now). The conference is at the magnificent Ritz Carlton in downtown Atlanta and there is even a special hotel rate for MWLUG attendee so you even get this for a relative steal too.

If you read this far, you need to attend. Here's the link: http://www.mwlug.com/mwlug/mwlug2015.nsf/Home.xsp

(Oh, and hopefully Promnic will bring some of Catherine's cookies....that's reason enough to attend right there).
Darren Duke   |   May 7 2015 11:12:34 AM   |    mwlug    |   Comments [6]

A few years ago I wrote about how to subscribe to the daily IBM product update newsletter. A few days ago some one asked me if I still used this service. I thought I did, but on recollection I hadn't gotten an email from them in ages (or "yonks" for a more technical definition). At first I thought it was getting stuck in spam.....nope. Hummm. OK Let me log in a see....

I had no subscriptions listed. None. Nada. Ziltch. WTF?

So I started adding in my subscriptions again and realized that when IBM rename a product (Lotus Domino becomes IBM Domino) then it drops off the subscription list. Blahhhh! Now, with any normal company this would be a once in a blue moon occurrence, but with IBM, like an old lady with a HSN addiction, they can't seem to refrain from buying into the hype and pulling the trigger.
Voila, list rebuilt:

Image:Do you subscribe to the IBM daily product update newletter? Part deux - or why renaming your products sucks

So head on over the IBM my notifications site and add your subscriptions back in, then check it every 5 minutes or so because that seems to be the frequency of IBM product renames. (that last bit was a joke).
Darren Duke   |   April 10 2015 10:38:15 AM   |    domino  lotus notes    |   Comments [2]

Unless you have been living under a rock somewhere you no doubt know that IBM finally gave use TLS 1.2 for IBM Domino servers. This means that Domino servers can now use SSLv3, TLS 1.0 and TLS 1.2. But it's IT, so just because you can does not mean you should......for example I would suggest most servers (I'll get the outliers further down the page) would probably want SSLv3 disabled. If you have been under a rock, then you need Domino 9.0.1 FP3 IF2 to get this new goodness.

Now this fix is only for Domino 9.0.1 FP3, so now you have a further reason to upgrade to R9 (SHA2 wasn't enough?) and is provided as an IF from fix central. There are other goodies in this release too like additional ciphers and forward secrecy (aka FS). Forward secrecy? Yes...via Wikipedia:

In cryptography, forward secrecy (FS; also known as perfect forward secrecy, or PFS and also key erasure) is a property of key-agreement protocols ensuring that a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in the future.


However (there's always a however), IBM has chosen to not enable FS by default. This is due to IBM not knowing how crap your servers are, as FS is "resource intensive". If you have crap servers, like a Pentium II running your production environment then FS is not for you (neither is IT for that matter). If you running a pretty recent CPU and plenty of RAM, then you should be OK. And you really want FS.....no really, you do.

So you've decided that your server hardware is up to the task, what do you do to get FS and the promise of Angels singing and the cries of despair from hackers now thwarted? Well you have use Notes.ini settings. See IBM are doing good stuff here....they are giving us new, very important features in fix packs and IF's....the cost of that is there are not yet any UI equivalents in the server and config docs yet. I'm good with that, good on yer IBM.

A few blog posts back, I mentioned the SSLCipherSpec notes.ini setting and it is this setting that once again gets to do all the work. Here's the thing though.....I would change the values in this setting based on the use of the Domino server. I'm not convinced there is "one setting to rule them all yet". I would suggest to you, dear reader, that a Traveler server needs different settings to a iNotes server which is different to a SMTP gateway server. Before that go read Daniel Nashed's excellently detailed post on all the new ciphers then come back here.....

Remember, SSLCipherSpec will be used despite what you have in the server or internet document and it is server wide.

iNotes with XP and IE support

Let's start with iNotes. Some organizations still need XP with IE support. Yes they do. Get over it. This is a conniption free zone with regards to XP. If you do need XP with IE then use TLS 1.0 with Triple DES. Why? Well XP with IE does not support AES, so that cipher is out, RC4 is now frowned upon so that cipher is out, leaving us with 3DES. Given the use of XP with IE support and FS on other platforms, I would suggest this cipher list for an iNotes server and you'll get a A- on SSL Labs:

SSLCipherSpec=9D9C3D3C352F0A3339676B9E9F
DISABLE_SSLV3=1


(Firefox and Chrome on XP do not have the same issues as IE)

iNotes without XP and IE support

Drop the 3DES cipher (0A), but SSLv3 still disabled, and get a A- on SSL Labs:

SSLCipherSpec=9D9C3D3C352F3339676B9E9F
DISABLE_SSLV3=1


(will also work with XP running Firefox or Chrome)

Traveler

Same as iNotes with no XP support:

SSLCipherSpec=9D9C3D3C352F3339676B9E9F
DISABLE_SSLV3=1


SMTP Domino Gateway

This is where it gets tricky if you're using STARTTLS (you are using STARTTLS right?) or your iNotes server is also your SMTP gateway.  I would love to be able to say kill off SSLv3 but that's only a decision you can make based on your findings of what breaks when others try to send you TLS messages, but I don't think there is one size fits all here. I would start with this and adjust as necessary (you may need to add RC4 ciphers back in):

SSLCipherSpec=9D9C3D3C352F0A3339676B9E9F
DISABLE_SSLV3=1
SSL_ENABLE_INSECURE_SSLV2_HELLO=1
RouterFallbackNonTLS=1


or (with SSLv3)

SSLCipherSpec=9D9C3D3C352F0A3339676B9E9F
SSL_ENABLE_INSECURE_SSLV2_HELLO=1
RouterFallbackNonTLS=1


or (with SSLv3 and RC4):

SSLCipherSpec=9D9C3D3C352F04050A3339676B9E9F
SSL_ENABLE_INSECURE_SSLV2_HELLO=1
RouterFallbackNonTLS=1


Domino LDAP for LDAPS Dir Sync

If you using any type of LDAP sync with cloud based services for things like Spam protection then this is difficult. You just need to try it and see.. For instance SpamHero (which I like a lot...) only uses SSLv2 (yes....T. W. O) last I checked. I did email them for clarification and they did say they are addressing this. I have not checked in a few weeks (Update July 29th 2015 - SpamHero now support TLS). So if this is the case, you cannot go above 9.0.1 FP2 for this server. Again, test. adjust, test again, repeat

-------------------------------------

You may be wondering about the "A-" on the SSL Labs test. Well, it's to do with older browser support for FS and IBM choosing to not (yet?) implement ECDHE ciphers. I hope at some they will reconsider this as this does seem to be the current trend in ciphers, and well, we don't want to be left a decade or more behind again, right? I wonder what the (now new) top ranked,, not fixed PMR is now?

So there you have it. TLS 1.2 support in Domino. Not quite as simple as you thought.

References :
TLS/SSL support history of web browser - Wikipedia
Domino TLS Cipher Configuration - IBM
Darren Duke   |   April 6 2015 06:50:28 AM   |    domino  ssl  security  tls    |   Comments [0]