This is a common deployment question. Should SSL Termination of the client request be done on Sentry or at the upstream load balancer.
This article lists several important considerations, but in general, Forum Systems recommends terminating SSL connections from clients on Sentry whenever possible.
1. If the upstream load balancer is terminating the SSL connection, the load balancer can either send the request to Sentry in clear text (e.g. HTTP) OR it can establish an entirely different SSL connection to Sentry (e.g. HTTPS) and use that. The latter option is more secure but not always necessary depending on the network topology/architecture. The important thing to note is that the SSL connection from the load balancer to Sentry is a completely separate SSL handshake that will use a completely different key - not related at all to the cert provided by the client to the load balancer.
2. If the load balancer is doing any content inspection (e.g. payloads/HTTP headers), it will need to do SSL termination of the client connection so that it can "see" the content.
3. Forum Systems recommends against using load balancers for SSL termination whenever possible because they are consistently found to be impacted by SSL vulnerabilities. Heartbleed a few years ago was the big one, but F5 BigIP was hit again earlier this year with Ticketbleed. Alternatively, Sentry does not utilize any OpenSSL libraries and has a US DoD certified PKI/SSL engine. When OpenSSL vulnerabilities are reported, in addition to having to patch impacted load balancers, in some cases new keys need to be generated and shared with trading partners.
4. If the load balancer is doing SSL termination - and you can't or don't want to change this - most load balancers allow for capturing the X.509 attributes from the provided client certificate (Sentry does). These attribute values can be passed down to Sentry in the form of HTTP headers. Sentry can validate the content of that header and use that value for authentication/authorization and/or pass it along to remote server. However, this is definitely not a substitution for SSL termination and should not be considered as such. This is simply Sentry consuming the value of an incoming HTTP header and using it for some purpose.
5. Some of the benefits of using Sentry for terminating SSL connections from the client directly include:
- enhanced security (no OpenSSL libraries)
- allow/prevent certain SSL/TLS protocols
- allow/prevent cipher suites used
- full support for SSL mutual auth with signer chain validation and CRL checking
- full access to the X.509 attributes of the client cert
- the ability to map a client certificate to a user in an identity repository (e.g. ensure the DN of the client cert maps to a known user in your internal LDAP)
6. The ability to map the SSL cert to a known user in an internal repository (e.g. Active Directory, LDAP v3 Server) allows for a true authorization factor based on the SSL cert. Simply validating a cert (signer checking, CRL checking) is important but it is only validating the certificate. While some load balancers may have a similar capability (query an LDAP server), this is the type of processing that should happen on Sentry where you will do multi-factor and multi-context authentication and authorization for the API flows. Sentry will be retrieving user attributes during these LDAP queries which can be used for authorization or added to requests or associated to SSO tokens. Sentry will be responsible for the security of the APIs and services and the authentication/authorization is a big part of that.
7. Multi-factor auth might be some combination of 1) SSL mutual auth & 2) username/password or SSO token/cookie & 3) validation of API key & 4) digital signature verification. There are many options for this in Sentry as different service types may call for different authentication methods.
8. Multi-context auth is ensuring that everything about the transaction is valid for the user (not just that the user credentials are OK). This is very important for API flows. For example.. does the user belong to an AD group that should have access to this API, does the user have access to the specific endpoint it is trying to reach, is the HTTP method allowed for this user, are the query parameters allowed for this user, is the payload size appropriate for this user, is the frequency / rate valid for this user, is the response content and size valid for this user, etc. All of this can be established in Sentry based on the client SSL cert when mapped to a known user.
To summarize, a lot of the security, authentication, and authorization processing that will happen in Sentry can still occur if you do SSL termination at the upstream load balancer. However, there is some security risk involved using the load balancer for SSL termination due to vulnerabilities with the SSL implementations in popular load balancer products. With termination on the load balancer you also lose access to the SSL client certs which Sentry can map to known users in internal repositories for authentication and authorization.