Log In
Register
Forum
Topic RSS
12:48, EET
October 16, 2014
Offline
Hi,
I have an installation of the Prosys OPC UA Simulation Server (v4.0.0) for testing our client. On the network hosting our server, the Prosys Server reports the EndpointURL using an unreachable hostname: the network is configured to resolve the IP to “.dhcp.company.net” but the connection-specific dns suffix is “company.net”. I suspect that the Prosys Server sets the endpointurl as “.”.
Is there an option in the settings file to manually set the hostname to use in the endpoint url? This would, for instance, allow a machine with multiple hostnames to present the appropriate one to clients.
16:16, EET
August 6, 2019
Offline
Hi,
Unfortunately it is currently not possible to set the hostname manually. However, we might consider this feature in future releases. Do note that you can replace the hostname in the connection address with the IP address when connecting to the server. The bound IP addresses can be configured in the Endoints view of Simulation Server in the Bind Addresses section.
12:46, EET
October 16, 2014
Offline
Thanks Markus. When connecting using an IP address though, the same problem arises: The EndpointDescriptions returned have the (inaccessible) host name in the endpointUrl field. In fact, this is a problem I see in many server implementations, where the endpoints returned by the server don’t take into account the Endpoint URL passed by the client in the getEndpoints request.
The UA Specifications, Part 4, section 5.4.3. includes this statement: “A Server may have multiple HostNames. For this reason, the Client shall pass the URL it used to connect to the Endpoint to this Service. The implementation of this Service shall use this information to return responses that are accessible to the Client via the provided URL.”
My interpretation of this is that if I pass an IP address as the URL, I should get IP addresses back in the endpointUrl fields of the returned EndpointDescriptions. However, almost all servers I have tested (not an exhaustive set, but enough) seem to return a predefined hostname as the endpoint URL. Clients must then recreate the endpoint URL to get access to the server in the case I have described.
Is my reading of the specification wrong, and should my client go through all the text processing required to replace the hostname?
12:28, EET
April 3, 2012
Offline
Hi,
“Both”, i.e. your reading is sort of right and we should improve our implementation, but additionally clients need to replace (or in practice partially sort of ignore) EndpointUrls as well.
1.04 Part 12 Annex A Deployment and Configuration section A.1 Firewalls and Discovery bottom half of page 66:
“
Note that Servers may not be aware of all HostNames which can be used to access the
Server (i.e. a NAT firewall) so Clients need to handle the case where the URL used to access
the Server is differen t from the HostNames in the Certificate. This is discussed in more detail
in Part 4.
“
i.e. clients in practice need to treat the original connection uri (e.g. a user-provider value) as the one to use and not treat EndpointUrl as a “connection url”, unless they have nothing else (e.g. via Discovery). The EndpointUrl is still passed to the Hello opc.tcp Message (once the socket connection is made with the “original connection uri”), and must be one of the “original” EndpointUrls returned by the server. Thus the communication layer must have a separate entry for the Socket address and the one that is sent in the Hello Message (but in a normal LAN environment they are usually the same). This is because behind a single port there could be many servers differentiated by the EndpointUrl.
Our implementation could use some improvements in this area. However in practice this has not been a problem and thus has been on a lower priority than lets say e.g. making PubSub support (still work in progress..).
It should be noted that it is not enough to just make the endpointUrl field of the EndpointDescriptions to have the different hostname or IP address. The Application Instance Certificate that is returned in the serverCertificate field must also contain that hostname/IP as part of it’s hostnames field (i.e. any changes -> new cert).
In Part 4 section 5.4.1
“
A Client shall verify the HostName specified in the Server Certificate is the same as the HostName
contained in the endpointUrl provided in the EndpointDescription returned by CreateSession. If
there is a difference then the Client shall report the difference and may close the SecureChannel.
Servers shall add all possible HostNames like MyHost and MyHost.local into the Server
Certificate. This includes IP addresses of the host or the HostName exposed by a NAT router used
to connect to the Server.
“
While that is specified like that, it is not a realistic option in all cases to know them all. However the client checking that the hostname is in the cert is needed, so server can only return values that it knows and that are inside the cert or the connection would probably fail. Additionally that would mean either one cert per name or recreating the cert each time e.g. a NAT configuration changes, which doesn’t make that much sense in my opinion.
Once we are in a world where all certificate management is done by GDS instances (Global Discovery Server) and cert handing is not done for each application it might be more feasible, but typically nowadays still it is common to have one cert that is made for the primary hostname/computername of the machine.
I hope that was enough of an explanation for now, but eventually we should make it better of course 🙂
13:02, EET
October 16, 2014
Offline
Thanks for the detailed reply. I think it’s exactly the fact that we should “sort of” ignore the EndpointUrl (for the connection) but use it elsewhere (for the validation) that has resulted in a few cases of connection errors I have been seeing. It also seems to me to open up the possibility of a different security compromise vector in the OPC UA standard (or the implementation) that warrants some thought on the part of Client and Server developers about whether to in fact ignore the information returned or not.
Your explanation seems to say that the certificate returned by the server must simply be consistent with the other information provided (EndpointUrl) but cannot be relied upon to make the actual connection to the server. I would argue that this breaks the security of the server in that case, because you don’t know whether the server is providing consistent but spoofed information. The Spec does say that the client “may” close the SecureChannel, so I guess it is up to the client to decide what to do.
With my paranoid security hat on (what other kind of security hat works, right?) I would also argue that if the NAT configuration changes sufficiently that the original certificate can no longer be associated with a published endpoint, then the Cert must also change, otherwise it makes the certificate compromisable in the way I have described.
I’m satisfied now that I have enough information to decide what to do in our case. Thanks to all the posters for the input.
Most Users Ever Online: 1919
Currently Online:
8 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Heikki Tahvanainen: 402
hbrackel: 144
rocket science: 88
pramanj: 86
Francesco Zambon: 83
Ibrahim: 78
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
Member Stats:
Guest Posters: 0
Members: 726
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1529
Posts: 6471
Newest Members:
gabriellabachus, Deakin, KTP25Zof, Wojciech Kubala, efrennowell431, wilfredostuart, caitlynfajardo, jeromechubb7, franciscagrimwad, adult_galleryModerators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1032, Jimmy Ni: 26, Matti Siponen: 349, Lusetti: 0
Administrators: admin: 1
