Since all of the session traffic between the StayLinked client and the StayLinked Server is encapsulated in the StayLinked Reliable Protocol, StayLinked is able to avoid transmitting any TCP or TELNET protocols over the wireless network. In other words, there will be no TELNET clear-text traffic traveling across the network while running StayLinked.<\/p>\n\n\n\n
Wireless Security Compatibility<\/h3>\n\n\n\n
The StayLinked \u2018Client2Host\u2019 reliable protocol is\nUDP-based, and thus is inherently compatible with any transport set security\nmeasures (Layers 1 \u2013 4) that a customer might implement. For example,\nStayLinked will run well through a VPN tunnel. Moreover, even if the VPN\nconnection is broken and then re-established, the StayLinked client will be\nable to reconnect to the existing telnet session, resuming operation at the\nsame screen and same cursor location.<\/p>\n\n\n\n
StayLinked is also compatible with standard RF security schemes like WEP, LEAP, PEAP, WPA, etc. This transport and RF compatibility allows customers to implement network security measures with assurance that the StayLinked solution will continue to operate within the new architecture. Additionally, StayLinked is compatible with various authentication methods such as Kerberos, RADIUS, etc. StayLinked sessions themselves are authenticated by the Telnet Host\u2019s login process.<\/p>\n\n\n\n
Additional Network Layer Security <\/h3>\n\n\n\n
StayLinked supports some traditional network security\nconfigurations by implementing a firewall- friendly communication architecture.\nThe StayLinked Server supports Static-NAT configurations and allows for\nconfiguration of Port Restriction rules in order to be compatible with any port\nfiltering switch or firewall. In the case of port filtering, since StayLinked\nis UDP-based and transmits no TCP or TELNET over the network, you can disable\nall TCP traffic through the switch or firewall, including ports usually\nsupporting the TELNET protocol. Further, you can restrict open UDP ports to\nonly those required to connect your licensed number of StayLinked devices.<\/p>\n\n\n\n
Following\nare a description of the UDP ports used by the StayLinked Client2Host protocol:<\/p>\n\n\n\n
Ports used for inbound communications from the Device (source) to the Server (destination):<\/strong><\/p>\n\n\n\n Inbound\npackets are typically filtered at the firewall. These are the UDP ports that\nwill be used by the StayLinked Server.<\/p>\n\n\n\n UDP Port 3006 <\/strong>– This is the port where the StayLinked Server is\nlistening for connection requests.<\/p>\n\n\n\n UDP Port Range <\/strong>– These are the ports that will be dedicated to each device connection to the server. This is a user-defined port range that is configured in the StayLinked Administrator->Server Settings->Firewall Settings. You will need enough ports opened up in the firewall so that each device session will have an available port. Usually, this is based upon how many connections are licensed. By default the server uses ports 3007 to 3999.<\/p>\n\n\n\n Ports used for outbound communications from the Server (source) to the Device (destination):<\/strong><\/p>\n\n\n\n Usually, outbound packets are not filtered at the\nfirewall. But, if you need to open outbound ports, these are the UDP ports used\nby the StayLinked Client.<\/p>\n\n\n\n UDP Port 3771 <\/strong>– This is the listening port used by the StayLinked Client for connections from the StayLinked Server.<\/p>\n\n\n\n UDP Port 3772 <\/strong>– This is the listening port used by the StayLinked Client to receive session status requests from the Server during any communication interruptions.<\/p>\n\n\n\n UDP Port 3773 <\/strong>– This is the port opened and used by the StayLinked Client to listen for any TFTP transfers from the StayLinked Administrator (legacy file transfer mechanism).<\/p>\n\n\n\n UDP Port 3774 to 3782 <\/strong>– This is the listening port range opened and used by the Stay-Linked Client for connections from the Stay-Linked Server for the (up to 9) additional sessions that may be started when running \u2018multi-connections\u2019.<\/p>\n\n\n\n StayLinked provides two different data encryption options for securing the data that is transmitted between the StayLinked Client on the device and the StayLinked Server on the host. The data encryption feature applies to all connections.<\/p>\n\n\n\n Level 1\nEncryption <\/strong>\u2013 This encryption method\nutilizes a native, proprietary, dynamic-symmetric 64- bit key, stream-cipher\nsymmetric encryption algorithm to encode\nthe cargo of the StayLinked \u2018Client2Host\u2019 reliable protocol packets. This encryption\ntechnology is designed to be compatible with older, legacy devices that are not\npowerful enough to support the high-end, public encryption algorithms. This\nencryption option is available for all StayLinked clients on all platforms.<\/p>\n\n\n\n Blowfish Encryption <\/strong>\u2013 This encryption method provides an increased level of data security for the StayLinked packets that are transmitted between the StayLinked Thin-Client and the StayLinked Server. StayLinked Blowfish encryption utilizes the Blowfish\/ECB\/PKCS5Padding cipher. You may also specify key rotation with up to four keys defined and you can specify a key rotation interval.<\/p>\n\n\n\n This encryption option is available only for StayLinked Clients of at least Version 9.1. <\/p>\n\n\n\n Twofish Encryption <\/strong>\u2013 This encryption method provides a very high level of data security for the StayLinked packets that are transmitted between the StayLinked Thin-Client and the StayLinked Server. StayLinked Twofish encryption is a symmetric key block cipher with a block size of 128 bits and key sizes up to 256 bits. As with Blowfish, this option also offers a specify key rotation with up to four keys defined and you can specify a key rotation interval.<\/p>\n\n\n\n Twofish Version Requirements – <\/strong>This encryption option is available only for StayLinked installations with the Android Client at Version 15.2 (build 222 thru 226) connecting to a Server at Version 15.3 (build 212). This implementation used the Twofish\/CBC\/PKCS5Padding method that is replaced with Twofish\/GCM\/NoPadding in Android Client version 15.3 (build 228 and newer), iOS Client (build 144) and Server (build 214 and newer). These implementations are not backwards compatible or interchangeable and it is recommended that security sensitive companies use the newest implementation possible.<\/p>\n\n\n\n At the heart of the StayLinked Host-based Terminal Emulation architecture is the StayLinked Server which runs directly on the same host platform as the emulation server and host applications. This host-based architecture provides an inherent level of security by isolating the telnet connection and communication within the host platform. In this host-based architecture, there are no telnet protocol packets transmitted across the network and no clear-text data exposed to the network. Additional levels of terminal emulation security are also supported by the StayLinked solution. In those cases where SOX or PCI compliance are required, the StayLinked solution supports both SSH and TLS\/SSL-Telnet terminal emulation connections to the host system. This section will describe the StayLinked support for Telnet, TLS\/SSL-Telnet and SSH connections to host systems.<\/p>\n\n\n\n Note that the VT-SmartTE emulation type supports SSH with a wider range of algorithms than VT-SSHv2. VT-SmartTE supports an emulation property to enable SSH, which replaces the older VT-SSHv2 option.<\/strong><\/p>\n\n\n\n Normal telnet connections feature the telnet protocol transmitted from the telnet server to and from the telnet client. The telnet client will typically connect to the telnet server on port 23 which is the official Telnet port. The data carried by the telnet protocol is not encrypted and contains information in clear-text. This protocol is TCP-based and provides the telnet connection between the StayLinked Server, running on the host, and the Telnet server which should be also running on the same machine. When the StayLinked Server and Telnet server are running on the same machine, the Telnet protocol is transported on the \u2018local loop back\u2019 connection which is internal to the machine and is inherently reliable. In some cases, the Telnet server may not be running on the same hardware as the StayLinked Server. Under these conditions, the Telnet protocol is transported over the regular network topology and is naturally more exposed to observation, failure or interruption. <\/p>\n\n\n\n In order to secure the data carried by the telnet protocol and also to secure the connection to a telnet server, the SSL (Secure Socket Layer)or TLS (Transport Layer Security) protocol may be employed (typically used for 5250 and 3270 emulation). With TLS\/SSL-Telnet, the telnet client will connect to the telnet server on port 992 which is the official TLS\/SSL-Telnet port. To run TLS\/SSL-Telnet connections, both the telnet server and the telnet client must support the TLS\/SSL protocol. Usually, the telnet server and telnet client (StayLinked) will provide options for configuring TLS\/SSL support.<\/p>\n\n\n\n To run SSL-Telnet connections with StayLinked, you must be on StayLinked version 8, build 134 or later. As of StayLinked server version 14, SSL connections are no longer allowed, and TLS 1.0 is the default protocol. With StayLinked version 14.5, support for TLS 1.1 and 1.2 was added.<\/p>\n\n\n\n Once your StayLinked Server is configured to provide TLS\/SSL-Telnet support, it is very simple to configure an TLS\/SSL-Telnet connection for your wireless devices. <\/p>\n\n\n\n To enable TLS\/SSL, you must add the following to \u2018Emulation Properties\u2019 in the \u2018Telnet Host Entry\u2019 using the StayLinked Administrator:<\/p>\n\n\n\n TLS Session <\/strong>– To request an encrypted TLS\/SSL session, set this property to True. This is the minimum configuration required to run TLS\/SSL-Telnet sessions.<\/p>\n\n\n\n To enable TLS 1.1 and higher, you must ALSO add the following to \u2018Emulation Properties\u2019 in the \u2018Telnet Host Entry\u2019 using the StayLinked Administrator:<\/p>\n\n\n\n TLS Use JSSE for TLS v1.1-v1.2 <\/strong>\u2013 This setting switches to using JSSE instead of SSLite. This has the added benefit of using Java\u2019s Certificate Authority (CA) file instead of the StayLinked Well-known CA file.<\/p>\n\n\n\n TLS Version Support <\/strong>\u2013 Allows the user to pick the version of TLS to use with JSSE (default is 1.0).<\/p>\n\n\n\n The simplest implementation of TLS\/SSL-Telnet with StayLinked is to use a certificate signed by a Well-known or Trusted CA. If your telnet server\u2019s certificate is signed by a Well-known or Trusted CA, then the only configuration option required is to turn on the \u2018TLS Session\u2019 Emulation Property as described above. If your certificate is signed by a Well-known CA and StayLinked does not recognize it, try turning on \u2018TLS Use JSSE for TLS v1.1-v1.2\u2019 as described above to use Java\u2019s CA file.<\/p>\n\n\n\n You can also use a Private or Third-party Server Certificate with StayLinked, but there is some additional configuration required in addition to the above settings. If, \u2018TLS Use JSSE\u2026\u2019 is not turned on, the CA chain that signed the certificate must be imported into a PKCS12 (Personal Information Exchange Syntax Standard) file named \u2018CustomizedCAs.p12\u2019. The password for this file must be set to \u2018hod\u2019. If however, \u2018SSL Use JSSE\u2026\u2019 is turned on, then the CA chain must be imported into a JKS (Java KeyStore) file named \u2018CustomizedCAs.jks\u2019. The password for this file must be set to \u2018hodpwd\u2019. Second, the file must be placed in the StayLinked Server main folder, \u2018..\\stay-linked\u2019. With the Customized CAs file properly created and located, the StayLinked Server will be able to operate using your Private or Third-party Server Certificate.<\/p>\n\n\n\n Client authentication is similar to server authentication\nexcept that the telnet server requests a certificate from the client to verify\nthat the client is who it claims to be. The certificate must be an X.509\ncertificate and signed by a certificate authority (CA) trusted by the server. You can only use client authentication\nwhen a server requests a certificate from a client. Not all servers support\nclient authentication. Client Certificates can be obtained from a Certificate\nAuthority or can be a Self-signed Certificate. The Client Certificate should be\nexported to a password-protected PKCS12 file.\nThe public portion of a self-signed client certificate should be added to the\ntelnet server\u2019s trusted list. The Client Certificate must be placed in the\nStayLinked Server main folder, \u2018..\\stay-linked\u2019, on the server. Now, you must\nadd three additional \u2018Emulation Properties\u2019 to the \u2018Telnet Host Entry\u2019 using\nthe StayLinked Administrator:<\/p>\n\n\n\n SSL Client\nCertificate Provided <\/strong>\u2013 Set this value to True to indicate that the client has\na certificate to provide to the server.<\/p>\n\n\n\n SSL Client Certificate URL <\/strong>\u2013 Set this value to the file name of the client certificate.<\/p>\n\n\n\n SSL Client Certificate Password <\/strong>\u2013 Set this value to the password of the client certificate. <\/p>\n\n\n\n For VT emulation, an alternative to the\ntelnet protocol is the SSH (Secure Shell) protocol. The Secure Shell (SSH) is a\nset of protocols for implementing secure sessions over a non-secure network\n(such as a standard TCP\/IP network). In order to use SSH, you must set up SSH\nserver software on the host. Security features include the following:<\/p>\n\n\n\n Note that TESS emulation does not provide the option for SSH and cannot be configured for secure protocols when in use with StayLinked.<\/p>\n\n\n\n The following table describes the SSH Version support currently implemented in StayLinked: <\/p>\n\n\n\n SSH is available under the emulation types VT-SmartTE (preferred) and VT-SSHv2. Using VT-SmartTE for SSH requires an emulation property for the option SSH Session set to true.<\/p>\n\n\n\n The following table describes the SSH Transport Protocol algorithms currently supported by the StayLinked VT-SSHv2 emulation type. <\/p>\n\n\n\n 1<\/sup> StayLinked always gives priority to 3des-cbc over aes128-cbc. If you want to use aes128-cbc, 3des-cbc needs to be disabled on the server side. Contact support for alternative supported algorithms.<\/p>\n\n\n\n The emulation type VT-SmartTE supports a wider range of security options (<\/strong>List as of V15.5):<\/strong><\/p>\n\n\n\n Key Exchange: <\/strong>ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c,kex-strict-c-v00@openssh.com For the SSH Authentication protocol, StayLinked supports the following under the VT-SSHv2 emulation type:<\/p>\n\n\n\n Configuring your SSH Server for keyboard-interactive authentication<\/strong><\/p>\n\n\n\n The server configuration for keyboard-interactive authentication differs depending on the vendor or source of the SSH support. Refer to the documentation for your SSH server software for information on how to configure the SSH server for the keyboard-interactive authentication method.<\/p>\n\n\n\n Your SSH host may need to disable keyboard interactive if a scripted password is not accepted. By default, StayLinked will honor the keyboard interactive setting and require the user to manually enter the password. Starting in version 15.3, an emulation property is available to ignore the host requirement for keyboard interactive login.<\/p>\n\n\n\n Configuring the StayLinked Server for keyboard-interactive authentication<\/strong><\/p>\n\n\n\n You do not need to configure StayLinked for keyboard-interactive authentication. The StayLinked SSH client will look for whether keyboard- interactive authentication is configured on the server. If it is configured on the server, then StayLinked will prompt the user for keyboard input.<\/p>\n\n\n\n StayLinked will display a logon prompt according to the data received from the host. This logon prompt allows you to input responses from the keyboard. If your server is configured for keyboard- interactive authentication, then the StayLinked \u2018Startup Scripts\u2019 will not be available for automated logon because manual keyboard entry of the user and password is required.<\/p>\n\n\n\n Configuring your SSH Server for password authentication<\/strong><\/p>\n\n\n\n The server configuration for password authentication\ndiffers depending on the vendor or source of the SSH support. Refer to the\ndocumentation for your SSH server software for information on how to configure\nthe SSH server for the password authentication method.<\/p>\n\n\n\n Configuring the StayLinked Server for password authentication<\/strong><\/p>\n\n\n\n You do not need to configure StayLinked for password authentication. If the SSH Server is not configured for keyboard-interactive authentication, then the StayLinked SSH client will display a login prompt for a user id and password. The user can type-in their user id and password or the StayLinked \u2018Startup Scripts\u2019 can be implemented for automated logon.<\/p>\n\n\n\n Starting in version 15.3 of the StayLinked Server, SSH passwords are no longer limited to the width of the device screen. Prior server versions were limited to passwords that could be typed into the number of columns configured on the Client.<\/em><\/p>\n\n\n\n Configuring your SSH Server for public key authentication<\/strong><\/p>\n\n\n\n The primary requirement for public key authentication is to import into the ~\/.ssh\/authorized_keys file (in the User\u2019s home directory) the public key file information for a public\/private key pair (typically in a file called id_rsa.pub). Refer to the documentation for your SSH server software for more information on how to configure the SSH server for the public key authentication method.<\/p>\n\n\n\n Configuring the StayLinked Server for public key authentication<\/strong><\/p>\n\n\n\n For StayLinked to use Public Key Authentication, the private-public key file will need to be imported into a jks (Java KeyStore) file. StayLinked can then utilize this jks file by placing it in the \u2018..\/stay-linked\u2019 folder on the server and setting the following \u2018Emulation Properties\u2019 to the \u2018Telnet Host Entry\u2019 using the StayLinked Administrator:<\/p>\n\n\n\n Use SSH Public Key Authentication<\/strong> \u2013 Set this value to True to indicate that you want to use Public Key Authentication. NOTE: Communication between Server and Administrator is not encrypted, other than the login process. We recommend only communicating on a trusted or secured connection.<\/p>\n\n\n\n The StayLinked Administrator console application runs on\na Windows-based computer and communicates with the StayLinked Server for the\npurposes of configuration and for session management. These tasks will\ntypically be performed from within the same network as the StayLinked Server\nand so, no special network communications configuration is required.<\/p>\n\n\n\n In some cases it may be desired to use the StayLinked Administrator to manage the StayLinked Server through a firewall. In this case, a special StayLinked Server configuration and special firewall access rules will need to be coordinated so that the StayLinked Administrator management traffic can navigate through the firewall.<\/p>\n\n\n\n The StayLinked Administrator uses two different protocols to communicate with and manage the StayLinked Server. The StayLinked Administrator sends commands to UDP Port 3006 from an OS assigned UDP port and receives responses from UDP Port 3006 back to the OS assigned UDP port. Some of these commands will instruct the StayLinked Server to provide additional data to the Administrator. This additional data will be delivered through a TCP socket connection that is opened on the server. The StayLinked Administrator will attempt to connect to the TCP socket on the server in order to send or receive additional data to or from the StayLinked Server. In order for these communications to be able to navigate through a firewall, you will need to open UDP Port 3006 for the Administrator commands, and also a fixed range of TCP Ports for the TCP socket connections. By default the server uses port range 3010 to 3019.<\/p>\n\n\n\n In order to have the StayLinked Server open TCP ports only in a specific range that\nwill match your Firewall rules, you must configure the StayLinked Server for\nthat specific TCP port range. You will accomplish this configuration by\nmanually modifying one of the server configuration files. The specific\nStayLinked Server configuration file that you will modify is located on the\nserver machine:<\/p>\n\n\n\n ..\/stay-linked\/config\/espadmin.xml<\/strong><\/p>\n\n\n\n In\nthis file, you will add an additional XML node just above the last line of the\nfile, like this:<\/p>\n\n\n\n <espadmin><\/strong><\/p>\n\n\n\n \u2026<\/strong> <adminfirewall lowport=\"3010\" highport=\"3019\"\/><\/strong><\/p>\n\n\n\n <\/espadmin><\/strong><\/strong><\/p>\n\n\n\n The above range matches the default in the latest version of StayLinked. You will want to specify at least 10 available ports in the range that you select. This should be enough ports to support multiple StayLinked Administrator consoles managing the server concurrently. This TCP port range should be opened in your firewall access control list in addition to UDP Port 3006.<\/p>\n\n\n\n Once you have saved the changes to this file, there is no additional action required on the server. These new settings will take effect the next time the StayLinked Server is restarted.<\/p>\n","protected":false},"excerpt":{"rendered":" Overview This article describes the security compatibilities and capabilities of the StayLinked Session Management and Device Management Solution and its unique Client2Host architecture. The StayLinked \u2018Client2Host\u2019™ architecture overcomes all of the security challenges associated with the traditional model of running \u201cdevice- side\u201d Telnet Client software on terminal devices that communicate…<\/p>\n","protected":false},"author":7,"comment_status":"open","ping_status":"closed","template":"","format":"standard","meta":[],"ht-kb-category":[25],"ht-kb-tag":[104,102,103],"yoast_head":"\nApplication Layer Data Encryption <\/h3>\n\n\n\n
Telnet, TESS, TLS\/SSL, and SSH Protocol Overview <\/h2>\n\n\n\n
The Telnet Protocol <\/h2>\n\n\n\n
The TLS\/SSL-Telnet Protocol <\/h2>\n\n\n\n
Software Prerequisites for StayLinked and TLS\/SSL-Telnet <\/h3>\n\n\n\n
TLS\/SSL Configuration for StayLinked Telnet Hosts <\/h3>\n\n\n\n
Well-known or Trusted CA Server Certificates <\/h3>\n\n\n\n
Private or Third-party Server Certificates <\/h3>\n\n\n\n
Client Certificates <\/h3>\n\n\n\n
The SSH Protocol <\/h2>\n\n\n\n
SSH Version Support<\/h3>\n\n\n\n
![\"\"](\"https:\/\/portal.staylinked.com\/sl\/kb\/wp-content\/uploads\/2019\/09\/Version_SSH_Supportby_SL.jpg\")
<\/figure>\n\n\n\n SSH Transport Algorithm Support <\/h3>\n\n\n\n
![\"\"](\"https:\/\/portal.staylinked.com\/sl\/kb\/wp-content\/uploads\/2020\/09\/Secure_Comm.01.jpg\")
<\/figure>\n\n\n\n
Encryption\/Cypher: <\/strong>aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
Data Integrity MAC:<\/strong> hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
Host Key Algorithm\/Public Key Authentication: <\/strong>ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512,rsa-sha2-256<\/p>\n\n\n\nSSH Authentication protocol Support <\/h3>\n\n\n\n
Keyboard-Interactive Authentication<\/h3>\n\n\n\n
Password Authentication<\/h3>\n\n\n\n
Public Key Authentication<\/strong><\/h3>\n\n\n\n
SSH Public Key Alias<\/strong> \u2013 Set this to the Alias of the Public\/Private key set in the Keystore File.
SSH Public Key Alias Password<\/strong> \u2013 Set this to the password of the Private key in the Keystore File if one is set.
SSH Public Keystore File Path<\/strong> \u2013 Set this to the location of the Keystore file on the server. It will look in \u2018..\/stay-linked\u2019 if only a filename is given.
SSH Public Keystore Password<\/strong> \u2013 Set this to the password of the Keystore file.<\/p>\n\n\n\nSecurity Diagram and Summary of Benefits <\/h2>\n\n\n\n
![\"\"](\"https:\/\/portal.staylinked.com\/sl\/kb\/wp-content\/uploads\/2019\/09\/SL-Security-Diagram.jpg\")
<\/figure>\n\n\n\nClient2Host\u00ae connections from the Client to the Server <\/h3>\n\n\n\n
Connections from the StayLinked Server to the Host Computer <\/h3>\n\n\n\n
StayLinked Administrator Secure Communications<\/h2>\n\n\n\n
StayLinked Administrator Communications Protocols <\/h3>\n\n\n\n
Configuring the StayLinked Server for a fixed TCP port range <\/h3>\n\n\n\n
\u2026<\/strong>
\u2026<\/strong><\/p>\n\n\n\n