OpenVAS Change Request #17: OTP: Make NVT signatures available to OpenVAS-Client
Status: Voted +1. Done. Implemented with SVN 1742.Purpose
To make NVT signatures more transparent to the user and ultimately enable the user to verify the trust set in the NVTs.
References
Rationale
In the current implementation, NVT signatures are verified by OpenVAS-Server. The server can be configured to enable only signed and trusted NVTs and will in that case only transmit those NVTs to the client which are signed with a trustworthy signature.
This behavior leaves no way for the user to verify who signed which NVT and prevents him from making up his own mind regarding the trustworthiness of the NVTs he is about to execute since the signature information is not transmitted to the client.
A better option would be to provide the OpenVAS client (and therefore the user) with more information regarding plugin signatures.
Effects
This change would add protocol elements to OTP 1.0 which enable the server to transmit signature and trust data to the client and would introduce handling for this new element in the appropriate places. It would also extend the client GUI to display the information received from the server to the user.
Design and Implementation
The signature information will be included in the PLUGIN_INFO and PLUGIN_LIST
message types as a last element; this is the easiest solution.
The current per-NVT response is:
oid <|> name <|> category <|> copyright <|> description <|> summary <|> family <|> plugin_version <|> cve_id <|> bugtraq_id <|> xrefs
After the change it would become:
oid <|> name <|> category <|> copyright <|> description <|> summary <|> family <|> plugin_version <|> cve_id <|> bugtraq_id <|> xrefs <|> nvt_fprs
"nvt_fprs" is a list of the fingerprints of the keys used to sign this NVTs separated by commas. The size of the new field is restricted to 48*3+2 characters, which allows 3 fingerprints to be commited.
The server implements a command that allows the client to retrieve all
the certificates (public keys) that are known to the server with a value
indicating whether the server trusts this certificated or not. This could
happen in the following way:
Client:
CLIENT <|> CERTIFICATES <|> CLIENT
Server:
SERVER <|> CERTIFICATES
[certificate_fpr] <|> [owner_name] <|> [trusted/untrusted] <|> pubkey_nr_bytes <|> pubkey_ascii
[certificate_fpr] <|> [owner_name] <|> [trusted/untrusted] <|> pubkey_nr_bytes <|> pubkey_ascii
[certificate_fpr] <|> [owner_name] <|> [trusted/untrusted] <|> pubkey_nr_bytes <|> pubkey_ascii
<|> SERVER
where pubkey_ascii is the full public key, ascii-armored and with newlines being replaced by semicolons (to keep a consistent mechanism with other otp commands that might send newlines).
Following changes have been done:
Changes in openvas-client
- A new field (simple string as transmitted - see above) in the plugin struct and access methods for it were added in nessus/plugin.c.
- General protocol changes are reflected in the clients "Communication Manager" nessus/comm.c
- Fingerprints are included in the client-side cache (nessus/plugin_cache.c).
- A copy of the openvas_certificate struct and functions (see below) is included in the client. The duplicate issue will be resolved in future versions.
- Certificate data is held per scope in the context in a GHashTable, where fingerprints are keys and pointers to the certificate structs are values.
- Signatures and the servers trust in that key are shown in the plugin info dialog. A button allows to open a window with a text view of the public key.
Changes in openvas-libraries / openvas-libnasl
- Unfortunately, duplicates of changes made to the plugin and openvas_certificate struct in the client. Duplicate will be resolved through merge and dependency openvas-client -> openvas-libraries. Changes in openvas-libnasl should be moved to openvas-libraries, as there is no nasl specificity anymore (e.g. signed OVAL plugins).
- Extraction of key-ids using gpgme.
- Extraction of certificate information using gpgme.
Changes in openvas-server
- General protocol changes are reflected in the servers "Communication Manager" openvasd/comm.c and handling the elements in /openvasd/otp_1_0.h/c.
- The cache uses the new field (in nessus/pluginload.c).
- Sends list of certificates.
History
- 2008-11-14 Felix Wolfsteller <felix.wolfsteller@intevation.de>:
Updated to fit actual implementation, marked done. - 2008-10-22 Felix Wolfsteller <felix.wolfsteller@intevation.de>:
Updated design and implementation part - 2008-10-16 Michael Wiegand <michael.wiegand@intevation.de>:
Updated protocol specification. - 2008-10-13 Michael Wiegand <michael.wiegand@intevation.de>:
Initial text.
English |
