|
Home > Archive > WebSphere Application Server > July 2007 > SSL Logging
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Steve Taylor 2007-07-28, 7:18 am |
| 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
| |
| Paul Ilechko 2007-07-28, 1:22 pm |
| 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.
| |
| Steve Taylor 2007-07-28, 1:22 pm |
| 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
| |
| Paul Ilechko 2007-07-28, 1:22 pm |
| 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 ?
| |
| Steve Taylor 2007-07-28, 7:17 pm |
| 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
| |
| Paul Ilechko 2007-07-28, 7:17 pm |
| Steve Taylor wrote:
>
> 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.
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 ?
| |
| Steve Taylor 2007-07-29, 1:20 pm |
| 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
| |
| Paul Ilechko 2007-07-29, 1:20 pm |
| 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.
| |
| Steve Taylor 2007-07-29, 7:18 pm |
| 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
| |
|
| > 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.
| |
| Steve Taylor 2007-07-30, 1:23 pm |
| On 2007-07-30 10:23:03 +0100, "Ben_" <reply@newsgroup.com> said:
>
> 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.
Hi,
All I'm after logging is just a single line that indicates that the
handshake has passed or failed, something along the lines of the http
access log would be more than sufficient.
I did look at using the -Djavax.net.debug=ssl,handshake but this
outputs reams of information which i am cautious of it.
Cheers
Steve
| |
|
| > Currently don't have a HTTP server, were using the SSL and HTTP within WAS
> 6.0.2.
If you setup one you could check if the following helps:
http://publib.boulder.ibm.com/infoc...sslloglvl.html.
There is also the SSLTrace directive, but it's documented as not recommended
for production.
| |
|
|
| Paul Ilechko 2007-07-31, 1:24 am |
| Paul Ilechko 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.
A friend of mine thinks that WAS 6.1 should log something, and if it
doesn't you would have the option of writing your own trust manager and
thus be able to log whatever you wanted. Is there any way that you can
test this with 6.1 ?
|
|
|
|
|