Bug 12536 - JA3 does not seem to be enabled when necessary on Core Update 153
Summary: JA3 does not seem to be enabled when necessary on Core Update 153
Status: NEW
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: unspecified Unspecified
: Will affect an average number of users - Unknown -
Assignee: Stefan Schantl
QA Contact:
URL:
Keywords:
Depends on:
Blocks: 12507
  Show dependency treegraph
 
Reported: 2020-11-19 11:52 UTC by Michael Tremer
Modified: 2021-10-23 11:23 UTC (History)
1 user (show)

See Also:


Attachments
Log (1.68 KB, text/plain)
2020-11-19 11:52 UTC, Michael Tremer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Tremer 2020-11-19 11:52:36 UTC
Created attachment 804 [details]
Log

When I start suricata 6 on my c153 installation, JA3 does not seem to be enabled:

> ja3 support is not enabled

Please see the attached log for more details.

My configuration file has the line "ja3-fingerprints: auto" from https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=0937bd9c01fd4c56fdee688e887958dc72a9b03b.
Comment 1 Stefan Schantl 2020-11-19 19:22:33 UTC
Hello Michael,

thank you for your report. I did the same testing and got the same result.

So I digged a bit deeper and set the "ja3-fingerprints" option to "yes" for allways on and got the following line in the log.

[ERRCODE: SC_WARN_NO_JA3_SUPPORT(308)] - no MD5 calculation support built in (LibNSS), disabling JA3

After searching the web I got to the following page:

https://lists.openinfosecfoundation.org/pipermail/oisf-users/2020-April/017451.html

It seems that the ja3 feature depends on libnss which is currently not part of IPFire.

There are two possible options how to deal with this issue:

1.) Implement another crypto library and add libnss to support ja3.

2.) Don't support ja3 and revert the commit which introduced it.
Comment 2 Michael Tremer 2020-11-19 21:02:48 UTC
I do not really know what is best really.

NSS is a PITA. We do not need it for anything else and if I had a choice I would rather remove a crypto library than add one. We packaged NSS for IPFire 3 before and it does not really have releases, or anything else.

It would be interesting to know why suricata made that choice to use NSS. I went through the source code and there isn't too much that it is being used for. It is simply being used to calculate MD5, SHA1 and SHA256 sums.

Would you be interested in contacting them and see how they feel about OpenSSL?
Comment 3 Michael Tremer 2020-12-30 11:41:02 UTC
I have opened a ticket on Suricata's bug tracker:

> https://redmine.openinfosecfoundation.org/issues/4243

I would like to migrate to OpenSSL rather than shipping NSS with IPFire.
Comment 4 Michael Tremer 2020-12-30 13:58:02 UTC
suricata has said that they will move away from NSS in favour of RustCrypto.

So we do not have to do anything here and just wait for that to land.