-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Quic ietf 4967 v5 #7106
Quic ietf 4967 v5 #7106
Conversation
Ticket: 4967 The format of initial packet for quic ietf, ie quic v1, is described in rfc 9000, section 17.2.2
so that we can use new functions in quic parser
and logs interesting extensions from crypto frame
As it can be 4, but it can also be 1, based on the first decrypted byte
The way to determine if the payload is encrypted is by storing in the state if we have seen a crypto frame in both directions...
So as to keep parse not too big
for detection
Ticket: 5143
Ticket: 5166
Looking much better
No other versions than these. |
ja3 situation remains unchanged. A single IP in my network has 993 unique values, which seems suspicious. If it is correct, then I seriously question if we should bother with ja3 at all for quic. |
Oops, forgot to update S-V test with new extensions naming |
let extv = quic_get_tls_extensions(ch.ext, &mut ja3, true); | ||
return Ok((rest, Frame::Crypto(Crypto { ciphers, extv, ja3 }))); | ||
} | ||
ServerHello(sh) => { |
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.
In TLS/tcp we only have ja3
for client hello iirc, for the server side there is ja3s
. How is that here?
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 used only one ja3
.
I do not understand why there should be a different naming.
The client ja3 has EllipticCurve and EllipticCurvePointFormat data while the server does not have them (as the server is not supposed to send such extensions) cf quic_tls_ja3_client_extends
Does that answer your question ?
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.
at least for tls ja3 is for clients, ja3s for servers
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 is not our invention, just part of the official "standard" https://github.com/salesforce/ja3#ja3s
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.
So, you want two signature keywords ja3
and ja3s
instead of using toclient
or toserver
? Or ?
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 want to it match how we do it for tls, unless there is a good reason not to do that.
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.
Done in #7130
I find it a bit strange as a code duplication, but I do not think this reason is good enough
I think it is correct. |
Needs OISF/suricata-verify#780 |
WARNING:
Pipeline 6470 |
Replaced by #7118 |
Link to redmine ticket:
https://redmine.openinfosecfoundation.org/issues/4967
https://redmine.openinfosecfoundation.org/issues/5143
https://redmine.openinfosecfoundation.org/issues/5166
Describe changes:
suricata-verify-pr: 775
OISF/suricata-verify#775
Replaces #7101 with
quic_transport_parameters
Still to do more generally about quic : see https://redmine.openinfosecfoundation.org/issues/4966 (frame support)