Description of problem:
After updating from openssl-0.9.6b-31 to openssl-0.9.6b-33, all applications
linked with OpenSSL fail all RSA operations. OpenSSH, Apache, imapd. Reverting
to openssl-0.9.6b-31 restores service.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Get a box with a bcm5820 SSL accelerator card
2. Edit /usr/share/ssl/openssl.cnf to set [engine] default = ubsec
3. Update to openssl-0.9.6b-33
I'm running kernel 2.4.18-19.8.0smp (I have updated further but have not
rebooted), openssl-0.9.6b-33, bcm5820 Cryptonet driver (Dell-OEM Broadcom SSL
[ engine ]
default = ubsec
I will try the obvious troubleshooting steps of rebooting with new kernel and
removing the "default = ubsec" when I can schedule the downtime, but am posting
this early in case anyone else has input. I do not have a surplus test machine
with an SSL accelerator card.
I got bit by this as well, only I'm still running RedHat 7.3. I'm running
openssl-0.9.6b-32.7 and that appears to broken with respect to hwcrypto.
Earlier versions of openssl worked and I'm also running
kernel-smp-2.4.18-27.7.x. The crypto card is an BroadCom card and simply
stopping the bcm5820 service caused the problem to go away.
Recompiling the hwcrypto package didn't seem to help any. I haven't modified my
openssl.cnf file (default is still set to openssl) but as I understand it,
openssl will use the card if its available so I think we're running basically
the same config.
redhat linux 7.3
the same with 0.9.6b-18 and 0.9.6b-30
[iro@web1 ssl]$ /www/ssl/bin/openssl s_client -connect web2:443 -state -debug
write to 08188710 [08188FB8] (142 bytes => 142 (0x8E))
0000 - 80 8c 01 03 01 00 63 00-00 00 20 00 00 39 00 00 ......c... ..9..
0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0 8..5............
0020 - 00 00 33 00 00 32 00 00-2f 03 00 80 00 00 66 00 ..3..2../.....f.
0030 - 00 05 00 00 04 01 00 80-08 00 80 00 00 63 00 00 .............c..
0040 - 62 00 00 61 00 00 15 00-00 12 00 00 09 06 00 40 b..a...........@
0050 - 00 00 65 00 00 64 00 00-60 00 00 14 00 00 11 00 ..e..d..`.......
0060 - 00 08 00 00 06 04 00 80-00 00 03 02 00 80 54 f5 ..............T.
0070 - ad 5b 9c 6a fa 01 fe 12-24 a6 d7 e2 b7 bb 11 3a .[.j....$......:
0080 - 6f 92 e9 07 86 33 bb 71-45 1f e4 4d 47 4c o....3.qE..MGL
SSL_connect:SSLv2/v3 write client hello A
read from 08188710 [0818E518] (7 bytes => 0 (0x0))
22195:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226:
service bcm5820 stop
causes ssl services to run...
does it mean that I've bought something that is certified by linux and doesn't
work ?? (dell poweredge 2650)
I confirm version independence (affects 7.3 as well) and fact that stopping the
bcm5820 service fixes the problem. But this means you're not using the SSL
accelerator card at all.
I've cross-posted a message to
Ok, I've done some research and testing on this since Red Hat still has this bug
marked as NEW. It appears that what breaks the hardware acceleration is the
blinding patch that came out of the following advisory:
Its not immediately clear to me just how widespread the impact is - the original
application that exhibited the vulnerability appears to be stunnel. It would
seem to make more sense to leave blinding off by default and enable it on a
per-vulnerable application basis, rather than turning it on by default and
breaking non-vulnerable applications. This assumes that Apache w/mod_ssl and
hardware accleration isn't vulnerable to this attack but I'm neither a
programmer or a cryptography expert so my assumption may be wrong.
Or maybe the bcm5820 module needs reworked to deal with blinding in a better
way. I'm disappointed Red Hat hasn't at least acknowledged this bug - it
reminds me of several other show stoppers in the past that took a long time to
get acknowledged and resolved - the Apache/PHP/mm leaking semaphore problem and
the upgrade-glibc-and-break-remote-MySQL-connections problem. I can get that
kind of support, stability, and upgrade quality-assurance from a vendor from
Redmond (of course I'd have to pay a lot more to get it ;)
For anyone having this problem, I'd propose, as a workaround, disabling the
openssl-sec3-blinding patch. You'll have to recompile the RPM for this to take
effect obviously but being vulnerable to a blinding attack might be better than
having broken hardware encryption accelerator support. The usual standard
disclaimers apply to that suggestion but thats the best I know to do at this point.
I guess I have to eat crow - web servers are vulnerable, as stated in the
original research paper, which I just found at:
So I guess the best approach is try and fix the bcm5820 module or modify OpenSSL
to do something different if HW crypto is being used...
Hello? Does anyone work at Red Hat anymore? Has it dawned on Red Hat that this
bug has been setting at a status of "NEW" since April 4, 2003 with no Red Hat
response at all? What kind of noise does one have to make to actually get a bug
acknowledged, let alone fixed?
For what its worth, it appears that the multithreading blinding patch fixes the
previous hardware crypto break introduced by the original blinding patch. I'm
just disappointed that no one at Red Hat apparently even looked at this bug or
responded to it. Thats poor customer service.
A ubsec fix was added in 0.9.6b-33.7 along with other blinding fixes, so does
the OpenSSL packages as part of this errata solve your problems?
Yes, see my comment #6 - it appears to be fixed with that patch. A note on this
bug when 33.7 was released would have been helpful and that omission is all I'm
trying to point out.