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
catenacyber
requested review from
victorjulien,
jasonish and
a team
as code owners
|
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.
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.
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.
at least for tls ja3 is for clients, ja3s for servers
There was a problem hiding this comment.
this is not our invention, just part of the official "standard" https://github.com/salesforce/ja3#ja3s
There was a problem hiding this comment.
So, you want two signature keywords ja3 and ja3s instead of using toclient or toserver ? Or ?
There was a problem hiding this comment.
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.
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_parametersStill to do more generally about quic : see https://redmine.openinfosecfoundation.org/issues/4966 (frame support)