Bug 88018
| Summary: | openssl update 2003:101-15 incompatible with ubsec hwcrypto? | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Rich Graves <rcgraves> |
| Component: | openssl | Assignee: | Tomas Mraz <tmraz> |
| Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.0 | CC: | jorton, kevin_myer, mjc |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-02-04 16:03:31 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Rich Graves
2003-04-04 17:46:02 UTC
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 openssl-0.9.6b-32.7 the same with 0.9.6b-18 and 0.9.6b-30 [engine] default=ubsec Broadcom bcm5820 kernel /vmlinuz-2.4.18-27.7.xsmp [iro@web1 ssl]$ /www/ssl/bin/openssl s_client -connect web2:443 -state -debug CONNECTED(00000003) SSL_connect:before/connect initialization 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) best regards Ireneusz Nowak 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 http://forums.us.dell.com/supportforums/board/message?board.id=pes_linux&message.id=1036 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: http://www.openssl.org/news/secadv_20030317.txt 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: http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf 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? http://rhn.redhat.com/errata/RHSA-2003-291.html 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. |