You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by "Van Tonder, Jaco" <Jv...@fnb.co.za> on 2012/05/31 17:02:49 UTC
WSS4J Timestamp validation for incoming messages confusion
Hello guys,
I am a bit confused about how Timestamp validation for incoming messages
work in WSS4J.
The current situation is that I have a CXF web service provider (WSS4J
1.6.3) validating a timestamp on an incoming message, but failing even
though the current date (on the server side) is right in the middle of
the <wsu:CreatedDate /> and <wsu:ExpiryDate/> elements specified by the
client. Here are the relevant parts from the logs (I added more debug
messages):
2012-05-31 15:59:40.798 DEBUG SignatureProcessor:325 - Verify XML Signature
2012-05-31 15:59:40.808 DEBUG TimestampProcessor:43 - Found Timestamp
list element
2012-05-31 15:59:40.808 DEBUG Timestamp:151 - Current time:
2012-05-31T13:59:40.808Z
2012-05-31 15:59:40.809 DEBUG Timestamp:156 - Timestamp created:
2012-05-31T13:53:26.226Z
2012-05-31 15:59:40.810 DEBUG Timestamp:162 - Timestamp expires:
2012-05-31T14:53:26.226Z
2012-05-31 15:59:40.811 DEBUG TimestampProcessor:53 - Timestamp ID =[TS-1]
2012-05-31 15:59:40.811 DEBUG TimestampValidator:62 - wssConfig element
exist, setting timestamp related values:
2012-05-31 15:59:40.812 DEBUG TimestampValidator:63 - timeStampStrict=[true]
2012-05-31 15:59:40.812 DEBUG TimestampValidator:65 - timeStampTTL=[300]
2012-05-31 15:59:40.813 DEBUG TimestampValidator:66 - futureTimeToLive=[60]
2012-05-31 15:59:40.813 DEBUG Timestamp:317 - verifyCreated() got
values: ttl=[300], future ttl=[60]
2012-05-31 15:59:40.814 DEBUG Timestamp:340 - Validation of Timestamp:
The message was created too long ago.
createdDate=[2012-05-31T13:53:26.226Z],
validCreation=[2012-05-31T13:54:40.808Z]
May 31, 2012 3:59:40 PM
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor handleMessage
WARNING:
org.apache.ws.security.WSSecurityException: The message has expired
(WSSecurityEngine: Invalid timestamp The security semantics of the
message have expired)
Looking at the code I can see that the default TTL (300) is being used
to calculate the valid time for creation even though both the created
and expiry times are set.
Is this behavior correct? Should the TTL not be ignored when validating
incoming messages? I fail to see how TTL should play a part when doing
this validation for the creation date of *incoming* messages.
Should the TTL play any part on the web service provider side (maybe to
enforce a specific timeframe)?
The code in question:
[1]
http://svn.apache.org/viewvc/webservices/wss4j/trunk/src/main/java/org/apache/ws/security/validate/TimestampValidator.java?revision=1130107&view=markup
(line 60-65)
[2]
http://svn.apache.org/viewvc/webservices/wss4j/trunk/src/main/java/org/apache/ws/security/message/token/Timestamp.java?view=markup
(line 304-345)
I will create a JIRA for this if someone could just verify that what I
am saying makes sense. :)
Thank you in advance.
---Jaco
--
Jaco van Tonder
Application Infrastructure: Analyst Programmer
First National Bank: Hogan Technology
3 First Place
Bank City
Corner Simmonds and Jeppe Streets
Johannesburg
Direct: +27 87 736 1790 :: Mobile: +27 83 417 5424
e-mail: jvantonder@fnb.co.za :: Web: http://www.fnb.co.za/
To read FirstRand Bank's Disclaimer for this email click on the following address or copy into your Internet browser:
https://www.fnb.co.za/disclaimer.html
If you are unable to access the Disclaimer, send a blank e-mail to
firstrandbankdisclaimer@fnb.co.za and we will send you a copy of the Disclaimer.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
Re: WSS4J Timestamp validation for incoming messages confusion
Posted by "Van Tonder, Jaco" <Jv...@fnb.co.za>.
Colm,
Thank you for the explanation. That clears up my confusion and it makes sense in the context of enforcing a limit at the server/recipient side. :)
Regards,
---Jaco
On 31/05/2012 17:23, Colm O hEigeartaigh wrote:
Hi Jaco,
> Looking at the code I can see that the default TTL (300) is being used
> to calculate the valid time for creation even though both the created
> and expiry times are set.
> Is this behavior correct? Should the TTL not be ignored when validating
> incoming messages? I fail to see how TTL should play a part when doing
> this validation for the creation date of *incoming* messages.
TTL is used on the incoming side to make sure that the message was not created "too long ago". The longer a message can be considered valid, the greater the range of time an adversary will have to create a message replay attack.
The client can use the Expiry time to enforce a restriction on the time validity of the message. TTL is a way for the message recipient to enforce its own restriction on the time validity of the message. In your example, the difference between Created and Expires is one hour, and so I suggest you adjust the TTL value on the recipient side accordingly if you want to accomodate this time difference.
Colm.
On Thu, May 31, 2012 at 4:02 PM, Van Tonder, Jaco <Jv...@fnb.co.za>> wrote:
Hello guys,
I am a bit confused about how Timestamp validation for incoming messages
work in WSS4J.
The current situation is that I have a CXF web service provider (WSS4J
1.6.3) validating a timestamp on an incoming message, but failing even
though the current date (on the server side) is right in the middle of
the <wsu:CreatedDate /> and <wsu:ExpiryDate/> elements specified by the
client. Here are the relevant parts from the logs (I added more debug
messages):
2012-05-31 15:59:40.798 DEBUG SignatureProcessor:325 - Verify XML Signature
2012-05-31 15:59:40.808 DEBUG TimestampProcessor:43 - Found Timestamp
list element
2012-05-31 15:59:40.808 DEBUG Timestamp:151 - Current time:
2012-05-31T13:59:40.808Z
2012-05-31 15:59:40.809 DEBUG Timestamp:156 - Timestamp created:
2012-05-31T13:53:26.226Z
2012-05-31 15:59:40.810 DEBUG Timestamp:162 - Timestamp expires:
2012-05-31T14:53:26.226Z
2012-05-31 15:59:40.811 DEBUG TimestampProcessor:53 - Timestamp ID =[TS-1]
2012-05-31 15:59:40.811 DEBUG TimestampValidator:62 - wssConfig element
exist, setting timestamp related values:
2012-05-31 15:59:40.812 DEBUG TimestampValidator:63 - timeStampStrict=[true]
2012-05-31 15:59:40.812 DEBUG TimestampValidator:65 - timeStampTTL=[300]
2012-05-31 15:59:40.813 DEBUG TimestampValidator:66 - futureTimeToLive=[60]
2012-05-31 15:59:40.813 DEBUG Timestamp:317 - verifyCreated() got
values: ttl=[300], future ttl=[60]
2012-05-31 15:59:40.814 DEBUG Timestamp:340 - Validation of Timestamp:
The message was created too long ago.
createdDate=[2012-05-31T13:53:26.226Z],
validCreation=[2012-05-31T13:54:40.808Z]
May 31, 2012 3:59:40 PM
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor handleMessage
WARNING:
org.apache.ws.security.WSSecurityException: The message has expired
(WSSecurityEngine: Invalid timestamp The security semantics of the
message have expired)
Looking at the code I can see that the default TTL (300) is being used
to calculate the valid time for creation even though both the created
and expiry times are set.
Is this behavior correct? Should the TTL not be ignored when validating
incoming messages? I fail to see how TTL should play a part when doing
this validation for the creation date of *incoming* messages.
Should the TTL play any part on the web service provider side (maybe to
enforce a specific timeframe)?
The code in question:
[1]
http://svn.apache.org/viewvc/webservices/wss4j/trunk/src/main/java/org/apache/ws/security/validate/TimestampValidator.java?revision=1130107&view=markup
(line 60-65)
[2]
http://svn.apache.org/viewvc/webservices/wss4j/trunk/src/main/java/org/apache/ws/security/message/token/Timestamp.java?view=markup
(line 304-345)
I will create a JIRA for this if someone could just verify that what I
am saying makes sense. :)
Thank you in advance.
---Jaco
--
Jaco van Tonder
Application Infrastructure: Analyst Programmer
First National Bank: Hogan Technology
3 First Place
Bank City
Corner Simmonds and Jeppe Streets
Johannesburg
Direct: +27 87 736 1790<tel:%2B27%2087%20736%201790> :: Mobile: +27 83 417 5424<tel:%2B27%2083%20417%205424>
e-mail: jvantonder@fnb.co.za<ma...@fnb.co.za> :: Web: http://www.fnb.co.za/
To read FirstRand Bank's Disclaimer for this email click on the following address or copy into your Internet browser:
https://www.fnb.co.za/disclaimer.html
If you are unable to access the Disclaimer, send a blank e-mail to
firstrandbankdisclaimer@fnb.co.za<ma...@fnb.co.za> and we will send you a copy of the Disclaimer.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org<ma...@ws.apache.org>
For additional commands, e-mail: dev-help@ws.apache.org<ma...@ws.apache.org>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Jaco van Tonder
Application Infrastructure: Analyst Programmer
First National Bank: Hogan Technology
3 First Place
Bank City
Corner Simmonds and Jeppe Streets
Johannesburg
Direct: +27 87 736 1790 :: Mobile: +27 83 417 5424
e-mail: jvantonder@fnb.co.za<ma...@fnb.co.za> :: Web: http://www.fnb.co.za/
To read FirstRand Bank's Disclaimer for this email click on the following address or copy into your Internet browser:
https://www.fnb.co.za/disclaimer.html
If you are unable to access the Disclaimer, send a blank e-mail to
firstrandbankdisclaimer@fnb.co.za and we will send you a copy of the Disclaimer.
Re: WSS4J Timestamp validation for incoming messages confusion
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Jaco,
> Looking at the code I can see that the default TTL (300) is being used
> to calculate the valid time for creation even though both the created
> and expiry times are set.
> Is this behavior correct? Should the TTL not be ignored when validating
> incoming messages? I fail to see how TTL should play a part when doing
> this validation for the creation date of *incoming* messages.
TTL is used on the incoming side to make sure that the message was not
created "too long ago". The longer a message can be considered valid, the
greater the range of time an adversary will have to create a message replay
attack.
The client can use the Expiry time to enforce a restriction on the time
validity of the message. TTL is a way for the message recipient to enforce
its own restriction on the time validity of the message. In your example,
the difference between Created and Expires is one hour, and so I suggest
you adjust the TTL value on the recipient side accordingly if you want to
accomodate this time difference.
Colm.
On Thu, May 31, 2012 at 4:02 PM, Van Tonder, Jaco <Jv...@fnb.co.za>wrote:
> Hello guys,
>
> I am a bit confused about how Timestamp validation for incoming messages
> work in WSS4J.
>
> The current situation is that I have a CXF web service provider (WSS4J
> 1.6.3) validating a timestamp on an incoming message, but failing even
> though the current date (on the server side) is right in the middle of
> the <wsu:CreatedDate /> and <wsu:ExpiryDate/> elements specified by the
> client. Here are the relevant parts from the logs (I added more debug
> messages):
>
> 2012-05-31 15:59:40.798 DEBUG SignatureProcessor:325 - Verify XML Signature
> 2012-05-31 15:59:40.808 DEBUG TimestampProcessor:43 - Found Timestamp
> list element
> 2012-05-31 15:59:40.808 DEBUG Timestamp:151 - Current time:
> 2012-05-31T13:59:40.808Z
> 2012-05-31 15:59:40.809 DEBUG Timestamp:156 - Timestamp created:
> 2012-05-31T13:53:26.226Z
> 2012-05-31 15:59:40.810 DEBUG Timestamp:162 - Timestamp expires:
> 2012-05-31T14:53:26.226Z
> 2012-05-31 15:59:40.811 DEBUG TimestampProcessor:53 - Timestamp ID =[TS-1]
> 2012-05-31 15:59:40.811 DEBUG TimestampValidator:62 - wssConfig element
> exist, setting timestamp related values:
> 2012-05-31 15:59:40.812 DEBUG TimestampValidator:63 -
> timeStampStrict=[true]
> 2012-05-31 15:59:40.812 DEBUG TimestampValidator:65 - timeStampTTL=[300]
> 2012-05-31 15:59:40.813 DEBUG TimestampValidator:66 - futureTimeToLive=[60]
> 2012-05-31 15:59:40.813 DEBUG Timestamp:317 - verifyCreated() got
> values: ttl=[300], future ttl=[60]
> 2012-05-31 15:59:40.814 DEBUG Timestamp:340 - Validation of Timestamp:
> The message was created too long ago.
> createdDate=[2012-05-31T13:53:26.226Z],
> validCreation=[2012-05-31T13:54:40.808Z]
> May 31, 2012 3:59:40 PM
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor handleMessage
> WARNING:
> org.apache.ws.security.WSSecurityException: The message has expired
> (WSSecurityEngine: Invalid timestamp The security semantics of the
> message have expired)
>
> Looking at the code I can see that the default TTL (300) is being used
> to calculate the valid time for creation even though both the created
> and expiry times are set.
> Is this behavior correct? Should the TTL not be ignored when validating
> incoming messages? I fail to see how TTL should play a part when doing
> this validation for the creation date of *incoming* messages.
>
> Should the TTL play any part on the web service provider side (maybe to
> enforce a specific timeframe)?
>
> The code in question:
> [1]
>
> http://svn.apache.org/viewvc/webservices/wss4j/trunk/src/main/java/org/apache/ws/security/validate/TimestampValidator.java?revision=1130107&view=markup
> (line 60-65)
> [2]
>
> http://svn.apache.org/viewvc/webservices/wss4j/trunk/src/main/java/org/apache/ws/security/message/token/Timestamp.java?view=markup
> (line 304-345)
>
> I will create a JIRA for this if someone could just verify that what I
> am saying makes sense. :)
>
> Thank you in advance.
> ---Jaco
>
> --
> Jaco van Tonder
> Application Infrastructure: Analyst Programmer
> First National Bank: Hogan Technology
> 3 First Place
> Bank City
> Corner Simmonds and Jeppe Streets
> Johannesburg
>
> Direct: +27 87 736 1790 :: Mobile: +27 83 417 5424
> e-mail: jvantonder@fnb.co.za :: Web: http://www.fnb.co.za/
> To read FirstRand Bank's Disclaimer for this email click on the following
> address or copy into your Internet browser:
> https://www.fnb.co.za/disclaimer.html
>
> If you are unable to access the Disclaimer, send a blank e-mail to
> firstrandbankdisclaimer@fnb.co.za and we will send you a copy of the
> Disclaimer.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: dev-help@ws.apache.org
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com