FreeOpcUa / python-opcua

LGPL Pure Python OPC-UA Client and Server
http://freeopcua.github.io/
GNU Lesser General Public License v3.0
1.36k stars 658 forks source link

Client doesn't handle existing SecurityToken after renewal #910

Open jonasgreen88 opened 4 years ago

jonasgreen88 commented 4 years ago

Hi,

I have encountered a problem that happens when the client of this stack renews the secure channel. The server I am using is the open62541 and it works fine with other clients such as UaExpert and dataFEED OPC UA Client.

What I could find was that the client changes its symmetric keys (both the sign and the verify key) once the OpenSecureChannel renew response has been received. https://github.com/FreeOpcUa/python-opcua/blob/b2dd6f3948396cdd2386f653dc2d02733aed637a/opcua/client/client.py#L296 This behavior is OK if you read the Part 6 (1.04), chapter 6.7.4 Establishing a SecureChannel:

The RevisedLifetime tells the Client when it shall renew the SecurityToken by sending another OpenSecureChannel request. The Client shall continue to accept the old SecurityToken until it receives the OpenSecureChannel response. The Server has to accept requests secured with the old SecurityToken until that SecurityToken expires or until it receives a Message from the Client secured with the new SecurityToken.

But in Part 4 (1.04), chapter 5.5.2 OpenSecureChannel, it says:

b) Servers shall use the existing SecurityToken to secure outgoing Messages until the SecurityToken expires or the Server receives a Message secured with a new SecurityToken. This should ensure that Clients do not reject Messages secured with the new SecurityToken that arrive before the Client receives the new SecurityToken.

The open62541 stack does what Part 4 says. It changes the signature key for outgoing messages once it receives a message from the client that is secured with the new SecurityToken.

As the client of this stack changes the verifier key immediately, it will not be able to validate the signature of received messages from the server that are signed with the old SecurityToken.

oroulet commented 4 years ago

That make sense. PR welcome, it should not be hard

jonasgreen88 commented 4 years ago

That make sense. PR welcome, it should not be hard

I guess not if you know the stack design. But I have no time to do that right now. We put it in our team backlog for the future and solves it if no one else fix before :)