KB Article #179399

ST security: Authentication and encryption with SSL/TLS

Authentication and encryption with SSL/TLS

This article will provide details about the usage of SSL/TLS in SecureTransport as well as explanation of several basic concepts of security.


Table of contents

  1. The SSL/TLS protocols
    1. Overview
    2. Handshake process
    3. Handshake details
    4. SSL/TLS session details
    5. Working with Wireshark to decode SSL/TLS session
    6. Collecting tcpdump
    7. Using OpenSSL as SSL/TLS client
  2. ST specific components
    1. HTTPD - for CITs using HTTPS
    2. FTPD - for CITs using FTPS
    3. AS2D - for CITs using HTTPS
    4. PESITD - for CITs using PeSIT over Secured Socket
    5. ADMIN - for administrators accessing the Admin UI over HTTPS
    6. TM - for SITs using HTTPS, FTPS, and PeSIT over Secured Socket
    7. Client Certificate Authentication for CITs and SITs
    8. TM - for internal communication (cluster, streaming, ICAP, Sentinel/Decision Insight, and LDAP)

1. The SSL/TLS protocols

SSL stands for Secure Sockets Layer and was originally created by Netscape. SSLv2 and SSLv3 are the 2 versions of this protocol. After SSLv3, SSL was renamed to TLS. TLS stands for Transport Layer Security and started with TLSv1 which is an upgraded version of SSLv3. Those protocols are standardized and described by RFCs. The latest standard version is TLSv1.2.


From the beginning SSLv2 showed some weaknesses and was deprecated shortly after the release of SSLv3. However, a few years ago some old servers still used SSLv2 record format during the initial handshake. For that reason, Oracle introduced SSLv2Hello in their Java. The SSLv2Hello is a pseudo-protocol which allows Java to initiate the handshake with an SSLv2 'hello message', but it does not lead to the use of the SSLv2 protocol, which is not supported by Java at all. Nowadays due to security reasons the support for SSLv2Hello is completely removed in most of the servers.


1.1. Overview

SSL/TLS is a subset of a few different protocols encapsulated in Record Protocol format. These protocols have a very specific purpose, and are used at different stages of the communication:


  • Handshake Protocol - It allows the peers to authenticate each other and to negotiate a cipher suite and other parameters of the connection. This article focuses mainly on this protocol and especially on the initial handshake.
  • ChangeCipherSpec Protocol - It makes the previously negotiated parameters effective, so communication becomes encrypted.
  • Alert Protocol - Used for communicating exceptions and indicating potential problems that may compromise security.
  • Application Data Protocol - It takes arbitrary data (application-layer data generally) and feeds it through the secure channel.


Record Protocol format is a header comprised of three fields:


  • Byte 0: TLS record type


 Record Type Values       dec      hex
 -------------------------------------
 CHANGE_CIPHER_SPEC        20     0x14
 ALERT                     21     0x15
 HANDSHAKE                 22     0x16
 APPLICATION_DATA          23     0x17


  • Bytes 1-2: TLS version (major/minor)


 Version Values            dec     hex
 -------------------------------------
 SSL 3.0                   3,0  0x0300
 TLS 1.0                   3,1  0x0301
 TLS 1.1                   3,2  0x0302
 TLS 1.2                   3,3  0x0303


  • Bytes 3-4: Length of data in the record (excluding the header itself). The maximum supported is 16384 (16K)


The Handshake Protocol is the most complex subprotocol within TLS. The specification focuses primarily on this, since it handles all the machinery necessary to establish a secure connection. There are 10 handshake message types in the TLS specification (not counting extensions). More details later. 


Handshake Type Values    dec      hex
 -------------------------------------
 HELLO_REQUEST              0     0x00
 CLIENT_HELLO               1     0x01
 SERVER_HELLO               2     0x02
 CERTIFICATE               11     0x0b
 SERVER_KEY_EXCHANGE       12     0x0c
 CERTIFICATE_REQUEST       13     0x0d
 SERVER_DONE               14     0x0e
 CERTIFICATE_VERIFY        15     0x0f
 CLIENT_KEY_EXCHANGE       16     0x10
 FINISHED                  20     0x14


The ChangeCipherSpec Protocol is the simplest protocol. It has only one message. The reason why this message must be a separate protocol instead of being part of the Handshake Protocol is because of the Record Layer encapsulation. The TLS protocol applies encryption to entire Record Layer messages at once. The ChangeCipherSpec message signals the activation of encryption, and since encryption cannot be applied to parts of a message it is impossible for any other message to follow a ChangeCipherSpec one.


The Alert Protocol is also rather simple. It defines two fields: severity level and alert description. The first field indicates the severity of the alert (1 for warning, 2 for fatal), while the second field encodes the exact condition. The supported alert descriptions depend on the SSL/TLS version. 


Alert severity               dec     hex
 ----------------------------------------
 WARNING                        1    0x01
 FATAL                          2    0x02



 TLS 1.0 Alert descriptions   dec     hex
 ----------------------------------------
 CLOSE_NOTIFY                   0    0x00
 UNEXPECTED_MESSAGE            10    0x0A
 BAD_RECORD_MAC                20    0x14
 DECRYPTION_FAILED             21    0x15
 RECORD_OVERFLOW               22    0x16
 DECOMPRESSION_FAILURE         30    0x1E
 HANDSHAKE_FAILURE             40    0x28
 NO_CERTIFICATE                41    0x29
 BAD_CERTIFICATE               42    0x2A
 UNSUPPORTED_CERTIFICATE       43    0x2B
 CERTIFICATE_REVOKED           44    0x2C
 CERTIFICATE_EXPIRED           45    0x2D
 CERTIFICATE_UNKNOWN           46    0x2E
 ILLEGAL_PARAMETER             47    0x2F
 UNKNOWN_CA                    48    0x30
 ACCESS_DENIED                 49    0x31
 DECODE_ERROR                  50    0x32
 DECRYPT_ERROR                 51    0x33
 EXPORT_RESTRICTION            60    0x3C
 PROTOCOL_VERSION              70    0x46
 INSUFFICIENT_SECURITY         71    0x47
 INTERNAL_ERROR                80    0x50
 USER_CANCELLED                90    0x5A
 NO_RENEGOTIATION             100    0x64


The Application Data Protocol is used to properly encapsulate the data coming from the Application Layer of the network stack, so it can seamlessly be handled by the underlying protocol (TCP) without forcing changes in any of those layers.


1.2. Handshake process

Every SSL/TLS connection begins with a handshake - the negotiation between two parties. The handshake determines what cipher suite will be used to encrypt their communications, verifies the server, and establishes that a secure connection is in place before beginning the actual transfer of data. The handshake itself uses asymmetric encryption – two separate keys are used, one public and one private. Thus, the public key is used for encryption and the private key for decryption during the handshake.


The Cipher suite defines a key exchange algorithm (KEX), a bulk encryption algorithm (symmetric one including secret key length), a Message Authentication Code (MAC) algorithm, and a Pseudo Random Function (PRF).


The first thing is to clarify who is the client and who is the server? The client is the one that initiates the connection and the server makes the decisions.


The below illustrates the SSL/TLS handshake process steps and messages exchanged during the handshake:

  1. Client Hello
  2. Server Hello, Server Certificate, Server Key Exchange (only for some key exchange methods), Certificate Request (optional), Server Hello Done
  3. Client Certificate (optional), Client Key Exchange, Certificate verify (optional)
  4. Change Cipher Spec (from client to server)
  5. Finished (from client to server)
  6. Change Cipher Spec (from server to client)
  7. Finished (from server to client)


The above represents a successful handshake. Any errors during the handshake are considered fatal and the communication drops before any user data transfer takes place. The best way to investigate issues during handshake is a network capture (tcpdump).


Wireshark is a network protocol analyzer used for network troubleshooting. Most of the screenshots of SSL/TLS messages in this article are decoded representations taken from Wireshark. The messages are generated mainly from SecureTransport application. When this was not possible messages were generated from OpenSSL. Network capture can be done either on the server or on the client side.


Each point presented above contains one or more messages usually sent in a single TCP/IP packet. Big SSL/TLS messages like the Server Certificate message will be split in multiple TCP/IP packets. When you decode the messages with Wireshark it looks like they belong to a single TCP/IP packet, but this is not the case. After the Change Cipher Spec message everything is encrypted. The Finished message is send encrypted. A Finished message is always sent immediately after a Change Cipher Spec message to verify that the key exchange and authentication processes were successful. Wireshark sometimes may decode this message wrongly - the Finished message appeared as Encrypted Handshake Message in Wireshark (see examples F1 and F2 below).


The most common scenario with the directions shown (C:Client and S:Server) is: 


C: Client Hello
S: Server Hello, Server Certificate, Server Hello Done
C: Client Key Exchange
C: Change Cipher Spec
C: Finished
S: Change Cipher Spec
S: Finished


Note that it is possible that all client messages (Client Key Exchange, Change Cipher Spec, and Finished) are delivered in a single TCP/IP packet. The same applies for the Server messages (Change Cipher Spec and Finished). This is application-specific and depends on the implementation in each application.


The following diagram represents the entire handshake process visually:



1.3. Handshake details

Client Hello


This message begins the SSL/TLS handshake negotiation. TLS versions TLSv1, TLSv1.1, and TLSv1.2, and SSLv3 use compatible Client Hello messages. SSLv2 uses a different format for the Client Hello message. Oracle introduced SSLv2Hello message in Java, which is like SSLv2 Client Hello. Since SSLv2 is not a subject of this article, you will find just a few examples of SSLv2 Client Hello and SSLv2Hello messages below and detailed analysis won't be provided.


Every SSL/TLS message is encapsulated in TLS Record Protocol called Record Layer in Wireshark. The record layer contains the TLS version which initially was intended to be the lowest version supported by the client, but in the practice this rule has never been followed. The client MAY send any SSL/TLS version (except SSLv2) in this field and the server MUST accept any value {0x03XX} as the record layer version number.



The client can also send a Client Hello in response to a Hello Request or on its own initiative to renegotiate the security parameters of an existing connection.


The Client Hello message contains:


  • Client TLS version - The highest SSL/TLS protocol version the client supports.
  • random number - A client-generated random structure. Contains the current time and date in standard UNIX 32-bit format, and random bytes generated by a secure random number generator.
  • Session ID - A variable-length session identifier. If not empty, the value identifies a session between the same client and server whose security parameters the client wishes to reuse. During the initial handshake the session ID is always empty (i.e. Session ID Length = 0).
  • Cipher suites list - An ordered list of cipher suites that the client was configured to support. The order represents the client's preference (favorite choice first).
  • Compression methods list - This is a list of the compression methods supported by the client, sorted by client preference. Value of null must always be present so that client and server will always be able to agree on a compression method.
  • Extensions - Clients MAY request extended functionality from servers by sending data in the extensions field. This is a property of TLS only. Most notably the server_name / Server Name Indication (SNI) extension is used to specify a remote host name. This allows the server to choose appropriate certificate based on the requested host name. With this extension one can host many SSL-enabled vhosts on a single IP address. The other important extension is renegotiation_info / Renegotiation Indication Extension. During the initial handshake for a connection the renegotiated_connection field is of zero length in Client Hello. Thus, the entire encoding of the extension is ff 01 00 01 00. Full list of supported extensions can be found at: IANA's page.


Examples for the Client Hello messages decoded with Wireshark.


Ex. C1: Client Hello message generated from ST 5.3.0 with default settings. Similar message generated from ST 5.2.1 SP4 with default settings. The default settings mean that the Https.SIT.EnabledProtocols is empty and Https.SIT.Ciphers is set with value TLS_RSA_WITH_AES_256_CBC_SHA. Even if the value of Https.SIT.Ciphers is empty we'll get a similar message.



Ex. C2: Client Hello message requesting TLSv1.2. Cipher suites list is limited intentionally for visibility. Note the TLSv1.1 before Record Layer highlighted below. This is the version chosen by the server for the entire handshake process and is not part of the data inside SSL/TLS message. Wireshark knows the whole flow and shows the version of the protocol which is used in the entire session.



Ex. C3: Client Hello message requesting TLSv1. The message has 26 cipher suites in the list, 2 compression methods and no extensions. Alert – Handshake Failure was generated by the server after this request, because the server was configured with cipher suites applicable only for TLSv1.2 (same as in example C5 below).



Ex. C4: Client Hello message requesting TLSv1.2.



Ex. C5: Client Hello message generated from ST 5.3.6 Patch 20 with default settings.



Ex. C6: Client Hello message generated from ST 5.3.6 Patch 20 with FIPS mode enabled.



Just a cipher suites list from previous Client Hello message.



Ex. C7: Client Hello message generated from ST 5.2.1 SP4 with FIPS mode enabled.



Ex. C8: Client Hello message generated from ST 5.3.0 with FIPS mode enabled.



Ex. C9: SSLv2Hello generated by ST 5.2.1 SP4. Note that the requested version is TLSv1.2 and the cipher suites which belong to TLS. Alert – Handshake Failure was generated by the server after this request, because the server did not like the Client Hello message format.



Ex. C10: SSLv2 Client Hello generated by OpenSSL. Alert – Handshake Failure was generated by the server after this request, because the server did not like the Client Hello message format and there was no common cipher suite.



Both the SSLv3 and TLSv1/TLSv1.1 specifications require implementations to ignore data following the Client Hello (i.e. extensions) if they do not understand it. However, some SSLv3 and TLSv1 implementations incorrectly fail the handshake in such a case. This means that clients that offer the renegotiation_info extension may encounter handshake failures. To enhance compatibility with such servers, RFC5746 defines a second signaling mechanism via a special Signaling Cipher Suite Value (SCSV) TLS_EMPTY_RENEGOTIATION_INFO_SCSV, with code point {0x00, 0xFF}. This SCSV is not a true cipher suite (it does not correspond to any valid set of algorithms) and cannot be negotiated. Instead, it has the same semantics as an empty renegotiation_info extension. Because SSLv3 and TLS implementations reliably ignore unknown cipher suites, the SCSV may be safely sent to any server. The SCSV can also be included in the SSLv2 backwards compatible Client Hello (see SSLv2Hello).


Note that the client MUST include either an empty renegotiation_info extension, or the TLS_EMPTY_RENEGOTIATION_INFO_SCSV signaling cipher suite value in the Client Hello. Including both is NOT recommended.


Alert - Handshake Failure


Based on the TLS version requested in the Client Hello or on the record layer format the server may reject the connection and return handshake failure alert. Then it closes the connection. Here is an example of such alert after SSLv2Hello in the above examples.



The server will send the same alert when there is no cipher suite in its lists that matched any of the cipher suites in the client list. Since the server makes all the decisions and the alert message is very simple, to find the root cause for the failure you will need application logs from the server.


Server Hello


The Server Hello message is very similar to the Client Hello message, with the exception that it only includes single Cipher Suite and single Compression method.


The Server Hello message contains:


  • TLS version - The server selects SSL/TLS protocol version which is lower of that suggested by the client in the Client Hello and the highest supported by the server. TLS versions TLSv1, TLSv1.1, and TLSv1.2, and SSLv3 are very similar, and use compatible Client Hello messages. Supporting all of them is relatively easy. Similarly, servers can easily handle clients trying to use future versions of TLS if the Client Hello format remains compatible, and the client supports the highest protocol version available in the server.
    • If the version chosen by the server is not supported by the client (or not acceptable), the client MUST send a protocol_version alert message and close the connection.
    • If the version chosen by the server is not supported by the client (or not acceptable), the client MUST send a protocol_version alert message and close the connection.
    • If a TLS server receives a Client Hello containing a version number greater than the highest version supported by the server, it MUST reply according to the highest version supported by the server. A TLS server can also receive a Client Hello containing a version number smaller than the highest supported version. If the server wishes to negotiate with old clients, it will proceed as appropriate for the highest version supported by the server that is not greater than client TLS version. For example, if the server supports TLSv1, TLSv1.1, and TLSv1.2, and client TLS version is TLSv1, the server will proceed with a TLSv1 Server Hello.
    • If server supports (or is willing to use) only versions greater than client TLS version, it MUST send a protocol_version alert message and close the connection.
  • random number - A server-generated random structure. Contains the current time and date in standard UNIX 32-bit format, and random bytes generated by a secure random number generator. The server random structure MUST be independently generated from the Client Hello.
  • Session ID - A variable-length session identifier. This is the identity of the session corresponding to this connection. For new connections the Session ID is not empty (i.e. Session ID Length > 0).
  • Cipher suite - The single cipher suite selected by the server from the Client Hello cipher suites list. For resumed sessions, this field is the value from the state of the session being resumed.
  • Compression method - The single compression algorithm selected by the server from the Client Hello compression methods list. For resumed sessions, this field is the value from the resumed session state.
  • Extensions - A list of extensions. This is a property of TLS only. Note that only extensions offered by the client can appear in the server's list. See more details in the Client Hello explanation above.


Examples for the Server Hello messages decoded with Wireshark


Ex. S1: Server Hello message as response to Client Hello from example C1.



Ex. S2: Server Hello message as response to Client Hello from example C2. Selected TLS version is TLSv1.1



Ex. S3: Server Hello message as response to Client Hello from example C5.


Server Certificate


The Server Certificate message contains the server's certificate chain starting from the server certificate, the intermediate CA certificates if they exist, and the root CA certificate, generally in X.509.v3 certificate format. This message will always immediately follow the Server Hello message. The certificate MUST be appropriate for the negotiated cipher suite's key exchange algorithm and any negotiated extensions. If the client provided a signature_algorithms extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension.


Examples for the Server Certificate messages decoded with Wireshark


Ex. R1: Server Certificate message from ST server configured with certificate from internal CA.




Ex. R2: Server Certificate message from ST server configured with certificate from public CA.




Server Key Exchange


The Server Key Exchange message will be sent immediately after the Server Certificate message only when the Server Certificate message does not contain enough data to allow the client to exchange a premaster secret. This is true for the following key exchange methods: DHE_DSS, DHE_RSA, and DH_anon. It is not legal to send the Server Key Exchange message for the following key exchange methods: RSA, DH_DSS, and DH_RSA. The format of keys exchange algorithm parameters depends exclusively on the selected Cipher Suite, which has been previously set by the server via the Server Hello message.


Example for the Server Key Exchange messages decoded with Wireshark



Certificate Request


A non-anonymous server can optionally request a certificate from the client, if appropriate for the selected cipher suite. This message, if sent, will immediately follow the Server Key Exchange message if it is sent. Otherwise, this message follows the Server Certificate message. The message not only asks the client for the certificate, it also tells which certificate types and signature algorithms are acceptable. In addition, it also indicates which Certificate Authorities are considered trustworthy.


Example for the Certificate Request messages decoded with Wireshark


Note that Distinguished names is a list of acceptable Certificate Authorities represented in DER-encoded format. In the example below only, a few entries are shown.



Server Hello Done


The Server Hello Done message is sent by the server to indicate the end of the Server Hello and associated messages. After sending this message, the server will wait for a client response.


Example for the Server Hello Done messages decoded with Wireshark


Upon receipt of the Server Hello Done message, the client SHOULD verify that the server provided a valid certificate, if required, and check that the Server Hello parameters are acceptable. If something is wrong the client returns handshake failure alert or error about server certificate like: bad_certificate, unsupported_certificate, certificate_revoked, certificate_expired, certificate_unknown, unknown_ca. Then it closes the connection.


Client Certificate


This is the first message the client can send after receiving a Server Hello Done message. This message is only sent if the server requests a certificate. If no suitable certificate is available, the client should send a no_certificate alert for SSLv3 and a certificate message containing no certificates for TLS. If the client does not send any certificates, the server MAY at its discretion either continue the handshake without client authentication or respond with a fatal handshake failure alert. Also, if some aspect of the certificate chain was unacceptable (e.g., it was not signed by a known, trusted CA), the server MAY at its discretion either continue the handshake or send a fatal alert.


This Client Certificate message conveys the client's certificate chain to the server. The end-entity certificate's public key and associated restrictions must be compatible with the certificate types listed in Certificate Request message. The Client Certificate message format is like the Server Certificate message.


Client Key Exchange


This message is always sent by the client. It MUST immediately follow the Client Certificate message, if it is sent. Otherwise, it MUST be the first message sent by the client after it receives the Server Hello Done message.


With this message, the premaster secret is set either by direct transmission of the RSA-encrypted secret or by the transmission of Diffie-Hellman parameters that will allow each side to agree upon the same premaster secret. The choice of messages depends on which public key algorithm has been selected. Details could be found in specifications.


Examples for the Client Key Exchange messages decoded with Wireshark


Ex. K1: Client Key Exchange message with RSA-encrypted secret.



Ex. K2: Client Key Exchange message with Diffie-Hellman parameters.



Certificate verify


This message is used by the client to prove the server that it possesses the private key corresponding to its public key certificate. The message holds hashed information digitally signed by the client. It is required if the server issued a Certificate Request to the client, so that it had to send a Client Certificate that needs to be verified. Once again, the exact size and structure of the information depends on the agreed algorithm.


Example for Certificate verify message decoded with Wireshark


Note that in below example all client TLS messages are send in a single TCP/IP packet. This is possible because the size of the certificate message is small enough.



Change Cipher Spec Protocol


The Change Cipher Spec Protocol was already explained in Overview. This is a single message to notify the receiving party that subsequent records will be protected under negotiated Cipher Suite and Compression Method.


Example of the Change Cipher Spec Protocol message decoded with Wireshark



Finished


This message signals that the TLS negotiation is complete, and the Cipher Suite is activated. It should be sent already encrypted, since the negotiation is successfully done, so a Change Cipher Spec Protocol message must be sent before this one to activate the encryption. The Finished message contains a hash of all previous handshake messages combined, followed by a special number identifying server/client role, the master secret and padding. The resulting hash is different from the Certificate Verify hash, since there have been more handshake messages.


If a Finished message is not preceded by a Change Cipher Spec Protocol message at the appropriate point in the handshake, this will trigger a fatal error.


Examples for Finished messages decoded with Wireshark


Ex. F1: Wireshark normally displays this as Encrypted Handshake Message.



Ex. F2: Wireshark sometimes may decode this message wrongly. See the two Hello Requests, but the length of the message is 40.



1.4. SSL/TLS session details

Application Data


Application data messages are carried by the record layer and are fragmented, compressed, and encrypted based on the current connection state. The messages are treated as transparent data to the record layer.


Examples for Application Data messages decoded with Wireshark


Ex. AD1: General Application Data message.



Ex. AD2: Application Data message for HTTPS.



Ex. AD3: Multiple Application Data messages could be delivered in a single TCP/IP packet. Note that each message has its own record layer header.



Resume previous session


The client sends a Client Hello using the Session ID of the session to be resumed. The server then checks its session cache for a match. If a match is found, and the server is willing to re-establish the connection under the specified session state, it will send a Server Hello with the same Session ID value. At this point, both client and server MUST send Change Cipher Spec messages and proceed directly to Finished messages.


Example for resume a previous session decoded with Wireshark 


C: Client Hello
S: Server Hello
S: Change Cipher Spec
S: Finished
C: Change Cipher Spec, Finished
C: Application Data



Session Ticket Resumption


Session resumption with Session IDs has a limitation. Servers are responsible for remembering negotiated TLS sessions for a given period. It poses scalability issues for servers with a large load of concurrent connections per second and for servers that want to cache sessions for a long time. Session ticket resumption is designed to address this issue.


The idea is to outsource session storage to clients. A session ticket is a blob of a session key and associated information encrypted by a key which is only known by the server. The ticket is sent by the server at the end of the TLS handshake. Clients supporting session tickets will cache the ticket along with the current session key information. Later the client includes the session ticket in the handshake message to indicate it wishes to resume the earlier session. The server on the other end will be able to decrypt this ticket, recover the session key and resume the session.


Encrypted Alerts


During the session everything is encrypted even the alerts. It is not possible to decode encrypted messages with tcpdump only. To investigate issues, you will need tcpdump and application logs from client and server side. Upon transmission or receipt of a fatal alert message, both parties immediately close the connection. Servers and clients MUST forget any session-identifiers, keys, and secrets associated with a failed connection. Thus, any connection terminated with a fatal alert MUST NOT be resumed.


Example for Encrypted Alert message decoded with Wireshark



Closing SSL/TLS session


The client and the server must share knowledge that the connection is ending to avoid a truncation attack. Either party may initiate the exchange of closing messages. Any data received after a closure alert is ignored. The close_notify alert is sent encrypted (see above).


1.5. Working with Wireshark to decode SSL/TLS session

If the connection is established on the default ports like 443 for HTTPS Wireshark directly decode the session properly. For any other ports you need to explicitly force Wireshark to decode the session.


Ex. WS1: Decoding an HTTPS session to the ST admin port 444


When you open tcpdump file with Wireshark you will see just a plain TCP session.



Right click on any row and select Decode As...



In the Value column select 444. In the Current column select SSL from the list. Click the OK button on the dialog box (not shown on the screenshot).



Now the session is properly decoded as TLSv1.2. The message number 4 with length 250 and data hash (196 bytes) from the screenshot above is now shown as Secure Socket Layer.



Ex. WS2: Decoding explicit FTPS on port 21


When you open tcpdump file with Wireshark you will see a plain TCP and FTP session. Note the FTP messages Response: 220 10.134.9.2 FTP server 5.3.3 ready., Request: AUTH TLS, and Response: 234 SSLv23/TLSv1.



FTP message server ready.



A Client Hello message decoded as FTP protocol message.



Right click on any row and select Decode As...



In the Value column select 21. In the Current column select SSL from the list. Click the OK button on the dialog box (not shown on the screenshot).



Now the FTP protocol messages are not decoded properly, but you can see the TLSv1.2 handshake after the 8-th frame (Response: 234 SSLv23/TLSv1 in original flow, length 84 in both original and decoded flows) from the screenshot above - it is now shown as Secure Socket Layer.



The FTP message "server ready" can not be decoded anymore.



The Client Hello message is now properly decoded. Note that this FTPS client supports SessionTicket TLS extension.



1.6. Collecting tcpdump


1.6.1 On Linux

On Linux, tcpdump is the most powerful and widely used command-line packet sniffer and package analyzer tool, which is used to capture or filter TCP/IP packets that were transferred over the network to/from a specific interface. It is available in most Linux/Unix distros. tcpdump also gives us option to save captured packets in a file for future analysis. It saves the file in a pcap format, that can be opened with tcpdump or with Wireshark.


By default tcpdump capture only 68 bytes of data from each packet. This is not enough to analyze SSL/TLS sessions and one has to capture the whole packets. For this purpos the command should be run with the -s 0 arguments.


By default tcpdump captures on all network interfaces except the loopback interface. If more than one network interface are available on the server, the command can be run for a specific NIC only, for example with the -i eth0 arguments.


By default tcpdump outputs the information in the console. Use option “write the raw packets to file”, with the -w /path/file.pcap arguments.


Example for tcpdump command: 


tcpdump -s 0 -w /path/file.pcap


or 


tcpdump -i eth0 -s 0 -w /path/file.pcap


eth0 here is the name of the interface from the output of ifconfig.


1.6.2 On Windows

Use Wireshark.


For the 1.x versions of Wireshark select the desired interface from Capture -> Interfaces... and click the Start button. Here is how the dialog looks like:



For the 2.x versions of Wireshark select desired interface from Capture -> Options... and click the start button. Here is how the dialog looks like:



1.7. Using OpenSSL as SSL/TLS client

1.7.1. General usage to connect to HTTPS servers 


openssl s_client -connect <IP address >:<Port>


Example output: 


# openssl s_client -connect 10.232.24.15:443
CONNECTED(00000003)
depth=1 CN = ST server CA, C = BG, O = Axway, OU = Axway, L = Sofia, serialNumber = 1b3ccf8ba1dbbec15b140ebb036250948d83e18412bbb072fa551f90790146f3
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
skipped certificate part
---
SSL handshake has read 15500 bytes and written 507 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 5A95839A431398C3013CE78C3E7220069B8BAE4FEA3A6C4CB4284D5B683F2764
    Session-ID-ctx:
    Master-Key: 272D6133607B67AA71B9A8FFDB616084EAECC29FDA1676DD7A4FF21D35BADB96320485A1B060B6D6121B66ECB578D92F
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1519747972
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
QUIT
DONE


1.7.2. To display the help 


openssl s_client -connect


Example: 


# openssl s_client -connect
usage: s_client args
 -host host     - use -connect instead
 -port port     - use -connect instead
 -connect host:port - who to connect to (default is localhost:4433)
 -verify arg   - turn on peer certificate verification
 -verify_return_error - return verification errors
 -cert arg     - certificate file to use, PEM format assumed
 -certform arg - certificate format (PEM or DER) PEM default
 -key arg      - Private key file to use, in cert file if
                 not specified but cert file is.
 -keyform arg  - key format (PEM or DER) PEM default
 -pass arg     - private key file pass phrase source
 -CApath arg   - PEM format directory of CA's
 -CAfile arg   - PEM format file of CA's
 -no_alt_chains - only ever use the first certificate chain found
 -reconnect    - Drop and re-make the connection with the same Session-ID
 -pause        - sleep(1) after each read(2) and write(2) system call
 -prexit       - print session information even on connection failure
 -showcerts    - show all certificates in the chain
 -debug        - extra output
 -msg          - Show protocol messages
 -nbio_test    - more ssl protocol testing
 -state        - print the 'ssl' states
 -nbio         - Run with non-blocking IO
 -crlf         - convert LF from terminal into CRLF
 -quiet        - no s_client output
 -ign_eof      - ignore input eof (default when -quiet)
 -no_ign_eof   - don't ignore input eof
 -psk_identity arg - PSK identity
 -psk arg      - PSK in hex (without 0x)
 -srpuser user     - SRP authentification for 'user'
 -srppass arg      - password for 'user'
 -srp_lateuser     - SRP username into second ClientHello message
 -srp_moregroups   - Tolerate other than the known g N values.
 -srp_strength int - minimal length in bits for N (default 1024).
 -ssl2         - just use SSLv2
 -ssl3         - just use SSLv3
 -tls1_2       - just use TLSv1.2
 -tls1_1       - just use TLSv1.1
 -tls1         - just use TLSv1
 -dtls1        - just use DTLSv1
 -fallback_scsv - send TLS_FALLBACK_SCSV
 -mtu          - set the link layer MTU
 -no_tls1_2/-no_tls1_1/-no_tls1/-no_ssl3/-no_ssl2 - turn off that protocol
 -bugs         - Switch on all SSL implementation bug workarounds
 -serverpref   - Use server's cipher preferences (only SSLv2)
 -cipher       - preferred cipher to use, use the 'openssl ciphers'
                 command to see what is available
 -starttls prot - use the STARTTLS command before starting TLS
                 for those protocols that support it, where
                 'prot' defines which one to assume.  Currently,
                 only "smtp", "pop3", "imap", "ftp" and "xmpp"
                 are supported.
 -engine id    - Initialise and use the specified engine
 -rand file:file:...
 -sess_out arg - file to write SSL session to
 -sess_in arg  - file to read SSL session from
 -servername host  - Set TLS extension servername in ClientHello
 -tlsextdebug      - hex dump of all TLS extensions received
 -status           - request certificate status from server
 -no_ticket        - disable use of RFC4507bis session tickets
 -nextprotoneg arg - enable NPN extension, considering named protocols supported (comma-separated list)
 -legacy_renegotiation - enable use of legacy renegotiation (dangerous)
 -use_srtp profiles - Offer SRTP key management with a colon-separated profile list
 -keymatexport label   - Export keying material using label
 -keymatexportlen len  - Export len bytes of keying material (default 20)


1.7.3. To connect to an explicit FTPS server 


openssl s_client -connect <IP address >:<Port> -starttls ftp


Example: 


# openssl s_client -connect 10.232.24.15:21 -starttls ftp
CONNECTED(00000003)
depth=1 CN = ST server CA, C = BG, O = Axway, OU = Axway, L = Sofia, serialNumber = 1b3ccf8ba1dbbec15b140ebb036250948d83e18412bbb072fa551f90790146f3
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
skipped certificate part
---
SSL handshake has read 15564 bytes and written 517 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 5A9586D53C7A93526AE1ECA0A7ECC721B24815DDFA15FA432BA5C9A99207A372
    Session-ID-ctx:
    Master-Key: EF709D0CC2B39762B9D70E5337D14583FCBF2BB347F143634E5F1E26BABB6C8534E6DC98D7FCFEEF3591830D37ADCCBF
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1519748800
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
220 10.232.24.15 FTP server 5.3.6 ready.
QUIT
DONE


1.7.4. Use a specific cipher suite (TLS_RSA_WITH_AES_256_CBC_SHA) 


openssl s_client -cipher AES256-SHA -connect <IP address >:<Port>


Example: 


# openssl s_client -cipher AES256-SHA -connect 10.232.24.15:443
CONNECTED(00000003)
depth=1 CN = ST server CA, C = BG, O = Axway, OU = Axway, L = Sofia, serialNumber = 1b3ccf8ba1dbbec15b140ebb036250948d83e18412bbb072fa551f90790146f3
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
skipped certificate part
---
SSL handshake has read 15111 bytes and written 453 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES256-SHA
    Session-ID: 5A95877487C93A328B693FCB355EF5BA17B7B4CC8F321F26C63AAADCB6EA7173
    Session-ID-ctx:
    Master-Key: 5D4E94ED45ABC794148773F92752A829ECA82961777B830BE916FE4837C5AE3B5A7676E223F8BB063A4FD98AEB567250
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1519748959
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
QUIT
DONE


1.7.5. Use a specific SSL/TLS version (TLSv1.1) 


openssl s_client -tls1_1 -connect <IP address >:<Port>


Example: 


# openssl s_client -tls1_1 -connect 10.232.24.15:443
CONNECTED(00000003)
depth=1 CN = ST server CA, C = BG, O = Axway, OU = Axway, L = Sofia, serialNumber = 1b3ccf8ba1dbbec15b140ebb036250948d83e18412bbb072fa551f90790146f3
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
skipped certificate part
---
SSL handshake has read 15083 bytes and written 551 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : AES256-SHA
    Session-ID: 5A95882147A4D65B3CDE2915254296E0EFA8FEB52D1E3C658FD872A2BE84E753
    Session-ID-ctx:
    Master-Key: 21E142C47FBCF4C63AECB5D7C7864322BE4C99360FA00685CD963B02AB67B420DD9E4C35577F48BE45E405D16E25D701
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1519749131
    Timeout   : 7200 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
QUIT
DONE


1.7.6. Use any SSL/TLS version except specified (turn off TLSv1.1): 


openssl s_client -no_tls1_1 -connect <IP address >:<Port>


Keep in mind that OpenSSL is a smart tool. When you turn off TLSv1.1 since we have a gap in versions it attempts to negotiate TLSv1. Example: 


# openssl s_client -no_tls1_1 -connect 10.232.24.15:443
CONNECTED(00000003)
depth=1 CN = ST server CA, C = BG, O = Axway, OU = Axway, L = Sofia, serialNumber = 1b3ccf8ba1dbbec15b140ebb036250948d83e18412bbb072fa551f90790146f3
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
skipped certificate part
---
SSL handshake has read 15067 bytes and written 535 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 5A9588EC6AA68B871E9957765FCCC8FD6380BE601D4572211095D566A2D6A1B5
    Session-ID-ctx:
    Master-Key: C862F20074FFDCDBE89813F3697FBE9443BCD8390FCC175C6B8F9666FA44C16F828E7235FD840A47464573A229ABEF1B
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1519749334
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
QUIT
DONE


1.7.7. Get a list of supported cipher suites 


openssl ciphers


Example: 


# openssl ciphers
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:SRP-3DES-EDE-CBC-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA


1.7.8. Display the OpenSSL product version 


openssl version


Example: 


# openssl version
OpenSSL 1.0.1t  3 May 2016


Good resources for cipher suites, OpenSSL and cipher names mapping


Known cipher suites - https://www.thesprawl.org/research/tls-and-ssl-cipher-suites


A full list of registered cipher suites from IANA - https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4


OpenSSL ciphers - https://www.openssl.org/docs/man1.1.1/man1/openssl-ciphers.html


OpenSSL vs RFC names mapping - https://testssl.sh/openssl-rfc.mapping.html


2. ST specific components

The SSL/TLS protocols are widely used in ST to secure the communication in the following components:


  • HTTPD - for CITs using HTTPS
  • FTPD - for CITs using FTPS
  • AS2D - for CITs using HTTPS
  • PESITD - for CITs using PeSIT over Secured Socket
  • ADMIN - for administrators to access Admin UI using HTTPS
  • TM - for SITs using HTTPS, FTPS, and PeSIT over Secured Socket
  • TM - for internal communication (cluster, streaming, ICAP, Sentinel/Decision Insight, and LDAP).


The explanations below are applicable to (tested with) the currently widely used ST version with the latest patch available at end of April 2018. This version is ST 5.3.6 Patch 30. If a different patch level of ST 5.3.6 was used in some tests, this will be specified in the respective sections.


Testing tools

The tests were performed with the following tools:


  1. For CITs
    1. OpenSSL 1.0.1t 3 May 2016. A custom shell script was used to test all cipher suites individually and for each SSL/TLS version. The results show cipher suites names following the OpenSSL naming convention. The script is attached to the article for demonstration purposes, but please use it on your own risk.
    2. A dotNET application called TestSSLServer compiled on Windows 7 from the following link: https://github.com/pornin/TestSSLServer/. The results show cipher suites names following the RFC naming convention. The results from this tool were used in this article.
    3. curl 7.38.0. Used to test some corner cases to make sure the above tools are working consistently and properly.
    4. Mozilla Firefox 59.0.2. Used to test some corner cases to make sure the above tools are working consistently and properly. The results are checked via tcpdump.
  2. For SITs for a partner server were used
    1. ST 5.3.6 Patch 30, ST 5.3.6 Patch 8, and ST 5.3.6
    2. OpenSSL 1.0.1t 3 May 2016. Configured as per instructions from link: https://blog.jorisvisscher.com/2015/07/22/create-a-simple-https-server-with-openssl-s_server/


The OpenSSL HTTPS server configuration was done as follows:


First generate a certificate with command (follow the prompts): 


openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 –nodes


Alternatively you could generate certificate containing DSA key with commands: 


openssl dsaparam 3072 -out params.pem

openssl gendsa -out keydsa.pem params.pem

openssl req -new -key keydsa.pem -out reqdsa.pem

openssl x509 -req -in reqdsa.pem -signkey keydsa.pem -out certdsa.pem


Second start the server with command: 


openssl s_server -key key.pem -cert cert.pem -accept 44330 -www


If you generated DSA certificate you could start the server with command: 


openssl s_server -key keydsa.pem -cert certdsa.pem -accept 44330 -www


Here is a list of supported cipher suites (OpenSSL naming convention): 


s_server -key key.pem -cert cert.pem -accept 44330 -www 
Secure Renegotiation IS supported
Ciphers supported in s_server binary
TLSv1/SSLv3:ECDHE-RSA-AES256-GCM-SHA384TLSv1/SSLv3:ECDHE-ECDSA-AES256-GCM-SHA384
TLSv1/SSLv3:ECDHE-RSA-AES256-SHA384  TLSv1/SSLv3:ECDHE-ECDSA-AES256-SHA384
TLSv1/SSLv3:ECDHE-RSA-AES256-SHA     TLSv1/SSLv3:ECDHE-ECDSA-AES256-SHA   
TLSv1/SSLv3:SRP-DSS-AES-256-CBC-SHA  TLSv1/SSLv3:SRP-RSA-AES-256-CBC-SHA  
TLSv1/SSLv3:SRP-AES-256-CBC-SHA      TLSv1/SSLv3:DHE-DSS-AES256-GCM-SHA384
TLSv1/SSLv3:DHE-RSA-AES256-GCM-SHA384TLSv1/SSLv3:DHE-RSA-AES256-SHA256    
TLSv1/SSLv3:DHE-DSS-AES256-SHA256    TLSv1/SSLv3:DHE-RSA-AES256-SHA       
TLSv1/SSLv3:DHE-DSS-AES256-SHA       TLSv1/SSLv3:DHE-RSA-CAMELLIA256-SHA  
TLSv1/SSLv3:DHE-DSS-CAMELLIA256-SHA  TLSv1/SSLv3:ECDH-RSA-AES256-GCM-SHA384
TLSv1/SSLv3:ECDH-ECDSA-AES256-GCM-SHA384TLSv1/SSLv3:ECDH-RSA-AES256-SHA384   
TLSv1/SSLv3:ECDH-ECDSA-AES256-SHA384 TLSv1/SSLv3:ECDH-RSA-AES256-SHA      
TLSv1/SSLv3:ECDH-ECDSA-AES256-SHA    TLSv1/SSLv3:AES256-GCM-SHA384        
TLSv1/SSLv3:AES256-SHA256            TLSv1/SSLv3:AES256-SHA               
TLSv1/SSLv3:CAMELLIA256-SHA          TLSv1/SSLv3:PSK-AES256-CBC-SHA       
TLSv1/SSLv3:ECDHE-RSA-AES128-GCM-SHA256TLSv1/SSLv3:ECDHE-ECDSA-AES128-GCM-SHA256
TLSv1/SSLv3:ECDHE-RSA-AES128-SHA256  TLSv1/SSLv3:ECDHE-ECDSA-AES128-SHA256
TLSv1/SSLv3:ECDHE-RSA-AES128-SHA     TLSv1/SSLv3:ECDHE-ECDSA-AES128-SHA   
TLSv1/SSLv3:SRP-DSS-AES-128-CBC-SHA  TLSv1/SSLv3:SRP-RSA-AES-128-CBC-SHA  
TLSv1/SSLv3:SRP-AES-128-CBC-SHA      TLSv1/SSLv3:DHE-DSS-AES128-GCM-SHA256
TLSv1/SSLv3:DHE-RSA-AES128-GCM-SHA256TLSv1/SSLv3:DHE-RSA-AES128-SHA256    
TLSv1/SSLv3:DHE-DSS-AES128-SHA256    TLSv1/SSLv3:DHE-RSA-AES128-SHA       
TLSv1/SSLv3:DHE-DSS-AES128-SHA       TLSv1/SSLv3:DHE-RSA-SEED-SHA         
TLSv1/SSLv3:DHE-DSS-SEED-SHA         TLSv1/SSLv3:DHE-RSA-CAMELLIA128-SHA  
TLSv1/SSLv3:DHE-DSS-CAMELLIA128-SHA  TLSv1/SSLv3:ECDH-RSA-AES128-GCM-SHA256
TLSv1/SSLv3:ECDH-ECDSA-AES128-GCM-SHA256TLSv1/SSLv3:ECDH-RSA-AES128-SHA256   
TLSv1/SSLv3:ECDH-ECDSA-AES128-SHA256 TLSv1/SSLv3:ECDH-RSA-AES128-SHA      
TLSv1/SSLv3:ECDH-ECDSA-AES128-SHA    TLSv1/SSLv3:AES128-GCM-SHA256        
TLSv1/SSLv3:AES128-SHA256            TLSv1/SSLv3:AES128-SHA               
TLSv1/SSLv3:SEED-SHA                 TLSv1/SSLv3:CAMELLIA128-SHA          
TLSv1/SSLv3:PSK-AES128-CBC-SHA       TLSv1/SSLv3:ECDHE-RSA-RC4-SHA        
TLSv1/SSLv3:ECDHE-ECDSA-RC4-SHA      TLSv1/SSLv3:ECDH-RSA-RC4-SHA         
TLSv1/SSLv3:ECDH-ECDSA-RC4-SHA       TLSv1/SSLv3:RC4-SHA                  
TLSv1/SSLv3:RC4-MD5                  TLSv1/SSLv3:PSK-RC4-SHA              
TLSv1/SSLv3:ECDHE-RSA-DES-CBC3-SHA   TLSv1/SSLv3:ECDHE-ECDSA-DES-CBC3-SHA 
TLSv1/SSLv3:SRP-DSS-3DES-EDE-CBC-SHA TLSv1/SSLv3:SRP-RSA-3DES-EDE-CBC-SHA 
TLSv1/SSLv3:SRP-3DES-EDE-CBC-SHA     TLSv1/SSLv3:EDH-RSA-DES-CBC3-SHA     
TLSv1/SSLv3:EDH-DSS-DES-CBC3-SHA     TLSv1/SSLv3:ECDH-RSA-DES-CBC3-SHA    
TLSv1/SSLv3:ECDH-ECDSA-DES-CBC3-SHA  TLSv1/SSLv3:DES-CBC3-SHA             
TLSv1/SSLv3:PSK-3DES-EDE-CBC-SHA     
---


Important Note: DSS cipher suites require a certificate containing DSA key and RSA cipher suites require a certificate containing RSA key. Server reports both types (DSS and RSA) of cipher suites as supported. Standard web browsers like Internet Explorer (does not like certificate with DSA key), Firefox (use only RSA cipher suites), and Google Chrome (use only RSA cipher suites) could not establish HTTPS connection to OpenSSL HTTPS server running with certificate containing DSA key.


The configuration of SSL/TLS in ST can be a complex task. The reason for this are the multiple layers within the application that affect the final configuration.


The first (lower) layer is the Java Virtual Machine (JVM). Current ST versions use Java 8, more precisely the Java SE Runtime Environment 8 also known as JRE 1.8.0. Java sets a major limitation of the available security providers, cipher suites, security algorithms (for encryption, hashing, and digital signature), key sizes, and SSL/TLS protocol versions. The description of the default settings and limits can be found on Oracle's page at the following link: https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html


On AIX platform the only supported JVM is IBM Java. There is a difference in the implementation and security providers between the Oracle's and IBM's Java. This result in a different list of ciphers suites and cipher names may also differ. Here is a link to IBM documentation about known differences: https://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/knowndiffsun.html?view=embed


The tests and explanations below are applicable to Oracle's Java.


Java 7 security limitations

Note that the following cipher suites are not supported in Java 7, which means that SecureTransport versions below ST 5.3.0 will not support them as well.


Cipher Suite Cipher Suite Name (RFC) Cipher Suite Name (OpenSSL) KEx Encr Bits
[0x9c] TLS_RSA_WITH_AES_128_GCM_SHA256 AES128-GCM-SHA256 RSA AESGCM 128
[0x9d] TLS_RSA_WITH_AES_256_GCM_SHA384 AES256-GCM-SHA384 RSA AESGCM 256
[0x9e] TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 DHE-RSA-AES128-GCM-SHA256 DH AESGCM 128
[0x9f] TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 DHE-RSA-AES256-GCM-SHA384 DH AESGCM 256
[0xa2] TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 DHE-DSS-AES128-GCM-SHA256 DH AESGCM 128
[0xa3] TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 DHE-DSS-AES256-GCM-SHA384 DH AESGCM 256
[0xa6] TLS_DH_anon_WITH_AES_128_GCM_SHA256 ADH-AES128-GCM-SHA256 DH AESGCM 128
[0xa7] TLS_DH_anon_WITH_AES_256_GCM_SHA384 ADH-AES256-GCM-SHA384 DH AESGCM 256
[0xc02b] TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 ECDH AESGCM 128
[0xc02c] TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDHE-ECDSA-AES256-GCM-SHA384 ECDH AESGCM 256
[0xc02d] TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 ECDH-ECDSA-AES128-GCM-SHA256 ECDH/ECDSA AESGCM 128
[0xc02e] TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 ECDH-ECDSA-AES256-GCM-SHA384 ECDH/ECDSA AESGCM 256
[0xc02f] TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDH AESGCM 128
[0xc030] TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDHE-RSA-AES256-GCM-SHA384 ECDH AESGCM 256
[0xc031] TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 ECDH-RSA-AES128-GCM-SHA256 ECDH/RSA AESGCM 128
[0xc032] TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 ECDH-RSA-AES256-GCM-SHA384 ECDH/RSA AESGCM 256


Java security settings

In ST, Java's security parameters can be modified globally via the java.security file located in <FILEDRIVEHOME>/jre/lib/security. The settings in the file control the security implementaion on the lowest level and have global effect on all JVMs. The most important are 3 parameters that widely affect SSL/TLS settings:


Algorithm restrictions for certification path via parameter jdk.certpath.disabledAlgorithms. This parameter affects certificates installed in ST and can prevent usage of a certificates which utilize algorithms disabled by this parameter. The default value in ST JRE is: 


jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \
    RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224


Algorithm restrictions for SSL/TLS processing via parameter jdk.tls.disabledAlgorithms. Disabled algorithms will not be negotiated for SSL/TLS connections, even if they are enabled explicitly in ST application. The default value in ST JRE is: 


jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, \
       EC keySize < 224


Legacy algorithms for SSL/TLS processing in JSSE implementation. During SSL/TLS security parameters negotiation, legacy algorithms will not be negotiated unless there are no other candidates. The default value in ST JRE is: 


jdk.tls.legacyAlgorithms= \
        K_NULL, C_NULL, M_NULL, \
        DHE_DSS_EXPORT, DHE_RSA_EXPORT, DH_anon_EXPORT, DH_DSS_EXPORT, \
        DH_RSA_EXPORT, RSA_EXPORT, \
        DH_anon, ECDH_anon, \
        RC4_128, RC4_40, DES_CBC, DES40_CBC, \
        3DES_EDE_CBC


Important Note: SSLv3 protocol version is disabled globally as per default settings in the java.security file presented above. Java 8 does not support SSLv2 protocols at all.


Another way to modify the Java settings globally is to add parameter to the JAVA_OPTS string in JVM startup script. This method is used for number of important settings described below:


The parameter jsse.enableCBCProtection=false disables a fix for the BEAST attack vulnerability which was causing compatibility issues with some SSL/TLS implementations. For details see the following KB article: KB 176175


Increase the session key size for the Diffie-Hellman key exchange for HTTP, FTP, and AS2. For details see the following KB article: KB 177976


Set debugging for the SSL/TLS protocol. In article KB176175 mentioned above it was explained how to setup SSL/TLS debugging for the TM server. The debug output is usually sent to the console, and the TM server redirects the console output to the file tm.stdout.log located in <FILEDRIVEHOME>/var/logs. As a result, you can start the TM either from the Admin UI ir from the console, and the service will work properly.


However, this does not apply for the other protocol daemons (HTTP, FTP, AS2, etc.) and the daemon must be started with the startup script from the consolse of the server. If you start the daemon from Admin UI it will not start properly and will not be operational.


Example how to set SSL/TLS debugging for HTTPD:


Add one of the following two lines in the startup script start_httpd located in the <FILEDRIVEHOME>/bin directory. 


JAVA_OPTS="-Djavax.net.debug=all $JAVA_OPTS"


or 


JAVA_OPTS="-Djavax.net.debug=ssl:handshake $JAVA_OPTS"


You should add the line somewhere after configurate_JVM_opts_os_signals and before JAVA="${JAVA_HOME}/bin/java". As explained above you should start the HTTP service from the OS console executing <FILEDRIVEHOME>/bin/start_httpd. The debug output appears in the same OS console and is huge. This kind of debugging is for short term usage usually in a test environment and not intended for production servers./


Third party libraries

The second (middle) layer is a third party library which is used in ST for services like Tomcat (for Admin UI and AS2D), Jetty (for HTTPD), Apache MINA (for FTPD), and Netty (for PESITD). These third party libraries may add or remove features on top of the default Java classes and can limit the usage of some cipher suites or SSL/TLS protocol versions. Usually these libraries are configured by ST application via exposed API interfaces, but that is not always the case. The Tomcat server for example has its own configuration in an XML file, which is not accessible via the Admin UI. The default configuration allows only TLSv1.2 protocol.


To enable TLSv1.1 and TLSv1 protocol for the admin service (Admin UI) you should follow the instructions from the following KB article: KB 179017


To enable SSLv2Hello and/or TLSv1 for Admin UI follow the instructions from the following article: KB 178079


ST application settings

The third (upper) layer is the ST application itself. The SSL/TLS configuration for each component includes Certificate, FIPS Transfer Mode or enabledProtocols and enabledCipherSuites from server configuration. FIPS Transfer Mode use a predefined set of cipher suites and enabled SSL/TLS protocol versions as per FIPS standards. In this mode server configuration parameters are ignored. There is one parameter in the Server Configuration page which affects FIPS Transfer Mode and can control which SSL/TLS protocol versions are enabled for FIPS mode. The name of the parameter is FIPS.DisabledProtocols and it has default value equal to TLSv1.


The default settings for each ST component and some specific settings and behavior are explained below:


HTTPD


The certificate and Enable FIPS Transfer Mode could be set from Server Control page of Admin UI. Changes require restart of the daemon.



With FIPS Transfer Mode enabled the following cipher suites and TLS versions are negotiable: 


  TLSv1.1:
     server selection: complex
     3-- (key:  RSA)  RSA_WITH_3DES_EDE_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_3DES_EDE_CBC_SHA
     3-- (key:  RSA)  RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_CBC_SHA
     3-- (key:  RSA)  RSA_WITH_AES_256_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_CBC_SHA
  TLSv1.2:
     server selection: complex
     3-- (key:  RSA)  RSA_WITH_3DES_EDE_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_3DES_EDE_CBC_SHA
     3-- (key:  RSA)  RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_CBC_SHA
     3-- (key:  RSA)  RSA_WITH_AES_256_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_CBC_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_CBC_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_GCM_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_GCM_SHA384
     3f- (key:  RSA)  ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_CBC_SHA256
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_CBC_SHA384
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_GCM_SHA256
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_GCM_SHA384


With FIPS Transfer Mode disabled the applicable server configuration parameters are Http.Ssl.Protocols and Http.Ssl.EnabledCipherSuites. Changes are applied dynamically (no restart needed). The default settings are:


For Http.Ssl.Protocols: TLSv1, TLSv1.1, TLSv1.2


For Http.Ssl.EnabledCipherSuites: 

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_EMPTY_RENEGOTIATION_INFO_SCSV


The following cipher suites and TLS versions are negotiable: 


  TLSv1.2:
     server selection: uses client preferences
     3-- (key:  RSA)  RSA_WITH_AES_256_CBC_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_CBC_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_CBC_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_GCM_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_GCM_SHA384
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_CBC_SHA256
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_CBC_SHA384
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_GCM_SHA256
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_GCM_SHA384


If we add the TLSv1 cipher suite TLS_RSA_WITH_AES_256_CBC_SHA to the Http.Ssl.EnabledCipherSuites default list, the result is: 


    TLSv1.0:
     server selection: uses client preferences
     3-- (key:  RSA)  RSA_WITH_AES_256_CBC_SHA
  TLSv1.1: idem
  TLSv1.2:
     server selection: uses client preferences
     3-- (key:  RSA)  RSA_WITH_AES_256_CBC_SHA
     3-- (key:  RSA)  RSA_WITH_AES_256_CBC_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_CBC_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_CBC_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_GCM_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_GCM_SHA384
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_CBC_SHA256
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_CBC_SHA384
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_GCM_SHA256
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_GCM_SHA384


If the value of parameter Http.Ssl.EnabledCipherSuites is empty the result is: 


  TLSv1.0:
     server selection: complex
     3-- (key:  RSA)  RSA_WITH_3DES_EDE_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_3DES_EDE_CBC_SHA
     3-- (key:  RSA)  RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_CBC_SHA
     3-- (key:  RSA)  RSA_WITH_AES_256_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_CBC_SHA
  TLSv1.1: idem
  TLSv1.2:
     server selection: complex
     3-- (key:  RSA)  RSA_WITH_3DES_EDE_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_3DES_EDE_CBC_SHA
     3-- (key:  RSA)  RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_CBC_SHA
     3-- (key:  RSA)  RSA_WITH_AES_256_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_CBC_SHA
     3-- (key:  RSA)  RSA_WITH_AES_128_CBC_SHA256
     3-- (key:  RSA)  RSA_WITH_AES_256_CBC_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_CBC_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_CBC_SHA256
     3-- (key:  RSA)  RSA_WITH_AES_128_GCM_SHA256
     3-- (key:  RSA)  RSA_WITH_AES_256_GCM_SHA384
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_GCM_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_GCM_SHA384
     3f- (key:  RSA)  ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_CBC_SHA256
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_CBC_SHA384
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_GCM_SHA256
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_GCM_SHA384


Conclusion: With default setting only TLSv1.2 is negotiable because the lists of configured cipher suites are applicable only for this protocol version. The TLS server assigns cipher suite as per client preference when not in FIPS Transfer Mode and the value of Http.Ssl.EnabledCipherSuites is not empty. Server configuration parameters are applied dynamically. Changing FIPS Transfer Mode requires restart.


FTPD


The certificate and Enable FIPS Transfer Mode can be set from Server Control page of Admin UI.



With FIPS Transfer Mode enabled the results are exactly the same as for HTTPD and AS2D.


With FIPS Transfer Mode disabled the applicable server configuration parameters are Ftp.Listeners.Ssl.enabledProtocols and Ftp.Listeners.Ssl.enabledCipherSuites. Changes are applied dynamically (no restart needed). The two parameters have the same default values as for HTTPD and AS2D and the results from the tests are the same. The difference is when we set empty value for parameter Ftp.Listeners.Ssl.enabledCipherSuites. The result with empty value is that we could not negotiate any cipher suite and FTPS connection is not possible at all.


AS2D


The certificate and Enable FIPS Transfer Mode can be set from Server Control page of Admin UI.



With FIPS Transfer Mode enabled the results are exactly the same as for HTTPD (see above).


With FIPS Transfer Mode disabled the applicable server configuration parameters are As2.Listeners.Ssl.protocols and As2.Listeners.Ssl.enabledCipherSuites. Changes require restart of the daemon. The two parameters have the same default values as for HTTPD and the results from the tests are the same. The difference is when we set empty value for parameter As2.Listeners.Ssl.enabledCipherSuites. The result with empty value is: 


  TLSv1.0:
     server selection: complex
     3f- (key:  RSA)  DHE_RSA_WITH_3DES_EDE_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_CBC_SHA
  TLSv1.1: idem
  TLSv1.2:
     server selection: complex
     3f- (key:  RSA)  DHE_RSA_WITH_3DES_EDE_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_CBC_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_CBC_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_GCM_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_GCM_SHA384
     3f- (key:  RSA)  ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_CBC_SHA256
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_CBC_SHA384
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_GCM_SHA256
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_GCM_SHA384


PESITD


The certificate and Enable FIPS Transfer Mode could be set from Server Control page of Admin UI.



With FIPS Transfer Mode enabled the results are exactly the same as for HTTPD, AS2D and FTPD.


With FIPS Transfer Mode disabled the applicable server configuration parameters are Pesit.Listeners.Ssl.enabledProtocols and Pesit.Listeners.Ssl.enabledCipherSuites. Changes require restart of the daemon. The two parameters have the same default values as for HTTPD, AS2D, and FTPD and the results from the tests are the same. The difference is when we set empty value for parameter Pesit.Listeners.Ssl.enabledCipherSuites. The result with empty value is that we could not initiate a handshake. It is not SSL/TLS socket.


ADMIN


The certificate is set in Admin UI -> Setup -> Certificates -> Local Certificates and has alias name admind. To change the certificate a new one must be created or imported with the same alias, overwriting the existing certificate. Changes require restart of the daemon. Make sure when you change the admin certificate that new one is valid and chained to a trusted root. Tomcat has no FIPS Transfer Mode setting. TLS protocol versions are controlled from a file <FILEDRIVEHOME>/tomcat/admin/conf/server.xml. Cipher suites are set from server configuration parameter Admin.EnabledCipherSuites. Changes require restart of the admin server. The default value is the same as all other protocols daemons and includes only TLSv1.2 cipher suites. Here is the list of enabled cipher suites: 


TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00a3)
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2)
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)


To enable TLSv1 and TLSv1.1 for the Admin UI all that's needed is to add cipher suites applicable for these versions like the list below: 


TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)


If the value of the parameter Admin.EnabledCipherSuites is empty the result is: 


  TLSv1.0:
     server selection: complex
     3f- (key:  RSA)  DHE_RSA_WITH_3DES_EDE_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_CBC_SHA
  TLSv1.1: idem
  TLSv1.2:
     server selection: complex
     3f- (key:  RSA)  DHE_RSA_WITH_3DES_EDE_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_CBC_SHA
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_CBC_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_CBC_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_128_GCM_SHA256
     3f- (key:  RSA)  DHE_RSA_WITH_AES_256_GCM_SHA384
     3f- (key:  RSA)  ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_CBC_SHA
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_CBC_SHA256
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_CBC_SHA384
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_GCM_SHA256
     3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_GCM_SHA384


TM for SITs


When ST acts as a client for establishing SSL/TLS communication with partner servers the Transaction Manager is one making it. The client certificate and Enable FIPS Transfer Mode could be set for each Transfer Site in its configuration page. The Server Configuration page has a pair parameters for each protocol (HTTPS. FTPS, AS2, and PeSIT) one for EnabledProtocols and the other for Ciphers. Here is the list of these parameters: 


As2.SIT.Ciphers
As2.SIT.EnabledProtocols
Ftps.SIT.Ciphers
Ftps.SIT.EnabledProtocols
Https.SIT.Ciphers
Https.SIT.EnabledProtocols
Pesit.SIT.Ciphers
Pesit.SIT.enabledProtocols


Changes are applied dynamically (no restart needed). The default values for SIT.EnabledProtocols is empty for AS2, FTPS, and HTTPS and have value of TLSv1, TLSv1.1, TLSv1.2 for PeSIT (see screenshot below). The default value is the same for all SIT.Ciphers and list of the cipher suites is the same as for all protocol daemons and Admin UI. TM starts negotiation with TLSv1.2 protocol with the default list of cipher suites. The default list could be found in description of ADMIN or HTTPD above and on the screenshot below:



Note that SIT.Ciphers are ordered lists and represent client preference. TLS servers usually choose cipher suite from the client preference list. For maximum security cipher suites must be ordered so that the strongest appears on top and weaker (less secure) on the bottom.


HTTP(S) and AS2 for SITs


For HTTPS and AS2 transfers the TM uses a third party library called apache.http.


For HTTP(S) and AS2 transfers TM starts negotiation with TLSv1.2 protocol. If the value of the parameter Https.SIT.Ciphers or As2.SIT.Ciphers is empty the TM would use the value configured in the parameter Tm.CipherSuites. The default value of Tm.CipherSuites contains only one cipher which is TLS_RSA_WITH_AES_256_CBC_SHA256. With FIPS Transfer Mode enabled TM initiates the connection with TLSv1.2 and uses the following list of cipher suites (38): 


TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00a3)
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2)
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003)
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)


FTP(S) for SITs


For FTPS transfers TM use third party library called Jscape.


For FTP(S) transfers the TM starts the negotiation with TLSv1.2. If the value of the parameter Ftps.SIT.Ciphers is empty the TM would use the following list of cipher suites (50): 


TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xc026)
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xc02a)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005)
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025)
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02e)
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 (0xc032)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00a3)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02d)
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xc031)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2)
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003)
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d)
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)


With FIPS Transfer Mode enabled TM initiates the connection first with TLSv1.2 and uses the following list of cipher suites (38): 


TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00a3)
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2)
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003)
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)


During the handshake after the Server Hello message the TM closes the connection with fatal alert Certificate Unknown (46). The reason for that is the problem with certificate which the FTPS server presents. The FTPS server certificate has a signature algorithm md5WithRSAEncryption. The algorithm MD5withRSA is globally disabled via the parameter jdk.tls.disabledAlgorithms in the java.security file. There is an error message in Admin UI with the following description java.security.cert.CertificateException: Certificates do not conform to algorithm constraints. TM report the following message in the Server Log: Trying to establish an FTPS connection with TLSv1.2 protocol failed. Continue with the next protocol - TLSv1.1.. TM initiates a second connection with TLSv1.1 and use the following list of cipher suites (22): 


TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003)
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)


Attached is the tcpdump (FTPS_SIT_test.pcap) from the above described handshake with FIPS Transfer Mode enabled.


PeSIT over Secured Socket for SITs


For PeSIT over Secured Socket transfers the TM uses a third party library called netty.


For PeSIT transfers the TM starts the negotiation with TLSv1.2 protocol. If the value of the parameter Pesit.SIT.Ciphers is empty the TM would not establish the TLS connection with fatal alert Internal Error (80). There is an error message in Admin UI with the following description: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate). With FIPS Transfer Mode enabled TM initiate connection with TLSv1.2 and use the same cipher suites list as the first connection attempt described above for FTPS SIT transfer with FIPS Transfer Mode enabled.


Client Certificate Authentication for CITs and SITs


ST application uses SSL/TLS to transfer client certificate for authentication with protocols HTTPS FTPS and PeSIT over Secured Socket. For AS2 protocol no authentication methods are available because of the design of this protocol which include encryption and signing on a higher layer.


For CITs


When ST acts as the server for CITs, to activate the client authentication function the default value "Disabled" should be changed to "Optional" or "Required" in Admin UI -> Authentication -> Login Settings -> Client Certificate Setting for each service.



When the client certificate authentication is active during SSL/TLS handshake ST sends Certificate Request message which includes a full list of CAs accepted by ST. The client responds with a Certificate message which contains the client certificate, or it is empty. Even if the client does not send a certificate ST will continue with the handshake and will complete the SSL/TLS connection. The authentication happens at a later stage over the secure channel when the client provides a user (account) name. If there are any problems with the client certificate ST will report it in the server logs and will close the connection.


Some self-explanatory examples of reported messages in the logs are:


  • No client certificate provided.
  • Error during client certificate verification. The details of this message can contain
    • Certificate verification failed (PESITD)
    • Failed login for user _ACCOUNT_ from _IP_ADDRESS_:_PORT_ and other similar messages.


Note that certificate verification (authentication) failed messages usually appear when ST does not have the CA certificate which signed the client certificate and can't compose the chain of trust to verify it. The signing CA certificate should be imported in the Setup -> Certificates -> Trusted CAs page of the Admin UI.


For SITs


The client certificate can be set for each Transfer Site separately. For FTPS and PeSIT over Secured Socket ST will always send the client certificate upon request from the remote server. For HTTPS ST checks the CAs list in the remote server's Certificate Request message. If the client certificate in the Transfer Site is not signed by any of the CAs in the list provided by the remote server, ST will not send the client certificate and the authentication will fail in most cases. If the remote SSL/TLS server is another ST, then a "No client certificate provided." message will appear in its server log.


This behavior is the same as the behavior of web browsers like Internet Explorer, Firefox, and Chrome. If the configured personal certificates are not signed by any of the CAs in the list contained in the remote server's Certificate Request message, the browsers will not prompt you to select a certificate to authenticate and will immediately throw an HTTP ERROR 401 like on the screenshot below:



For that reason if you are going to use a certificate authentication in one of your Transfer Sites, make sure you have sent the signing CA certificate to the remote partner, so they import it in their trusted CAs store. If the remote party runs ST as well, they need to import the signing CA in the Setup -> Certificates -> Trusted CAs page of the Admin UI.


TM for internal communication


TM for cluster communication


For inter-node communication in a Standard cluster ST uses a secure connection on port 44431 which is controlled by two server configuration parameters - Cluster.Listeners.Ssl.protocol with default value TLSv1.2 and Cluster.Listeners.Ssl.enabledCipherSuites with default value TLS_RSA_WITH_AES_256_CBC_SHA256.


To replicate configuration changes in a Standard cluster ST uses a dynamic synchronization on admin port. A server configuration parameter Cluster.DynamicSync.SSLProtocol controls which version of SSL/TLS protocol to be used when performing dynamic synchronization. Allowed options are: TLSv1 | TLSv1.1 | TLSv1.2. If empty value is specified then TLSv1 will be used. The default value is TLSv1.2. There is no parameter for the cipher suites used for dynamic synchronization. ST uses the same list of 50 cipher suites shown above for FTPS SIT connection when Ftps.SIT.Ciphers is empty.


TM for Streaming communication


For a streaming communication between protocol daemons and TM when a secured connection is configured by selecting a certificate in the Network Zone, two server configuration parameters are used: Streaming.EnabledProtocols with default value TLSv1.2 and Streaming.EnabledCipherSuites with default value TLS_RSA_WITH_AES_256_CBC_SHA256.


TM for ICAP communication


In ST 5.3.6 two ICAP servers can be configured. For each server two server configuration parameters control SSL/TLS settings. Here is the list of the parameters with their default values:


For icap.FirstServer.EnabledProtocols: TLSv1, TLSv1.1, TLSv1.2


For icap.FirstServer.EnabledCipherSuites: 


TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_EMPTY_RENEGOTIATION_INFO_SCSV


For icap.SecondServer.EnabledProtocols: TLSv1, TLSv1.1, TLSv1.2


For icap.SecondServer.EnabledCipherSuites: the same list as for the first server


If the EnabledCipherSuites parameters are empty, a connection will not be established and error message will appear in the Server Log: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate).


In the ICAP settings page there is an option to enable FIPS Transfer Mode. With FIPS Transfer Mode enabled the TM will initiate connection first with TLSv1.2 and use the same list of 38 cipher suites shown above for FTPS SIT connection with FIPS enabled.


TM for Axway Sentinel or Decision Insight Server communication


For communication with Axway Sentinel or DI ST uses two server configuration parameters: AxwaySentinel.SecureConnection.Protocol with default value TLSv1.2 and AxwaySentinel.SecureConnection.EnabledCipherSuites with default value slightly different from the standard list - Cipher 0x0035 is used instead of 0x003d. See the list below: 


TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00a3)
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2)
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)


If the parameter AxwaySentinel.SecureConnection.EnabledCipherSuites is empty ST uses the same list of 50 cipher suites shown above for FTPS SIT connection when Ftps.SIT.Ciphers is empty.


In the Axway Sentinel/DI setup page there is option to enable FIPS Transfer Mode. With FIPS Transfer Mode enabled TM initiate connection first with TLSv1.2 and use the same list of 38 cipher suites shown above for FTPS SIT connection with FIPS enabled.


TM for LDAP communication


For communication with LDAP servers ST does not offer parameters in the Server Configuration page and there is no FIPS Mode control option. ST uses the same list of 50 cipher suites shown above for FTPS SIT connection when Ftps.SIT.Ciphers is empty.


Final Notes

The default SSL/TLS setting in ST 5.3.6 presented above are applicable to new installations and are consistent across the daemons' configruation. All cipher suites parameters except one (see Axway Sentinel or DI above) hold the same list of 14 cipher suites. This default list of 14 cipher suites (for example Http.Ssl.EnabledCipherSuites) contains only TLSv1.2 ciphers. This effectively limits the handshake to negotiate only the TLSv1.2 protocol version. TLSv1 and TLSv1.1 protocols have to be specifically enabled by adding at least one cipher suite applicable to all TLS protocol versions. Such a list of 7 cipher suites, which will work for TLSv1/TLSv1.1, is presented in the ADMIN description above.


Pay attention to:


  • The SIT.Ciphers parameters hold an ordered list of cipher suites and represent client preference.
  • DSS cipher suites require a certificate containing DSA key. Avoid using a certificate with a DSA key for the HTTP service because modern web browsers do not support it.
  • ST uses a 1024 bit session key-size for the Diffie-Hellman Exchange (DHE). To increase the session key size refer to the Java security settings section above.
  • SSLv3 protocol version is disabled globally in ST 5.3.6.


ST environments upgraded from previous versions of ST may not have the same settings as most of the server configuration parameters are not changed during the upgrade. If the upgrade changes some parameters, it should be written explicitly in the release notes (Readme).


Enjoy secure communication with ST!

Still need help?

If this information wasn't helpful to you, just drop us a line. We'll get back to you as soon as possible.