linked/TELNET_TERMINAL-launcher-edit-dialog.png
Built-in Proxy32 TELNET-TLS Client has the ability to send certificate to TELNET-TLS Server to authenticate itself.
Certificate used by the TELNET-TLS Client to authenticate itself to TELNET-TLS Server should have matching private key associated with it. On Microsoft Windows computers there are two ways to keep certificates together with their private keys: - install certificate with private key into Windows System Certificate Store - save certificate with private key into password-protected PFX-file.
Windows System Certificate Store would be used if certificate is provided by corporate IT people. It will also be used for certificates that are installed into plug-in smart cards (as smart card will be mounted as an additional system store into System Store Tree).
Password protected PFX-file provides portability between different computers (it can be moved as part of proxy32 installation that is located on the flash-drive).
TLS Client Certificate can be obtained from Commercial or Corporate certificate authority or issued by Proxy32 user with the help of Proxy32 built-in Certificate Authority (located in Proxy32 Options Dialog, pages "Create Root CA Certificate" and "Create Temporary Certificate"). If CA and Client certificates are issued by Proxy32 user, then CA certificate of the issuing user has to be installed into trusted CA store on all computers running TLS Servers. Client certificates issued by Proxy32 user has to be distributed to appropriate users running TLS Clients. In case of Commercial or Corporate certificate authority, their CA certificates are already pre-installed to all computers, so users should not exchange any certificates between each other, only receive client certificate from CA and configure it to be used by the TLS Client software.
Configuration of Proxy32 TELNET-TERMINAL Launcher has parameters that allow to specify any available certificate to be used as TLS Client certificate.
linked/TELNET_TERMINAL-launcher-edit-dialog.png
Following eight parameters are present to configuration of TELNET-TERMINAL launcher to configure Client certificate:
When configuring TELNET-TERMINAL Launcher, user would do following in TELNET-TERMINAL editor dialog: 1) Provide hostname or IP address of the TELNET or TELNET-TLS server (text field "Hostname or IP"). 2) Provide TCP port number on which TELNET or TELNET-TLS server is listening (text field "Port"). 3) Decide whether to use plain TELNET or to use TLS protocol to protect TELNET traffic (depends on the server type). To use TLS select check mark "Use TLS+Telnet". 4) If the check mark "Use TLS+Telnet" is selected, decide whether to send certificate to TELNET-TLS server to authenticate our client. Client has to send certificate to server only if the server requires it. If server would require client to send certificate, select check mark "Send Certificate". 5) If the check mark "Send Certificate" is selected, proceed with certificate selection steps: a) select type of the certificate store where client certificate is located. User can select either "Use System Certificate Store" or "Use Certificate Store in PFX-file" radio button. b) If "Use System Certificate Store" radio button is selected, proceed with selecting system certificate store where client certificate is located. This is done by selecting from three drop-down lists in proper order (from the left to the right). Content of every drop-down list depends on the choice that is made in the previous drop-down list. This is because system certificate stores are organized into tree-like structure. Every application can add its store to the Tree of the Stores, so Proxy32 has to query the system for available system certificate stores as the user progresses with his/her selection via the chain of the drop-down lists. First, select "system store location" from the first drop-down list. Default location is CURRENT_USER. After selection is made in the first drop-down list, content of the next two drop-down lists will be re-populated to reflect the change in selection of the first drop-down list. Then proceed to select "logical name of the store" via second drop-down list. Default logical name for CURRENT_USER is "My". After selection is made in the second drop-down list, content of the third drop-down list will be re-populated to reflect the change in selection of the second drop-down list. Then proceed to select "physical name of the store" via third drop-down list. Default physical name for "CURRENT_USER/My" is ".Default". c) If "Use Certificate Store in PFX-file" radio button is selected, proceed with selecting PFX-File name. PFX-File is certificate store where client certificate is located. This is done by pressing the button "Select PFX-File" and selecting desired PFX-file via "File Open" dialog. d) After certificate store is selected, proceed with selecting particular certificate from the store. Store may contain more than one certificate and certificate in the store should be identified by its subject common name and thumbprint. User should press "Select Certificate" button and choose desired certificate from the list in the dialog. After highlighting desired certificate and pressing "OK", certificate subject common name and thumbprint will appear in the appropriate text fields in TELNET-TERMINAL editor dialog and they will be remembered (along with certificate store information) to help identify certificate in the store. 6) Provide tooltips for the TELNET-TERMINAL Launcher. Tooltips will also be used as initial terminal window name when terminal window is created.
Client Certificate is accessed when TELNET-TLS Client performs connection attempt. When TELNET-TERMINAL Launcher is used for the connection (either on terminal creation or on terminal re-connect), user will be asked to supply password to get access to client certificate in following cases: - certificate is located in the PFX-File. PFX-file is always password-protected, the password was set when PFX-File was created. - certificate was installed into the system store with "HIGH PROTECTION". The password was set during certificate installation. This password is asked only once per lifetime of Proxy32 process. It will not be asked again unless user has restarted Proxy32 process.
The only way to avoid supplying password on every connection attempt (to get access to configured client certificate), is to install client certificate into system store with LOW PROTECTION (Windows default).
Proxy32 has Terminal Session Sharing functionality that is implemented via TELNET or TELNET-TLS Server that is built into every terminal window. When using TLS protocol, TLS Server has to authenticate itself by presenting valid certificate to TLS Client. TLS Client can optionally authenticate itself to TLS Server with digital certificate if TLS Server requests it. So far, Proxy32 built-in TELNET Client was capable of using TLS protocol to authenticate TLS Server and to encrypt TELNET traffic, but was not able to send digital certificate to the TLS Server to authenticate itself. Starting from "February 20th 2013" version of Proxy32, functionality of the Proxy32 built-in TELNET Client was expanded to allow it to send certificate to authenticate itself to TLS Server when using TLS protocol.
| Terminal Session Sharing Server | Terminal Session Sharing Client | Note |
| Proxy32 TELNET-TLS Server | Proxy32 TELNET-TLS Client | Two-way certificate authentication. Client and Server certificates are located anywhere on PC (any Windows System Store or any PFX-file) |
| Proxy32 TELNET-TLS Server | CYGWIN telnet client + stunnel | Two-way certificate authentication. Client certificate can be located only in certificate file compatible with OpenSSL (PEM with encrypted or unencrypted private key). |
| Proxy32 TELNET-TLS Server | CryptoTerm | Two-way certificate authentication. Client certificate can be located only in "CURRENT_USER/My/.Default" Windows System Certificate Store (as of Oct 2011) |
| Proxy32 TELNET-TLS Server | SecureCRT | One-way certificate authentication (as of Oct 2011 SecureCRT TELNET-TLS Client did not have functionality to send certificate to TELNET-TLS server) |
| SecureCRT monitoring port (SSH server built into terminal window) | Any SSH client | SSH protocol is problematic when configuring server authentication for the large number of clients. Without properly configured server authentication SSH connection is vulnerable to Man-In-The-Middle attack. To authenticate SSH server: 1) public key of the server should be distributed in advance via out-of-band secure channel to every SSH client and installed into such client together with IP address of the SSH server; 2) IP address of the server should be static as it is associated in every SSH client with server public key (unless server hostname is available to all clients and can be used safely instead of server IP address). |
| Proxy32 TELNET Server | Any TELNET Client | Not secure (no authentication, encryption and integrity protection) |
As Client authentication is optional in TLS protocol, to make use of new client functionality user should go to TLS Server configuration and instruct TLS Server to request certificate from the TLS Client and validate this certificate when received. To do so user should visit Options Dialog Page "TLS Set Server Trusted Certificate Store" and set the checkmark "TLS Server requests TLS Client to Authenticate itself by presenting valid trusted certificate" and then select desirable certificate checking options.
When using Windows System Certificate Stores as Server trusted store, Client certificate is validated either by "peer trust" (in this case "peer trust" should be enabled and Client certificate should be pre-installed into TrustedPeople Windows System Certificate store, works only on Vista+) or via issuer's chain of CA certificates (in this case CA certificate(s) should be pre-installed in the trusted System CA store). When using PFX-file as Server trusted store, this PFX-file should contain issuer's chain of CA certificates and, if configured, also Client Certificate itself.
linked/Options-dialog-page-TLS-Set-Server-Trusted-Store1.png
To configure what checks can be ignored when validating Client certificate user should go to "TLS Set Server Policies" Options Dialog Page. If Client certificate check has failed, or if Client certificate is not received, TLS Server will refuse the connection to the TLS Client.
linked/Options-dialog-page-TLS-Set-Server-Policies.png