TLS security - examples of communication

The next part shows what cases of secure connections can occur, what variants they have and what needs to be set for each communication participant.The next part shows what cases of secure connections can occur, what variants they have and what needs to be set for each communication participant.

Typical cases of communication scenarios are the following:

The client (IDE, Visual, SCADA,...) connects via secure SSCP to the PLC.
The web browser connects via https:// to the PLC.
The PLC connects to the database (DB), wants to save data.
PLC connects to kmail server via SMTPS, wants to send mail.
The PLC connects to the Merbon Proxy server.
A PLC connects as a client using SSCP to another PLC.
In the following diagrams, the red arrow represents the direction of establishing a TLS connection, i.e. from the client towards the server.

The client (IDE, SCADA, ...) connects using SSCP to the PLC

The PLC is in the role of the server. Several variants are possible.
No Security - Normal configuration, SSCP connection to destination port 12346. Enable SSL is not selected in IDE in Connection Parameters, SSL server may not be enabled in PLC configuration.
Secure TLS connection without authentication - Enable SSL is selected in the IDE in the Connection Parameters, and the destination port is the one on which the SSL server in the PLC is listening (default is 12347), the SSL server must be enabled in the PLC configuration. In PLC there must be uploaded with a private key (srv_key) and a certificate with a public key (srv_cert). Both files are part of the factory settings. When establishing a connection, the PLC sends the public key to the client so that the parties can establish secure communication. Only the obfuscation of communications for outsiders is addressed, not the verification of the identity of the parties.
Default server certificate - The default server certificate is also part of the factory setting. In the def_ca file, the PLC has a self-signed certificate issued by the certification authority Domat, also self-signed (that is, not verified against a public authority), and since these certificates are loaded in all PLCs, it is enough for them to verify each other even without access to the Internet. This self-signed certificate must also be imported to the computer where the client program is running. The certificate will be delivered by Domat technical support.
With a server certificate, authentication against an authority - It is necessary to equip the client with a certificate against an authority on the Internet (then the client must have access to the Internet), or with a certificate that the PLC has uploaded in user_ca - this is arranged by the user who builds his own trust system.

How to upload the certificate to the PC so that it can be used by client programs (SCADA, IDE...)? On Windows, the process is as follows:

In the cmd window run mmc, in the console select File / Add or remove snap-in module / Certificates (local)

and with the right mouse button, for example, on Wide Area Network Trust (all folders are technically the same, it's just a clear classification and user access rights), All tasks, Import.

SCADA configured in RcWare today has the possibility to set a secure connection in RcWare export from version 12.4.2023. (In RcWare the secure connection itself doesn't work, it's just an export setting option for SCADA.)

The web browser connects via https:// to the PLC

The PLC is in the role of the server. Several levels are possible.

No security - Connection via http:// protocol (TCP port 80). Some browsers already allow access only on the local network, not over the Internet; it is necessary to agree that the user is accessing an unsecured website.
Secure connection without domain verification - Connection via https:// protocol (TCP port 443). The data is unreadable to a third party, but the client cannot verify the authenticity of the domain on which the web server is running. Factory loaded default TLS certificates can be used.
Secure connection with domain verification - Connection via the https:// protocol (TCP port 443), plus verification using a domain certificate. For them, it is necessary to upload both "Web Server..." files - certificate and key - to the PLC. The web server certificate must be issued for the domain on which the PLC web server will be visible to the client, i.e. plc.firma.cz. When creating the certificate, this is entered in "common name". The domain administrator arranges the certificate.

If you neglect to maintain a secure web server, there is a risk that browsers will reject expired or self-signed certificates. Today, it is still possible to confirm in the browser that the user still wants to visit the website.

A better option is to use a web proxy server (not to be confused with Domat Proxy!) The web proxy server is managed by the IT department, which ensures the connectivity of the internal network to the Internet). The certificate is then part of the web proxy server and the secure connection from the Internet is translated into a non-secure connection to the PLC in the internal network (which is considered secure). In this case, all the settings are managed by IT and only a regular non-secure web server (http://) is set in the PLC. The topology looks like this:

PLC connects to database (DB), wants to save data

The PLC is in the client role when establishing the connection. The DB Adapter can contain a security certificate at the IIS server level (setting the DB Adapter server is normally done in IIS as https://). Configuration on the side of the DB server (more precisely, the adapter) is provided by its operator.

The connection options are:

Insecure connection: Standard http:// connection to the Domat DB adapter, neither the adapter nor the PLC needs to be configured in any way from a security point of view.
Secure connection without domain validation: Secure connection, just enter the URL in the form https:// in the PLC. It is not necessary to upload any certificates, keys, etc. to the PLC.
Secure connection with domain validation: A certificate provided by the DB server operator (or the certificate of the authority to which the DB server certificate refers) must be loaded in the PLC.

How does the PLC know that the DB adapter is what it claims to be? Authentication is done using the DB adapter certificate (from IIS) and the certificate that the PLC has loaded into it.

How does the DB know that the PLC is what it claims to be? He doesn't know, the PLC is authorized to the database only with a name and password as without SSL (the name and password for accessing the DB can be the same for all PLCs). The Runtime ID serves as a differentiator for multiple PLCs. It is not yet possible to upload a client certificate to the PLC, i.e. it is not possible to verify the identity of the PLC against the DB adapter.

The PLC connects to the e-mail server via SMTP and wants to send an e-mail.

A very common case. PLC is in the role of the client. Several levels are possible.

Without security - The server usually listens on TCP port 25. Today, this is practically only possible in local networks. All public servers already require a secure connection.
Secure connection without domain validation - The server usually uses TCP port 587 or 465. To set it up, just check "Enable SSL" in the alarm channel definition. It is not necessary to upload any certificates etc. to the PLC.
Secure connection with domain validation - "Certificate validation" is checked in the report definition settings. When establishing a connection, the PLC makes sure that the mail server is who it claims to be (that is, that the PLC is not connecting to some other fake server). In the PLC, a certificate provided by the e-mail server administrator must be uploaded in the User CA or Default CA. This can be obtained from the email service provider or sometimes exported from the web browser from which the email server was accessed. (Another option is to upload the certificate of the authority to which the e-mail server certificate refers to the PLC).

When establishing a secure connection, the client and server agree, among other things, on the method of data encryption. The encryption methods are called cipher suites. PLCs currently support the TLS1.2 standard and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) cipher suite. It is possible that the cipher suites in the PLC will need to be updated over time as the security level requirements of mail servers become more stringent. In case of problems establishing a connection, a Wireshark dump will help to determine why the PLC was unable to communicate with the server.

It is not yet possible to upload a client certificate to the PLC, i.e. only the identity of the server to the PLC can be verified, not the identity of the PLC to the e-mail server.

The PLC connects to the Domat Proxy server

The PLC is (from a TLS point of view) the client. (This means that the PLC establishes a TLS connection to the proxy server, although from the perspective of the SSCP protocol and especially the "other party" connected to the proxy server - the Merbon IDE, SCADA or other client program - the PLC behaves as a server.) On the proxy server side, all the settings are provided by the service provider, Domat.

No security: Standard http connection. In the PLC, we set the Proxy URL http://plcproxy.domat.cz:12349
Secure, no domain validation: No certificates need to be uploaded. In the PLC, in the proxy settings, just enter the URL in the form https://plcproxy.domat.cz:12359 (be careful, the port number is different from the non-secure connection).
With domain validation: In addition, a certificate provided by the proxy server administrator (Domat) must be uploaded to the PLC. By default, the Domat domain certificate is already loaded in the PLC.

It is not yet possible to upload a client certificate to the PLC, i.e. only the identity of the server to the PLC can be verified, not the identity of the PLC to the proxy server.

The SSCP client (IDE, PLC, SCADA) connects to the Domat Proxy server

On the "other side" of the proxy, from the point of view of TLS, it is also a client connection to the proxy server.

Again, we have several options to secure the connection (regardless of how it connects to the PLC proxy server):

No security: Standard SSCP connection. In the IDE, in the Connection Parameters, we set the Proxy URL tcp://plcproxy.domat.cz:12348
Secure, no domain validation: No certificates need to be uploaded. In the IDE, you just need to enter the URL in the form tcps:// plcproxy.domat.cz:12358 (be careful, the port number is different than for a non-secure connection).
With domain validation: In addition, a certificate provided by the proxy server administrator (supplied by Domat) must be uploaded to the client PC.

All combinations of secure and non-secure connections from the PLC and SSCP clients are possible, for example the PLC can connect to the Proxy server with a secure connection, but the IDE with a non-secure connection.

Domat Visual / HT200 is connected to the PLC

Domat Visual does not yet support secure connections.

Back to listing