OpenSSL and AES in 5.4

Hi Everybody,

I'm a Net-SNMP newbie so please bear with me if the answers to the
following problems are obvious to you more experienced users...

I'm using Win32 and the current (@ 11Dec06) copy of the
net-snmp-5.4.0-ssl-1.win32.exe.

I have the matching source drop too.

My immediate goal is to send Traps from an application extension dll
that I am writing to a second machine which is hosting the vanilla
installation of the net-snmp.exe mentioned above. 

I believe I have tripped over several issues which stem from the support
of OpenSSL within Net-SNMP

I suspect that the following sequence of problems are fundamentally
caused by a bug in net-snmp-config.h. The most important problem is the
header file issue as it very effectively disables AES support in 5.4.

Specifically, some elements of the OpenSSL support within Net-SNMP are
not being pulled in by net-snmp-config.h when the Configure script is
calling for them.

At line 1377 there is a test for #if defined(USE_OPENSSL)..... #define
HAVE_AES.

I suggest that this test should changed to be #if
defined(NETSNMP_USE_OPENSSL)

Configure has thoughtfully defined NETSNMP_USE_OPENSSL a few lines
higher up.

I cannot find an example of "USE_OPENSSL" in any of the Net-SNMP
makefiles.

Without HAVE_AES no AES functionality works. Although SHA1 does work.
With this change AES is supported correctly.

I have also found a few bits of missed coding in keytools.c, see
"Symptom Three" for details.

There are four fault symptoms listed below:-

Symptom One: No AES support in SSL pre-built binaries.

Environment: Using the binary distribution from Net-SNMP listed above...

Snmptrapd.conf content as follows:-

disableAuthorization yes 

createUser -e 0x0102030405 spe MD5 auth_password DES crypt_password
createUser -e 0x0102030405 spemd5des MD5 auth_password DES
crypt_password
createUser -e 0x0102030405 spemd5aes MD5 auth_password AES
crypt_password
createUser -e 0x0102030405 speshades SHA auth_password DES
crypt_password
createUser -e 0x0102030405 speshaaes SHA auth_password AES
crypt_password

Now start snmptrapd.exe using the -d option.

Snmp gives the following output...

No log handling enabled - turning on stderr logging
c:\usr\etc\snmp/snmptrapd.conf: line 5: Error: Unknown privacy protocol
c:\usr\etc\snmp/snmptrapd.conf: line 7: Error: Unknown privacy protocol

This matches to the two lines attempting to register a user using an AES
cipher.

No decryption of AES encoded Traps occurs using this build. Testing
showed that combinations of MD5 or SHA1 and DES all work fine.


Symptom Two: AES cipher support missing from Net-SNMP API.

Environment: Now using headers generated from the source dist' of 5.4
using the following Configure line...

perl Configure --with-sdk --with-ssl --linktype=dynamic

Odd behaviour is observed regarding hash and cipher support...

MD5 is supported
SHA1 is supported
DES is supported
AES is not supported - and no obvious error messages are generated to
say "oi, I'm not compiled for AES - go away" when trying to use it. 

The actual mode of failure is a 0xffffffd3 (SNMPERR_USM_ENCRYPTIONERROR)
error from a send attempt. 

Is this how Net-SNMP is meant to report "not supported in this build"
errors?




Symptom Three: Using headers generated during the install of the above
binary distribution...

Generate_Ku() fails to report an error when an incorrect
usmHMACMD5AuthProtocol value is used.

The session.securityAuthKey is set to zeros and the
session.securityAuthKeyLen is set to -1, however the function return
code is SNMPERR_SUCCESS.

Inspection of the code indicates that in keytools.c at lines 136 and
line 140 the two EVP_DigestInit calls to OpenSSL do not have any status
checks. If no OpenSSL support is enabled via Configure correct error
reporting of MD5 hash errors are performed. 

Looking at further calls to EVP_ elsewhere in this function shows this
to be part of a pattern of not checking status upon return from EVP
calls.


Symptom Four: Makefile support for linking of OpenSSL static libraries
is faulty.

Environment: Still using headers generated from the source builds using
the Configure options listed above. Also using libeay32.lib and/or
ssleay32.lib from a static build of OpenSSL 0.9.8d.

Several missing symbols are reported at link time, and the netsnmp.dll
will fail to link. 

To resolve the link errors gdi32.lib should be added to the link library
list. 

The underlying reason for this is that the OpenSSL library uses several
screen functions to derive random data to create salts. When linking to
a .dll version of OpenSSL these are opaque to the caller.

An attempt to link to them when creating the netsnmp.dll using dynamic
libeay32.lib/ssleay32.lib modules will have no adverse effect. 

When linking to the static versions of the OpenSSL libraries these are
required to complete the link.

May I suggest that wherever libeay32.lib appears in the Win32 Makeifles
a gdi32.lib should always accompany it.




Regards,

   Simon

- --
Simon Edwards 


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users