You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by Robert Maier <ro...@gmail.com> on 2006/06/22 14:14:14 UTC
Bug or feature?
Hi,
One more contribution to this list:
I discovered some strange behaviour which I am not sure whether it is a bug
or a feature:
Environment: Apache Axis 1.4, WSS4J 1.5, Apache Tomcat 5.5.17 (server-side),
Java app (client-side). I use the WSDoAllSender and WSDoAllReceiver for the
RequestFlow and ResponseFlow of both the client and the service. The client
and the service are able to exchange signed and/or encrypted messages.
Now, on to the issue: For the request flow, if the client handler specifies
as action "Signature" and the service handler expects "Signature Encrypt",
the client sends a signed message, the signature is verified at the server
side and the message gets delivered to the service, although the message is
not encrypted as expected. The same happens in the opposite direction as
well.
Although it might be nice as a feature (see my previous post), I am afraid
it is a bug and an exception should be thrown/fault should be returned
(something like WSDoAllReceiver: security processing failed (actions
mismatch)).
What would the verdict be: bug or feature?
Cheers,
Robert.
Re: Bug or feature?
Posted by Robert Maier <ro...@gmail.com>.
See inline.
On 6/22/06, Fred Dushin <fd...@iona.com> wrote:
>
>
>
> Robert Maier wrote:
> > Now, on to the issue: For the request flow, if the client handler
> > specifies as action "Signature" and the service handler expects
> > "Signature Encrypt", the client sends a signed message, the signature
> > is verified at the server side and the message gets delivered to the
> > service, although the message is not encrypted as expected. The same
> > happens in the opposite direction as well.
> Yes, I agree that this is an issue, though I would suspect that flipping
> your scenario a bit is more troublesome. To wit, suppose a message
> comes in encrypted but not signed, but the message consumer requires
> integrity protection. You might want to reject the request (or
> response, as the case may be) right there.
Sure, I totally agree, receiving an only-encrypted message while the
consumer requires integrity protection also would be more troublesome This
case I've tested and the message is properly rejected.
However, if the consumer requires both integrity protection and
confidentiality and receives a message that is only integrity protected, the
message should also be rejected at least for the sake of being consequent.
Otherwise the developer will have to check whether the received message has
been protecetd for both or only its integrity.
(Requiring encryption is
> certainly important and laudable, but the "cat is out of the bag", as it
> were, if the message is sent without confidentiality protection).
The "cat is out of the bag" reasoning would not really hold since, for
instance, me as a service developer I need to be sure that I only accept
messages that have been both integrity and confidentiality protected. In
order to do that I place "Signature Encryption" as an action and I presume
(foolishly in this case) that whatever messages are passed to my service
have been checked for those kinds of protection. The fact that the message
has not been protected for confidentiality and still I accept it as a valid
(for my criteria) message would diminish the security of the service I
provide. The fact that the message has been seen by whoever is listening to
the wire is exactly the reason I did not want to accept such messages in the
first place.
I am not an expert on Axis, but at a minimum the information about what
> occurred (the "results" from processSecurityHeaders) should be
> propagated up the stack through some sort of request context (good ol'
> Current). Perhaps that would mitigate your concerns?
True, I believe the developer can check the results of the security
processing and probably see that the message has not been confidentiality
protected. But then why not allow all messages to be received and leave the
choice to the higher layer (service)? To better explain: all messages would
pass the security handler(s), being processed if necessary and it would be
the responsibility of the developer to check the results of the security
processing. That way, the service would know if it has to deal with an
"insecure", "signed", encrypted", "signed and encrypted" message and would
take necessary action. The results of the security processing which now just
throw faults and reject a message (e.g. "message signed but certificate not
trusted") would be accessible to the developer.
If the philosophy behind WS-Security is an "access-control"-like philosophy
(i.e. "I only want to receive messages that fulfill certain criteria") then
the ramblings in my previous paragraph are not to be taken into account, but
then the original issue would be a "bug".
If the philosophy behind WS-Security would be a "protect messages"-like
philosophy (i.e. "I want to be able to protect messages that I send and
receive") then the original issue would not be a "bug" but then
transparently rejecting messages would not be right.
>
> > Although it might be nice as a feature (see my previous post), I am
> > afraid it is a bug and an exception should be thrown/fault should be
> > returned (something like WSDoAllReceiver: security processing failed
> > (actions mismatch)).
> >
> > What would the verdict be: bug or feature?
> I would hesitate to call this a bug, per se. It's a valid enhancement
> request, however.
I suppose I am just advocating for being consequent :-) Thanks for your
reply.
Cheers,
Robert.
Re: Bug or feature?
Posted by Robert Maier <ro...@gmail.com>.
See inline.
On 6/22/06, Fred Dushin <fd...@iona.com> wrote:
>
>
>
> Robert Maier wrote:
> > Now, on to the issue: For the request flow, if the client handler
> > specifies as action "Signature" and the service handler expects
> > "Signature Encrypt", the client sends a signed message, the signature
> > is verified at the server side and the message gets delivered to the
> > service, although the message is not encrypted as expected. The same
> > happens in the opposite direction as well.
> Yes, I agree that this is an issue, though I would suspect that flipping
> your scenario a bit is more troublesome. To wit, suppose a message
> comes in encrypted but not signed, but the message consumer requires
> integrity protection. You might want to reject the request (or
> response, as the case may be) right there.
Sure, I totally agree, receiving an only-encrypted message while the
consumer requires integrity protection also would be more troublesome This
case I've tested and the message is properly rejected.
However, if the consumer requires both integrity protection and
confidentiality and receives a message that is only integrity protected, the
message should also be rejected at least for the sake of being consequent.
Otherwise the developer will have to check whether the received message has
been protecetd for both or only its integrity.
(Requiring encryption is
> certainly important and laudable, but the "cat is out of the bag", as it
> were, if the message is sent without confidentiality protection).
The "cat is out of the bag" reasoning would not really hold since, for
instance, me as a service developer I need to be sure that I only accept
messages that have been both integrity and confidentiality protected. In
order to do that I place "Signature Encryption" as an action and I presume
(foolishly in this case) that whatever messages are passed to my service
have been checked for those kinds of protection. The fact that the message
has not been protected for confidentiality and still I accept it as a valid
(for my criteria) message would diminish the security of the service I
provide. The fact that the message has been seen by whoever is listening to
the wire is exactly the reason I did not want to accept such messages in the
first place.
I am not an expert on Axis, but at a minimum the information about what
> occurred (the "results" from processSecurityHeaders) should be
> propagated up the stack through some sort of request context (good ol'
> Current). Perhaps that would mitigate your concerns?
True, I believe the developer can check the results of the security
processing and probably see that the message has not been confidentiality
protected. But then why not allow all messages to be received and leave the
choice to the higher layer (service)? To better explain: all messages would
pass the security handler(s), being processed if necessary and it would be
the responsibility of the developer to check the results of the security
processing. That way, the service would know if it has to deal with an
"insecure", "signed", encrypted", "signed and encrypted" message and would
take necessary action. The results of the security processing which now just
throw faults and reject a message (e.g. "message signed but certificate not
trusted") would be accessible to the developer.
If the philosophy behind WS-Security is an "access-control"-like philosophy
(i.e. "I only want to receive messages that fulfill certain criteria") then
the ramblings in my previous paragraph are not to be taken into account, but
then the original issue would be a "bug".
If the philosophy behind WS-Security would be a "protect messages"-like
philosophy (i.e. "I want to be able to protect messages that I send and
receive") then the original issue would not be a "bug" but then
transparently rejecting messages would not be right.
>
> > Although it might be nice as a feature (see my previous post), I am
> > afraid it is a bug and an exception should be thrown/fault should be
> > returned (something like WSDoAllReceiver: security processing failed
> > (actions mismatch)).
> >
> > What would the verdict be: bug or feature?
> I would hesitate to call this a bug, per se. It's a valid enhancement
> request, however.
I suppose I am just advocating for being consequent :-) Thanks for your
reply.
Cheers,
Robert.
Re: Bug or feature?
Posted by Fred Dushin <fd...@iona.com>.
Robert Maier wrote:
> Now, on to the issue: For the request flow, if the client handler
> specifies as action "Signature" and the service handler expects
> "Signature Encrypt", the client sends a signed message, the signature
> is verified at the server side and the message gets delivered to the
> service, although the message is not encrypted as expected. The same
> happens in the opposite direction as well.
Yes, I agree that this is an issue, though I would suspect that flipping
your scenario a bit is more troublesome. To wit, suppose a message
comes in encrypted but not signed, but the message consumer requires
integrity protection. You might want to reject the request (or
response, as the case may be) right there. (Requiring encryption is
certainly important and laudable, but the "cat is out of the bag", as it
were, if the message is sent without confidentiality protection).
I am not an expert on Axis, but at a minimum the information about what
occurred (the "results" from processSecurityHeaders) should be
propagated up the stack through some sort of request context (good ol'
Current). Perhaps that would mitigate your concerns?
>
> Although it might be nice as a feature (see my previous post), I am
> afraid it is a bug and an exception should be thrown/fault should be
> returned (something like WSDoAllReceiver: security processing failed
> (actions mismatch)).
>
> What would the verdict be: bug or feature?
I would hesitate to call this a bug, per se. It's a valid enhancement
request, however.
>
> Cheers,
> Robert.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Bug or feature?
Posted by Fred Dushin <fd...@iona.com>.
Robert Maier wrote:
> Now, on to the issue: For the request flow, if the client handler
> specifies as action "Signature" and the service handler expects
> "Signature Encrypt", the client sends a signed message, the signature
> is verified at the server side and the message gets delivered to the
> service, although the message is not encrypted as expected. The same
> happens in the opposite direction as well.
Yes, I agree that this is an issue, though I would suspect that flipping
your scenario a bit is more troublesome. To wit, suppose a message
comes in encrypted but not signed, but the message consumer requires
integrity protection. You might want to reject the request (or
response, as the case may be) right there. (Requiring encryption is
certainly important and laudable, but the "cat is out of the bag", as it
were, if the message is sent without confidentiality protection).
I am not an expert on Axis, but at a minimum the information about what
occurred (the "results" from processSecurityHeaders) should be
propagated up the stack through some sort of request context (good ol'
Current). Perhaps that would mitigate your concerns?
>
> Although it might be nice as a feature (see my previous post), I am
> afraid it is a bug and an exception should be thrown/fault should be
> returned (something like WSDoAllReceiver: security processing failed
> (actions mismatch)).
>
> What would the verdict be: bug or feature?
I would hesitate to call this a bug, per se. It's a valid enhancement
request, however.
>
> Cheers,
> Robert.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org