Upgrade to DNN 9.11.0: Search broken on FIPS enabled systems

[brentil]

Description of bug

After upgrading to DNN 9.11.0 from 9.10.1 the search is broken on FIPS enabled systems. It looks like something is using MD5 per the exception text when it shouldn't in a FIPS compliant environment.

Steps to reproduce

List the precise steps to reproduce the bug:

1. Windows server with FIPS compliance enabled
2. Upgrade existing DNN 9.10 system to 9.11
3. Doing a search returns no results but will log an exception
4. Doing a search re-index doesn't run but will log an exception
5. See error

Current behavior

Doing a search returns no results and attempting to re-index the website fails both dropping exceptions in the logs. When the scheduler runs the search crawl it throws exceptions too.

Error information

AbsoluteURL:
DefaultDataProvider:DotNetNuke.Data.SqlDataProvider, DotNetNuke
ExceptionGUID:c053665e-e300-40d7-820c-1a7b795139d3
AssemblyVersion:
PortalId:-1
UserId:-1
TabId:-1
RawUrl:
Referrer:
UserAgent:
ExceptionHash:oVoRwz/44xNPaHBu2oFFcOe6kOI=
Message:The type initializer for 'Lucene.Net.Store.FSDirectory' threw an exception.
StackTrace:
   at DotNetNuke.Services.Search.Internals.LuceneControllerImpl.get_Writer()
   at DotNetNuke.Services.Search.Internals.LuceneControllerImpl.Delete(Query query)
   at DotNetNuke.Services.Search.Internals.InternalSearchControllerImpl.DeleteSearchDocumentInternal(SearchDocument searchDocument, Boolean autoCommit)
   at DotNetNuke.Services.Search.Internals.InternalSearchControllerImpl.DeleteAllDocuments(Int32 portalId, Int32 searchTypeId)
   at DotNetNuke.Services.Search.SearchEngine.DeleteOldDocsBeforeReindex()
   at DotNetNuke.Services.Search.SearchEngineScheduler.DoWork()
InnerMessage:System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. 
---> System.InvalidOperationException: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms. at System.Security.Cryptography.MD5CryptoServiceProvider..ctor() 
--- End of inner exception stack trace 
--- at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor) at System.Reflection.Ru
InnerStackTrace:
   at Lucene.Net.Store.FSDirectory..cctor()
Source:DotNetNuke
FileName:
FileLineNumber:0
FileColumnNumber:0
Method:

Additional context

Verified the App_Data\FipsCompilanceAssemblies\Lucene.Net.dll was correctly in the bin\ folder already. I used a compare tool and saw that the 9.11.0 DLL is actually identical to what was there from 9.10.1 so the issue is likely not in that DLL but somewhere else?

Affected version

• 10.00.00 alpha build
• 09.11.00
• 09.10.02
• 09.10.01

Affected browser

• Chrome
• Firefox
• Safari
• Internet Explorer 11
• Microsoft Edge (Classic)
• Microsoft Edge Chromium

[WillStrohl]

The FIPS compliant encryption provider was never FIPS compliant because of the very reason this feature is broken. The chosen algorithm isn't what FIPS expects.

More details can be seen in this README:

https://github.com/UpendoVentures/Dnn.FipsAesCryptoProvider#readme

[brentil]

I understand what's there about Triple DES vs AES but the issue being kicked out here causing the exception is the use of MD5. Even if not for FIPS compliance MD5 should have been replaced with SHA. We've been running in Windows FIPS mode for a very long time and it was working in every version of DNN 8/9 we've installed on our websites until 9.11.0.

[bdukes]

DNN Platform has not changed anything with Lucene.net in many years. Perhaps there was an issue during the upgrade with copying the FIPS assembly into the bin folder. Have you tried copying that assembly from the App_Data\FipsCompilanceAssemblies into the bin?

[brentil]

I did verify the App_Data\FipsCompilanceAssemblies version of the file was in the bin folder. It's slightly larger than the non-FIPS one.

I did a fresh install and it works under FIPS enforced mode but the upgraded website does not. Are there some other DLLs I can look to verify they're correct?

[stale]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[mitchelsellers]

@brentil Are you on Evoq by chance? Also, do you have any third-party search modules installed or anything that may have modified Lucene?

[brentil]

@brentil Are you on Evoq by chance? Also, do you have any third-party search modules installed or anything that may have modified Lucene?

@mitchelsellers we are not using Evoq, just the normal DNN. We do not have and 3rd party search modules installed or modified Lucene. This happens to us on a default fresh DNN installation. We ended up having to makes changes to the specific IIS websites running the DNN installs to disable FIPS for their applications. I have not tested again with 9.12 though.

[david-poindexter]

We had a client in a FIPS environment run a test on 9.12.0 and they had no issues.

[jeremy-farrance]

[like] Jeremy Farrance reacted to your message:

…

________________________________ From: David Poindexter ***@***.***> Sent: Tuesday, September 19, 2023 9:58:24 PM To: dnnsoftware/Dnn.Platform ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [dnnsoftware/Dnn.Platform] Upgrade to DNN 9.11.0: Search broken on FIPS enabled systems (Issue #5344) We had a client in a FIPS environment run a test on 9.12.0 and they had no issues. — Reply to this email directly, view it on GitHub<#5344 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAE7P5KXAPAFOMI5PO7GYXTX3IIQBANCNFSM6AAAAAARIKR3PQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[brentil]

We had a client in a FIPS environment run a test on 9.12.0 and they had no issues.

When DNN 9.13.0 final drops I will run through testing with it.

[david-poindexter]

We had a client in a FIPS environment run a test on 9.12.0 and they had no issues.

When DNN 9.13.0 final drops I will run through testing with it.

@brentil thanks for the offer to test. Please test with DNN 9.13.0-rc3 so that any potential bugs can be resolved before the official release of 9.13.0.