-
Notifications
You must be signed in to change notification settings - Fork 488
Add support for TLS protocol tracing #2096
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for TLS protocol tracing #2096
Conversation
src/stirling/source_connectors/socket_tracer/testing/containers/ssl/nginx.conf
Outdated
Show resolved
Hide resolved
7de9384 to
b8ed611
Compare
8c0cffd to
3e556d6
Compare
Signed-off-by: Dom Del Nano <ddelnano@gmail.com>
3e556d6 to
8ff4143
Compare
Signed-off-by: Dom Del Nano <ddelnano@gmail.com>
| HandshakeType handshake_type; | ||
|
|
||
| uint24_t handshake_length; | ||
| uint24_t handshake_length = uint24_t(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GCC fails if this isn't initialized (buildbuddy failure)
src/stirling/source_connectors/socket_tracer/bcc_bpf/protocol_inference.h
Show resolved
Hide resolved
src/stirling/source_connectors/socket_tracer/bcc_bpf/protocol_inference.h
Show resolved
Hide resolved
src/stirling/source_connectors/socket_tracer/socket_trace_connector.cc
Outdated
Show resolved
Hide resolved
src/stirling/source_connectors/socket_tracer/tls_trace_bpf_test.cc
Outdated
Show resolved
Hide resolved
| {"req_type", "The type of request from the TLS record (Client/ServerHello, etc.)", | ||
| types::DataType::INT64, | ||
| types::SemanticType::ST_NONE, | ||
| types::PatternType::GENERAL_ENUM}, | ||
| {"version", "Version of TLS record", | ||
| types::DataType::INT64, | ||
| types::SemanticType::ST_NONE, | ||
| types::PatternType::GENERAL_ENUM}, | ||
| {"extensions", "Extensions in the TLS record", | ||
| types::DataType::STRING, | ||
| types::SemanticType::ST_NONE, | ||
| types::PatternType::GENERAL}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have examples of the records we would see? Is version and extensions valid on all those records?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This gist shows the output from stirling_wrapper (also copied below). Note: that the content type and version fields will have carnot function support that turn their integer representations into human readable strings. I already have that completed, but wanted to make that its own PR.
record=[
req=[TLS Frame [len=216 content_type=22 legacy_version=769 handshake_version=771 handshake_type=1 extensions={"server_name":"[\"google.com\"]"}]
resp=[TLS Frame [len=100 content_type=22 legacy_version=771 handshake_version=771 handshake_type=2 extensions={}]
]
As of now, the tls_events table inserts one record for each TLS handshake. Thus, the version and extensions columns will always have a value. I think it could be useful to support alert, heartbeat, or change cipher messages in the future. These messages don't contain extensions, and while they do have a "version" field, it is the legacy version used in TLS 1.2 and earlier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@oazizi000 after our discussion on the tls_events table schema, I made the following changes in 3f80935:
- Renamed
req_typetocontent_type: this better matches what was already inserted into the table (handshakes) and will map nicely to alerts, heartbeats, etc. - Removed the
extensionscolumn in favor ofreq_bodyandresp_body: this allows for storing extensions that exist on both the client and server side and means that the field is no longer specific to handshake records.
Signed-off-by: Dom Del Nano <ddelnano@gmail.com>
Signed-off-by: Dom Del Nano <ddelnano@gmail.com>
…TLS records. Update JSON parsing to better match new structure Signed-off-by: Dom Del Nano <ddelnano@gmail.com>
f48ebb6 to
3f80935
Compare
| canonical_data_elements::kLocalPort, | ||
| canonical_data_elements::kTraceRole, | ||
| {"req_type", "The type of request from the TLS record (Client/ServerHello, etc.)", | ||
| {"content_type", "The content type of the TLS record (e.g. handshake, alert, heartbeat, etc)", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit/subjective: Feel like the original req_type or something like message_type might be a better name, but I'll let you make the final call.
Part of the rationale is that there's a req_body, so req_type/req_body seem to pair up better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was originally thinking that req_type could be confusing since a TLS 1.2 handshake (content type -- name per TLS spec) results in 2 round trips and 2 requests (ClientHello/ServerHello exchange followed by key exchange and cipher spec messages).
After thinking about it more, I've renamed it to req_type in 256b76e for consistency with our other tables.
… col in favor of later use of req_body/resp_body. Clean up duplicated body field on tls::Frame type Signed-off-by: Dom Del Nano <ddelnano@gmail.com>
Signed-off-by: Dom Del Nano <ddelnano@gmail.com>
Summary: Add support for TLS protocol tracing This is the final change to wire up the tls protocol parser and stitcher into stirling. I've also filed pixie-io#2095 to track supporting tracing TLS handshakes and the application data. Relevant Issues: N/A Type of change: /kind feature Test Plan: New tests verify functionality works end to end Changelog Message: Added support for tracing TLS handshakes. This can be enabled with `--stirling_enable_tls_tracing=1` or through the `PX_STIRLING_ENABLE_TLS_TRACING` environment variable. Until pixie-io#2095 is addressed, this will disable tracing the plaintext within encrypted connections. --------- Signed-off-by: Dom Del Nano <ddelnano@gmail.com> GitOrigin-RevId: 33e3fdd
Summary: Add support for TLS protocol tracing
This is the final change to wire up the tls protocol parser and stitcher into stirling. I've also filed #2095 to track supporting tracing TLS handshakes and the application data.
Relevant Issues: N/A
Type of change: /kind feature
Test Plan: New tests verify functionality works end to end
Changelog Message: Added support for tracing TLS handshakes. This can be enabled with
--stirling_enable_tls_tracing=1or through thePX_STIRLING_ENABLE_TLS_TRACINGenvironment variable. Until #2095 is addressed, this will disable tracing the plaintext within encrypted connections.