Using TLS/SSL with our command line 2.0 library

We're continuing to add SSL/TLS support to our libraries. This week, it's the turn of the command line library, which is upgraded to v2.0 for the occasion.


As with our other libraries, the addition of the SSL/TLS layer changes very little. Simply use "wss://" or "https://" before the VirtualHub 2.0 or VirtualHub for web address to use encrypted communication. The "wss://" prefix stands for "WebSocket Secure" and configures the library to communicate using the WebSocket protocol over an SSL/TLS-encrypted connection, while the "https://" prefix uses the classic http protocol over an encrypted connection. Note that VirtualHub for web only supports the https protocol.

For example, the following command lists the modules connected to VirtualHub for web:

Certificates

SSL/TLS authentication is based on an electronic certificate list. When the connection is established, the client checks the validity of the certificate list, ensuring that at least one of the certificates in the list has been issued by an authority recognized by the client. To establish a 100% secure connection, the client needs to know the certificate issuers of all the servers it will be accessing.

The trusted certificates of the command-line library are stored in a subdirectory of the user's home dir. Under Windows, this is the %APPDATA%\Yoctopuce\CmdlineV2\certs directory, and under Unix ~/.ycmdlineV2/certs.

By default, the command line library doesn't know any certificate. Consequently, the first time you connect to VirtualHub v2.0, the following error is displayed:

This means that the certificate list used on the https://vhub4web.example.com server is unknown and cannot be verified. Which is logical, as this is the first time we've contacted this VirtualHub for web.

In this situation, you have three solutions:

The --ignore_cert option

You can use the --ignore_cert option to disable certificate verification.

Communications are always encrypted, so an attacker spying on the network would not be able to decipher the communication. However, as the VirtualHub certificate is not validated, communications are vulnerable to a man-in-the-middle attack.

The addRemoteCertificate command

The addRemoteCertificate command lets you manually add a certificate to the list of trusted certificates. This function takes as arguments the certificate path and the host name for which the certificate is valid. The certificate format must be in PEM format.

Once the certificate has been added, the library can establish a 100% secure connection with the remote host. Communication is both encrypted and authenticated.

The downloadRemoteCertificate command

The downloadRemoteCertificate command is a lazy variant of the addRemoteCertificate command. This command takes the VirtualHub URL as an argument, downloads the certificate and adds it to the list of trusted certificates.

Obviously, to download this certificate, the library must connect to VirtualHub before it can be used. So, technically, execution of this command is vulnerable to man-in-the-middle attacks, but all subsequent commands are encrypted and authenticated.

Conclusion

The command-line library is the first library to officially go to v2.0 with SSL/TLS support. All commands are unchanged, and the migration should go smoothly. Should you encounter any problem, please do not hesitate to contact support.