Set TLS protocol version
Following 5 tables describe user choices when configuring TLS protocol for Proxy32 Terminal Session Sharing (TSS) server.
Table 1. Configure protocol version and ciphersuites
Table 2. Configure Server certificate origin mode
Table 3. Configure existing permanent certificate for use by server
Table 4. Configure CA mode in the server to generate permanent Server certificate manually or to generate temporary server certificate automatically on every start of Proxy32 application
Table 5. Configure how server will verify client certificates
|
TLS configuration step |
Configuration choices |
|---|---|
|
|
|
Select allowed TLS ciphersuites and order of their negotiation |
|
Set TLS protocol version
Build ordered list of allowed ciphersuites
Configure server policies to disconnect if weak cipher is negotiated
|
TLS configuration step |
Configuration choices |
|---|---|
|
Configure server certificate origin mode
|
TLS configuration step |
Configuration choices |
|---|---|
|
Select TLS Server certificate: |
Server certificate origin mode should be set to: "Use Existing Certificate" (please, refer to Table 2) |
|
|
|
View store and select certificate. Selected certificate should have matching private key (RSA, DSA or ECDSA key, ECDSA key is supported starting from Windows Vista). Certificate common name and SHA1 hash will be stored to be used for future automatic loading of this certificate. If certificate is selected successfully, it is also loaded into server |
|
Autoload options: Decide whether to use default password for automatic loading of PFX-files or always ask user for PFX-file password |
Configure server certificate origin mode (show existing certificate mode)
Load existing server certificate
Configure certificate automatic loading on startup
|
TLS configuration step |
Configuration choices |
|---|---|
| Create, Load and use CA certificate: |
Server certificate origin mode should be set to CA : “Create and/or use your own CA certificate to generate temporary server certificate” (please, refer to Table 2) |
Creation options:
|
|
|
|
|
|
|
2.2. Select CA certificate from the store (this is also manual loading) |
View store and select certificate. Selected certificate should have matching private key (RSA). Certificate common name and SHA1 hash will be stored to be used for future automatic loading of this certificate. If certificate is selected successfully, it is also loaded into application and ready to be used for creation of server certificate |
Options for creation:
|
|
Autoload options: Decide whether to use default password for automatic loading of PFX-files or always ask user for PFX-file password |
Server certificate origin mode should be set to: “Create and/or use your own CA certificate to generate temporary server certificate” (please, refer to Table 2)
Configure server certificate origin mode (show CA mode)
Create and save root CA certificate
Load existing CA certificate
Create temporary server certificate
Configure certificate automatic loading on startup
More info about configuring TLS Certificate validation can be found here.
|
TLS configuration step |
Configuration choices |
|---|---|
|
|
|
|
|
|
|
List of pre-defined policies: |
Set server trusted store
Configure server policies to disconnect if weak cipher is negotiated
In transport layer security protocol encryption is used to protect traffic from eavesdropping. If someone can see TCP/IP packets traveling over the network one cannot read their content/payload because this content we'll be encrypted. Traffic travels through encrypted pipe from sender to receiver and nobody but sender or receiver can read it.
But encryption alone is not enough.
When sender is establishing encrypted pipe towards the recipient he needs to know that he is to the recipient that he need to talk to. If hijacker will be in the middle between sender and recipient then sender will start talking (establishing encrypted pipe) with hijacker thinking that he is to the valid recipient. Hijacker will use information that he received from sender to start establishing encrypted pipe towards the recipient. As a result both sender and the recipient will establish encrypted pipe with hijacker but they will think that they are talking directly to each other and not with hijacker. The hijacker will be sitting in the middle and will be able to see and even modify unencrypted traffic traveling between sender and the recipient in both directions.
Such attack is possible when both sender and recipient do not use authentication.
That is why transport layer security protocol mandates using authentication at least in one direction. Under this protocol server has to show its certificate to the client. Use of an authentication in another direction is possible but not mandatory. Server can request client to present valid certificate.
Using authentication and digital certificates is based on the properties of the pair of ciphering keys (RSA, DSA, ECDSA):
If information is encrypted with the first key of the pair then it can only be decrypted with the second key of the same pair.
If one knows only the first key of the pair, it is practically impossible to recover second key of the same pair.
Using property 2 one of the keys can be made public and publicly associated with the name of the server so that everybody can see it. The second key always have to be a secret one and should stay on the server. When client connects to the server server shows to the client its public key that is associated with the name of the server. Client generates random number, encrypts this number using public key of the server and sends this encrypted number to the server. Server decrypts this number using its secret key and then it sends decrypted number back to the client. Client checks that server returned the same number that was sent to it. Therefore, client is making sure (using property 1) that server possesses this secret key that works in pair with the public key of the server. That means that public key of the server belongs to this particular server with which connection is being established. Otherwise, server would not be able to decrypt random number correctly.
In this situation client relies on the fact that it knows public key of the server in advance. Public key is being used to confirm that server is exactly the same server that it is declaring to be. The problem is that clients should know in advance and from reliable sources public keys of all servers to which it will be connecting.
In secure shell protocol this problem is solved in the very sample way. When server sends its public key to the client client secure shell program shows this key (which is 2048-bit long number) to its user and asks him: "the server to which I am connecting send me this key. Does this key belongs to this server?". This question would assume that the user of the client secure shell program can directly connect to the owner of the server, for example, using encrypted phone channel, encrypted email or chat, and ask server owner to confirm that this public key really belongs to his server. In a real-life situation user of the client secure shell program would rarely do this. In most cases user of the client secure shell program will reply: "yes, this key belongs to this server". You wouldn't really call and talk to the server owner to confirm this statement. In reality this public key may belong to hijacker but it is too much trouble for the user of the client secure shell program to start checking who is the real owner of this public key.
To make secure shell connection secure owner of the secure Shell server would have to distribute public key of his server for the installation into all client secure shell programs that will be connecting to his server. Owners of the client secure shell programs should install received public key of the secure Shell server into their client secure shell programs before those client programs will be used to connect to secure shell server.
In transport layer security protocol digital certificates are being used for the authentication instead of plain public keys that are used in SSH. Every owner of the transport layer security server send his server's public key and the server name to the Internet Notary Public (Certificate Authority - CA). Internet notary public is a big organization which everybody trusts implicitely. This organization checks the identity of the server owner, checks the name of the server and attaches public key of the server to this checked information. Than it would seal all three pieces of information into one digital file by the means of the digital signature. Digital signature is made by CA's own secret key. Anyone can verify this signature using the CA's public key. Owner of the server will receive digitally signed file that contains name of the server and its public key. This file is called digital certificate. This certificate can be shown to anyone, but only owner of the server secret key can prove that this certificate belongs to him/her.
When transport layer security client receiving digital certificate of the server it first checks that server possess secret key that works in pair with the public key that is shown on server certificate. That means that server is the owner of the public key that is shown on certificate. After this transport layer security client has to check that this particular public key is associated with the name of the server to which connection should be established. In order to do so transport layer security client has to verify digital signature of the Internet notary public on servers certificate. The signature that attaches the name of the server to its public key. This digital signature is checked with the help of the public key of the Internet notary public. This public key is contained in the own certificate of the Internet notary public. If digital signature on the server certificate is valid then transport layer security client really deals with the server whose name is shown on its certificate.
Summary: Step 1: Verify that public key on server's certificate "matches" secret key possessed by the server. Step 2: Verify that public key on server's certificate attached to server name by "valid" signature of the "trusted" CA. End Result: The name on server's certificate truly belongs to this server.
To achieve this client has to trust to Internet notary public and to have CA's own certificate in order to be able to validate other certificates that were issued by this CA.
As we have shown transport layer security protocol delegates checking identity of the public key to global Internet notary public but not to the user of the transport layer security client program, as it is done in secure Shell protocol.
As a result authentication is performed automatically and the only thing that user of transport layer security client program has to do - is to install own certificates of those Internet notary public to whom he trusts.
To achieve the same level of security user of client secure shell program would have to contact in person the owner of every secure shell server, receive the public key of the server and install this key into his own client secure shell program before establishing connection to secure shell server.
Again, as it was shown above transport layer security protocol delegates checking identity of the public key to global Internet notary public. There are not too many global Internet notary public organizations to whom everybody trusts. Certificates of such global Internet notary public organizations are already installed into the operational system's certificate stores and into certificate stores of the mainstream web browsers. In large corporations there are divisions that perform functions of Internet notary public inside of the company. In such cases certificates of the corporate Internet notary public departments are already installed on the corporate computers. As a result, in most cases the infrastructure for checking certificates of the transport layer security server and transport layer security client is already present on the user's computer. Transport layer security server program and transport layer security client program simply has to have the ability to use this existing infrastructure.
Proxy32 application gives to the user two different options.
Option number one.
User can use the list of trusted notary public certificates that is stored in the operational system and used globally for the whole computer. On corporate computers content of global list may be changed by system administrators and also by users of this computer who has appropriate privileges.
Option number two.
If user doesn't want to use global list that is stored in the operational system then he can create his own store of trusted notary public certificates in the special file with extension ".PFX", that is protected with the password. This file can be configured in the Proxy32 application as a store of trusted notary public certificates. In such case only certificates that are signed by notary public from this list will be accepted by Proxy32 application when connection is made using transport layer security protocol. Proxy32 application has special functions that allow user to create PFX-files (certificate store files) and view, delete, import and export certificates from such files.
There are also different options that allow user to fine-tune process of validating server certificate with the help of the notary public certificate. First of all, server certificate has to be signed by the public key shown on the certificate of one of the trusted internet notary public. If such digital signature is valid than application will proceed with checking the information that is contained in the certificate itself: - Validity period of the server certificate should not expire; - Subject common name on the server certificate should much the name or IP address of the computer on which transport layer security server is running; - Sometimes it is also required that the server certificate would be explicitly labeled as permitted to be used as server certificate (key usage property); - Also in some cases it is required that server certificate would be explicitly labeled that it is not certificate of the notary public, but rather certificate of the end entity (basic constraints property); - In some cases it may also be required that server certificate itself should be installed in advance into the trusted certificate store in the transport layer security client program. Transport layer security client program will check that server certificate received from the server exactly matches server certificate that was pre-installed into the trusted certificate store in the client program. This requirement can be used either in addition or instead of the requirements that server certificate will be signed by the trusted notary public. In latter case it is called "peer trust" as opposite to regular "root trust". Peer trust option is added on Windows Vista.
All listed checks may have impact on the decision whether transport layer security client program will accept server certificate or it will refuse to establish connection with the server.
In the good transport layer security program all listed certificate checks can be turned on and off separately depending on the requirements of the user.
Similar checks are performed on the client certificate in the transport layer security server program if server is configured to request such certificate from the client and if client possesses and presents such certificate. The only difference is that subject common name on client certificate tends to rather reflect name of the user of the transport layer security client program and not the name/address of the computer on which such program is running. Because of this difference name on the client certificates normally is not compared with the name of the computer on which transport layer security client program is running.
So far, we have been looking on checking certificate that was sent by the peer and we have noticed that this check is usually relies on the existing infrastructure and it doesn't need user intervention. In order to present certificate the peer has to have it and this certificate has to be installed together with its secret key in the transport layer security client or in the transport layer security server. In the large corporation such certificate may be already installed in Windows systems store on the user's computer or such certificate can be ordered by the corporate user and installed on his computer.
If user is not part of the large corporation he would have two options:
User can order commercial certificate from global Internet notary public. The advantage of such approach is that commercial certificate will be accepted by all users who trusts to this particular global Internet notary public. Normally, this would include all users on the Internet. The disadvantage of this approach is that user have to pay money for issuing the certificate and also for re-issuing this certificate when it's period of validity will expire;
User can perform functions of Internet notary public himself. He can create his own notary public certificate. Then using this notary public certificate he can issue certificates for his own transport layer security server and transport layer security client. Advantage of this approach is that there is no need to pay money for issuing and extending certificate. Additional advantage is the ability to re-issue certificate in the situations when name or IP address of the computer on which transport layer security server is running has changed and no longer matches the name or IP address shown on the server certificate. Disadvantage of this approach is the need for the user to distribute his own notary public certificate for the installation into the trusted store of all client program that will be trying to connect to this particular transport layer security server. This option is similar to what user of secure Shell server has to do. He would have to distribute public key of the server for the installation into all client secure shell programs that will be connecting to his server.
It is important to note that using global Internet notary public is the main option for authentication in the transport layer security protocol. This option allows large group of user (potentially, all internet users) to authenticate each other according to the transport layer security protocol. Important thing is that all those users doesn't have to exchange the keys with each other, instead they only have to register their keys with the global Internet notary public to whom they all should trust. Another option is when user performs function of the local Internet notary public. This option makes sense, for example, when the group of the users is very small and all users can exchange their own notary public certificates with each other. Another example when this option may be required is when IP address of the transport layer security server is dynamic and clients cannot use name of the computer instead of IP address to connect to such server. Global Internet notary public cannot re-issue server certificate on every change of server name or IP address, but server owner can.
When user is about to use transport layer security protocol he has to choose needed configuration for this protocol:
first user has to choose protocol version. At this moment there are 4 versions of protocol in use: Secure Socket Layer (SSL) protocol version 3, transport layer security (TLS) protocol version 1, TLS protocol version 1.1, TLS protocol version 1.2. Proxy32 application is using Microsoft Windows TLS library Schannel, so supported version of transport layer security protocol depends on the version of the Windows on which the application is running. On Windows XP and Windows Vista only SSL version 3 and transport layer security protocol version 1 is supported. Windows 7 and newer are adding support for transport layer security protocol version 1.1 and transport layer security protocol version 1.2. To achieve best security it is recommended to choose the highest protocol version that is supported on your system. But there would also be some exceptions, for example, if peer computer does not support new protocol version. Another example is when the error is found in the implementation of new protocol version and until such error is fixed it is recommended to use older version of the protocol.
then user have to choose one particular combination of four algorithms used in TLS (authentication, key exchange, ciphering, integrity). When establishing connection according to transport layer security protocol each side will use above 4 algorithms. Each of these four algorithms has different options or different incarnations. To establish successful connection it is required that both sides would use the same set of algorithms. Therefore, in the very beginning of TLS handshake both sides have to negotiate which algorithms they will have to use to establish connection. In such negotiation algorithms are chosen not on the individual basis but as a fixed set (ciphersuite) of 4 algorithms. List of supported ciphersuites depends on the version of the transport layer security protocol in use and it also depends on particular implementation of this protocol in the Microsoft Windows library. When transport layer security client connects to transport layer security server it will offer to the server list of ciphersuites that client can support in the order of preference. Transport layer security server chooses from this list one particular ciphersuite that it will prefer to use and return it to the client to start establishing of the encrypted connection. User of transport layer security protocol has an option to configure list of the enabled ciphersuites and change the order of the preferences for those ciphersuites as they are used in the negotiation process. On Windows XP and Windows Vista user can disable particular algorithms so that ciphersuite containing disabled algorithms will not be used in negotiations between transport layer security client and transport layer security server. Starting from Windows Vista user can directly add and remove supported ciphersuites into the negotiation list and change their order of preference. Unfortunately, in Microsoft transport layer security library changes made to such list of the ciphersuites are always global and applied to all application on this computer that are using Microsoft transport layer security library (which is called Schannel). In particular, changes to ciphersuites list made from the Proxy32 application will impact Internet Explorer web browser. Selected ciphersuite (in particular authentication algorithm and key exchange algorithm) will define the type of the certificate that will have to be used by server in order to implement such ciphersuite. At this moment there are only free types of certificates (according to the type of the key pair used for such certificates). There are RSA, DSA and ECDSA. Proxy32 application allows to use one existing certificate of any type. Using only one certificate when establishing connection means that ciphersuites that would require server to use other two types of certificates will be automatically removed by the server from the list of the ciphersuites that are being used in negotiations. Also, Proxy32 application has built-in tools to generate only RSA certificates. That means that if connection is established using certificates generated by Proxy32 application then during negotiation application will only use ciphersuites that will work with the certificates of the RSA type.
then user have to choose how he will be verifying certificates sent by the peer. We have already covered all the details above.
User will have to configure certificate (together with its secret key) that server will send to the client. After installation of the application if user does not configure anything transport layer security server will use temporary self-signed 2048-bit certificate that is automatically generated on every start of the program. This option is intended to be temporary because it does not provide authentication (temporary self-signed certificate is not signed by Internet notary public). It will still provide encryption, but to connect to such server transport layer security client will have to disable server certificate check and such connection will be vulnerable to man-in-the-middle attack.
User has two options that he can configure and that would allow reliable authentication and protection of the key exchange.
First option is to use existing certificate that is signed by global Internet notary public or by Internet notary public of the large corporation. Sigh certificate may be already installed on the users computer or it is has to be ordered from the Internet notary public and after it is issued it needs to be installed on the user's computer. Certificate can be installed on the user's computer either into the system store of certificates in the Windows operational system or into the PFX-file. Proxy32 allows to load certificate for the use in the transport layer security server either from Windows system store or from the PFX-file on the disk. As certificate is being loaded together with it's associated secret key loading process might require from the user to enter password that is protecting secret key. When using Windows system store password may not be required if the secret key was installed into the Windows system store without the password. When loading key from the PFX-file password is always required but it can be set to the word "password" and then program may be configured to automatically enter such password when the key is loaded. Therefore, user will not be required to type in password. All these options are available in the Proxy32 application. In order to load certificate user will have to specify the name of the Windows system store or the name and the password for the PFX-file. After this user with have to look into the selected store and select one certificate that he would like to load into transport layer security server. Selected certificate will have to have matching secret key (this key should match with the public key that is shown on the certificate). After certificate is loaded manually Proxy32 application will remember name of this certificate and its SHA1 hash. Using these two parameters Proxy32 application will be able to load the same certificate automatically on the next start of the program. The checksum (SHA1 hash) is needed because one certificate store can contain several certificates with the same common name of the subject. User doesn't have to type in the password on the next automatic loading of the certificate on the next start of the program if certificate secret key is installed into the Windows system store without password or if this secret key is loaded from the PFX–file that is created with default password "password" and program is configured to automatically enter this default password during the loathing of the PFX-file.
Second option allows user to perform function of Internet notary public instead of ordering certificate from existing global or corporate Internet notary public. In such case user will have to create his own Internet notary public certificate. Then user can use this certificate to issue temporary certificates for his own transport layer security server and transport layer security client. This approach has one problem. User will have to distribute his Internet notary public certificate (without associated secred key) to all the computers and programs with which he will be establishing connection. This Internet notary public certificate will have to be installed in the trusted notary public certificate store before computer or program may use it to verify certificate that they would receive from the peer. There are two different ways to use this approach. With the regular approach user will create certificates for the server and the client and install them into Windows system store or into PFX-file to use them on a permanent basis. These option is optimal because user creates certificate only once and later this certificate is stored and there is no need to spend the time to create it again. Also, this certificate doesn't change so it can be sent to the peer so that peer will install it into trusted store and match this certificate to ensure additional security. But in some cases transport layer security server may be running on the computer which is impossible to connect to using name of this computer. If the IP address of this computer is also dynamic then address to connect to such server will be frequently changing. Because the name on the server certificates has to match the address of the computer on which server is running, in such situation it will be impossible to use one particular certificate that was issued one time for the server. Server certificate will have to be issued again every time the address of the server will change. In order to do so program can use notary public certificate that is loaded from Windows system store or from the PFX-file and using such certificate it will issue new temporary server certificate on every change of the server address. One of the options is to reissue server certificate manually every time the IP address of the server would change and then save this certificate in the Windows system store or into PFX-file for the future loading into the server. Another option is to reissue server certificate automatically on every start of the program then load it into the server but not to save it into Windows system store or into PFX-file. This option also provides perfect forward security for ciphersuites that use RSA for key exchange, as pair of RSA keys for temporary certificate is discarded on exit from the application or being overwritten on manual re-issuing of temporary certificate. If RSA keys are being discarded, there is no chance that they will be compromised in the future, allowing decryption of past recorded communications. So there are two options to load certificate into TLS server (into transport layer security server): loading existing certificate from Windows system store or from PFX-file (without regards to whether certificate is issued by global notary public or user has performed function of notary public himself) or automatic creation of the new temporary certificate and loading it into the server without saving this certificate into the Windows system store or into the PFX-file.
Two options on how to create certificate:
Two options on how to load certificate into the server:
Loading of the certificate into the server may be done in two ways: