Milestone #29
Updated by Daniele Cruciani 3 months ago
## Use SNI for routing https requests
The scenario is a proxy exposing https protocol. SNI, Server Name Indication, happens before ssl handshake negotiation.
If SNI is used for routing https request, the same port can be used for multiple domains
The problem is on passing the headers:
- X-Forwarded-Proto
- X-Forwarded-Port
- X-Forwarded-Host
- X-Forwarded-For
These headers are require for internal http/1.1 service for:
- setting cookies
- craft the internal urls in each page served (base uri)
- internal redirections
### Adopting https on the backend service
The drawback of https adoption is:
- ssl certificate managed by the internal service: at very least the internal service must generate a self signed certificate
## SSL Termination
There are 2 options for the proxy service, for a given tcp port:
1. act as SSL termination
2. stream the SSL to the internal service
If the proxy does SSL termination, the proxy certificate must be valid for the browser
If the proxy stream the SSL data to internal service, the internal service certificate must be valid
If proxy does SSL termination, and then proxy requests to internal service, the internal service would be not aware about the client caller, and how te client expect cookie are settled, and how the pages internal urls must be crafted:
> **Proxy SSL Termination is only usable for pure REST calls** (or GraphQL, or similar)
## Conclusions
There are no options to serve both https and http requests for the backend for the same proxy service on the same port.
This limitation does not apply to internal services providing pure REST
### Internal service CPU load
SSL handshake negotiation involves challenge solving and symmetric key generation for communication, that is described here: https://sematext.com/glossary/ssl-tls-handshake/
If proxy implement SSL termination, this happens once, on the proxy.
### Connection bound and load balancing
When proxy is settled to not terminating SSL, the connection between external client, and internal service is bounded one-to-one.
This has some implications:
- internal service load depends on how many clients are bounded to the specific service instance
- during connection lifetime, the bound can not be changed for balancing between multiple clients, to multiple internal service instance
- if internal instance has some error (connection error, node not reachable, instance crash) the client must handle the error: close the https channel, open new https channel, negotiate SSL handshake. These operations pointing to the same url, from client point of view, but talking with another internal instance.
It is valuable to mention that, in case of error, receive a
- 502 Bad Gateway
- 504 Gateway Timeout
- 5XY (no standard)
see https://en.wikipedia.org/wiki/List_of_HTTP_status_codes for proxy related message.
### UDP
The SSL "To Terminate or To do not terminate" dilemma does not exist for UDP messages. In UDP world does not exists SSL neither, because the connection control flow must be implemented on Application level (OSI Level 7). These are the application responsibility for UDP:
- Implement Security Layer
- Implement traffic control flow and deal with network errors
For each UDP based service (mostly media stream), there are libraries providing these features.