App Suite Security

Cryptography

BSI IT-Grundschutz 2023 sections covered by this page
  • CON.1
  • CON.8
  • APP.3.1
  • APP.5.3

OX App Suite implements widely recognized industry standards for cryptography. It does not include hard-coded key material, proprietary cryptography nor export control restrictions.

Key management

Java Key Stores (JKS) are used to manage cryptographic material. Using unique shared secrets to protect JKS data sources are supported and encouraged. A restart of OX App Suite is required when rotating key material. Validity and expiry dates are considered when evaluating certificates. For this reason, it is critical to ensure accurate system clocks, for example, using network-based time management.

TLS Cipher suites

Certain functionality requires support for TLS cipher suites that include functions for key exchange, encryption and message authentication (signatures). Whether OX App Suite is the client or server party, it uses TLS cipher suites, which are provided by the underlying runtime environment (the operating system and Java runtime). Operators can manipulate the list of valid protocol versions and cipher suites for system hardening. Since outgoing TLS connections to arbitrary servers are very commonly used, for example, when using external mail accounts or user-defined data feeds, compatibility with third-party systems needs to be considered.

Common system configuration produces support for the following cipher suites:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA

Modern protocols, like TLSv1.3, and ciphers providing "forward secrecy" are fully supported, but availability depends on the runtime environment.

TLS implementation

The OX App Suite middleware has the capability to only establish connections (as a client via HTTPS) to external servers if the certificates provided for a desired endpoint pass validation checks against the issued authority, certificate expiration, self-signature and hostname validation.

Potential risk

If certificate validation is disabled the client cannot be sure that the desired endpoint is who it pretends to be, for example it might be possible that the endpoint is an attacker. If so, user sensitive data would be transferred to the attackers.

Security measures

When OX App Suite middleware serves as a client and tries to establish connections to external (3rd party) providers then it can be configured to validate certificates provided by the desired endpoint.

With enabled certificate validation the server by default uses the trust store provided by the JRE (containing root certification issued by a trusted certificate authority (CA)). This can be adapted by adding a custom trust store with CAs defined by the administrator. If the administrator does not want to rely on the default trust store, support for it can be disabled. If both, default and custom trust store are disabled, the default trust store will be used.

If the end user would like to establish a connection to untrusted endpoints she is able to configure to trust all endpoints (whether this is offered to the end-user is an administrator-defined configuration). The administrator is also able to configure whether the end user would trust all endpoints or whether the user can add exceptions dynamically to trust or not trust specific sites.

If the end user decides to trust all endpoints they will be responsible if data is compromised due to an attacker providing untrusted certificates. To facilitate ease of administration it is possible to allow-list hosts. If a host is allow-listed and a connection should be established to it the validation mechanism will not be applied.

The validation mechanism itself (executed while TLS handshaking) contains the following checks:

  • Issued authorities: validates if there is a trusted authority within the certificate chain
  • Certificate issuer: validates if the certificate is self-signed
  • Expired certificates: validates if the provided certificate is expired
  • Hostname check: validates if the hostname provided by the certificate matches the endpoint host

For backward compatibility reasons the feature is disabled by default and should be enabled by the administrator via com.openexchange.net.ssl.trustlevel configuration. See https://documentation.open-xchange.com/components/middleware/config/8/#mode=search&term=com.openexchange.net.ssl.trustlevelopen in new window.

Hashing

OX App Suite supports modern hashing algorithms to create salted hashes for sensitive information, including passwords. Those include:

  • Unix Crypt / DES
  • SHA-1
  • SHA-256 (default)
  • SHA-512
  • BCrypt

Non-default algorithms can be used for compatibility, however, selecting Unix crypt, DES and SHA-1 is discouraged as those algorithms are generally considered vulnerable and have been superseded by state-of-the-art algorithms.