| Comments: |
-
With this command you can define all the parameters necessary for the PLC to successfuly connect
to the HTTP or HTTPS web server.
- Not all indices are needed. E.g. if you are not using secure connection, then you do not need to define the certs
and key filenames (index = 4 to 9)
- If the PLC is to use encrypted (TLS) connection to connect to the server, then configure it to Use Secure
(TLS) Connection as follow:
HTTP_CONFIG 1, "1"
Note: the above command is only effective if the URL_string
in the HTTP_COMMAND does not include a "http://" or "https://" prefix. Otherwise this setting is ignored and the prefix will
determine the connection security type.
TLS (encrypted) Connection Explain
-
TLS connection involves the client (PLC) and the web server exchanging encryption keys during the initial
connection (handshake) and it is a complex and time consuming process (typically takes a few seconds to complete).
Once the keys exchanges are completed the client and server agree on a secret key that are used to encrypt all data
exchanges between the two parties. The connection is now considered "secured".
For applications that require highest security (such as banking transactions), the client will also want to make sure
that the server that it is connecting to is the "real" thing. This requires a 3rd party, trusted entity to certify that
the server is "real" and this 3rd party entity is known as the "Certification Authority (CA)". The CA issues a CA certificate that
is used to "sign" the server's own encryption keys (expressed as digital certificates).
When the client initiates connection with the server it uses the CA certificate to check against the server certificate
to make sure that it is valid. We call this process "CA cert check".
To enable Wx PLC to carry out "CA cert check", first you must download the valid CA cert PEM file from the web server and store the
PEM file in the PLC's local disk space. You will then need to run the HTTP_CONFIG 5,"1" command and also run
HTTP_CONFIG 6, [CA cert PEM filename string]. You probably should also run the HTTP_CONFIG 4,"1" command
to enable the CNname check to maximize security. (The only reason you want to turn off CNname check while turning on CA cert check is
when the server does not have a domain name but only an IP address and thus there is no valid CNname to check).
Caution: Note that all
CA certicates have expiry date (can be from a few months to a few years) and once the certificate has expired the communication with
the server will fail. This means that if you are enabling CA cert check you will need to properly schedule maintenance to update the
CA cert before expiry to prevent sudden loss of communication.
In our opinion, unless the PLC is connected to a public WiFi where some man-in-the-middle attacker can put up a "DNS Spoofer"
to redirect your web server connection to bogus website, it may not be necessary to enable the CA cert check since most
PLCs are likely connected to a work place or home network and has no danger of meeting a DNS spoofer.
By not enabling CA cert check it eliminates the necessity to find, store and maintain the CA cert on the PLC file space.
With or without the CA cert check the TLS data exchanges between the PLC client and the web server on the Internet are still
encrypted and are thus secured against eave-dropping.
- If you are simulating the TLS communication with CA cert check using i-TRiLOGI simulator,
the certificates and key files should be copied to the folder C:\TRiLOGI\certs\
- Some web servers only allow selected clients to connect to it. It typically does it in two ways:
- The most common way is to authenticate via username+password and this can be used
for both encryted (TLS) and non-encrypted connection. During initial connection the server requests the client to
supply the valid username and password and only authenticated clients are allowed in. You must run the
HTTP_CONFIG 2, [username string] and HTTP_CONFIG 3, [password string]
before running the HTTP_COMMAND so that the PLC will be able to supply the credentials when queried by the server
-
The second method is only applicable to TLS encrypted connection, where the server will require the client to supply a
client certificate that has been signed by a CA that it recognizes. The client certificate lets the server know that
you are really who you said you are and it can then check your identity against a database of authenticated users
before granting you access. It will be rare for a PLC to be issued client certificates for communicating with
web server. But if required the PLC must run HTTP_CONFIG with index 7,8 and 9 to define the client certificate,
client's private key file and password to the private key file before running HTTP_COMMAND.
Note: The client certificate feature is currently
experimental and not officially supported, but we welcome feedback from users who have actually tried using it.
- Keep Connection Open: After a HTTP request has been sent to a webserver and a proper response
has been received by the client the connection is usually closed automatically either by the client (PLC) or the server after a short time-out
period. However, if you have a few HTTP requests that you would like to send to the same web server (same server host address)
consecutively, then it is more efficient to use the same connection to send multiple HTTP requests.
The efficiency improvement is especially significant for encrypted (TLS) communication than
non encrypted communication since the initial handshake of a TLS connection session can take several seconds. To keep the
connection open, run the command HTTP_CONFIG 10, "1" before the HTTP_COMMAND. Please remember to run
HTTP_CONFIG 10, "0" before the last HTTP_COMMAND to allow the connection to close after running the last HTTP_COMMAND in a custom function.
|
Basic to TBASIC Reference Manual