Skupper exposing services/deployments protected by TLS

[Chris Munford]

Let's say skupper is used to expose a service or deployment, that is protected with common public key encryption using TLS. Examples are HTTPS servers/services, and the Kubernetes API.  In these cases, by default, there will be a CA cert check to prevent man-in-the-middle attacks, by validating the authenticity of the destination domain/url.  When the requestor accesses the destination directly (at say https://mydomain.com or kubernetes service at https-server.default.svc), the cert check passes, and all is good.  However, when the requestor attempts the same connection over skupper, they will call the skupper service name in the destination (at say https://skupper-service1), not the service name or IP of the HTTPS server that was originally created and signed in the cert.  This will cause an authentication error, such as "x509: certificate is valid for minikubeCA, control-plane.minikube.internal, kubernetes.default.svc.cluster.local, kubernetes.default.svc, kubernetes.default, kubernetes, localhost, not skupper-service1"

Some tools, like curl, that embed TLS communications, allow you to issue "--insecure" to skip this CA check.  But, as the command says, it is insecure, which is not ideal.  And some other tools don't expose the "-- insecure" capability, so it creates a blocking issue.

Some other proxy tools I've worked with in the past use SNI to change the destination domain/URL at the proxy, in the final hop, so that this CA cert check passes.

My question is, How can I use skupper with TLS-based services, and still pass CA checks?  Does skupper have a mechanism, like SNI, that I can use?  Is skupper not supposed to be used to connect TLS based services with CA cert checks?  What are the best practices for this?  Am I missing something fundamental?

Thanks for your guidance...

[Gordon Sim]

On Tue, Jul 12, 2022 at 3:12 PM Chris Munford <ch...@nethopper.io> wrote:
> Let's say skupper is used to expose a service or deployment, that is protected with common public key encryption using TLS. Examples are HTTPS servers/services, and the Kubernetes API. In these cases, by default, there will be a CA cert check to prevent man-in-the-middle attacks, by validating the authenticity of the destination domain/url. When the requestor accesses the destination directly (at say https://mydomain.com or kubernetes service at https-server.default.svc), the cert check passes, and all is good. However, when the requestor attempts the same connection over skupper, they will call the skupper service name in the destination (at say https://skupper-service1), not the service name or IP of the HTTPS server that was originally created and signed in the cert. This will cause an authentication error, such as "x509: certificate is valid for minikubeCA, control-plane.minikube.internal, kubernetes.default.svc.cluster.local, kubernetes.default.svc, kubernetes.default, kubernetes, localhost, not skupper-service1"
>
> Some tools, like curl, that embed TLS communications, allow you to issue "--insecure" to skip this CA check. But, as the command says, it is insecure, which is not ideal. And some other tools don't expose the "-- insecure" capability, so it creates a blocking issue.
>
> Some other proxy tools I've worked with in the past use SNI to change the destination domain/URL at the proxy, in the final hop, so that this CA cert check passes.

Hostname verification is done by the client, in order to ensure that
it is connecting to the correct server. It verifies that the server's
certificate is valid for the name to which it connected. SNI transmits
that hostname to the server, and it is often then used to route the
request correctly through some intermediary. Proxies should not try to
alter that though, nor would doing so have any effect on the client
side hostname verification.

> My question is, How can I use skupper with TLS-based services, and still pass CA checks? Does skupper have a mechanism, like SNI, that I can use? Is skupper not supposed to be used to connect TLS based services with CA cert checks? What are the best practices for this? Am I missing something fundamental?

There are two possibilities. The first is end-to-end tls in which the
service certificate needs to include any name by which it can be
legitimately accessed. The second is for the TLS from the client to be
terminated at the skupper router and then re-encrypted by the remote
router before it is sent to the actual service. That is not fully
supported yet in skupper but will be in a future release.

[sankar ramamoorthi]

Need a clarification on the first option listed above. In the case of end—to-end TLS the client application is accessing the service using original DNS url name - hence from the end client application point of view the name by which service is accessed has not changed. 

Therefore is there a need for server certificate to include the skupper-<service-name> in the sub.alt.name extension? Accessing the service using the DNS name skupper-<service-name> is done internal in the skupper network data path and is hence transparent to the client application. Am I correct?

Thanks - sankar

[Gordon Sim]

On Thu, Oct 19, 2023 at 3:47 AM sankar ramamoorthi <sank...@gmail.com> wrote:
>
> Need a clarification on the first option listed above. In the case of end—to-end TLS the client application is accessing the service using original DNS url name - hence from the end client application point of view the name by which service is accessed has not changed.
>
>
> Therefore is there a need for server certificate to include the skupper-<service-name> in the sub.alt.name extension? Accessing the service using the DNS name skupper-<service-name> is done internal in the skupper network data path and is hence transparent to the client application. Am I correct?

If that service name is not being used by the clients, then no, it is
not needed. All that is needed is that every hostname by which a
client is connecting is valid for that certificate (i.e. included as
an SAN entry).