Daniel Nashed 2 October 2015 20:46:52There is a brand new new TN describing how to enable higher security for the updated JVM 1.6 in Notes/Domino. -->http://www.ibm.com/support/docview.wss?uid=swg21967996 The IBM 1.6 JVM does support TLS 1.2 and also some modern ciphers. Sadly by default they cannot be used because they use higher encryption levels (AES 256) which are disabled by default in the IBM and even in the current Oracle JVM 1.8.
The TN describes a download for something that is called "Java Cryptography Extension" which is nothing new and is around with descriptions for other products and JVM versions. But now that Notes/Domino has updated crypto standards in the JVM in some of the last updates and also Domino supports (EC)DHE with higher encryption levels looking into those higher encryption levels in the JVM makes sense. When you download the install files you basically get two jars that replace your JVM security files (in notes\jvm\lib\security). The two jar files local_policy.jar and US_export_policy.jar contain two files
I have done some testing with the feed reader which started to use DHE_RSA_WITH_AES_256_CBC_SHA with 2048 bit key and TLS 1.2 which is already great. That provides PFS via DHE cipher and also AES 256 with a CBC cipher. Sadly it still uses SHA and no GCM cipher. With the new Mac 64bit client using the Oracle 8 JVM you still need the same type of patches. My tests using the feed-reader and embedded browser on the new Mac Notes 9.0.1 64bit resulted in a ECDHE_RSA_WITH_AES_128_GCM_SHA256 connection!
So now the Mac is using higher encryption levels for Java then the current Notes/Domino 9.0.1 release with current JVM patches (1.6.0 SR16 FP7).
I would wish that IBM would update the JVM in Windows and Linux as well in the 9.0.1 code stream!! To give you some additional background about the changed settings. You can see that the old files contained restrictions (probably because some countries still don't allow higher crypto). The replaced files remove all the restrictions. Have a great weekend!!! -- Daniel
-- Old Content --
// Some countries have import limits on crypto strength. This policy file is worldwide importable.
permission javax.crypto.CryptoPermission "DES", 64;
permission javax.crypto.CryptoPermission "DESede", *;
permission javax.crypto.CryptoPermission "RC2", 128,
permission javax.crypto.CryptoPermission "RC4", 128;
permission javax.crypto.CryptoPermission "RC5", 128,
"javax.crypto.spec.RC5ParameterSpec", *, 12, *;
permission javax.crypto.CryptoPermission "RSA", 2048;
permission javax.crypto.CryptoPermission *, 128;
-- New Content --
// Manufacturing policy file.
// There is no restriction to any algorithms.
Daniel Nashed 1 October 2015 10:21:45 After updating to OSX 10.11 I did a quick test. It wasn't sure if Apple will only support ECDHE and implementing their new standard ATS. The first tests shows that the current ciphers are there but Apple does even support quite simple ciphers like RSA_WITH_RC4_128_SHA / MD5 as a fall back. But you never know if this is going away in one of the next updates. Here is a trace from against a Domino 9.0.1 FP4 IF2 server. You can see all supported common ciphers and I highlighted the most important parts of the handshake. Happy updating! -- Daniel SSLProcessProtocolMessage> Record Content: Handshake (22) SSLProcessHandshakeMessage Enter> Message: ClientHello (1) State: HandshakeServerIdle (3) Key Exchange: 0 Cipher: Unknown Cipher (0x0000) SSLProcessHandshakeMessage client_hello> SGC FLAG: 0 CTX state = 3 SGCCount = 0 SSLProcessClientHello> clientVersion: 0303 SSLProcessClientHello> SSL/TLS protocol clientVersion 0x0303, serverVersion 0x0303 SSLProcessClientHello> 26 ciphers requested by client SSLProcessClientHello> Client requested TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00FF) SSLProcessClientHello> TLS_EMPTY_RENEGOTIATION_INFO_SCSV found SSLProcessClientHello> Client requested ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xC02C) SSLProcessClientHello> Client requested ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xC02B) SSLProcessClientHello> Client requested ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xC024) SSLProcessClientHello> Client requested ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xC023) SSLProcessClientHello> Client requested ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xC00A) SSLProcessClientHello> Client requested ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xC009) SSLProcessClientHello> Client requested ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xC008) SSLProcessClientHello> Client requested ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC030) SSLProcessClientHello> Best common cipherspec 0xC030 (so far) SSLProcessClientHello> Client requested ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC02F) SSLProcessClientHello> Client requested ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xC028) SSLProcessClientHello> Client requested ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xC027) SSLProcessClientHello> Client requested ECDHE_RSA_WITH_AES_256_CBC_SHA (0xC014) SSLProcessClientHello> Client requested ECDHE_RSA_WITH_AES_128_CBC_SHA (0xC013) SSLProcessClientHello> Client requested ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xC012) SSLProcessClientHello> Client requested RSA_WITH_AES_256_GCM_SHA384 (0x009D) SSLProcessClientHello> Best common non-EC cipherspec 0x009D (so far) SSLProcessClientHello> Client requested RSA_WITH_AES_128_GCM_SHA256 (0x009C) SSLProcessClientHello> Client requested RSA_WITH_AES_256_CBC_SHA256 (0x003D) SSLProcessClientHello> Client requested RSA_WITH_AES_128_CBC_SHA256 (0x003C) SSLProcessClientHello> Client requested RSA_WITH_AES_256_CBC_SHA (0x0035) SSLProcessClientHello> Client requested RSA_WITH_AES_128_CBC_SHA (0x002F) SSLProcessClientHello> Client requested RSA_WITH_3DES_EDE_CBC_SHA (0x000A) SSLProcessClientHello> Client requested ECDHE_ECDSA_WITH_RC4_128_SHA (0xC007) SSLProcessClientHello> Client requested ECDHE_RSA_WITH_RC4_128_SHA (0xC011) SSLProcessClientHello> Client requested RSA_WITH_RC4_128_SHA (0x0005) SSLProcessClientHello> Client requested RSA_WITH_RC4_128_MD5 (0x0004) SSLProcessClientHello> Extensions found in this message SSLProcessClientHello> Received TLS Server Name Indication (SNI) extension SSLProcessClientHello> SNI - client requested server name 'domino.nashcom.de' SSLProcessClientHello> Received Elliptic Curves extension SSLProcessClientHello> Client supports NamedCurve secp256r1 (23) SSLProcessClientHello> Client supports NamedCurve secp384r1 (24) SSLProcessClientHello> Client supports NamedCurve secp521r1 (25) SSLProcessClientHello> Received EC Point Formats extension SSLProcessClientHello> Client supports uncompressed (0) points SSLProcessClientHello> Processing TLS signature algorithms extension SSLProcessClientHello> Client supports hash mask 0x0034; server cert chain has mask 0x0014 SSLProcessClientHello> Extension type 0x3374, extension length 0x0000 SSLProcessClientHello> Extension type 0x0010, extension length 0x0030 SSLProcessClientHello> Processing TLS Status Request extension (OCSP) SSLProcessClientHello> Extension type 0x0012, extension length 0x0000 SSLProcessClientHello> hash/alg in certchain fSupHasAlg:0000 SSLProcessClientHello> We selected cipher ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC030) SSLProcessHandshakeMessage Exit> Message: ClientHello (1) State: HandshakeServerIdle (3) Key Exchange: 15 Cipher: ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC030) SSLAdvanceHandshake Enter> Processed: ClientHello (1) State: HandshakeServerIdle (3) SSLAdvanceHandshake client_hello> SGC FLAG: 0 Count = 2 SSLAdvanceHandshake client_hello> Using resumed SSL/TLS Session SSLAdvanceHandshake calling SSLPrepareAndQueueMessage> SSLEncodeServerHello SSLEncodeServerHello> Sending empty renegotiation_info (0xff01) extension SSLEncodeServerHello> Sending empty status_request (0x0005) extension SSLEncodeServerHello> Sending supported point formats (0x000b) extension SSLAdvanceHandshake calling SSLPrepareAndQueueMessage> SSLEncodeChangeCipherSpec SSLAdvanceHandshake calling SSLPrepareAndQueueMessage> SSLEncodeFinishedMessage SSLCalculateTLS12FinishedMessage Enter> senderID: server finished, PRF using SHA384 SSLAdvanceHandshake Exit> State HandshakeChangeCipherSpec (13) SSL_Handshake> After handshake state = HandshakeChangeCipherSpec (13); Status = -5000 int_MapSSLError> Mapping SSL error -5000 to 4176 [SSLHandshakeNoDone] SSLProcessProtocolMessage> Record Content: Change cipher spec (20) SSL_Handshake> After handshake2 state HandshakeFinished (14) int_MapSSLError> Mapping SSL error -5000 to 4176 [SSLHandshakeNoDone] SSLProcessProtocolMessage> Record Content: Handshake (22) SSLProcessHandshakeMessage Enter> Message: Finished (20) State: HandshakeFinished (14) Key Exchange: 15 Cipher: ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC030) SSLCalculateTLS12FinishedMessage Enter> senderID: client finished, PRF using SHA384 SSLProcessHandshakeMessage Exit> Message: Finished (20) State: HandshakeFinished (14) Key Exchange: 15 Cipher: ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC030) SSLAdvanceHandshake Enter> Processed: Finished (20) State: HandshakeFinished (14) SSLAdvanceHandshake Exit> State HandshakeServerIdle (3) SSL_Handshake> After handshake2 state HandshakeServerIdle (3) SSL_Handshake> Using resumed SSL/TLS session SSL_Handshake> Protocol Version TLS1.2 (0x303) SSL_Handshake> Cipher = ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC030) SSL_Handshake> KeySize = 256 bits SSL_Handshake> Original Elliptic Curve = NIST P-256 (23) SSL_Handshake> Server RSA key size = 2048 bits SSL_Handshake> SSLErr = 0 SSL_Handshake> TLS/SSL Handshake completed successfully int_MapSSLError> Mapping SSL error 0 to 0 [SSLNoErr]
Daniel Nashed 29 September 2015 14:03:34Wow the Mac 64bit Client has been released today! If you are looking for it, the description and the part number might help.
Already downloaded from Partnerworld. I hope you also find it in Passport Downloads already.
IBM Notes V9.0.1 Mac 64 Bit English (CN6VDEN ). And here is the technote -> http://www.ibm.com/support/docview.wss?uid=swg21962311 Have fun! Daniel
Daniel Nashed 26 September 2015 10:38:11
After updating to the new IF which introduces ECDHE with some additional settings you can get to a "A+" SSL Labs rating.
When you install IF2 by default you get a good set of ciphers. In the previous sets oif fixes DHE was disabled by defaiult. Now you have DHE and also ECDHE enabled by default. There is not much in addition to that you have to do. Cipher Suites (SSL 3+ suites in server-preferred order; deprecated and SSL 2 suites at the end)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH 256 bits (eq. 3072 bits RSA)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 2048 bits (p: 256, g: 1, Ys: 256)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH 256 bits (eq. 3072 bits RSA)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 2048 bits (p: 256, g: 1, Ys: 256)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH 256 bits (eq. 3072 bits RSA)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 2048 bits (p: 256, g: 1, Ys: 256)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 2048 bits (p: 256, g: 1, Ys: 256)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH 256 bits (eq. 3072 bits RSA)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 2048 bits (p: 256, g: 1, Ys: 256)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA)
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) 256
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 128
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 256
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112
The SSL Labs rating says that PFS is supported with current browsers: "Forward Secrecy - With modern browsers"
-- Disable SSL V3 -- First of all you have to disable SSL V3. By default it is still enabled.
And I think it is time to completely disable it. DISABLE_SSLV3=1
The current fixes also support HSTS but by default the max age is a bit too low.
So I set the following notes.ini settings:
Which resulted in the following rating:
"Strict Transport Security (HSTS) Yes max-age=17280000; includeSubDomains"
-- OCSP -- Also OCSP is supported in the current version.
I have set the following notes.ini settings to enable it and to specify the responder URL for my certificate provider.
And I also enabled debugging for testing and ensured that time differences of different clocks do not cause any issues.
SSL_ENABLE_OCSP_STAPLING=1 OCSP_RESPONDER=http://evssl-ocsp.globalsign.com/responder OCSP_CLOCKSKEW=10 OCSP_LOGLEVEL=31 The result is:
OCSP stapling -> Yes
-- Cipher Configation -- The cipher configuration has changed a bit. For the new ciphers you need four digits.
Using the SSLCipherSpec you can continue to configure the existing ciphers using the two digit code.
But I would recommend that you start using 4 digits for all cipher types to keep the settings more consistent.
Also there is a way to disable certain ECDHE Curves via notes.ini settings.
And you can also gnerate your own DHE Groups.
I don't want to repeat all the settings from the current documentation.
The wiki entry has been updated. You find all the details here:
http://www.lotus.com/ldd/dominowiki.nsf/dx/TLS_Cipher_Configuration Most of the settings are not really required. But those options can help when you have special requirements.
Daniel Nashed 25 September 2015 16:35:19 Domino 9.0.1 Fix Pack 4 Interim Fix 2 shipped. It contains some important fixes in the security area. First of all it corrects some bugs in the DHE and AES-GCM area. And also fixes in MIME conversion specially important for Traveler servers. But it also introduces ECDHE ciphers! Again the Domino security team did a great job implementing important new functionality in an Interims Fix. As posted before Apple iOS 9 which shipped last week requires ECDHE at least for custom applications. But we expect that in one of the next version Apple might require ECDHE also for Safari and ActiveSync applications as posted before. When updating to IF2 you should remove the SSLCIPHERSPEC notes.ini setting from your server. This will enable a good set of ciphers including DHE and ECDHE ciphers. I am working on a more detailed blog post once I have fully tested the fix over the weekend. My test server was rated "A+" by SSL Labs with some additional settings and with a proper certificate. Again thanks to the Domino security team for their great work!!! -- Daniel -- List of the server side fixes in 9.0.1 FP4 IF2 -- ACHG9XJB6Y Fixed a potential Domino Server crash in JVM When Converting CD To Mime. ECYS9XXDMF Memory leaks in two MIME routines that caused Traveler 901FP7 crash/hang when fetching MIME body parts that are attachments. PLYSA2EQ5T Defensive code to prevent Traveler crash/hang when fetching MIME body parts that are attachments. KLYHA2DKT7 Fixes an AES-GCM memory leak. KLYH9YNR8F Introduce support for Elliptic Curve TLS_ECDHE for compatibility with Apps compiled for Apple iOS 9.0 / OS X 10.11. This adds Elliptic Curve support for HTTP/HTTPS, LDAP/LDAPS, SMTP, IMAP, and POP3. (technote 1966059) RPINA2FNSM Fixed intermittent DHE failures in TLS1.2 connections. TDOOA2GP8G_DEBUG Added a debug notes.ini DEBUG_IMAP_DEADLOCK_TRACE to troubleshoot long held lock leading to insufficient memory in IMAP. This ini is off by default.
Daniel Nashed 17 September 2015 12:41:48
The IBM Champion program is a great way to thank active members of the community.
"The IBM Champion program recognizes innovative thought leaders in the technical community — and rewards these contributors by amplifying their voice and increasing their sphere of influence.
An IBM Champion is an IT professional, business leader, developer, or educator who influences and mentors others to help them make best use of IBM software, solutions, and services."
So if there is someone you think how deserves it, here is the nomination form --> https://ibm.biz/NominateChamps
For more details see --> https://www.ibm.com/developerworks/champion/learn.html
Daniel Nashed 16 September 2015 21:00:34Yesterday Apple released the final version of iOS 9.
As posted before it wasn't sure which part of the ATS specification they will enforce for ActiveSync connections and other internal applications like the Safari web browser.
My tests have shown that Apple is not enforcing the requirement for ECDHE and not even TLS 1.2 for ActiveSync connections yet.
I have been still able to connect with the final iOS 9 release. So the ATS standard is just enforced for custom applications (I did not test all type of Apple applications but at least Safari also continues to work).
In my tests I have disabled TLS 1.2 and I have also disabled the DHE ciphers and iOS 9 was still able to connect over ActiveSync to my Traveler server.
So it is still important that we are getting an update for Domino 9.0.1 FP4 that introduces ECDHE (which is expected until end of September) but we have been lucky that Apple is not enforcing the full ATS standard for Safari and ActiveSync yet.
Below you see the list of ciphers my iOS 9 device requested. This looks like a pretty wide range of ciphers with a lot none ECDHE ciphers.
Here is again a link to the IBM technote --> http://www.ibm.com/support/docview.wss?uid=swg21966059
You should update all your iOS apps to the latest version. There have been fixes for the companion and the todo app for iOS 9 support.
As of now the TN is not update to reflect my findings for the internal applications. And I would be interested to hear from your tests and results with iOS 9.
I have not tested with RSA keys < 2048 or a none SHA-256 cert. Can anyone share their findings?
You can either reply here or drop me an e-mail.
Daniel Nashed 7 September 2015 10:46:02 Traveler 126.96.36.199 shipped while I was away for holidays. I have updated my server already over the weekend and it looks good. I have also not heard anything negative from any customer yet. This release does not only add support for iOS 9 but also Windows 10 Pro on tablet devices and the latest MS SQL Server.
- Support for Windows 10 Pro running on tablet devices. - Support for Apple iOS 9.x running on all Apple devices. - Support for Microsoft SQL Server 2014 Enterprise Edition. Here is the link to the fixlist which includes fixes specifiy for iOS9. http://www.ibm.com/support/docview.wss?uid=swg21700212#9017 Because iOS9 did not ship yet and the version is not final yet, you never know if there are new fixes needed once iOS 9 shipped. But you should be prepared for iOS9 with this update. !! Important Reminder !!! In addition you should keep in mind (as posted before) that Apple is introducing ATS which has way higher requirements for HTTPS/TLS on your server. The missing component for the Domino HTTP stack is currently ECDHE ciphers. Hopefully IBM will make a new fix available before iOS9 shippes.
If you are running Domino HTTPS for anything that directly communicates with a iOS9 or the next OSX you have to meet the following requrirements:
- TLS 1.2
- >= 2048 bit RSA
- SHA-256 signed web server certificates
So you have to already ensure that your device facing HTTPS component is using the right certificates. If you are running behind a secure reverse proxy you can already check if you meet all requirements. For native Domino you should upgrade at least to 9.0.1 FP4 to be prepared.
Daniel Nashed 22 July 2015 09:50:30Apple is introducing a new standard for their next OS versions.
App Transport Security (ATS) is planned for iOS 9 and OS X 10.11.
The current plan is to only support
- TLS 1.2
- >= 2048 bit RSA
- SHA-256 signed web server certificates
TLS 1.2 is a good idea, 2048 RSA keys are a good idea and SHA-256 is also a good idea because SHA-1 is rated as insecure.
The general requirement for PFS ciphers (https://en.wikipedia.org/wiki/Forward_secrecy) is a good idea from security point of view.
But not everyone is supporting ECDHE (Elliptic curve Diffie–Hellman). The normal DHE Ciphers should be perfectly be OK from security point of view.
Maybe Apple is just allowing ECHDE because they have less overhead compared to the normal DHE Ciphers.
On the other side if ECDHE ciphers would be compromised in any way this would leave us with no supported cipher suite at all for communication.
Usually the server is responsible for the order in which ciphers are selected. There are server settings (like in current Domino 9.0.1 versions) to allow the client to select the cipher order.
So in general having a short cipher list with only secure ciphers is a good idea to really ensure that a strong cipher is selected!
But that will leave out many applications and will put a lot of pressure on many vendors and also on administrators implementing the latest software versions on server side.
As an app developer you can change you application to allow less secure TLS versions and ciphers.
But if you are running a server and the application is build against a newer API without those exceptions you will have to provide this strong security standard.
See this link for details --> https://developer.apple.com/library/prerelease/ios/technotes/App-Transport-Security-Technote
The Domino 8.5.x stack will not support TLS 1.2 and and SHA-256 because the code base does not include and SHA-256 support.
But even the current Domino 9.0.1 FP4 version does not completely comply with ATS. DHE is supported in the current Domino FPs and can be configured which would be a vaild and good PFS cipher. But that is not on the ATS list.
There is currently no support for ECDHE in native Domino.
So I am interested to see the feedback from software companies on this Apple move.
On the other side there are Apple servers not complying to those standards and we are still having issues with some Apple SMTP Servers using SSLV2Hello.
It's going to be interesting again to see what will happen when a vendor like Apple pushes standards so hard and in such a short time.
Update: IBM officially announced that they are working on a IF that will introduce ECDHE for all important internet protocols.
The timeline for the fix is end of September. So they will miss the very short timeline they had before iOS 9 will ship today by a couple of days.
Daniel Nashed 20 July 2015 06:05:44One of my customers and another partner reported a new crash when applying 9.0.1 FP4 IF1.
They both reported the exact same call-stack both running on Linux. I have no details yet but given the fact that there are two independent crash reports with the same call-stack this might be a more general issue.
I am waiting for more information and will update you ASAP once I hear anything new.
For now I would stay on the last IF of FP3 until we know what is happening.
Enclosed you find the call-stack for reference.
IBM is working on a fix. One of my customers got a hotfix. It is not clear what is exactly broken.
But we also found some other details and a work-around.
It turns out that IBM moved from Dojo 1.5.2 to 1.5.4 in FP4.
The file owner is not set correctly in those new Dojo files. I have one Linux customer and one AIX customer where fixing the file-permissions did help to avoid the crash and also to get other functionality in XPages and other applications working again.
The permissions looked like this:
/local/notesdata/domino/js/dojo-1.5.4 [root@mail dojo-1.5.4]# ll total 20 drwxr-xr-x. 12 10537 6001 4096 Jun 8 11:10 dijit drwxr-xr-x. 13 10537 6001 4096 Jun 8 11:11 dojo drwxr-xr-x. 53 10537 6001 4096 Jun 8 11:11 dojox drwxr-xr-x. 5 10537 6001 4096 Jun 8 11:11 dwa drwxr-xr-x. 5 10537 6001 4096 Jun 8 11:11 ibm
Changing them via chown -R notes:notes /local/notesdata/domino/js/dojo-1.5.4 did help in our case.
But the hotfix my Linux customer got, did fix it in some other way, because after applying the hotfix the file owners have been still wrong.
Thread 44 (Thread 0x7fa2b8429700 (LWP 14306)):
#0 0x00007fa354c1c063 in select () from /lib64/libc.so.6
#1 0x00007fa355d6db47 in FRDoSleep (secs=, usecs=) at cleanup.c:986
#2 0x00007fa355d6e812 in OSRunExternalScript (
passed_script=0x7fa2b841b340 "\"/export/opt/ibm/domino/notes/latest/linux/nsd.sh\" -batch -crashpid 12669 -crashtid 3091371776", flags=) at cleanup.c:4037
#3 0x00007fa355d6fba3 in OSFaultCleanupExt (action2take=0, CleanupScriptExecFlag=,
iniFileName=0x0, szProcess=, Length=, CrashedPID=0x0) at cleanup.c:1574
#4 0x00007fa355d6ffaf in OSFaultCleanup (action2take=0, CleanupScriptExecFlag=0, iniFileName=0x0)
#5 0x00007fa355d3d9c0 in fatal_error (signl=11, info=, context=) at break.c:2519
#6 0x00007fa3006c4438 in jsig_handler ()
#7 0x00007fa30021132f in masterSynchSignalHandler ()
#9 0x00007fa354bafb32 in fgets () from /lib64/libc.so.6
#10 0x00007fa35433fa0f in Haiku::GetLastModified (this=, pNote=,
argc=, argv=, argl=, rethResult=0x7fa2b841f22c,
retResultLength=0x7fa2b841f228) at haiku/haiku.cpp:17170
#11 0x00007fa35430a864 in Haiku::AtFuncDispatch::ExecuteDbCommand (this=, pHaiku=,
note=0x7fa2b8423480, index=, argc=1421540096, argv=0x7fa354ebbef8 ,
argl=0x7fa2b8421340, bIsJsData=1, bIsHTML=0) at haiku/haiku.cpp:32883
#12 0x00007fa35430ab7e in Haiku::ExecuteDbCommand (this=, note=,
nCmd=, argc=, argv=, argl=, bIsJsData=1,
bIsHTML=0) at haiku/haiku.cpp:4731
#13 0x00007fa3543923e9 in HuDocNote::AddHaikuDbCommand (this=0x7fa2b8423480, iCmd=89, args=..., bIsJsData=1,
bIsHTML=0) at haiku/HuDocNote.cpp:5549
#14 0x00007fa354481eb7 in ShBuiltInNameSpaceTag::Write (this=0x2c27148, formStream=0x7fa2b84235c0, layoutBody=...)
#15 0x00007fa3543e66b7 in HuLayout::WriteContents (this=0x7fa2b48ccdd8, formStream=0x7fa2b84235c0)
#16 0x00007fa354396727 in HuDocNote::GenerateHTML (this=0x7fa2b8423480, html=...) at haiku/HuDocNote.cpp:2589
#17 0x00007fa35433bad7 in Haiku::GenerateHtml (this=0x7fa2b8423470) at haiku/haiku.cpp:3964
#18 0x00007fa354373fd6 in Haiku::HandleDominoCmd (this=0x7fa2b8423470, cmd=...) at haiku/HandleOpenDoc.cpp:192
#19 0x00007fa35433ec30 in Haiku::HandleCmd (cmd=0x7fa2b48b6dd8, cmdHandler=...) at haiku/haiku.cpp:3441
#20 0x00007fa354144fbc in CmdHandlerBase::PrivHandle (this=0x7fa3026cc038, cmd=0x7fa2b48b6dd8, cachedCmd=0x0)
#21 0x00007fa354144037 in CmdHandler::PrivHandle (this=0x7fa3026cc038, cmd=0x7fa2b48b6dd8) at cmdhand.cpp:102
#22 0x00007fa354143ca2 in CmdHandler::Handler (cmd=0x7fa2b48b6dd8, data=) at cmdhand.cpp:153
#23 0x00007fa354135cf5 in Cmd::Execute (this=0x7fa2b841eaa0) at cmd.cpp:1166
#24 0x00007fa3541afe68 in InotesHTTPProcessRequestImpl (ihReq=0x7fa2b54c0f88) at inotesif.cpp:2488
#25 0x00007fa3541b050e in InotesHTTPProcessRequest (ihReq=0x7fa2b841eaa0) at inotesif.cpp:2053
#26 0x00007fa3592114f3 in HTInotesRequest::ProcessRequest (this=0x7fa2b54c0f70) at htinotes.cpp:1254
#27 0x00007fa35920946b in HTRequestExtContainer::ProcessRequest (this=0x7fa2b54c0b08, appSpace=)
#28 0x00007fa35922487d in HTRequest::ProcessRequest (this=0x7fa2b54c0878) at htrequst.cpp:1880
#29 0x00007fa35922dc20 in HTSession::StartRequest (this=0x7fa2b54d61b0) at htsesson.cpp:620
#30 0x00007fa359239276 in HTWorkerThread::CheckForWork (this=0x7fa2b4ae7de8) at htwrkthr.cpp:226
#31 0x00007fa35923949b in HTWorkerThread::ThreadMain (this=0x7fa2b4ae7de8) at htwrkthr.cpp:90
#32 0x00007fa359233331 in HTThreadBeginProc (arg=0x7fa2b4ae7de8) at htthread.cpp:39
#33 0x00007fa355d65383 in ThreadWrapper (Parameter=) at thread.c:1155
#34 0x00007fa3558617b6 in start_thread () from /lib64/libpthread.so.0
#35 0x00007fa354c22d6d in clone () from /lib64/libc.so.6
#36 0x0000000000000000 in ?? ()