We will soon update our Bambora Epay domains to only support the four (4) following TLS1.2 cipher suites:
IANA name: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
OpenSSL name: ECDHE-ECDSA-AES128-GCM-SHA256
Cipher information: https://ciphersuite.info/cs/TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256/
IANA name: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
OpenSSL name: ECDHE-RSA-AES128-GCM-SHA256
Cipher information: https://ciphersuite.info/cs/TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256/
IANA name: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
OpenSSL name: ECDHE-ECDSA-AES256-GCM-SHA384
Cipher information: https://ciphersuite.info/cs/TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384/
IANA name: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
OpenSSL name: ECDHE-RSA-AES256-GCM-SHA384
Cipher information: https://ciphersuite.info/cs/TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384/
This means that older operating systems, applications and other software that acts as a client to perform requests to our public domains might fail to negotiate a cipher suite and the requests will fail.
The error message might for example be something like:
"Could not create SSL/TLS secure channel"
"Algorithm/Cipher negotiation failed"
"TLS/SSL Handshake Failure"
It is only required that a single of the listed cipher suites is supported by the client application.
Please note that we will not be able to identify which clients that does not support our cipher suites. This change only affects traffic to our domains, and not requests to your domains (callbacks).
September 14, 12.00-12.30 CET: Temporary switch to the new cipher suites
September 21, 12.00-13.00 CET: Temporary switch to the new cipher suites
September 28, 12.00 CET: Permanent switch to the new cipher suites
If you are using a hosting provider, then they should be able to confirm if the cipher suites are supported by them.
We have created the following new temporary Bambora Epay API endpoint that will redirect to the original endpoint:
If you can update your client config or code to point to the "cipher-test-"-prefixed domain name and the client still works after the update, then you can be certain that your client supports the new cipher suites. If the client does not seem to work, then it probably does not support the new cipher suites.
In case you are unable change the client config or code, try to use the same runtime as your client application to perform requests to any of the above "cipher-test-"-prefixed domains. If you get a response then the runtime and OS support the ciphers.
When you are running a C-based interpreter/language like Python, Ruby, PHP, Bash, etc., then the OpenSSL version that it was built with will decide the supported ciphers. In case you are running .NET or Powershell on Windows, then the supported ciphers are decided by the Windows version and installed patches.
In most cases an update to a sufficiently new version of the client application's interpreter/framework/platform/runtime will provide support for at least one of our supported cipher suites. For example, if you are running a PHP script, then upgrading PHP should be sufficient.
Please note that if you are running .NET applications or Powershell on "Windows 8"/"Windows Server 2012 R2" or earlier, then it will unfortunately not work to upgrade .NET or Powershell, but you will most likely need to upgrade to a newer OS that support our ciphers. On the other hand, running software that uses OpenSSL on Windows should always work if the OpenSSL version supports the listed ciphers and the application is configured accordingly.
Another option to support our ciphers on legacy systems is to set up a TLS-terminating proxy in your network to perform the requests to us. It's important that the proxy is hosted in your network, else the transmitted data will be less protected than when using a strong cipher end-to-end. Please note that we cannot provide support on how to set up a proxy.