TL;DR Skip directly to the bottom of the article to find out the fastest and most secure SSL configuration for WLP/TM1Web. Otherwise, read on to understand the how and the why. 

TM1Web also known as "Planning Analytics Spreadsheet Services" is a web app serving websheets through the IBM WebSphere Liberty Profile webserver currently operating under Java Running Environment 1.8.0. 

The encryption to communicate with that WLP server is handled by a choice of ciphersuites to be configured in <TM1Web_install>\wlp\usr\webserver\server.xml 

One line of particular interest regarding security and compliance is the following setting the enabled ciphers:

<ssl id="CAM" keyStoreRef="CAMEncKeyStore" serverkeyAlias="encryption" enabledciphers="SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 SSL_ECDHE_ECDSA_WITH_AES_256 GCM_SHA384" sslProtocol="TLSv1.2"/>

However, the IBM documentation fails to provide the list of available ciphersuites. If you are familiar with ciphersuites, it should be an easy guess after a few online searches. But you can also unveil the exact list of cipher suites by compiling and running the linked Ciphers.java code.

javac Ciphers.java
java Ciphers

I will spare you all the work of finding, downloading, installing the correct java compiler, compiling the code and finally executing it. So, here is the list of all the ciphersuites available for TM1Web. The recommended ciphersuites are set in bold.

TLS v1.2

• SSL_DHE_DSS_WITH_AES_128_CBC_SHA
• SSL_DHE_DSS_WITH_AES_128_CBC_SHA256
• SSL_DHE_DSS_WITH_AES_128_GCM_SHA256
• SSL_DHE_DSS_WITH_AES_256_CBC_SHA
• SSL_DHE_DSS_WITH_AES_256_CBC_SHA256
• SSL_DHE_DSS_WITH_AES_256_GCM_SHA384 
• SSL_DHE_RSA_WITH_AES_128_CBC_SHA 
• SSL_DHE_RSA_WITH_AES_128_CBC_SHA256 
• SSL_DHE_RSA_WITH_AES_128_GCM_SHA256 
• SSL_DHE_RSA_WITH_AES_256_CBC_SHA 
• SSL_DHE_RSA_WITH_AES_256_CBC_SHA256 
• SSL_DHE_RSA_WITH_AES_256_GCM_SHA384 
• SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 
• SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 
• SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 
• SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 
• SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 
• SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 
• SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA 
• SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256 
• SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256 
• SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA 
• SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384 
• SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384 
• SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA 
• SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 
• SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 
• SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA 
• SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 
• SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 
• SSL_ECDH_RSA_WITH_AES_128_CBC_SHA 
• SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256 
• SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256 
• SSL_ECDH_RSA_WITH_AES_256_CBC_SHA 
• SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384 
• SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384 
• SSL_RSA_WITH_AES_128_CBC_SHA 
• SSL_RSA_WITH_AES_128_CBC_SHA256 
• SSL_RSA_WITH_AES_128_GCM_SHA256 
• SSL_RSA_WITH_AES_256_CBC_SHA 
• SSL_RSA_WITH_AES_256_CBC_SHA256 
• SSL_RSA_WITH_AES_256_GCM_SHA384 

TLS v1.3

• TLS_AES_128_GCM_SHA256 
• TLS_AES_256_GCM_SHA384 
• TLS_CHACHA20_POLY1305_SHA256 
• TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 
• TLS_EMPTY_RENEGOTIATION_INFO_SCSV

So what does this all mean? A ciphersuite is a combination of algorithms used in the SSL/TLS protocol for secure communication. Each ciphersuite name is structured to describe the algorithmic contents of it.

For example, the ciphersuite `SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` is built with the following components:

• SSL: This indicates the protocol version. In this case, it's TLS v1.2 (Transport Layer Security). 
• ECDHE: This stands for Elliptic Curve Diffie-Hellman Ephemeral. It's the key exchange method used in this ciphersuite. Diffie-Hellman key exchanges which use ephemeral (generated per session) keys provide forward secrecy, meaning that the session cannot be decrypted after the fact, even if the server's private key is known. Elliptic curve cryptography provides equivalent strength to traditional public-key cryptography while requiring smaller key sizes, which can improve performance.
• ECDSA: This stands for Elliptic Curve Digital Signature Algorithm. It's the algorithm used for server authentication. The server's certificate must contain an ECDSA-capable public key.
• AES_256: This indicates the symmetric encryption cipher used. In this case, it's AES (Advanced Encryption Standard) with 256-bit keys. This is reasonably fast and not broken.
• GCM: This stands for Galois/Counter Mode. It's a mode of operation for symmetric key cryptographic block ciphers. It's used here for the symmetric encryption cipher.
• SHA384: This is the hash function used. It's used for the Message Authentication Code (MAC) feature of the TLS ciphersuite. This is what guarantees that each message has not been tampered with in transit. SHA384 is a great choice.

Some ciphersuites in the list above are not recommended because of the following obsolete algorithms:

• DHE_DSS: This is an old key exchange algorithm that uses the Diffie-Hellman key exchange and the DSS (Digital Signature Standard) algorithm for digital signatures. It's not recommended for use because DSS is considered less secure than ECDSA (Elliptic Curve Digital Signature Algorithm), and Diffie-Hellman is not as efficient as Elliptic Curve Diffie-Hellman.
• RSA as server authentication: While RSA is still widely used, it's not recommended for use as both the key exchange and authentication algorithm. This is because it does not provide Perfect Forward Secrecy.
• CBC: This is a mode of operation for symmetric key cryptographic block ciphers. It's not recommended for use because it's vulnerable to padding oracle attacks, which allow an attacker to decrypt ciphertext without knowing the encryption key. Instead, it's recommended to use GCM (Galois/Counter Mode) or CCM (Counter with CBC-MAC).
•  SHA (also known as SHA1): This is a hash function that is not recommended for use because it's considered to be weak and vulnerable to collision attacks. Instead, it's recommended to use SHA-256 or SHA-384.

faster and more secure TM1Web with TLS v1.3

TLS 1.3 offers several performance improvements over TLS 1.2. One of the key differences is the faster TLS handshake. Under TLS 1.2, the initial handshake was carried out in clear text, requiring encryption and decryption, which added considerable overhead to the connection. TLS 1.3, on the other hand, adopted server certificate encryption by default, which reduced this overhead and allowed for faster, more responsive connections. 

Another performance improvement in TLS 1.3 is the Zero Round-Trip Time (0-RTT) feature. This feature eliminates an entire round-trip on the handshake, saving time and improving overall site performance. When accessing a site that has been visited previously, a client can send data on the first message to the server by leveraging pre-shared keys (PSK) from the prior session.

TLS 1.3 offers more robust security features compared to TLS 1.2. It supports cipher suites that do not include key exchange and signature algorithms, which are used in TLS 1.2. TLS 1.2 used ciphers with cryptographic weaknesses that had security vulnerabilities. TLS 1.3 also eliminates the security risk posed by a static key, which can compromise security if accessed illicitly. Furthermore, TLS 1.3 uses the Diffie-Hellman Ephemeral algorithm for key exchange, which generates a unique session key for every new session. This session key is one-time and is discarded at the end of every session, enhancing forward secrecy.

So, an optimal configuration for WLP server.xml will be: 

<ssl id="CAM" keyStoreRef="CAMEncKeyStore" serverkeyAlias="encryption" enabledciphers="TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256" sslProtocol="TLSv1.3">

Unfortunately, I haven't found a way to have both TLSv1.2 and TLSv1.3 protocols available at the same time in that configuration file. If you know how, please leave a comment with the details.

You can easily check the configuration is correct in Chrome, with Developer Tools -> Security -> Security Overview -> Connection: "The connection to this site is encrypted and authenticated using TLS 1.3"

On a side note, the configuration file for TM1Web is located at <TM1Web_install>\webapps\tm1web\WEB-INF\configuration\tm1web_config.xml.