https://ift.tt/nMIHXKd
Recently, after reading a great engineering blog post on OCSP and CRL verifiers in Go, and after further discussion in the community, I’ve got an insight that made me really gloomy.
Mass of projects use technologies without paying attention to their security holes. For instance, financial applications adopt TLS (transport layer security) protocol, often disregarding to configure it properly and support only the latest versions (1.2
and 1.3) and TLS extensions. Fintech projects often get into this trap.
The typical mistake is to chase after technology and ignore the real state of security of the project itself and the technologies it uses.
For example, OCSP (Online Certificate Status Protocol) and CRL (Certificate Revocation List) are TLS extensions, which could be highly useful for fintech infrastructures and network security controls, as they play significant roles in establishing trust
to remote parties (servers, applications). Moreover, OCSP and CRL support is a must-have for applications that process sensitive data, like banking applications or cryptocurrencies wallets.
OCSP allows any party of a TLS handshake to ask the designated authority (CA, or OCSP responder server) whether a provided TLS certificate is still valid. CRL is a file that contains a list of certificates revoked by a single certificate authority (CA),
with serial numbers and reasons for revocation.
The support of OCSP and CRL is crucial for fintech applications to prevent unauthorised connections from malicious or misconfigured apps to sensitive data.
But many programming languages do not support OCSP and CRL out-of-the-box, and projects’ teams need to homebrew them. As developers are not security engineers, they make mistakes during implementation, increasing the chances of attacks and security incidents.
If developers can’t enable or implement OCSP/CRL, they can implement
application level encryption (ALE) instead. The idea is very different: the application encrypts sensitive data before sending and decrypts on retrieval. When done properly, ALE mitigates the risk of exposing the data to a malicious party or person in the
middle.
This OCSP/CRL example is only one small thing. Efficient data protection requires a multilevel approach and effort (aka “defence-in-depth”). Otherwise, using even the best tools with leaky but famed technologies is just an illusion of security. Stay in reality,
pay attention to risks and threats.
Financial Services
