View Issue Details

IDProjectCategoryView StatusLast Update
0003256UAImplementation Bugpublic2016-05-04 07:16
ReporterBernd Edlinger Assigned Touser319 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Summary0003256: SequenceNumbers not checked by the Stack
Description

We have an issue with the SequenceNumbers in the AnsiC stack (and in the .NET stack too).

We fail to check them since ever. There is a check on the Request Ids of multiple chunk messages, but that is not enough, to avoid man-in-the-middle from replaying, re-ordering or dropping any message they want.

The current status is, the AnsiC stack starts sequence numbers at 51, counts till UInt32.MaxValue, rolls over to 0, and counts on.
The .NET stack starts at 1, and counts on, have not tested how they actually roll over. Both stacks obviosly do not check the received sequence numbers at all. If the connection is signed&encrypted, the sequence numbers are encrypted too, if the connection is signed, the sequence numbers are signed too.
So it is impossible for man-in-the middle to alter the sequence numbers.
But he could drop anything that he dont like to reach the server, and neither the server nor the client will know what is going on. The correct behavior would be to reset the connection if there is a gap in the sequence numbers.

Well, initially I thought a SequnenceNumber of 0 is somehow forbidden, but I do not find any place in the part 6, that says that. Nor do I find any information what to expect, how the sequence numbers start.

There is however the following sentence in part 6:

The SequenceNumber shall also monotonically increase for all Messages and shall not wrap around until it is greater than 4 294 966 271 (UInt32.MaxValue – 1 024). The first number after the wrap around shall be less than 1 024.

Well, I dont like this at all. It allows too many choice, and it is way too complicated. I do not like to implement the wrap over in the sending side in this way.

And this allows Mr. man-in-the-middle to drop up to 1024 messages before and 1024 messages after the wrap over, which is bad.

I will implement the checking to allow a jump in the sequence numbers anywhere from 4294966272..4294967295 => 0..1023. At all other times, the sequence numbers may not jump, or the connection gets closed.

Currently, I want to check that the first sequence number is 0..1023 too. But that is actually not explicitly specified.

But I want to change this in the future, to be more restrictive.

I think at some time in the future, the wrap around should only be accepted from 4294967295 => 0, everything else is due to Mr. man-in-the-middle.
And the initial SequenceNumber of a new connection must be 1, and nothing else.

(If secure-channel reconnection is ever implemented, then the sequence number must start at LastSequenceNumber+1..LastSequenceNumber+1023
Currently I do not see that ever happening.)

My suggestion would be that we recommend now to start the sent SequenceNumbers from 1 on connection, and roll over from 4294967295 => 0, which should be compatible with the current spec, and allow the initial received SequenceNumber between 0..1023 and allow for the roll over to happen as currently specified in part 6, for backward compatibility.

But be prepared, that this can become more restrictive in the next version of the spec.

TagsNo tags attached.
Fix Due Date

Activities

Bernd Edlinger

2015-12-21 11:39

reporter   ~0006474

to reproduce you can change
OpcUa_TcpSecureChannel_GetSequenceNumber to use -- instead of ++:
result:
AnsiC stack still able to connect, because it has no checks at all.
.NET stack does not connect.

but but if we skip sequence numbers, i.e. perform ++ twice:
.NET stack is able to connect.
Thus .NET implemented some checks but not correctly.

user319

2016-05-04 07:16

  ~0006858

fixed in 1.03.340.
Sequence numbers are now checked.

Issue History

Date Modified Username Field Change
2015-12-18 13:25 Bernd Edlinger New Issue
2015-12-21 11:39 Bernd Edlinger Note Added: 0006474
2016-05-04 07:15 user319 Assigned To => user319
2016-05-04 07:15 user319 Status new => acknowledged
2016-05-04 07:16 user319 Note Added: 0006858
2016-05-04 07:16 user319 Status acknowledged => resolved
2016-05-04 07:16 user319 Resolution open => fixed