Splunk forwarder is not validating ExtendedKeyUsage for server authentication

[spilli]

We are using Splunk forwarder v9.0.3. One of the X509 validation we would like to have against TLS server certificate coming from the Splunk Indexer is ExtendedKeyUsage(EKU) validation for Server authentication. 

We generated the TLS server certificate without the ExtendedKeyUsage to test this use case. However, Splunk forwarder is still accepting the TLS server certificate. Ideally, it should allow only when ExtendedKeyUsage is set to Server authentication.

Is this a known limitation or does it require a configuration change to perform this EKU validation? Please advise.

Below is our outputs.conf contents.

[tcpout-server://host:port]
clientCert = /<..>/clientCert.pem
sslPassword = <..>
sslRootCAPath = /<..>/ca.pem
sslVerifyServerCert = true
sslVerifyServerName = true

[spilli]

One of the SFR from Security Target of https://www.niap-ccevs.org/products/11330 claims the below.

FIA_X509_EXT.1 X.509 Certificate Validation
.
.
The application shall validate the extendedKeyUsage (EKU) field according to the following rules:
.
.
Server certificates presented for TLS shall have the Server Authentication purpose (id-kp
1 with OID 1.3.6.1.5.5.7.3.1) in the EKU field.

So, I am assuming that this validation is handled only in Splunk enterprise's  common criteria mode. 

[PickleRick]

If that is true (never tested it this way myself) that would be unexpected since when you're using cert-based client auth it requires that client's cert has client authentication usage.

[tscroggins]

I just tested forwarder version 9.1.1 on Windows with outputs.conf [tcpout] sslVerifyServerCert = true, and key usage is checked:

11-09-2024 20:57:30.517 -0500 ERROR X509Verify [85708 TcpOutEloop] - Server  X509 certificate (CN=splunk.example.com,O=Example,L=Washington,ST=District of Columbia,C=US) failed validation; error=26, reason="unsupported certificate purpose"

Edit: I tested in 9.0.3, and key usage is verified there as well.

splunkd, splunkweb, and mongod on Splunk Enterprise 9.3.0 do happily load and use the certificate, though.

My last conversation with Splunk on the topic was circa 8.2. I haven't had cause to test this specifically since then. Good to see!

[spilli]

Hi @tscroggins ,

Here are observations from my tests.

1)EKU extension exists with serverAuth – server cert accepted
2)EKU extension exists but without serverAuth, it is set to clientAuth – server cert rejected
3)EKU extension does not exist – server cert accepted.

I am referring to the 3rd test here, i.e. EKU does not exist.

Could you confirm which test case is the one you referred in your comment?

[PickleRick]

I'd have to dig through standards to confirm it but this actually makes sense. It's up to CA to define what the certificate is good for. ExtKeyUsage is an extension of X.509 which means it doesn't have to be present. If it is not present, one can assume that no restrictions have been imposed on key usage. Also rememher that this extension, even if present, could be marked as non-critical.

[tscroggins]

From RFC 5280 section 4.2.1.12:

---

If the extension is present, then the certificate MUST only be used for one of the purposes indicated. If multiple purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present. Certificate using applications MAY require that the extended key usage extension be present and that a particular purpose be indicated in order for the certificate to be acceptable to that application.

---

"If" and "MAY"--the easy way out. At a glance, OpenSSL's libssl only rejects unsupported certificate purposes if extended key usages are present [https://github.com/openssl/openssl/blob/master/crypto/x509/v3_purp.c] (the implementation may vary by version, of course; I'm making an assumption that earlier versions are similar):

/* ... */

#define xku_reject(x, usage) \
    (((x)->ex_flags & EXFLAG_XKUSAGE) != 0 && ((x)->ex_xkusage & (usage)) == 0)

/* ... */

/*
 * Key usage needed for TLS/SSL server: digital signature, encipherment or
 * key agreement. The ssl code can check this more thoroughly for individual
 * key types.
 */
#define KU_TLS \
    KU_DIGITAL_SIGNATURE | KU_KEY_ENCIPHERMENT | KU_KEY_AGREEMENT

static int check_purpose_ssl_server(const X509_PURPOSE *xp, const X509 *x,
                                    int non_leaf)
{
    if (xku_reject(x, XKU_SSL_SERVER | XKU_SGC))
        return 0;
    if (non_leaf)
        return check_ssl_ca(x);

    if (ns_reject(x, NS_SSL_SERVER))
        return 0;
    if (ku_reject(x, KU_TLS))
        return 0;

    return 1;

}

[tscroggins]

Speaking broadly (and without citing anything--ipse dixit), the consensus is an application (client and server) should require the presence of extended key usages to keep implementers from harming themselves, but it's not required.

If you identify a scenario in which Splunk Enterprise/Splunk Universal Forwarder are vulnerable to some attack independent of the implementer's choices, it would be wise to disclose the vulnerability privately to Splunk through https://advisory.splunk.com/report.

Otherwise, https://ideas.splunk.com/ is the best place to request new features, i.e. requiring extended key usages. I would upvote such an idea.

[PickleRick]

To be fully honest, I wouldn't upvote it. It's working as designed. If the issuer cannot be bothered to specify key usage, why would the client argue with the issuer? You wanna shoot yourself in the foot? Be my guest, here's the gun 😉

[tscroggins]

Ha. I do think splunkd etc. should require it when acting as a server, especially given that it requires it when acting as a client! You're right about lazy CA policies, though.

[PickleRick]

Splunkd requires TLS client usage if the usage is specifed. (Been there several times - customer used mutual auth and their CA issued wrong usage certs for UFs).

I also don't think I've seen a fairly modern CA which doesn't push usages by default in their policies. So it's a volenti non fit iniuria case when someone issues such crappy cert.

[tscroggins]

Hi,

When sslVerifyServerCert is true, Splunk verifies the trust chain, disallows self-signed certificates, and checks validity dates.  If you have certificateStatusValidationMethod = crl, Splunk will also verify the certificate against any revocation lists you have configured. Splunk does support OCSP.

The most recent common criteria evaluation covers Splunk TLS configuration quite well. See the administrative guide at https://www.niap-ccevs.org/products/11330.

As I recall from my last conversation with support/development, key usages are not verified, but you should contact support to confirm.