FIPS 140-2 Verification

[ccastbr]

In the ePO 5.10 Installation Guide, from July 2018 there are three steps to take to verify FIPS mode.

The first is looking at the server.ini file, which likely will have FipsMode=0 for normal or mixed mode.

The second is to check the Apache httpd.conf file to see that Apache mod.ssl is configured for FIPS enablement with        SSLFips on.

The third, however, has me stumped.   It said to 

Select Menu → Configuration → Server Settings → Security Keys, then confirm that Security Mode is FIPS 140-2.

Where in Security Keys does that show up?    I do not see it.

I do see the OpenSSL version listed in Server Info, but I see no mention of Security Mode in the Security Keys screen.

Is there a different place to look?

Thank you

[Hem · Accepted solution]

Hi,

Good morning,

Menu->configuration->server setting->security keys=>Security mode: FIPS 140-2

Please look at screenshot.

Was my reply helpful?

If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?

[ccastbr]

Thanks - My screen looks exactly like that except missing the Security Mode panel at the end.  ePO 5.10.0.2408  Update 7

[cdinet]

I am checking on that, as mine is missing too, and I am on cu9.  It was supposed to have been fixed in one of the cu's.  I will get back to you.

[cdinet]

In /conf/orion/epo.java.security file, opened with Notepad, what does orion.fips140.mode equal - true or false?

[cdinet]

Actually, please post that file here, assuming your server is installed in fips mode.  I have a conversation with dev on this and they are asking to see it.  

[ccastbr]

orion.fips140.mode=false

Cannot attach a txt file, contents here:

-----------------------------epo.java.security------------------------------------------------------------

# This file is to override the existing/new params in the java.security file
#
# Algorithm restrictions for Secure Socket Layer/Transport Layer Security
# (SSL/TLS) processing.
# Additional algorithm TLSv1 is added to the list apart from the algorithms that are
# present as defaults in the JDK java.security file.
#
jdk.tls.disabledAlgorithms=SSLv2Hello,SSLv3,TLSv1,RC4,MD5withRSA,DH keySize < 1024,EC keySize < 224,DES,3DES

#
# These properties indicate whether or not MFS should be running within
# FIPS mode.
#
# 1) orion.fips140.mode
# Configuration property that puts MFS into FIPS 140 mode. This will cause it to
# perform self checks on start-up. Valid values are
# - true - indicates that MFS should start up in FIPS 140 mode
# - false - indicates that MFS should start up into FIPS 140 mode
# If this property is not specified, then MFS assumes the value is false.
#
# In a production environment, these properties should always be specified.
# FIPS 140 mode should always be enabled for BCFIPS, unless circumstances require
# otherwise and if FIPS-compliance is not required. MFS can only be run in FIPS mode
# if BCFIPS is also in FIPS mode.
#
# It should also be noted that the values of these properties should never changed
# after being set during installation, since doing so will result in a non-FIPS
# compliant mode of operation, regardless of whether FIPS mode is enabled or disabled.
# FIPS 140 requires all CSPs to be re-created when switching modes of operation;
# however, MFS does not support (programmatic) regeneration of its CSPs.
#
# In non-production environments, particularly those of developers, there may
# be cases where these properties are not specified. In that case, MFS will
# assume that it is not in FIPS 140 mode. If the BCFIPS libraries are present, then
# they will assume FIPS 140 mode (since that is their default assumption).
# However, those libraries may not be present in the non-production JRE. In
# that case, MFS should still continue to function, using whatever the default
# JCE providers are for the security methods that it leverages.
#
orion.fips140.mode=false

# JCE jurisdiction policy files used by the JDK can be controlled via a
# 'crypto.policy' Security property.
#
# To enable unlimited cryptography, one can use the crypto.policy
# Security property. In the java.security file this property (crypto.policy)
# is not set by default. We overwrite this property by enabling it and
# setting it to unlimited.
#
# If the property is undefined and the legacy JCE jurisdiction files
# don't exist in the legacy lib/security directory, then the default
# cryptographic level will remain at 'limited'.
#
# To configure the JDK to use unlimited cryptography, set the crypto.policy
# to a value of 'unlimited'. See the notes in the java.security file of the
# latest jdk for more information.
crypto.policy=unlimited

#
# Cipher suites restrictions for MFS jTDS connections
#
# In some environments, certain cipher suites or may be undesirable
# for jTDS connections. For example, SSL handshake with
# TLS_RSA_WITH_AES_128_CBC_SHA will generally fail when the SQL
# Server's certificate has an RSA public key of length less than 2048
# bits. This section describes the mechanism for enabling only specific
# cipher suites based on suite name.
#
# The syntax of the enabled cipher suites string is described as follows:
# EnabledCipherSuites:
# " EnabledCipherSuite { , EnabledCipherSuite } "
#
# EnabledAlgorithm:
# CipherSuiteName
#
jtds.enabledCipherSuites=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA

#
# List of providers and their preference orders:
#
security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider C:DEFRND[HMACSHA256];ENABLE{ALL};
security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider fips:BCFIPS
security.provider.3=com.sun.net.ssl.internal.ssl.Provider
security.provider.4=sun.security.provider.Sun
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC
security.provider.10=sun.security.mscapi.SunMSCAPI

#
# Sun Provider SecureRandom seed source.
#
# Select the primary source of seed data for the "SHA1PRNG" and
# "NativePRNG" SecureRandom implementations in the "Sun" provider.
# (Other SecureRandom implementations might also use this property.)
#
# On Unix-like systems (for example, Solaris/Linux/MacOS), the
# "NativePRNG" and "SHA1PRNG" implementations obtains seed data from
# special device files such as file:/dev/random.
#
# On Windows systems, specifying the URLs "file:/dev/random" or
# "file:/dev/urandom" will enable the native Microsoft CryptoAPI seeding
# mechanism for SHA1PRNG.
#
# By default, an attempt is made to use the entropy gathering device
# specified by the "securerandom.source" Security property. If an
# exception occurs while accessing the specified URL:
#
# SHA1PRNG:
# the traditional system/thread activity algorithm will be used.
#
# NativePRNG:
# a default value of /dev/random will be used. If neither
# are available, the implementation will be disabled.
# "file" is the only currently supported protocol type.
#
# The entropy gathering device can also be specified with the System
# property "java.security.egd". For example:
#
# % java -Djava.security.egd=file:/dev/random MainClass
#
# Specifying this System property will override the
# "securerandom.source" Security property.
#
# In addition, if "file:/dev/random" or "file:/dev/urandom" is
# specified, the "NativePRNG" implementation will be more preferred than
# SHA1PRNG in the Sun provider.
#
securerandom.source=file:/dev/urandom

# override the jceks key filter so that bouncycastle keys can be serialized
jceks.key.serialFilter = org.bouncycastle.**;java.lang.Enum;java.security.KeyRep;java.security.KeyRep$Type;javax.crypto.spec.SecretKeySpec;!*

--------------------------------------------- end of file-------------------------------------------

[cdinet · Accepted solution]

Ok, that field in security keys is only present if fips mode = true.  So if you believe your server should be in fips mode, it is not.

[ccastbr]

OK - I was actually trying to see if it was.   I have since learned that for our application it should not.  I was confused by the manual since I did not see any reference to security mode.  Two out of three methods gave good answers(server.ini, and Apache httpd.conf, but the third made me wonder if the system was working properly.       For my own notes in the future, I will replace looking at the Security Keys page and look for the epo.java.security file.

Thanks!

[cdinet]

Ok, thanks.