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

Richard Colley rcolley at cardaccess.com.au
Tue Jan 10 05:52:02 CET 2012

I don't think so ... I think the evidence shows otherwise.

In this case, openvasmd attempts to connect to openvassd (or in my
test cases gnutls_serv or openssl s_client), and
openvassd/gnutls_serv/s_client read 0 bytes immediately after
accepting the connection.  i.e. no data has been exchanged yet, so
there's been no chance to exchange certs and negotiate the session.

I also forgot to mention I watched with tshark/tcpdump the connection
attempt.  Here's a sample (complete trace):

  0.000000 ->    TCP 74 38558 > 9391 [SYN]
Seq=0 Win=32792 Len=0 MSS=16396 SACK_PERM=1 TSval=95755968 TSecr=0
  0.000018 ->    TCP 74 9391 > 38558 [SYN, ACK]
Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 SACK_PERM=1 TSval=95755968
TSecr=95755968 WS=16
  0.000031 ->    TCP 66 38558 > 9391 [ACK]
Seq=1 Ack=1 Win=32800 Len=0 TSval=95755968 TSecr=95755968
  0.002405 ->    TCP 66 38558 > 9391 [FIN, ACK]
Seq=1 Ack=1 Win=32800 Len=0 TSval=95755971 TSecr=95755968
  0.002515 ->    TCP 73 9391 > 38558 [PSH, ACK]
Seq=1 Ack=2 Win=32768 Len=7 TSval=95755971 TSecr=95755971
  0.002532 ->    TCP 54 38558 > 9391 [RST]
Seq=2 Win=0 Len=0

This seems to show the connecting end (openvasmd) closing the
connection (sent a FIN) before any data had been exchanged.

Is there anything I've missed that still indicates to you that there
is a pki trust issue at this point?

Thanks for your continued input.


On 10 January 2012 15:32, Stephen Villano <stephen.p.villano at gmail.com> wrote:
> 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
>>  SSL_accept:before/accept initialization
>>  read from 0xfe92b0 [0x1000380] (11 bytes => 0 (0x0))
>>  shutting down SSL
>> 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
>>  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 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 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
>>>> 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