Supporting FIPS in domain mode

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Supporting FIPS in domain mode

Ryan Emerson
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Supporting FIPS in domain mode

Darran Lofthouse
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Supporting FIPS in domain mode

Anil Saldanha
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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Supporting FIPS in domain mode

Ryan Emerson
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" <[hidden email]>
To: "Darran Lofthouse" <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Supporting FIPS in domain mode

Brian Stansberry
In reply to this post by Ryan Emerson
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Supporting FIPS in domain mode

Darran Lofthouse
On 19/11/15 15:50, Brian Stansberry wrote:

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

To get to the error in the bug report the underlying user has taken
these two steps: -
  1 - Configure the JVM to be FIPS Compliant.
  2 - Start a default domain configuration.

They have experienced the error and reported it to us.

I would be very surprised if they were not planning to subsequently
enable TLS for the remote communication with the HostController.

I suppose at a push master may have no application server instances but
have TLS enable for remote communication and the individual slave host
controllers only bind management to loopback so don't enable TLS.

>
> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Supporting FIPS in domain mode

Brian Stansberry
On 11/19/15 10:07 AM, Darran Lofthouse wrote:

> On 19/11/15 15:50, Brian Stansberry wrote:
>> 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.
>
> To get to the error in the bug report the underlying user has taken
> these two steps: -
>   1 - Configure the JVM to be FIPS Compliant.
>   2 - Start a default domain configuration.
>
> They have experienced the error and reported it to us.
>
> I would be very surprised if they were not planning to subsequently
> enable TLS for the remote communication with the HostController.
>

I can't say I disagree. :)

> I suppose at a push master may have no application server instances but
> have TLS enable for remote communication and the individual slave host
> controllers only bind management to loopback so don't enable TLS.
>

With WildFly 9/10 the intra-domain comms can be running on a completely
separate network from non-management stuff, so the possibility that
traffic doesn't use TLS is a bit greater. But still not likely. In
earlier versions this kind of setup is harder since CLI would talk to
the DC over the same interface intra-domain comms use. With WF 9/10 the
CLI could use HTTP Upgrade to talk to the DC on one network while
intra-domain comms are on another network using the old native interface.

>>
>> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Supporting FIPS in domain mode

Vaclav Tunka
In reply to this post by Ryan Emerson
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" <[hidden email]>
> To: "Darran Lofthouse" <[hidden email]>
> Cc: [hidden email]
> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Supporting FIPS in domain mode

Ryan Emerson
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" <[hidden email]>
To: "Ryan Emerson" <[hidden email]>
Cc: [hidden email], "Jean-Frederic" <[hidden email]>
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" <[hidden email]>
> To: "Darran Lofthouse" <[hidden email]>
> Cc: [hidden email]
> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Supporting FIPS in domain mode

Darran Lofthouse
Still thinking about the initial report a complete solution is seeming
very ambitious at the moment.

However an alternative option to overcome this specific error could be a
new set of system properties to define how the SSLContext is assembled
for the AS->HC connections.  If these properties are set then they are
used to create the stores, managers and resulting SSLContext - if not
set we keep the existing behaviour.

The risk however is that as this is FIPS related using system properties
to contain anything sensitive is probably not an option.

This does still leave the scenario of using a FIPS configured JVM but no
TLS to the HostController although I am still inclined to believe that
is more the edge case.

Also note I am not considering the standard system properties for this
as they may already be being used for another purpose within the
application server process.

Regards,
Darran Lofthouse.


On 20/11/15 11:22, Ryan Emerson wrote:

> 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" <[hidden email]>
> To: "Ryan Emerson" <[hidden email]>
> Cc: [hidden email], "Jean-Frederic" <[hidden email]>
> 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" <[hidden email]>
>> To: "Darran Lofthouse" <[hidden email]>
>> Cc: [hidden email]
>> 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 <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev