Bug 1198554

Created attachment 997855 [details]
Proposed fence agent

@Gerwin:

can you try to run fence agent (with current library) on your machine. It should be enough to use new option --notls which should solve this problem.

Hi Marek,

Does not work here:

./fence_ilo -o status -a 172.19.1.40 -l XXXXX -p XXXXXXX --notls -v
Running command: /usr/bin/gnutls-cli --priority "NORMAL:-VERS-TLS1.2:-VERS-TLS1.1:-VERS-TLS1.0:+VERS-SSL3.0" --insecure --crlf -p 443 172.19.1.40
Sent: <?xml version="1.0"?>

Unable to connect/login to fencing device

btw fence_ilo is same as fence_ilo2?

Hi,

can you take a look what will happend when you run that gnutls command directly? possibly with --verbose, so we can see where the problem is

output ilo2 2.27 - with oemhp_ssl_v3_enable=no (default in 2.27!)
=================================================================
openssl s_client -connect  x.x.x.x:443 -no_tls1_2 -no_tls1_1 -no_tls1:
SSL handshake has read 0 bytes and written 124 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NON

output ilo2 2.27 - with oemhp_ssl_v3_enable=yes
================================================
openssl s_client -connect  x.x.x.x:443 -no_tls1_2 -no_tls1_1 -no_tls1:

SSL handshake has read 1566 bytes and written 338 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 03F64F841BC33C593C4016866E59209389762EFD5701168EC57CA23C9E46E90E
    Session-ID-ctx:
    Master-Key: 05BC5524F3C97CD7EDDCB71A691C734301702F0DA1F5D86714EC8A9C5E660450D9327673F667DFD4ACEC998532BF783C
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1425483129
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)

Resolving '172.19.1.40'...
Connecting to '172.19.1.40:443'...
*** Fatal error: A TLS packet with unexpected length was received.
*** Handshake has failed
GNUTLS ERROR: A TLS packet with unexpected length was received.

Thanks, I will try to obtain a machine with that firmware and fix the issue.

If you have problems finding one. I can can help you with that :-) Just let me know.

@Gerwin: that will be great; I hope that I will need it just for a while.

@Gerwin:

thanks a lot, you can close connection.

as official fix will follow later, hotfix is

change line with 'gnutls_opts = ' in fencing.py to

gnutls_opts = "--priority \"NORMAL:-VERS-TLS1.2:-VERS-TLS1.1:+VERS-TLS1.0:%LATEST_RECORD_VERSION\""

that way, if you will use --notls, it should work as expected. 

Problem is that HP iLO2 supports only TLS1.0

In gnutls-cli (v2.8) there is not a required option. Bug against gnutls was created and if it will be approved, we will fix this issue.

Raising priority/severity based on recent customer case.

We have fix that does not need change in gnutls.

Created attachment 1009609 [details]
Proposed patch to fence_ilo

@John:

Proposed patch to add gnutls-cli support. In order to not break anything, fence agent will:

Try to connect using nss_wrapper as before and only if this fail, we will fallback to gnutls-cli.

This way, we can be sure that existing functionality will not be broken. Patch is quite simple, so code review by someone else will be fast.

Great, I'll see if the customer can test this.  

Thanks

@marek
Do you have the complete patched script? I will test it here then.

One small issue, one with your test build that's not in your patch posted at https://bugzilla.redhat.com/attachment.cgi?id=1009609&action=diff.  path specified was /usr/bin/gnutls, not gnutls-cli.  In RHEL 7 its provided by autoconf so we didn't have to worry about it, so I think the manual entry just led to a typo here. I built a new package with the correct path and tested it against your ilo and it works (status only, at least).  Customer is confirming in their environment, and we'll report back. 

I'm going to go ahead and start the ball rolling on the z-stream request now.

Justification: this issue requires customers that rely on iLO devices to maintain a widely-publicized security hole on these devices for the sake of compatibility with our fence agent.  Releasing a fix for this will allow our product to work with the iLO firmware version that closes that security hole, and so it is not only important for this customer, but we will surely see a number of others looking for this in 6.6.z in the months to come.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1350.html