A logger process being terminated/killed while in the process of creating
a new .shadow file may leave an empty (invalid) one around. This in turn
causes the logger to error and exit during startup.
$ $ ls -lha .shadow.*
-rw-r--r-- 1 root root 0 Dec 16 18:48 .shadow.dns.log
-rw-r--r-- 1 root root 0 Dec 16 18:48 .shadow.packet_filter.log
$ zeek LogAscii::enable_leftover_log_rotation=T Log::default_rotation_interval=30sec -i wlp0s20f3
error in <params>, line 1: failed to process leftover log 'dns.log': Found leftover log, 'dns.log', but the associated shadow file, '.shadow.dns.log', required to process it is invalid
error in <params>, line 1: failed to process leftover log 'packet_filter.log': Found leftover log, 'packet_filter.log', but the associated shadow file, '.shadow.packet_filter.log', required to process it is invalid
$ ...
Prevent creating invalid .shadow files by atomically creating them.
This event is raised for messages that (probably) are TLS 1.3 handshake
messages, including finished. This allows scripts to examine handshake
messages without having to handle all encrypted messages.
In TLS 1.3, the ChangeCipherSpec message is meaningless; it only is
included to convince middleboxes that the devices actually are speaking
TLS 1.2. Nowadays some TLS 1.3 implementations also just don't send the
packet.
In a push to unify our handling of TLS 1.3 connections - ignore CCS and
always go with application data packet counting to determine if
connections are or are not encrypted.
Otherwise, the global Broker manager object containing CAF/threading
logic is never destructed and can result in a heap-use-after-free if it
tries to access other global objects after they're cleaned up from
__cxa_finalize().
This commit changes the logic that is used to tracks connection
establishment - and moves it from scriptland into the core.
TLS 1.3 connection establishment is much more finnicky for us than the
establishment of earlier versions - since we cannot rely on the CCS
message anymore (which is meaningless and not sent in a lot of cases).
With this commit, the ssl_encrypted_data message gets raised for
encrypted TLS 1.3 handshake messages - which is much more correct than
the behavior before that just interpreted them as plaintext messages.
I will refine this a bit more - at the moment the connection established
event happens a bit too early - earlier than TLS 1.3 connections
actually can be estasblished.
Part of GH-1323
Otherwise there is a functional problem caused by using #include to
insert the disconnected source code: language server/analysis tools,
like clangd, may get confused by those files and report everything
in them as an error.
* Rename overly generic ACCESSORS macro with ZEEK_ prefix
* A few places where whitespace was noticeably wrong/distracting
* Minor/obvious reference/move semantics improvements suggested by linter
* Remove unused detail::Scope::Remove(), no need for deprecation
Previously, an assertion was triggered in debug builds upon any attempt
to insert or remove a Dictionary entry while any iteration of that
Dictionary is underway and also even in cases where Dictionary membership
was not actually modified (and thus invalidates a loop).
Now, it emits run-time warnings regardless of build-type and only when
insert/remove operations truly change the Dictionary membership. In the
context of a Zeek script causing an invalidation, the warning message
also now helps pinpoint the exact expression that causes it.
Merge adjustments:
- Fix the `--with-caf=` option from emitting messages about a variable
having an unset value.
- Fix the `zeek-config --caf_root` option
* origin/topic/neverlord/caf-migration:
Update submodule(s)
Fix message ordering of Broker messages
Fix UB in shutdown of Broker manager
Preserve string output of Broker errors
Migrate to CAF 0.18
