[Openvas-discuss] openvasmd fails to start: fedora 16 atomic repo, GnuTLS internal error.

Stephen Villano stephen.p.villano at gmail.com
Tue Jan 10 05:32:29 CET 2012


That goes into permissions, as I previously mentioned. 
In THIS case, it appears that the CA isn't being accepted as trusted. 
I'd take, at a guess, that the CA isn't trusted at all. I'd have to dig down deep into the source to see if it's self-signed at machine level or working off of an external CA (I'd go with NOT, for the latter and yes for the former) and a configuration change in Fedora not permitting the self-signed certificate authority of your server.
In short, your server doesn't accept trust of itself.
Ran into that in the DoD, when we had a cert change, some years ago.
PKI troubleshooting is annoying, due to the difference in logged errors in differing environments.
I'd go for checking trusts first, see if openvas keys are trusted AND if self-signed certificates are trusted on that machine.

On Jan 9, 2012, at 11:24 PM, Richard Colley wrote:

> I've tried a few more things ... it seems there has been some changes
> in GNU TLS that may break some code.  See here for some details
> https://savannah.gnu.org/support/?107660#comment3
> 
> I have now rebuilt openvas libs, openvassd & openvasmd.  But openvasmd
> refused to ssl handshake properly.  I'll try and spend more time today
> on it.
> 
> Interestingly, when I connect to openvassd with 'openssl s_client',
> there is no problem.  The ssl handshake proceeds correctly.  From this
> I am assuming that openvassd is functioning ok.
> 
> Also, I tried running openssl s_server listening on port 9391 (instead
> of openvassd), and tried to get openvasmd to connect.  It disconnects
> immediately.  The output from s_server shows:
> 
>  $ openssl s_server -debug -msg -state -accept 9391 -cert
> /var/lib/openvas/CA/servercert.pem -CAfile
> /var/lib/openvas/CA/cacert.pem -key
> /var/lib/openvas/private/CA/serverkey.pem
>  Using default temp DH parameters
>  ACCEPT
>  SSL_accept:before/accept initialization
>  read from 0xfe92b0 [0x1000380] (11 bytes => 0 (0x0))
>  ERROR
>  shutting down SSL
>  CONNECTION CLOSED
> 
> This suggests that s_server was trying to read 11 bytes, but got 0.
> Contrast this with connecting from s_client to s_server:
> 
>    $ openssl s_server -debug -msg -state -accept 9391 -cert
> /var/lib/openvas/CA/servercert.pem -CAfile
> /var/lib/openvas/CA/cacert.pem -key
> /var/lib/openvas/private/CA/serverkey.pem
>  Using default temp DH parameters
>  ACCEPT
>  SSL_accept:before/accept initialization
>  read from 0xfe92b0 [0x1000380] (11 bytes => 11 (0xB))
>  ...
> 
> Which shows that s_server was able to read 11 bytes from s_client.
> 
> Using the equivalent commands in the GNUTLS utils package, I get a
> similar result:
> 
>  $ gnutls-serv -d 9 --x509keyfile
> /var/lib/openvas/private/CA/serverkey.pem --x509certfile
> /var/lib/openvas/CA/servercert.pem --x509cafile
> /var/lib/openvas/CA/cacert.pem -p 9391
>  Set static Diffie-Hellman parameters, consider --dhparams.
>  Processed 1 CA certificate(s).
>  Echo Server listening on IPv4 0.0.0.0 port 9391...done
>  Echo Server listening on IPv6 :: port 9391...bind() failed: Address
> already in use
>  |<4>| REC[0x1b6c1e0]: Allocating epoch #0
> 
>  * Accepted connection from IPv4 127.0.0.1 port 38534 on Tue Jan 10
> 13:51:36 2012
>  |<2>| ASSERT: gnutls_constate.c:695
>  |<4>| REC[0x1b6c1e0]: Allocating epoch #1
>  |<2>| ASSERT: gnutls_buffers.c:637
>  |<2>| ASSERT: gnutls_record.c:969
>  |<2>| ASSERT: gnutls_handshake.c:2991
>  Error in handshake
>  Error: A TLS packet with unexpected length was received.
>  |<4>| REC: Sending Alert[2|22] - Record overflow
>  |<4>| REC[0x1b6c1e0]: Sending Packet[0] Alert(21) with length: 2
>  |<4>| REC[0x1b6c1e0]: Sent Packet[1] Alert(21) with length: 7
>  |<2>| ASSERT: gnutls_record.c:276
>  |<4>| REC[0x1b6c1e0]: Epoch #0 freed
>  |<4>| REC[0x1b6c1e0]: Epoch #1 freed
>  |<4>| REC[0x1b6c1e0]: Allocating epoch #0
> 
> So, I will look more closely at openvasmd to see why it's failing the
> ssl handshake.  It is entirely possible that gnutls is completely
> broken on fedora 16.  But I'll take a little more time before I admit
> defeat.
> 
> Richard
> 
> 
> On 10 January 2012 13:23, Stephen Villano <stephen.p.villano at gmail.com> wrote:
>> My late evening dyslexia on the order of distros...  :/
>> My notion was that the database wasn't created after the previous --rebuild, as I assume you had tried. I thought this was a second attempt, which would hint at database connection/permission issue.
>> Perhaps security settings have been changed in the newest version of Fedora.
>> Along with the depreciated functions...
>> 
>> On Jan 9, 2012, at 1:19 AM, Richard Colley wrote:
>> 
>>> Thanks for the response Stephen.  That error message is normal, and is
>>> always displayed the first time you run openvasmd --rebuild.
>>> Thereafter, the message isn't displayed.
>>> 
>>> With regards to building from source, in fact I've already started
>>> doing this.   But so far, no luck.
>>> 
>>> I built openvasmd from source, and this exhibited the same problem.
>>> So I rebuilt openvas-libraries from source, and the problem is still
>>> there!
>>> 
>>> Building the libs from source has uncovered one possible cause of the
>>> problem.  In misc/network.c there are a bunch of deprecated functions
>>> from GNU TLS being used.
>>> 
>>>    beta2/misc/network.c: In function ‘set_gnutls_priorities’:
>>>    beta2/misc/network.c:423:3: error: ‘gnutls_protocol_set_priority’
>>> is deprecated (declared at /usr/include/gnutls/compat.h:344)
>>> [-Werror=deprecated-declarations]
>>>    beta2/misc/network.c:424:7: error: ‘gnutls_cipher_set_priority’ is
>>> deprecated (declared at /usr/include/gnutls/compat.h:335)
>>> [-Werror=deprecated-declarations]
>>>    beta2/misc/network.c:425:7: error:
>>> ‘gnutls_compression_set_priority’ is deprecated (declared at
>>> /usr/include/gnutls/compat.h:339) [-Werror=deprecated-declarations]
>>>    beta2/misc/network.c:426:7: error: ‘gnutls_kx_set_priority’ is
>>> deprecated (declared at /usr/include/gnutls/compat.h:342)
>>> [-Werror=deprecated-declarations]
>>>    beta2/misc/network.c:427:7: error: ‘gnutls_mac_set_priority’ is
>>> deprecated (declared at /usr/include/gnutls/compat.h:337)
>>> [-Werror=deprecated-declarations]
>>>    beta2/misc/network.c: In function ‘open_SSL_connection’:
>>>    beta2/misc/network.c:829:3: error: ‘gnutls_transport_set_lowat’ is
>>> deprecated (declared at /usr/include/gnutls/compat.h:351)
>>> [-Werror=deprecated-declarations]
>>> 
>>> To get the build to work (though the final binary failed as already
>>> described), I had to add "-Wno-deprecated-declarations" to
>>> CMAKE_C_FLAGS.
>>> 
>>> I am going to try and replace the deprecated functions now ... but if
>>> the conversion is too hard, I probably won't have time to complete.
>>> 
>>> Unfortunately, Fedora isn't really based on RHEL.  Fedora is the
>>> use-most-recent-version-of-everything release.  So it's probably the
>>> case that the newer GNU TLS hasn't been widely used on other distros
>>> yet.  Maybe.
>>> 
>>> Anyway, I'll report here on success or otherwise of my changes.
>>> 
>>> Richard
>>> 
>>> 
>>> On 9 January 2012 16:47, Stephen Villano <stephen.p.villano at gmail.com> wrote:
>>>> One hint is what you posted:
>>>> md   main:WARNING:2012-01-09 04h35.12 utc:1353: sql_x:
>>>> sqlite3_prepare failed: no such table: meta
>>>> 
>>>> The sql tables weren't created, hence the server isn't coming up to listen
>>>> to any commands.
>>>> As I can't recall offhand the procedure for installing the database
>>>> schema/elements, I suggest reviewing the source documentation on
>>>> installation "the hard way" by compiling source and installing.
>>>> 
>>>> But, if it's any consolation, I put together a CentOs virtual machine a few
>>>> weeks back and it installed flawlessly.
>>>> As CentOs is built upon Redhat, as is Fedora, perhaps some security issues
>>>> are present or unresolved libs are an issue.
>>>> That would become apparent after installing the DB and reviewing any errors
>>>> as before.
>>>> 
>>>> On Jan 8, 2012, at 11:38 PM, Richard Colley wrote:
>>>> 
>>>> md   main:WARNING:2012-01-09 04h35.12 utc:1353: sql_x:
>>>> sqlite3_prepare failed: no such table: meta
>>>> 
>>>> 
>> 




More information about the Openvas-discuss mailing list