TykTechnologies / tyk / 3104

47%

master: %

push

travis-ci

Mutual TLS protection on API Level

Fixes #357

In most of the cases when you try to access secured HTTPS/TLS endpoint, you experience only client-side check of the server certificate. Purpose of this check is to ensure that no fraud involved and data transfer between client and the server is encrypted.

In fact, TLS standard allows specifying client TLS certificate, so the server can accept connections only from clients which certificates registered at server certificate authority. In other words, clients are required to provide certificate and this certificate should be whitelisted on the server. This is what we call “Mutual TLS”, e.g. both sides require and verify certificates.

This change introduce Mutual TLS on the following layers:
* Authorization (white listing certificates on api level)
* Authentification (creating keys based on certificates)
* Upstream access (including JSVM)
* Control API
* Dashboard and MDCB API

There is 2 types of certificates: with and without private keys. Certificates without public keys used for authorization and authentification. Certificates with private keys used for upstream access, and server certificates: in other works when we need sign and encrypt request or response.

We support only certificates in PEM format. Nice bonus of PEM that it allows having multiple entries inside same file. It helps simplify the logic:  certificate with private keys store in the same file.

This PR adds new `certs` package, introducing `CertificateManager` API, which handle all the certificate parsing, storage and retrieval logic. Certificates can be stored inside Redis or plain files. Certificates stored in Redis identified by their SHA256 fingerprint. Worth noticing that x509 certificate format implies that fingerprint is already embed into certificate, same as information about algorithm which was used to generate fingerprint. Tyk certificate storage do not use embed certificate fingeprints, and insted always use SHA256 algorit... (continued)

432 of 432 new or added lines in 11 files covered. (100.0%)

6283 of 13735 relevant lines covered (45.74%)

0.5 hits per line