Now, 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:
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 was expanded by adding parameters that allow to specify any available certificate to be used as TLS Client certificate.
Following eight parameters were added to configuration of TELNET-TERMINAL launcher:
When configuring TELNET-TERMINAL Launcher, user would do following in TELNET-TERMINAL editor dialog:
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:
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.
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.