Rationale for server authenticating client certificates|OPC UA Implementation: Stacks, Tools, and Samples|Forum|OPC Foundation

Avatar
Search
Forum Scope


Match



Forum Options



Minimum search word length is 3 characters - maximum search word length is 84 characters
Lost password?
sp_Feed sp_PrintTopic sp_TopicIcon
Rationale for server authenticating client certificates
Avatar
EG
Member
Members
Forum Posts: 35
Member Since:
12/06/2021
sp_UserOfflineSmall Offline
1
12/14/2021 - 01:00
sp_Permalink sp_Print

I am developing an OPC UA server that will use anonymous and username/password authentication. I was surprised that when I made a connection to the server, I had to manually move the clients certificate into the ‘trusted’ folder before it could connect. I have discovered the AutoAcceptUntrustedCertificates feature which seems to solve my problem, but I am trying to understand the rationale behind this comment in the sample server:

———————————

<!– WARNING: The following setting (to automatically accept untrusted certificates) should
be used for easy debugging purposes ONLY and turned off for production deployments! –>
<AutoAcceptUntrustedCertificates>false</AutoAcceptUntrustedCertificates>

———————————

If a client is connecting to my server, why is it important for the server to also validate their certificate? To me this seems analogous to a HTTPS server. It is not necessary for every web browser to have a certificate in order to establish trust, the onus is on the user to verify the servers certificate. It would be extremely inconvenient if every time you communicated with a new HTTPS website, the website owner had to add your browser certificate to their ‘trusted’ folder.

I am concerned by disabling AutoAcceptUntrustedCertificates, the workflow for a client connecting to my server is going to be needlessly complicated. But equally I don’t want to enable this feature if there are genuine security problems introduced by it.

Thanks

Avatar
Randy Armstrong
Admin
Forum Posts: 1580
Member Since:
05/30/2017
sp_UserOfflineSmall Offline
2
12/14/2021 - 09:17
sp_Permalink sp_Print

In industrial automation the systems are tested and locked down. i.e. you can have a cell with a few PLCs and an HMI panel and only the HMI panel is allowed to talk to the PLCs. Specially, you do not want an operator to download a UA app on their phone or laptop and connecting directly to the PLCs and using the legitimate user credentials they have. Client certificate authentication is the feature that makes those types of restrictions possible.

That said, there are applications that legitimately need to allow any client to connect and can choose to accept all certificates, however, these applications may grant more restricted permissions to clients that are not trusted. IOW, the server is still aware of the untrusted state and uses that information to decide what the client can do.

For any large UA system you will need a GDS/CertificateManager that centrally manages TrustLists and Certificates because manually configuring every node is not practical.

Avatar
EG
Member
Members
Forum Posts: 35
Member Since:
12/06/2021
sp_UserOfflineSmall Offline
3
12/16/2021 - 03:16
sp_Permalink sp_Print

OK I think I can see your point. If somebody wanted to perform malicious actions, they could do this stood at the HMI, but they risk being seen. Whereas if they could perform those malicious actions remotely from an unauthorized client, they might be able to get away with it.

Avatar
Randy Armstrong
Admin
Forum Posts: 1580
Member Since:
05/30/2017
sp_UserOfflineSmall Offline
4
12/16/2021 - 21:32
sp_Permalink sp_Print

OK I think I can see your point. If somebody wanted to perform malicious actions, they could do this stood at the HMI, but they risk being seen. Whereas if they could perform those malicious actions remotely from an unauthorized client, they might be able to get away with it

It is more than that. The HMI software could limit the actions that are available but a generic test client downloaded from the internet could allow many more things to be done. It also does not have to be malicious – employees trying to do their jobs by working around s/w limitations can cause a lot of damage.

Avatar
Zbynek Zahradnik
Member
Members
Forum Posts: 62
Member Since:
02/24/2014
sp_UserOfflineSmall Offline
5
12/17/2021 - 00:16
sp_Permalink sp_Print

There are also capacity concerns. Many OPC servers are in embedded devices withy limited resources. They will only support certain number of sessions etc. And you really want these sessions be used by client devices that the system was designed to have, and not by additional “random” devices, because that would prevent the right ones from connecting, and disrupt the operation of the system. 

User authentication is orthogonal to this, because for such concerns, it is irrelevant who is the user of the device.

Avatar
EG
Member
Members
Forum Posts: 35
Member Since:
12/06/2021
sp_UserOfflineSmall Offline
6
12/17/2021 - 00:57
sp_Permalink sp_Print

Randy Armstrong said

OK I think I can see your point. If somebody wanted to perform malicious actions, they could do this stood at the HMI, but they risk being seen. Whereas if they could perform those malicious actions remotely from an unauthorized client, they might be able to get away with it

It is more than that. The HMI software could limit the actions that are available but a generic test client downloaded from the internet could allow many more things to be done. It also does not have to be malicious – employees trying to do their jobs by working around s/w limitations can cause a lot of damage.

  

My plan was to very carefully design the node space and permissions/roles so that they have no more rights over OPC UA than they would have through the HMI. It would also be a hard requirement that no more damage can be done than they could also do through the HMI. The administrator of the device would also be able to select on a per-user basis which users have permission to connect over OPC UA – and by default probably none of them would have this right. So with these things in mind and circling back to the original question, do you still see authentication of client certificates valuable in this scenario?

Avatar
Randy Armstrong
Admin
Forum Posts: 1580
Member Since:
05/30/2017
sp_UserOfflineSmall Offline
7
12/17/2021 - 06:41
sp_Permalink sp_Print

do you still see authentication of client certificates valuable in this scenario?

Implementing client authentication is mandatory if you want to be compliant with UA. It is possible that your use case could justify turning it off in some cases but the capability still needs to be there.

Your concerns about managing the trust list on the server can be addressed by implementing the Part 12 push interface:

https://reference.opcfoundatio…../docs/7.3/

This is technically optional, however, a device that does not support it will be very hard to use.

Avatar
Randy Armstrong
Admin
Forum Posts: 1580
Member Since:
05/30/2017
sp_UserOfflineSmall Offline
8
12/17/2021 - 12:44
sp_Permalink sp_Print

I also think a user based system is a nightmare to to configure unless you have a shared identity provider. How would people maintain this user database if there were 10 of your devices at a single site?

Avatar
EG
Member
Members
Forum Posts: 35
Member Since:
12/06/2021
sp_UserOfflineSmall Offline
9
08/04/2022 - 02:36
sp_Permalink sp_Print

Hi Randy

Please could you clarify whether the two-way application certificate authentication should also be performed when using SecurityPolicy=None?

Should the server authenticate the clients application certificate?

Should the client authenticate the servers application certificate?

Thanks

Avatar
Randy Armstrong
Admin
Forum Posts: 1580
Member Since:
05/30/2017
sp_UserOfflineSmall Offline
10
08/04/2022 - 05:51
sp_Permalink sp_Print

SecurityPolicy=None means no authentication handshake. Certificates are only used for UserIdentityToken encryption.

Forum Timezone: America/Phoenix
Most Users Ever Online: 510
Currently Online:
Guest(s) 34
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Forum Stats:
Groups: 2
Forums: 10
Topics: 1446
Posts: 4891