English | Deutsch
Home »

OpenVAS Change Request #17: OTP: Make NVT signatures available to OpenVAS-Client

Status: Voted +1. Done. Implemented with SVN 1742.


To make NVT signatures more transparent to the user and ultimately enable the user to verify the trust set in the NVTs.


Discussion on mailing list.


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.


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:


[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

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

Changes in openvas-libraries / openvas-libnasl

Changes in openvas-server