On Nov 19, 2015, at 6:50 AM, Darran Lofthouse <darran.lofthouse(a)jboss.com&gt; wrote: The problem with this issue is that it is going to be quite complex to solve, especially once we start to expand on all the scenarios we need to support. Add to that it becomes even more complex once we need to consider backwards compatibility. Generally the scenarios we need are: - - Using a FIPS configured JVM - Using a non-FIPS configured JVM Combined with: - - TLS enabled for the host controller connection. - TLS not enabled. Although the issue raised only talks about an error message for one we need to ensure we cover them all. Firstly the connection that is being talked about here is the connection from the individual application server process back to it's host controller all running on the same machine. The reason for the simple trusting solution is because although a connection is used it is always local - the reason we need to be able to support TLS for this connection is because we connect to the same Remoting connector as remote clients also used so once TLS is enabled it is enabled for all. Firstly I think it is worth exploring if there is anything else we can do to automatically configure the client side of this connection without requiring any additional configuration from the administrator. If we can identify the certificate the server will be using for the connection there may be something we can do to send this to the application server process so that it can instantiate a SunJSSE compatible KeyStore and subsequently a SunJSSE TrustManager that will be accepted into the SSLContext. When it comes to host controller and application server initialisation those two processes are always guaranteed to be the same version so this gives us some leeway on how the application server process is initially configured. If that is not possible then an alternative is that to achieve a FIPS mode compliant connection from the application server to the host controller is going to require a custom configuration. The problem is we do not have the management model available on the application server at this time so we would probably still need a way to define it within the host controller and convert it to a format that can be used on the application server. In this case I don't think using the standard system properties would be a good idea as existing installations could already be relying on these elsewhere. If we needed to go down the custom configuration route then I would suggest lack of configuration means stick with the current behaviour so existing installations are unaffected leaving the configuration to be set by those that do require it. If automatically obtaining the certificate is viable then that could be used for all cases without breaking compatibility but additional verification is probably needed there. Regards, Darran Lofthouse. > On 19/11/15 10:25, Ryan Emerson wrote: > Hello All, > > Currently domain mode is unable to execute when the JVM has FIPS enabled. See [1] for example config files and the resulting stacktrace. > > I am looking into this issue (SET engineer), however my current knowledge of core and FIPS is limited. What are your thoughts on how to implement FIPS compatibility? Is there any fundamental reasons why such a feature shouldn't be supported? > > [1] https://issues.jboss.org/browse/WFCORE-1135 > > Thanks > Ryan > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

This issue originated from a downstream customer issue (BZ now linked in JIRA), so there is some demand. Originally the intention was to try and backport the upstream fix, however as FIPS support now appears to be a complex RFE this may not be possible. ----- Original Message ----- From: "Anil Saldanha" <anilsaldhana(a)gmail.com&gt; To: "Darran Lofthouse" <darran.lofthouse(a)jboss.com&gt; Cc: wildfly-dev(a)lists.jboss.org Sent: Thursday, 19 November, 2015 1:07:32 PM Subject: Re: [wildfly-dev] Supporting FIPS in domain mode I agree with Darran that this is a complicated exercise that should be backed by a business demand. The potential for the feature -- if implemented -- to break in the long run is high -- if any custom configuration is involved. > On Nov 19, 2015, at 6:50 AM, Darran Lofthouse <darran.lofthouse(a)jboss.com&gt; wrote: > > The problem with this issue is that it is going to be quite complex to > solve, especially once we start to expand on all the scenarios we need > to support. Add to that it becomes even more complex once we need to > consider backwards compatibility. > > Generally the scenarios we need are: - > - Using a FIPS configured JVM > - Using a non-FIPS configured JVM > Combined with: - > - TLS enabled for the host controller connection. > - TLS not enabled. > > Although the issue raised only talks about an error message for one we > need to ensure we cover them all. > > Firstly the connection that is being talked about here is the connection > from the individual application server process back to it's host > controller all running on the same machine. The reason for the simple > trusting solution is because although a connection is used it is always > local - the reason we need to be able to support TLS for this connection > is because we connect to the same Remoting connector as remote clients > also used so once TLS is enabled it is enabled for all. > > Firstly I think it is worth exploring if there is anything else we can > do to automatically configure the client side of this connection without > requiring any additional configuration from the administrator. > > If we can identify the certificate the server will be using for the > connection there may be something we can do to send this to the > application server process so that it can instantiate a SunJSSE > compatible KeyStore and subsequently a SunJSSE TrustManager that will be > accepted into the SSLContext. > > When it comes to host controller and application server initialisation > those two processes are always guaranteed to be the same version so this > gives us some leeway on how the application server process is initially > configured. > > If that is not possible then an alternative is that to achieve a FIPS > mode compliant connection from the application server to the host > controller is going to require a custom configuration. The problem is > we do not have the management model available on the application server > at this time so we would probably still need a way to define it within > the host controller and convert it to a format that can be used on the > application server. In this case I don't think using the standard > system properties would be a good idea as existing installations could > already be relying on these elsewhere. > > If we needed to go down the custom configuration route then I would > suggest lack of configuration means stick with the current behaviour so > existing installations are unaffected leaving the configuration to be > set by those that do require it. > > If automatically obtaining the certificate is viable then that could be > used for all cases without breaking compatibility but additional > verification is probably needed there. > > Regards, > Darran Lofthouse. > > > >> On 19/11/15 10:25, Ryan Emerson wrote: >> Hello All, >> >> Currently domain mode is unable to execute when the JVM has FIPS enabled. See [1] for example config files and the resulting stacktrace. >> >> I am looking into this issue (SET engineer), however my current knowledge of core and FIPS is limited. What are your thoughts on how to implement FIPS compatibility? Is there any fundamental reasons why such a feature shouldn't be supported? >> >> [1] https://issues.jboss.org/browse/WFCORE-1135 >> >> Thanks >> Ryan >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Thank you for all the input. Clearly this is a substantial RFE, which is unrealistic for backporting. I have update the original JIRA to reflect that this is a RFE. Thanks Ryan ----- Original Message ----- From: "Vaclav Tunka" <vtunka(a)redhat.com&gt; To: "Ryan Emerson" <remerson(a)redhat.com&gt; Cc: wildfly-dev(a)lists.jboss.org, "Jean-Frederic" <jclere(a)redhat.com&gt; Sent: Friday, 20 November, 2015 10:16:59 AM Subject: Re: [wildfly-dev] Supporting FIPS in domain mode Enabling the implementation itself to be "FIPS compliant" is just one part (although quite complicated itself), second part is the audit by a third party agency, lot of paperwork and lot of costs to be able to mark something as truly FIPS compliant. So this is definitely a big RFE. Ryan if you want to find out more, I suggest you get in touch with Jean-Frederic Clere - I tried to organize a call with platform developers about FIPS, not sure if that already happened. Cheers, Vaclav On 11/19/2015 02:59 PM, Ryan Emerson wrote: > This issue originated from a downstream customer issue (BZ now linked in JIRA), so there is some demand. Originally the intention was to try and backport the upstream fix, however as FIPS support now appears to be a complex RFE this may not be possible. > > ----- Original Message ----- > From: "Anil Saldanha" <anilsaldhana(a)gmail.com&gt; > To: "Darran Lofthouse" <darran.lofthouse(a)jboss.com&gt; > Cc: wildfly-dev(a)lists.jboss.org > Sent: Thursday, 19 November, 2015 1:07:32 PM > Subject: Re: [wildfly-dev] Supporting FIPS in domain mode > > I agree with Darran that this is a complicated exercise that should be backed by a business demand. > > The potential for the feature -- if implemented -- to break in the long run is high -- if any custom configuration is involved. > >> On Nov 19, 2015, at 6:50 AM, Darran Lofthouse <darran.lofthouse(a)jboss.com&gt; wrote: >> >> The problem with this issue is that it is going to be quite complex to >> solve, especially once we start to expand on all the scenarios we need >> to support. Add to that it becomes even more complex once we need to >> consider backwards compatibility. >> >> Generally the scenarios we need are: - >> - Using a FIPS configured JVM >> - Using a non-FIPS configured JVM >> Combined with: - >> - TLS enabled for the host controller connection. >> - TLS not enabled. >> >> Although the issue raised only talks about an error message for one we >> need to ensure we cover them all. >> >> Firstly the connection that is being talked about here is the connection >> from the individual application server process back to it's host >> controller all running on the same machine. The reason for the simple >> trusting solution is because although a connection is used it is always >> local - the reason we need to be able to support TLS for this connection >> is because we connect to the same Remoting connector as remote clients >> also used so once TLS is enabled it is enabled for all. >> >> Firstly I think it is worth exploring if there is anything else we can >> do to automatically configure the client side of this connection without >> requiring any additional configuration from the administrator. >> >> If we can identify the certificate the server will be using for the >> connection there may be something we can do to send this to the >> application server process so that it can instantiate a SunJSSE >> compatible KeyStore and subsequently a SunJSSE TrustManager that will be >> accepted into the SSLContext. >> >> When it comes to host controller and application server initialisation >> those two processes are always guaranteed to be the same version so this >> gives us some leeway on how the application server process is initially >> configured. >> >> If that is not possible then an alternative is that to achieve a FIPS >> mode compliant connection from the application server to the host >> controller is going to require a custom configuration. The problem is >> we do not have the management model available on the application server >> at this time so we would probably still need a way to define it within >> the host controller and convert it to a format that can be used on the >> application server. In this case I don't think using the standard >> system properties would be a good idea as existing installations could >> already be relying on these elsewhere. >> >> If we needed to go down the custom configuration route then I would >> suggest lack of configuration means stick with the current behaviour so >> existing installations are unaffected leaving the configuration to be >> set by those that do require it. >> >> If automatically obtaining the certificate is viable then that could be >> used for all cases without breaking compatibility but additional >> verification is probably needed there. >> >> Regards, >> Darran Lofthouse. >> >> >> >>> On 19/11/15 10:25, Ryan Emerson wrote: >>> Hello All, >>> >>> Currently domain mode is unable to execute when the JVM has FIPS enabled. See [1] for example config files and the resulting stacktrace. >>> >>> I am looking into this issue (SET engineer), however my current knowledge of core and FIPS is limited. What are your thoughts on how to implement FIPS compatibility? Is there any fundamental reasons why such a feature shouldn't be supported? >>> >>> [1] https://issues.jboss.org/browse/WFCORE-1135 >>> >>> Thanks >>> Ryan >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Darran's the expert on this, but my initial naive question is whether this can be split into two logical use cases: 1) Where we know TLS is not going to be used on the HC<->server connection. 2) Where we don't know that. I ask because if case 2 is harder or requires changes that don't belong in a micro release (e.g. management model changes) perhaps we can first deal with case 1. My impression from the initial bug report is that SSL/TLS was not configured on the host's management interfaces.

On 11/19/15 4:25 AM, Ryan Emerson wrote: > Hello All, > > Currently domain mode is unable to execute when the JVM has FIPS enabled. See [1] for example config files and the resulting stacktrace. > > I am looking into this issue (SET engineer), however my current knowledge of core and FIPS is limited. What are your thoughts on how to implement FIPS compatibility? Is there any fundamental reasons why such a feature shouldn't be supported? > > [1] https://issues.jboss.org/browse/WFCORE-1135 > > Thanks > Ryan > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >