You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello
Please also see #692 on UA .Net standard for the question on the specified behaviour.
The CreateHttpsServiceHost method of StandardServer.cs always opens a channel with SecurityMode "None". This disable client authentication totally, because clients can choose to connect on the "None" channel. Therefore, any client can connect to the OPC UA Server without any application authentication mechanisms.
This is conformant with Part2 §4.10, with indicates that is such a case User authentication should be used.
The problem is there are indeed people willing to use Application Authentication to authenticate OPC UA Clients applications, and the specified behaviour is indeed a security vulnerability.
By the way this was fixed in UA .NET standard by removing the automatic "None" channel (without security announcement, and without updating the specifications).
Another option would have been to check client certificate at the transport level in the WebHttpBinding underlying object. Be carefull that there are interoperability problems to take into account.
I therefore suggests:
enable client certificate verification at the transport level on WebHttpBinding object via property binding.Security.Transport.ClientCredentialType;
optionnaly, with spec update:
let the host application choose which binding expose;
always take the lowest security level.
The text was updated successfully, but these errors were encountered:
The Server library from this repository exposes indeed the HTTPS endpoints with security None.
In case the application authentication is required in a specific implementation, the option is to implement an override for StandardServer.CreateSesion() and validate the "clientCertificate" parameter of the method.
And this is possible without changes in the library.
For the client side the ApplicationInstance.SetUaValidationForHttps() call can be used in order to validate the server certificates with the same validator (trust list) of the application.
I will check also the related entries reported for the .NET Standard repository.
Please note that this repository is not further updated by OPC Foundation and the official OPC UA .NET Stack provided and maintained by OPC Foundation is UA-.NET Standard
First, as the whole discussion is about https client authentication which is also addressed in reports in UA .Net Standard, I propose to discuss more thoroughly this subject in .Net standard environment then see if something should be done in .Net Legacy.
I'm agree development is now focussed on .NET Standard, ** but** security updates are done in .NET Legacy, and this is really a security issue.
Overriding CreateSession is not an option, since with binding None the client has the option to not even send any certificate. Moreover, its not realistic to tell every user to modify its application in order to not fix a security flaw in this implementation of the stack.
The norm says Sign should be exposed unless security level 0 is selected, in which case None can be used. The behaviour therefore depends on the bindings proposed by the application. The strongest securitymode should be used (till Sign since Encrypt is transfered to the TLS layer).
Hello
Please also see #692 on UA .Net standard for the question on the specified behaviour.
The CreateHttpsServiceHost method of StandardServer.cs always opens a channel with SecurityMode "None". This disable client authentication totally, because clients can choose to connect on the "None" channel. Therefore, any client can connect to the OPC UA Server without any application authentication mechanisms.
This is conformant with Part2 §4.10, with indicates that is such a case User authentication should be used.
The problem is there are indeed people willing to use Application Authentication to authenticate OPC UA Clients applications, and the specified behaviour is indeed a security vulnerability.
By the way this was fixed in UA .NET standard by removing the automatic "None" channel (without security announcement, and without updating the specifications).
Another option would have been to check client certificate at the transport level in the WebHttpBinding underlying object. Be carefull that there are interoperability problems to take into account.
I therefore suggests:
The text was updated successfully, but these errors were encountered: