TLS Session Fields

[peterpramb]

Is there already a consensus as to where to place session properties for TLS sessions? I found some reference to a tls subtree in #64, but nothing in the schema itself.

Will there be some session.tls group or the like with TLS session related fields, eg. protocol versions, ciphers, session identifier, and the like?

[webmat]

Yes, TLS is the next protocol in line after dns. So it's coming.

But I would recommend you proceed with custom fields for now. It would even be appreciated if you commented here (or opened a PR) with the way you've done it, or the way you think would make most sense.

Another thing you could consider is looking at how Packetbeat does it. We will likely start from this, see if it needs adjustments. If we determine we need to change things vs Packetbeat, we'll provide guidance on migration, which you may then be able to leverage for yourself :-)

[peterpramb]

Thanks for the hint.

The field list in Packetbeat is fairly exhaustive. The only missing field for our use case is the verification result of the provided client certificate (which is really an application property and nothing available on network level), so for the sake of completeness something like:

- name: tls.client_certificate_verification_result
  type: keyword
  description: >
    The result of the server side verification of the provided client certificate.
    This is specific to the application terminating the TLS session. The value
    depends on the TLS library in use. With OpenSSL the resulting string is
    usually one of 'NONE', 'SUCCESS', 'GENEROUS', or 'FAILED:reason'.

And for the certificate attributes I specifically miss (L)ocality and Street, which can be ocasionally seen in the wild.

[webmat]

@peterpramb Thanks for the feedback! We'll be coming back to this, when we work on TLS

[webmat]

Closing, as #606 should address this.

[peterpramb]

Unfortunately it still does not contain anything where I can put the client certificate's verification result (see my comment above) as provided by various TLS terminating applications like web servers...

[webmat]

@peterpramb We're getting there, tls.* was only the first part. The certs are coming #762, this will be good for TLS sessions, code signatures, eventually email and other things.

[peterpramb]

Ok, fine for me.