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 [0]

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 [2]

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. 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]

While sat in Daniel Nashed and David Kern's excellent Domino Security session at Connect, there was a comment and slide that made me tweet this:




Now, I'm back in the office it's time to address this. So based on that session it seems as if LDAP, SMTP, DIIOP, POP3 and IMAP (and Remote debug monitor?) protocols do not adhere to the cipher list in the server document (there was no mention of internet sites documents, but I would presume they are affected by this issue too). That means even if you indicate that the server should only use, say AES ciphers like this:

Image:Domino and SSL ciphers. The server document may not be doing what we expect it to do

then any protocol that is not HTTP or HTTPS seems not to restrict this to AES. It would seem to allow RC4 and any other cipher allowed by the server (one would hope that with the TLS fix that also disabled low quality ciphers that none, 40 and 56 bit would get disabled by this but I can neither confirm nor deny this).

There is however a server notes.ini you can use that apparently does work on these errant protocols, but note, this also overrides anything in the server document FOR ALL PROTOCOLS so test first:

Use the NOTES.INI setting SSLCipherSpec to specify SSL restrictions for all protocols. Ciphers are specified by a 2-digit code. You can add as many ciphers as you need.

For example, to enable 3DES and RC4128SHA ciphers, enter the following line in the NOTES.INI file:

SSLCipherSpec=050A    

where 05 = 3DES and 0A = RC4128SHA.



So that's handy right? What about the two digit hex values? Well this is where you hit a bit of a brick wall. All I can find is this list:

(SSL users only) Determines which SSL-compliant cipher to use to encrypt files on the server. Specification numbers correspond to the following ciphers:

01 - SSL_RSA_WITH_NULL_MD5
02
- SSL_RSA_WITH_NULL_SHA
03
- SSL_RSA_EXPORT_WITH_RC4_40_MD5
04
- SSL_RSA_WITH_RC4_128_MD5
05
- SSL_RSA_WITH_RC4_128_SHA
06
- SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
09
- SSL_RSA_WITH_DES_CBC_SHA
0A
- SSL_RSA_WITH_3DES_EDE_CBC_SHA
0B
- SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
0C
- SSL_DH_anon_WITH_RC4_128_MD5
0D
- SSL_DH_anon_WITH_DES_CBC_SHA

To enter multiple ciphers, enter each cipher specification value, including leading zeros. Do not include spaces between values. For example:

SSLCipherSpec = 01020A

from http://www-10.lotus.com/ldd/dominowiki.nsf/dx/SSLCipherSpec. What you will no doubt notice is the absence of any AES ciphers in that list. My guess is a quick PMR (sic!) will get you all the values, but I can't seem to find them anywhere so I cracked open DDE and took a look:

Image:Domino and SSL ciphers. The server document may not be doing what we expect it to do

So it looks to me as if AES 128 is "2F" and AES 256 is "35". I would still suggest you PMR this as you use any information on this blog at your own risk (see what I did there?).

So if you want to limit all protocols on a server to just RC4 128 SHA-1and MD5 and AES 128 and 256, which will give you a pretty good spread of clients then add this:

SSLCipherSpec=04052F35


Again this will override anything in the server or internet sites documents. After sitting through Daniel and David's session there should be a lot more to come in the next few weeks, like TLS 1.2, new ciphers, SSLv2 handshake's (to prevent some issues people are having with STARTTLS between Domino and other servers) and other things I can no longer recall.

Darren Duke   |   February 3 2015 08:03:36 AM   |    domino  ssl    |   Comments [2]

February 2 2015 Monday

ConnectED-sphere sudo review

UPDATE 2/2/15 : 5:03PM EST - Super doh! Forgot to mention the Domino4Wine (hence the sudo)...

I was fully expecting to write a "what a train wreck" review before I went. I was not expecting to say I had a metric shit ton of fun. But I did. And based on other posts I've perused it seems almost everyone else did. There are far more eloquent reviews elsewhere, so this will be bare bones.

First the "ups", in no particular order:
  • Much, much improved OGS. Flow, demos, people who care.....And a quintet, who doesn't like quintets?
  • It doesn't seem to matter how many people don't turn up every year, BALD still rocks with people new and old
  • Verse, and yes, a feature actually made me moist (more in a post on that later)
  • No theme park. Hardly ever went anyway. Gave more time to "proper" socializing
  • The 3rd (or 4th??) annual day-after-ConnectED-sphere breakfast. If you ever get a chance to have breakfast with any of these, do it : Lisa Duke, Julian Woodward, Ben Poole, Mat Newman, Amanda Bauman and Tony Holder. A truly mind bending experience, and not for the faint of heart
  • No law enforcement was called as we left the Dolphin rotunda at 4AM on Thursday AM
  • Math(s) during the CGS. Who doesn't like math(s)?
  • Size does matter. Smaller *is* better
  • Coming soon (or not), move the Domino view indexes out of the NSF....also called NIF something or other
  • They are taking Domino security seriously again
  • The Penumbra Dinner and Lisa getting her "captain hat" to go with "the Duke family yacht"
  • Domino4Wine from the great folks at Prominic....run DDE and Admin on OSX and/Linux. See more here http://vimeo.com/117342115

Now the "downs"
  • I'd guess there were more "technical" sessions than last year, but the admin in me was still left yearning. If you're into Xpages, then you are A-OK. Anything else, the outlook was a tad glum. There was lots of Verse, but not really a lot of *actual* Verse. If IBM wanted to leave me gagging for more, it worked. I really shouldn't have had to sit through three or four near identical sessions to figure this out
  • Same price, less days
  • New hotel price was $70 per night more expensive. 25% more expensive
  • If you know the "Carry On..." films/movies, you'll know what I mean when I say the conference had a bit of that kind of feel to it. That maybe an "up" though, so who knows
  • Tickets for booze, although IBM did seem to succumb to "social shame" and reverse that decision, no doubt to Mark Roden's dismay....he had at least 20+ tickets. Again, could technically be an "up"
  • The required BlueMix slide in pretty much every presentation I sat through. Still a bit hazy on what BlueMix is
  • Beyond the Everyday still makes me think of that movie with Emily Blunt and Tom Cruise, neither of whom presented
  • The sheer amount of time between sessions....some were 45-60 minutes apart

Now for the synopsis....

To me, it doesn't matter what you call it, but I think it would matter where you hold it. Vegas? Nah, not really me. Florida-sphere for me given the chance.

I do think Verse has some legs if IBM can get it out soon with features that make it killer. There is one feature I really, really like but it won't be there until Verse 1+. I am worried about seeing the words "IBM" and "freemium" in a sentence. They have divested themselves of any business deemed a "commodity", so they don't have the skills and I doubt they'll have the stomach for consumer long term. If it's just to garner press, then yeah....otherwise color me nonplussed. Verse on-prem? My guess is 6-12 months behind what they are aiming for if they are trying to make it "simple", although I am getting that "Quickr feeling" about this, you know, the one where the rug gets pulled out from under you.....yeah, that one.

I was pleasantly surprised that IBM didn't just completely paper over the elephant in the CGS room by indicating that the decision for next year had not been made (that's what I heard all week by the way). Subsequent "rumor" has it that we may not hear until May-ish.

Finally, IBM needs to be very careful with the loyal (?) folks still using their stuff on-prem. They need to get 9.0.2 out or roll out the 9.0.2 features in fix packs or other avenues. If 9.0.2 doesn't ship until Q4-2015 then it will be two-ish years since 9.0.1. That's just bad form and sends the wrong message. IBM must multi-task effectively, for it is they who have decided to go multi-client.

So there you have it. Maybe the best ConnectED-sphere yet. I'm still contemplating how much of that is down to the attendees and how much is down to IBM.
Darren Duke   |   February 2 2015 12:43:03 PM   |    lotusphere  verse  domino    |   Comments [2]

Somehow I missed this, so I'm guessing some of you did too....New rules dated 10/16/2014. Thank you IBM.

Woohoo! Indeed!!

Image:New-ish Domino Configuration Tuner (DCT) rules are available
Darren Duke   |   February 2 2015 05:16:52 AM   |    domino  dct    |   Comments [0]

Well, technically this is for any Linux VM appliance you download, not just my reverse proxy....

Anyway, every Linux host should have it's own unique host SSH key to ensure security and authenticity of the server you are connecting to. When you create a server from an OVF that doesn't happen automatically. In fact you get the SSH host key that is on the OVA at time of creation (in this case mine).....potentially opening you up to man in the middle attacks (potentially.....although unlikely).

Here's how to do it......Log in into the Proxy server as root (either via VMware console or SSH into the host using Putty) and issue the following commands:

rm -rf /etc/ssh/ssh_host_*
ssh-keygen -A

service ssh restart



Here's the expected output from the above commands....

Image:If you are using my Reverse Proxy, please change the SSH host key

Once you do this, try logging in again via SSH (again I use Putty) and you should see a warning about a potential security breach and that this could be a bad thing (see below), it's not as we meant to create a new key, so click Yes;

Image:If you are using my Reverse Proxy, please change the SSH host key
Darren Duke   |   January 14 2015 07:55:31 AM   |    proxy  linux    |   Comments [0]

UPDATE 12/17/2014 - Based on Mike's comment below it does indeed look like option 2 is supported!! So have at it, proxy away people....

Over that past few weeks I've been banging my head against the wall trying to figure out why a Traveler server that has been relocated behind a proxy would not work (it was a standalone server that was working fine before it was moved behind the proxy). Everything seemed fine, except one couldn't get to the Traveler log on page and/or add devices to the servers. Existing users worked flawlessly. Needless to say this was extremely aggravating. I'd install another, new Traveler server and put it behind the same proxy and it would work fine. WTF?

So after much digging and testing (I've create more Traveler servers in the last week than I have in the rest of my career), I think I have finally managed to work out what the issue is. I would say this is definitely a bug with Traveler, but given the issues I've had lately with PMR's I'm in no mood to play that game Russian Roulette so I decided to  figured out a fix on my own (probably and utterly unsupported but it works for me - oh, it is supported!!!).

So first, let's outline the problem/bug I found in Traveler.....

If your Traveler server Domino common name, lets say Traveler/Blah (so traveler) is the same as the hostname in the proxy URL, lets say traveler.blah.com (so traveler) then Traveler throws a wobbler. Do not pass go, do not collect $200 if you will. You will be unable to get to the Traveler web page on the device or any browser for that matter.

Now, use any other Domino server name and as long as it's not the hostname part of  URL you use on the proxy then you are fine. This is what I was inadvertently doing when I was creating new Traveler servers to test on. Doh.

So a Domino server name of LNT1/Blah and a proxy URL of traveler.blah.com.....fine! No issues, proxy works fine. "Argh!" I hear you say, "Darren, I have a Traveler server called Traveler/Blah and also use the URL traveler.blah.com to get to it....so I can't proxy it then?". Well yes......

You have two options.....

1 - Install Domino with IHS (on Windows of course) and use IHS. I don't think IHS will have this issue. Hum, IHS no longer supported for a front end to Domino, see this IBM technote.

2 - (and this is the part that is probably unsupported) I was able to build a new Domino server (exact same Domino and Traveler versions as the one you want to proxy) using the Domino server name LNT1/BLAH and copied over the LotusTraveler.nsf and traveler folders out of the existing servers data folder to the new one. I then configured the proxy to use traveler.blah.com and low and behold, it works!

I've been running on the new server for a few days and so far neither iOS users nor Android users have reported any issues so, fingers crossed, this may well work. Who knew?


Here's the new flow:

Internet -> Proxy using host name traveler.blah.com -> Domino Traveler server called LNT1/Blah with a host name of lnt1.blah.com
Darren Duke   |   December 16 2014 07:10:46 AM   |    domino  traveler    |   Comments [1]

December 12 2014 Friday

How to disable SSLv3 in Domino

In my POODLE TLS post from a few days back, there was a comment asking how to fully disabling SSLv3 in Domino. You'll notice in the comments I mention that there is a way but at the time it was under NDA. Well, apparently not anymore....

Now, fair warning this may not yet be supported by IBM so if you choose to do this, you do it at your own risk (while under NDA on this, it was stated that is unsupported so YMMV).

According to this post on the Domino wiki, you can use this server notes.ini setting to fully disable SSLv3 but still keep TLS working.:

DEBUG_UNSUPPORTED_DISABLE_SSLV3=17


If you need this, test it before you put it into production. I have not yet done this, but everyone I know that has has had no issues so far. Again YMMV.



Darren Duke   |   December 12 2014 07:39:06 AM   |    domino  tls  ssl  poodle    |   Comments [4]