Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security: https channel always create endpoint with Non securityMode #182

Open
ccasteyde opened this issue Apr 3, 2019 · 2 comments
Open

Comments

@ccasteyde
Copy link

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.
@AlinMoldovean
Copy link
Contributor

Hi @ccasteyde ,

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.

e.g.

   ApplicationInstance.SetUaValidationForHttps(application.ApplicationConfiguration.CertificateValidator);

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

@ccasteyde
Copy link
Author

Hello

  1. 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.
  2. 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.
  3. 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.
  4. 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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants