Anyone looking at the EBICS specification might be surprised to learn that it still prescribes version 1.0 for the Transport Layer Security (TLS). At one time that was a very wise choice – when the EBICS specification was published, TLS 1.0 was the latest technology. So this was mainly a decision against SSL, which put manufacturers and operators in a nice position e.g. concerning POODLE. EBICS ruled out SSL and so EBICS applications were safe from POODLE. It wouldn’t have had much of a chance with an EBICS client anyway: the attacker makes the client send thousands of requests to the HTTPS server so that, for example, it can access the session cookie. But EBICS doesn’t use session cookies, and the clients aren’t web applications that would execute malicious JavaScript code to send thousands of requests. But try explaining that to the auditors!
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.
Curd Reinert
0 comments:
Post a Comment