And that was just one of the malicious attacks with the cute names – HEARTBLEED exploited a fault in the TLS implementation of OpenSSL. And then there’s BEAST. As with POODLE, EBICS should not be susceptible to a BEAST attack. But the reputation of TLS 1.0 has been permanently damaged and everyone is advising the use of its secure successor, TLS 1.2.
This was also recognised with EBICS and relevant change requests were planned for the next version so as to support TLS 1.2. Unfortunately, there’s a delay with this next version and, in the meantime, the auditors are asking: Why are you still using TLS 1.0 with EBICS? “Because that’s what it says in the specification” is hardly a valid reason anymore when the Federal Office for Information Security (BSI) is officially warning against this version. Therefore the Deutsche Kreditwirtschaft has published security recommendations on the official EBICS website advising the use of TLS 1.2 – with no explanation of how that fits in with the specification.
We tested 82 EBICS servers in Germany and France – only 52 servers could communicate with us using TLS 1.2. If, therefore, you are a customer product manufacturer and you decide today not to support TLS 1.0 anymore, you can no longer connect to around a third of the EBICS servers. It might be even worse for server operators with customer products in all kinds of versions.
So what can you do? You can offer TLS 1.2 without prohibiting TLS 1.0. This applies to both client and server, and in the TLS handshake both sides agree on the safest common variant – so the theory goes. And with 28 of the servers tested this did indeed work. But unfortunately, we also found two servers that abruptly break off communication when the client suggests TLS 1.2. For manufacturers of customer products this is very inconvenient because the clients cannot simply propose TLS 1.2 “on spec” – unless they accept that communication will fail with a few servers.
We notified the operators of the two EBICS servers. But because our test didn’t include every EBICS server, all operators should check the behaviour of their EBICS server themselves.
Another question comes to mind: How dangerous would the decryption of the TLS layer in EBICS actually be; what data would be visible? The order data itself is encrypted a second time and remains invisible to the attacker. So what remains is the XML frame around the order data or, as you would call it in the post-Snowden era, metadata. These are mainly the order type or the file format, customer and user ID. In other words, not a great deal. But whether this makes people happier is a completely different matter altogether.