View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
000184410000-006: Mappingspublic2012-01-13 08:232012-02-09 23:07
ReporterUstinov Vetcheslav Assigned ToRandy Armstrong  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Fixed in Version1.02 
Summary0001844: Potential problem with reconnecting channels when using OPC UA TCP and SecurityPolicy "None"
Description

Scenario:

  1. Client 1 connects to some server and that server assigns SecureChannelId 1.
  2. Client 2 connects to the same server and that server assigns SecureChannelId 2.
  3. Server restarted.
  4. Client 2 attempts to reconnect, get an error and create new secure channel. Server assigns SecureChannelId 1.
  5. Client 1 attempts to reconnect and this reconnect succeeded because server already has SecureChannelId 1 and it can't distinguish between Client 1 and Client 2 (checks for sequence numbers and something else may be successful accidentally). So Client 1 begins to use the channel for Client 2.

The same issue may occurs with other security policies. For example, some user may launch different instances of the same application on the same computer. Because they use the same certificate the server may not distinguish different instances.

TagsNo tags attached.
Commit Version
Fix Due Date

Activities

Randy Armstrong

2012-01-24 15:07

administrator   ~0003226

Added this text to Table 29:

When a Server starts the first SecureChannelId used shall be a random or pseudo-random value. The bottom 4 bytes of the system time one possible source of pseudo-randomness. This requirement ensures that a Server restart does not allow previously connected Clients to accidently ‘reuse’ SecureChannels that did not belong to them.

Jim Luth

2012-01-27 15:23

administrator   ~0003235

Relaxed the requirement to a "should" and edited the text in the final version.

Issue History

Date Modified Username Field Change
2012-01-13 08:23 Ustinov Vetcheslav New Issue
2012-01-13 17:38 Karl Deiretsbacher Status new => assigned
2012-01-13 17:38 Karl Deiretsbacher Assigned To => Randy Armstrong
2012-01-24 15:07 Randy Armstrong Status assigned => resolved
2012-01-24 15:07 Randy Armstrong Resolution open => fixed
2012-01-24 15:07 Randy Armstrong Note Added: 0003226
2012-01-27 15:23 Jim Luth Status resolved => closed
2012-01-27 15:23 Jim Luth Note Added: 0003235
2012-02-09 23:07 Jim Luth Fixed in Version => 1.02