我想了解的时间戳的请求头中的Web服务的概念,但不知何故仍然无法理解它完全是如何工作的。
我将不胜感激,如果有人可以解释请求的Web服务响应终端到终端的使用时间戳。
难道真的防止重放攻击的一个简单的方法?
我想了解的时间戳的请求头中的Web服务的概念,但不知何故仍然无法理解它完全是如何工作的。
我将不胜感激,如果有人可以解释请求的Web服务响应终端到终端的使用时间戳。
难道真的防止重放攻击的一个简单的方法?
本身时间戳是不够的,但通常它与散列机制相结合,保证值没有被篡改。
这个想法是,客户端生成的参数,并使用自己的私钥对散列参数。 的[散列+原始值+公钥]然后与请求一起发送。 该服务器可以使用公共密钥来查找私钥,并确保参数是否正确。
时间戳被使用,与一些阈值一起,以确保特定的请求不能被使用一次以上。 如果阈值小(几百毫秒),然后重放攻击几乎是不可能的。
时间戳是不加密的,它应该是在肥皂头。
<wsu:Timestamp wsu:Id="timestamp">
<wsu:Created>2014-07-01T11:30:28.123+05:30</wsu:Created>
<wsu:Expires>2014-07-01T11:35:28.123+05:30</wsu:Expires>
</wsu:Timestamp>
如果过期时间很少创建时间后,就可以最大限度地减少重放攻击。 其实这不只是时间戳。 你应该时间戳添加到消化的SignedInfo部分。
<ds:Reference URI="#timestamp">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces PrefixList="wsse soap" xmlns="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>TGgFBvglhb+jZCvjV0+oVnNaivpVBp5iVbJEqkTfaCU=</ds:DigestValue>
</ds:Reference>
因此,在服务器端这些摘要必须匹配。 即使不是全部,那么您就与私钥整体的SignedInfo和签名值Signature元素添加如下。
<ds:SignatureValue>jdO5GIZ9v1VTngFZcMpz5hz62RwToq2W24A9KhJ5JNySZW1AHhd3s+eTduZZPD0Ok6Wtgzu5kquK
IinPdi5IbGjlg6mXGDbVkLd79RBdnbzFxsJFBtRr9r3mQZp9xfU7zSJW3kbizz6Jjk3h+S2nNbUu
f7rFrNN53ciRtj9RlKzQzmW7BDaFuq18DUfcr70muSkmd4DIqxYDGScjEjgIqLE2pYwIdDDRUGPD
MuwuIN3DgB051QwcE75SVrKBKsTHmFADmN3nKzmQ/JUQuLot0vW6WUFRMLVlAcl5C09SGPOcpow2
kjbuWx/bI7Aj4nAaAnmAYsWKIA3xVao+nPBOWmM0Lg7kpC4Dr5DwahmjH0/78aVUU23DEiMc0kR0
YDg5CxD8MUuj24w8tAjuzoHrvcsIYw+vWCTKvucnXwTlZ+K3QFB6gkct2zVOyQeYaPpkAnmPYS3W
DDpNmsx3lDcNr+5QWTsUbSQaFDddjHT/zoOJ8+iZKY/RujOI5vfXVwgN</ds:SignatureValue>
现在,我们可以确保重放攻击是不可能的。 因为任何人都不能有相同的私钥,所以没有办法改变的时间戳,仍然有一个有效的签名。