search

elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.49k stars 8.05k forks source link

SIEM Network Info TLS Certificate Info Requirement #40470

Open neu5ron opened 5 years ago

neu5ron commented 5 years ago

Describe the feature: During the navigation in the Network tab for IP details, when looking into TLS/SSL information the data is returned based on the necessity of a server certificate fingerprint (tls.server_certificate.fingerprint.sha1). The issue currently, is when this value does not exist then no information can be displayed/shown. Because of TLS version 1.3 this will become much more prevalent (to a good amount this is already the case with many sites using TLS 1.3 already)

Also, even if a certificate does not exist there is the other values that are nice to have like JA3 hash and some SAN/server name information.

I would recommend that this required field/value tls.server_certificate.fingerprint.sha1 be removed.

Wouldn't call this a feature, but didn't want to submit in under bug either.

Describe a specific use case for the feature: Better support for TLS/SSL connection pivoting. Regardless of a certificate or not, it would still be useful to pivot with the values mentioned above (ja3, etc..)

elasticmachine commented 5 years ago

Pinging @elastic/secops

cwurm commented 4 years ago

@neu5ron tls.server_certificate.fingerprint.sha1 is calculated as the SHA-1 hash of the entire certificate in raw byte form. I think that should be possible even in TLS 1.3? When would this not be available?

Also, even if a certificate does not exist there is the other values that are nice to have like JA3 hash and some SAN/server name information.

I'm curious, when would JA3/SAN exist but not a certificate?

I would recommend that this required field/value tls.server_certificate.fingerprint.sha1 be removed.

We aggregate on this field to show one aggregated row per certificate (rather than showing one row per event or connection, where likely many would be showing the same certificates). Do you think there is a better field to aggregate on by default?

neu5ron commented 4 years ago

TLS 1.3 causes the majority (of what previously was previously visibile in <= TLS 1.2) to be negotiated in an encrypted channel. Think this is one of the better blogs I have seen showing this.

Maybe could perform the cardinality/agg on JA3 if the network view is for a source/client IP. Then for destination/server IP, I would say to use the server name/host or JA3s.

Technically speaking I am no expert on JA3/JA3s - but all I can say is it still exists in TLS 1.3 despite the metadata that is cut out of TLS 1.3 - because the ja3/ja3s fingerprinting is performed on the negotiating ciphers.

dcode commented 4 years ago

@cwurm SAN comes from an x509 certificate, so it shouldn't exist without any certificate info.

You could however get "server name" from SNI, which the client sends to the server, which allows for a virtual host implementation on the TLS endpoint.

JA3 is not dependent on certificates at all, which is why you can get fingerprints for common clients. Conventionally, the TLS server endpoint would be the only host required to present a certificate, but this is primarily for HTTPS, as that protocol requires that to be true. TLS on the other hand can be used in many more use-cases than just HTTPS. Namely, there are TLS-PSK for using pre-shared keys TLS-SRP for "secure remote passwords". Neither of these requires x509 certificates, but would present a valid TLS connection with a JA3 fingerprint on the cipher negotiation on both sides of the connection.