Add semantic convention for describing SSL/TLS connections

[svrnm]

What are you trying to achieve?

Encrypting network communication with SSL/TLS adds an additional layer of complexity to the communication which can be the source of issues, like expired certificates, outdated ciphers&protocols, ...

I would like to add several semantic conventions to the spec to describe SSL/TLS connections. I suggested a few through an instrumentation implementation for nodejs at open-telemetry/opentelemetry-js-contrib#447 via https://nodejs.org/api/tls.html (most other languages will have the same properties available):

tls.protocol
The negotiated SSL/TLS protocol version of the current connection, one of the following values:

• 'SSLv3'
• 'TLSv1'
• 'TLSv1.1'
• 'TLSv1.2'
• 'TLSv1.3'

tls.authorized
true, if the peer certificate was signed by one of the CAs specified when creating the tls.TLSSocket instance, otherwise false.

tls.cipher.name
OpenSSL name for the cipher suite.

tls.cipher.version
The minimum TLS protocol version supported by this cipher suite.

tls.certificate.fingerprint (or tls.server.certificate.fingerprint?)
The SHA-1 (or SHA-256) digest of the DER encoded certificate

tls.certificate.serial_number
The certificate serial number, as a hex string

tls.certificate.valid_from
The date-time the certificate is valid from.

tls.certificate.valid_to
The date-time the certificate is valid to.

tls.alpn_protocol
The negotiated ALPN protocol

There are a lot more potential candidates, like certificate details (subject, issuer, subjectaltname), SNI server name used, ephemeral key details, client certificate details. If there is value in adding any of these, part of a discussion should be which ones provide the most value and which ones might be irrelevant from an observability perspective or which ones are interchangable (fingerprint vs serial number // cipher.name vs cipher.standardName ...)

[azdagron]

This sounds like a great idea!

One data point for considering SANs as candidates is that SANs (specifically the URI SAN) are used to convey service identity for SPIFFE empowered workloads. SPIFFE (a CNCF incubation project) is a set of specifications all about how to encode, distribute, and validate service identities. The SPIFFE ID (e.g. spiffe://example.org/database) is an identity assigned to a service and is very useful from an observability standpoint to understand which services are talking to each other. The SPIFFE ID is represented as a URI SAN in the X509-SVID (which is an X.509 certificate based identity document).

[svrnm]

Hi @azdagron, thanks for adding in your expertise. As you can see from my stalled PR (due to my PTO) I am not an expert on that topic myself and as @Oberon00 commented correctly (#1854 (comment)) we would need Someone with more domain knowledge to help out.

To be honest my knowledge about SPIFFE is even more limited but I see the value add you are describing!

[svrnm]

fixed via open-telemetry/semantic-conventions#21