Re: [openssl.org #2790] [PATCH] Better compatibility with C++ compilers and MSDEV memory debugger
On Mon, 16 Apr 2012 19:44:32 +0200, Andy Polyakov via RT r...@openssl.org wrote: http://cvs.openssl.org/chngview?cn=22397 Looks good, thanks! -- Alexei. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2790] [PATCH] Better compatibility with C++ compilers and MSDEV memory debugger
On Mon, 16 Apr 2012 19:44:32 +0200, Andy Polyakov via RT r...@openssl.org wrote: http://cvs.openssl.org/chngview?cn=22397 Looks good, thanks! -- Alexei. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2635] 1/n-1 record splitting technique for CVE-2011-3389
I think from the point of view of both interoperability and security, the original empty-fragment approach is best when a cipher using 8-byte blocks has been negotiated (usually 3DES), while 1 / n-1 splitting is better for interoperability and fully adequate for large block sizes (AES). Regardless of which of these splitting techniques is chosen, we'd want it to be enabled by default, but it always should be possible to entirely disable this. So I'd suggest to rename SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS to cover 1 / n-1 splitting (e.g., SSL_OP_DONT_SPLIT_FRAGMENTS) while retaining the old name as an alias (#define SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS SSL_OP_DONT_SPLIT_FRAGMENTS). To slightly simplify the code, we could stop worrying about the 8-byte block ciphers (i.e., never use empty fragments, use 1 / n-1 splitting instead), but while using 8-byte blocks comes with known security issues, there's probably no good justification to make this worse [*]. Data that Yngve Pettersen has shown actually suggests that interoperability with 3DES implementations is better with the empty-fragment approach anyway. [*] For a 8-byte block cipher, the 1 / n-1 splitting approach means you 56 MAC bits for randomization in the first block. With some luck (p = 2^-56), these bits will come out as needed by the attacker. You'd typically have other security problems too when using an 8-byte block cipher, but why add to them? I think from the point of view of both interoperability and security, the original empty-fragment approach is best when a cipher using 8-byte blocks has been negotiated (usually 3DES), while 1 / n-1 splitting is better for interoperability and fully adequate for large block sizes (AES). Regardless of which of these splitting techniques is chosen, wed want it to be enabled by default, but it always should be possible to entirely disable this.So Id suggest to rename SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS to cover 1 / n-1 splitting (e.g., SSL_OP_DONT_SPLIT_FRAGMENTS) while retaining the old name as an alias (#define SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS SSL_OP_DONT_SPLIT_FRAGMENTS). To slightly simplify the code, we could stop worrying about the 8-byte block ciphers (i.e., never use empty fragments, use 1 / n-1 splitting instead), but while using 8-byte blocks comes with known security issues, theres probably no good justification to make this worse [*]. Data that Yngve Pettersen has shown actually suggests that interoperability with 3DES implementations is better with the empty-fragment approach anyway. [*] For a 8-byte block cipher, the 1 / n-1 splitting approach means you 56 MAC bits for randomization in the first block. With some luck (p = 2^-56), these bits will come out as needed by the attacker. Youd typically have other security problems too when using an 8-byte block cipher, but why add to them?
Re: FIPS 2 mode with shared libs : Clarification needed .....
On 04/16/2012 04:41 PM, Simon Convey wrote: Dear all, ( On a Linux 2.6.32 x86_64 ) I'm trying to build a FIPS 2 openssl When I configure the fips code, config spits out as warning ... WARNING: OpenSSL has been configured using unsupported option(s) to internally generate a fipscanister.o object module for TESTING PURPOSES ONLY; ... I *assume* that the warning is because we are using test software, rather than configuration problems ? And that the correct procedure is just ./config rather than ./config fipcanisteronly, which the README.FIPS suggests ? Secondly, once fipscansiter is built, ( and installed to /usr/local/ssl/fips-2.0 ), I should be using ... #cd openssl-1.0.1 #./config fips shared ( I want fipscanister in libcrypto.so.1 ) Is it ok to use fipscanister inside libcrypto this way ? Yes to all three questions. The validation is still pending for the 2.0 module (we're engaged in an extended dialog about the precise process used to verify the source tarball). Once a validated module is properly generated you are free to use it with any application, including an OpenSSL shared library. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.net __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2792] Crash in rc4 on x86_64
Hi, I've had 2 users report a crash in RC4() on x86_64. The backtrace looks like: #0 RC4 () at rc4-x86_64.s:343 #1 0x012d in ?? () #2 0x00df in ?? () #3 0x020b5660 in ?? () #4 0x7fc075f6a9c9 in rc4_hmac_md5_cipher (ctx=optimized out, out=0x20aae98 .\324\300\377AE'|#\242\300\233\025T\341\002}\237\242\240\273G\260\257\214z\321\001HK«RA\257HC0\0\257N*1C/,$\252-N1%1\261\/0C*'C\246-\!/C*\nb% SO\261\067\303\060,17^'*\260\063/\:C7+\261\'^1%\246\061- 0C\267+1\'^1\246%0C.6/7\252\33-'C\266-0/ 7\303 +*/'1\255C-\.03\242 C6*'3\257\066\060C/*07\316;7-'\247C*R[-/\265/^RC ,\255..., in=optimized out, len=0) at e_rc4_hmac_md5.c:163 #5 0x7fc076272b8f in tls1_enc (s=0x209c120, send=1) at t1_enc.c:828 #6 0x7fc076269e18 in do_ssl3_write (s=0x209c120, type=23, buf=0x209cf34 2 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CON..., len=285, create_empty_fragment=0) at s3_pkt.c:808 #7 0x7fc07626a144 in ssl3_write_bytes (s=0x209c120, type=23, buf_=0x209cf34, len=optimized out) at s3_pkt.c:605 This looks simular to the AES problem with had, with a length of 0? More details are at: http://bugs.debian.org/666405 Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Module 1.2 build with Visual Studio 2010 fails self-tests
Issue got fixed after adding /fixed flag in the linker. One mistake was fipscanister.lib was in the link like. Issue resolved after removing fipscanister.lib from the link line. Thanks everyone for your help. Thanks, -Vimol On Mon, Apr 16, 2012 at 10:49 PM, Dr. Stephen Henson st...@openssl.orgwrote: On Mon, Apr 16, 2012, Vimol Kshetrimayum wrote: It is still not working for me. I had tried all possible place to add /dynamicbase:NO and/or /fixed flag. I am wondering how it was working for Grant Averett. Where did you exactly add the /FIXED flag? That's weird. I can reproduce that issue with my setup and this fixes it: http://cvs.openssl.org/chngview?cn=22392 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Static analysis?
Hello, I would like to ask if any static analysis tool was ever used to detect possible problems in OpenSSL source code. Is some tool used regularly? I tried running Clang Static Analyzer [1] on the source of OpenSSL. It found 222 possible bugs. You can see the full list here [2]. At least 65 of them are false positives. Most of the ones that seem valid to me are classified as Dead Code. However, even some dead assignments look like real problems. Some examples follow: http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-JxXj0g.html#EndPath The variable 'al' is never read. The goto should probably jump to 'f_err' in order not to lose the alert. http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-6OKYC8.html#EndPath The assignment to 'ret' is either useless or goto should jump to 'err'. http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-117dnV.html#EndPath http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-rT4fgM.html#EndPath Duplicit assignment to 'ret' and 'saved_state.epoch', respectively. http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-xy1iZT.html#EndPath 'qbits' gets assigned the same value in following condition again. http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-IG0Qez.html#EndPath The 'E', 'e', 'G', 'g' cases don't seem to do anything. Is there some missing functionality? http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-euj1zH.html#EndPath Default port is assigned twice, on line 234. Would you be interested in some patches? How and where should I submit them? Regards, Lubomír Sedlář [1]: http://clang-analyzer.llvm.org/ [2]: http://www.fi.muni.cz/~xsedlar3/openssl-analysis/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
