Hi,

I'm running WebSphere 6.0.2 the application we are creating is using
mutual SSL with to ensure the identity of the client.  All of this is
working without a problem, the issue that I have is that I cannot
workout how to set-up logging on SSL within WAS 6.0.2.

What I want to do is set-up some form of logging where it writes a log
entry for each ssl negotiation, by doing this i can provide audit on
the connections made and raise a system alter via a file monitor when
there is a failure.

I have looked at the option of setting the javax.net.debug options but
these output copious amounts of data and i am concerned about the
performance impact of such a large amount of logging and running debug
in production.

Any help would be appreciated.

Thanks in advanced

Steve

[ Post a follow-up to this message ]

Steve Taylor wrote:
> Hi,
>
> I'm running WebSphere 6.0.2 the application we are creating is using
> mutual SSL with to ensure the identity of the client.  All of this is
> working without a problem, the issue that I have is that I cannot
> workout how to set-up logging on SSL within WAS 6.0.2.
>
> What I want to do is set-up some form of logging where it writes a log
> entry for each ssl negotiation, by doing this i can provide audit on the
> connections made and raise a system alter via a file monitor when there
> is a failure.


SSL negotiation typically doesn't happen at WAS, it happens at the HTTP
server, and the plugin forwards the original user's DN to WAS.

[ Post a follow-up to this message ]

On 2007-07-28 14:15:18 +0100, Paul Ilechko <paul.ilechko@us.ibm.com> said:

> Steve Taylor wrote: 
>
>
> SSL negotiation typically doesn't happen at WAS, it happens at the HTTP
> server, and the plugin forwards the original user's DN to WAS.

Currently don't have a HTTP server, were using the SSL and HTTP within
WAS 6.0.2.

Cheers

Steve

[ Post a follow-up to this message ]

Steve Taylor wrote:
> On 2007-07-28 14:15:18 +0100, Paul Ilechko <paul.ilechko@us.ibm.com> said:
> 
[vbcol=seagreen] 
>
> Currently don't have a HTTP server, were using the SSL and HTTP within
> WAS 6.0.2.

How are you doing load balancing, failover, session affinity etc ?

To go back to your original question, if WAS fails the SSL connection
for some reason I would assume that an exception would be logged. Are
you not seeing that ?

[ Post a follow-up to this message ]

On 2007-07-28 17:38:12 +0100, Paul Ilechko <paul.ilechko@us.ibm.com> said:

> Steve Taylor wrote: 
> 
>
> How are you doing load balancing, failover, session affinity etc ?
>
> To go back to your original question, if WAS fails the SSL connection
> for some reason I would assume that an exception would be logged. Are
> you not seeing that ?

On the load balancing and failover this is taken care of by CSS's at
the network layer, session affinity well don't really care about it,
the app is totally stateless..

Anyway use an invalid client certificate, not in the sever trust store
chain, to simulate the type of failure I want to trap and none of the
log files move.  I've been checking access.log, http_access.log,
http_error.log, SystemOut.log, SystemErr.log.  The only way I seem to
get any output is to use the -Djavax.net.debug=ssl,handshake as a vm
start-up parameter but this just generated massive amounts of logging
data.

Cheers

Steve

[ Post a follow-up to this message ]

Steve Taylor wrote:
[vbcol=seagreen]
>
> Anyway use an invalid client certificate, not in the sever trust store
> chain, to simulate the type of failure I want to trap and none of the
> log files move.  I've been checking access.log, http_access.log,
> http_error.log, SystemOut.log, SystemErr.log.  The only way I seem to
> get any output is to use the -Djavax.net.debug=ssl,handshake as a vm
> start-up parameter but this just generated massive amounts of logging data.[/vbcol
]

Just want to clarify something - you said in the original post that you
are "using mutual SSL to ensure the identity of the client". Did you
mean by that the identity of some server or the identity of an actual
end user?

I'm asking because I assumed the latter, so I was expecting that you
would test with a cert where the DN was for a user not in registry.
However, you tested for a different condition, which is where the
certificate signed is not in your trust store. That actually tells you
nothing about the identity of the client, merely about the identity of
the signer of the certificate. Are you actually trying to validate a
client cert, or merely establish trust ?

[ Post a follow-up to this message ]

On 2007-07-29 00:10:03 +0100, Paul Ilechko <paul.ilechko@us.ibm.com> said:

> Steve Taylor wrote:
> 
>
> Just want to clarify something - you said in the original post that you
> are "using mutual SSL to ensure the identity of the client". Did you
> mean by that the identity of some server or the identity of an actual
> end user?
>
> I'm asking because I assumed the latter, so I was expecting that you
> would test with a cert where the DN was for a user not in registry.
> However, you tested for a different condition, which is where the
> certificate signed is not in your trust store. That actually tells you
> nothing about the identity of the client, merely about the identity of
> the signer of the certificate. Are you actually trying to validate a
> client cert, or merely establish trust ?

Hi,

It's just a case of establishing trust at the connection level between
my services and the client (either a server or a client process).  This
is not being used to validate the actual end user identity, which is
subsequently transmitted via the service call.

This approach is being taken because of our service based architecture,
and mutual ssl is being used to establish trust between the two ends
before the service can be invoked.

However the trapping of a failed negation of trust is important to me
as it can be used as an indicator that an attempt to breach system
security is in progress.

Cheers

Steve

[ Post a follow-up to this message ]

Steve Taylor wrote:
> On 2007-07-29 00:10:03 +0100, Paul Ilechko <paul.ilechko@us.ibm.com> said:
> 
>
> Hi,
>
> It's just a case of establishing trust at the connection level between
> my services and the client (either a server or a client process).  This
> is not being used to validate the actual end user identity, which is
> subsequently transmitted via the service call.
>
> This approach is being taken because of our service based architecture,
> and mutual ssl is being used to establish trust between the two ends
> before the service can be invoked.
>
> However the trapping of a failed negation of trust is important to me as
> it can be used as an indicator that an attempt to breach system security
> is in progress.

OK, clearly you know what you are doing here, I just ask because a lot
of people don't really understand SSL. I'm a little surprised that
nothing is logged on an inbound SSL request with an invalid signer cert.
You could try opening a PMR, see if you can get an answer from
development as to whether there ought to be something logged. Meanwhile
I'll ask a contact or two of mine.

paul.

[ Post a follow-up to this message ]

On 2007-07-29 14:42:42 +0100, Paul Ilechko <paul.ilechko@us.ibm.com> said:

> Steve Taylor wrote: 
>
> OK, clearly you know what you are doing here, I just ask because a lot
> of people don't really understand SSL. I'm a little surprised that
> nothing is logged on an inbound SSL request with an invalid signer
> cert. You could try opening a PMR, see if you can get an answer from
> development as to whether there ought to be something logged. Meanwhile
> I'll ask a contact or two of mine.
>
> 	paul.

Hi,

Thanks for your help on this, I'll try to get hold of IBM Support to
raise a request tomorrow, if i get anywhere I'll post back the result.

Cheers

Steve

[ Post a follow-up to this message ]

> I'm a little surprised that nothing is logged on an inbound SSL request
> with an invalid signer cert. You could try opening a PMR, see if you can
> get an answer from development as to whether there ought to be something
> logged.

Not too much should be logged either.

Remembers me of a certain version of WAS (was it v4) logging a stacktrace
for each and every 404 error.

Needless to say that this caused a serious performance hit on web sites with
many broken links or boken visitors.

If something is logged for SSL failure, ideally, it should be light.
Internet facing applications must not see their logs fill up in minutes
because of malicious / broken visitors.

[ Post a follow-up to this message ]