X509-SVID: How does SNI work? Should certificates for servers also have dNSName SubjectAltNames?

[briansmith]

Service spiffe://example.com/foo provides services to spiffe://example.com/bar and others through HTTPS; i.e. it is a web server of some form. Other services will look up how to contact spiffe://example.com/foo, which is likely to be an HTTPS connection to some hostname, e.g. https://foo.example.com/.

When clients connect to https://foo.example.com/ to access spiffe://example.com/foo, what should they put in the SNI Server Name Indication (SNI) extension? AFAICT the client cannot put spiffe://example.com/foo because the SNI extension only defines a name form for (DNS) hostnames, so presumably the client must put "foo.example.com" there or avoid SNI completely. If it avoids SNI completely then we lose the ability to have multiple services listening on a single IP, so that seems out. Thus, it seems like the client must put "foo.example.com" in the SNI extension of the TLS client hello.

How, then, should the X.509 certificate for spiffe://example.com/foo include a dNSName subjectAltName entry for foo.example.com in addition to the uniformResourceIdentifier entry for spiffe://example.com/foo?

Or, do we need to define a new SNI entry type or a new SNI-like extension that lets us put the SPIFFE ID in the client hello? See the mailing list thread [TLS] Accepting that other SNI name types will never work. about the difficulties in doing that.

[mlakewood]

I don't think there is anything that fundamentally stops you from having both the DNS name and a URI in the SubjectAltNames in either the SPIFFE Spec or SNI/TLS (although please feel free to correct me). The SPIFFE SVID spec makes no claims on DNS names in the Subject Alternate Name, and the Subject Alternative Name can contain multiple different fields (IP, DNS and URI).

Reading between the lines, sometimes the URI nature of the Spiffe ID leads people to think its a domain name that needs to be verified like other domain names in the TLS space. This is not the case, you should think about it almost as an opaque string that has some human readable information but for most machines is just used for matching.

In the case of a client I can foresee that it would most likely take the following steps

1. Check the cert chain is "correct" and that it trusts i, most likely through existing mTLS mechanisms.
2. Extract the Spiffe id from the certificate provided and was the one it expected ( ie "spiffe://example.com/foo" )

At that point the client has verified that it is talking to the correct server. Additionally if you like you could also use SNI to verify the domain in a more traditional way by also embedding a DNSName in the subjectAlt name but that is orthogonal to SPIFFE and not really part of this discussion.

Hope that helps clarify things. Feel free to ask follow up questions.

Mark

[evan2645]

Out of curiosity, is there a use case for SNI outside of user-facing services? SNI is an important feature for consolidating workloads on a single machine which all want to use the standard port numbers, but is this the case for backend infrastructure as well?

To be clear, I think there is good use in ultimately supporting SVIDs issued to humans etc, just trying to better understand where SNI is most valuable and most frequently used.

[boz]

@evan2645 we use it for for cross-cluster communications. there might be a couple of different postgres instances hosted on cluster A that services in cluster B need to talk to, for instance.

[evan2645]

@boz I assume then you're using a proxy of some sort in front of your postgres instances? Is this under k8s?

[evan2645]

Also curious about how you discover the postgres endpoints... Via DNS?

[boz]

@evan2645 : yeah, haproxy sits in front of a kube cluster and does the SNI vhosting ( SNI pg1.cluster.com -> kube service postgres.ns1.svc ) . haproxy builds configuration from kube ingresses & other objects.

apps on other clusters can basically have something like DATABASE_URL=pg1.cluster.com set. I don't know if SPIFFE is applicable here but I'd really, really like it to be ;)

edit: it's basically needed for everything but http and terminated https - postgres is just one example. grpc/http2 is another.