Change "key:value" notation in field "finding" #830
Milestone
Comments
|
Just doing some brainstorming over this while working on a similar matter... As privately communicated: It would makes sense. So instead of: an output like (change in last line) It would be a bit at the cost of readability for humans and as you said a breaking change. But sometimes there need to be changes and I hope if people use the dev tree they don't to a git pull and run it without review 1:1 in production. |
drwetter
added a commit
that referenced
this issue
Jan 22, 2018
The server default run had several JSON objects which weren't, looking at just
the ID, either clear or contained a redundant explanation in "finding". Purely
certificate related JSON objects are now having the id "cert_<object>" like
cert_CN or cert_SAN.
This commit changes all this, also it avoids another colon in finding (see #830).
Also the implicit strategy "output for the screen s followed by only one output with
fileout" has been relaxed -- which results on more, better parsable JSON objects.
Some example of the changes:
Old:
----
{
"id" : "Server Certificate #1 fingerprint",
"severity" : "INFO",
"finding" : "Fingerprints / Serial: SHA1 2940BC13ECF7DAF30B9084CC734C3B971D73B3BB / 01BFD1DC15006E0ABBA7C670FF5E1101, SHA256 30BA61012FFE7CEAAF9A148A0CB0C5C852A9C04F4B1C27DB6
EFA9919C7F49CCF"
}
[..]
{
"id" : "Server Certificate #2 ocsp_stapling",
"severity" : "OK",
"finding" : "OCSP stapling : offered"
}
New:
----
{
"id" : "cert_key_size <cert#1>",
"severity" : "INFO",
"finding" : "Server keys 2048 bits"
},{
"id" : "cert_fingerprint_SHA1 <cert#1>",
"severity" : "INFO",
"finding" : "2940BC13ECF7DAF30B9084CC734C3B971D73B3BB"
},{
"id" : "cert_fingerprint_SHA256 <cert#1>",
"severity" : "INFO",
"finding" : "30BA61012FFE7CEAAF9A148A0CB0C5C852A9C04F4B1C27DB6EFA9919C7F49CCF"
},{
"id" : "cert_serial <cert#1>",
"severity" : "INFO",
"finding" : "01BFD1DC15006E0ABBA7C670FF5E1101"
}
[..]
{
"id" : "OCSP_stapling <cert#2>",
"severity" : "OK",
"finding" : "offered"
}
This PR also fixes the JSON output where for "OCSP must staple" the id was just
'id" : "OCSP must staple: ocsp_must_staple",' for multiple server
certificates without the certificate number.
As far as the code is concerned: $json_prefix should be a variable which is
used for the id object. If there was more then one certificates for a single
host detected, $json_postfix carries the certificate number.
Unit tests need to be fixed -- if possible.
|
closing this, see #970 (also for continuing any communication) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, the "finding" field in JSON output may contain a "key : value" pairs, such as:
While that "key : value" format is helpful when directly displayed to the user, it requires parsing when only the value part is needed. Example scenarios are displaying the scan results in a table where the key part is the columns header but should not repeat in every cell. Also any other type of further processing the data, like monitoring on certificate expiration dates or counting the list of SAN of a certificate.
My recommendation would be to add a command line switch to suppress the key part in the finding (in the above example "OCSP stapling") as well as " : " and only include the value part (again in above example "not offered").
The text was updated successfully, but these errors were encountered: