CVE-2013-0169
Hi all, Recently, OpenSSL Security Advisory sent a message about a new vulnerability which was found and numbered as CVE-2013-0169. This announce advises to all SSL and TLS users to upgrade the OpenSSL version. But from a quick Google search, it looks like there is a contradiction between the OpenSSL details description to the description of this issue in many sites on the web: http://en.securitylab.ru/nvd/437439.php , http://www.cvedetails.com/cve/CVE-2013-0169/ and http://en.securitylab.ru/nvd/437439.php describe that this vulnerability affects just The TLS protocol 1.1 and 1.2 and the DTLS protocol 1.0 and 1.2, but in the OpenSSL announcements it's described that this effects also SSL and TLS 1.0: They also apply to implementations of SSL 3.0 and TLS 1.0 that incorporate countermeasures to previous padding oracle attacks. This is critical for us to know whether it's a typo mistake in the OpenSSL announcements or in the sites I noted above. Can anyone please assist us to in clearing up this point? Thanks in advance, Rachel - Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
s_client doesn't like pipes
Sorry, but the mailing list program has eaten more than half of my rant. Looks like it doesn't like a dot on it's own on a line (Yes, I know it's the SMTP signal for EOT). Hi, I was monkeying around a bit with s_client. Idea is to feed s_client a file with commands required to STARTTLS, authenticate to the smtp server and the message itself. I have this file: -- ehlo hereami auth login dfbdffdbZWhhcjU= dffdddBoYTI= mail from:here...@gmail.com rcpt to:here...@gmail.com data From: here...@gmail.com To: whoe...@gmail.com Subject: With s_client Date: Mon, 18 Feb 2013 22:28:00 +0100 Testing ... one-single-dot QUIT --- Without the dashes, of course; plus real addresses and passwords. I then do openssl s_client -crlf -connect smtp.gmail.com:587 -CApath /etc/mutt_CA -starttls smtp -pause -quiet feed gmail then comes back with depth=2 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority verify return:1 depth=1 /C=US/O=Google Inc/CN=Google Internet Authority verify return:1 depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com verify return:1 250 ENHANCEDSTATUSCODES 250-mx.google.com at your service, [91.44.157.56] 250-SIZE 35882577 250-8BITMIME 250-AUTH LOGIN PLAIN XOAUTH XOAUTH2 250 ENHANCEDSTATUSCODES 334 VXNlcm5hbWU6 and that's it, nothing more. Won't take any more interactive input either. The 334 VXNlcm5hbWU6 is begging for the user name, but apparently it doesn't get one. Now comes the funny thing: leaving out the ehlo line in the file gives me depth=2 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority verify return:1 depth=1 /C=US/O=Google Inc/CN=Google Internet Authority verify return:1 depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com verify return:1 250 ENHANCEDSTATUSCODES 334 VXNlcm5hbWU6 334 UGFzc3dvcmQ6 Final words are now 334 UGFzc3dvcmQ6 which means it's awaiting the password. The thought would arise that somehow s_client for whatever reason only gets the first two lines from the external file. Typing the commands interactively wotks ok. I tired all sorts of other things, like leaving out -pause etc, but to no avail. Anybody has any clues, please (bug or feature)? TIA, regards Andreas __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS_selftest fails under windows dynamic linking
Thank you, Steve for your input. You say it is dynamic linked. How are you actually handling that? Are you linking to libeay32.dll only or fipscanister.lib too? If I do not manually export FIPS_selftest through crypto.h and libeay.def I have to use the fipscanister.lib too otherwise Visual Studio linker(link) reports unresolved external symbol for FIPS_selftest. This is kind of expected cause the symbol FIPS_selftest is not found by the linker. If I use the the same approach that I did above with the FIPS_selftest_2 function I can call the FIPS_selftest_2 which calls FIPS_selftest and everything works fine. No fibscanister.lib. The same situation applies if I include the FIPS_selftest function in crypto.h and in the libeay.def file. Then there is no problem with the FIPS_selftest function. The question is should it be done? If FIPS_selftest has no practical value it probably doesn't matter. But then there is the problem that it is mandated by the FIPS 140-2. I do not believe that there is a problem with my setup of OpenSSL and the FIPS-module. I can run FIPS_set_mode and everything works fine, all the following crypto operations works as expected. Once again thank you Stephen. I am great admirer of the OpenSSL project. Rickard Binnare 2013/2/20 Dr. Stephen Henson st...@openssl.org On Wed, Feb 20, 2013, Rickard Binnare wrote: So FIPS_mode_set() cannot succeed if FIPS_selftest() fails, for static or dynamic linking. No this is not the case on the windows platform. Tested on a Windows 7 machine using Visual Studio 2010 with OpenSSL.1.0.1.c and OpenSSL-Fips-2.0. The FIPS_mode_set() succeeds but FIPS_selftest() fails. The FIPS_mode_set method should not succeed as you have stated above if FIPS_selftest fails. FIPS_selftest clearly works when it is called in the call chain starting with FIPS_mode_set, but not otherwise. I think this has to do with how Windows handles loading and mapping of DLL:s. I recommend trying this, if you do not believe me. Here is a minimalistic test program that displays this anomaly. Dynamic linked. It could easily be modified to show OpenSSL error msgs. But I try to keep it short. You say it is dynamic linked. How are you actually handling that? Are you linking to libeay32.dll only or fipscanister.lib too? I've known cases where FIPS_selftest appears to fail on non-Windows platforms because the application was linked against a shared library and fipscanister: effectively there were two instances of fipscanister which were confusing the hell out of each other. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
check certificate chain in a pem file
I have a certificate chain in a file chain.pem .it also has root certificate(self signed) . How can i verify the chain,if all certificates are present in the chain . Thanks -- View this message in context: http://openssl.6102.n7.nabble.com/check-certificate-chain-in-a-pem-file-tp43871.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Use TLS over UDP connection
Hello, I am trying to implement TLS security (in the client side) over a UDP connection. I have a parallel TCP connection(to the same server) over which TLS is already done and it works fine. In the same session of my application I am creating a UDP connection to the same server (UDP socket) and am trying to do a TLS handshake. When I call SSL_connect() over UDP connection, it fails with SSL_ERROR_SYSCALL error. When I checked the error with ERR_get_error() I get a value of 0. Can I use TLS over a UDP connection(I understand DTLS can be used but my project needs TLS)? Please share some pointers. Thanks for your time. Regards, Saurav __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Use TLS over UDP connection
-Original Message- From: saurav barik Can I use TLS over a UDP connection(I understand DTLS can be used but my project needs TLS)? No, you can't. You need a reliable transport protocol, i.e. TCP. See RFC 5246. It's right there in the first paragraph of chapter one. Patrick Eisenacher
Re: Recommended/allowed private key lengths Reg.
Perhaps some on this list are better qualified than me to answer this question, but this is my $0.02. Generally speaking, higher-bit key lengths (than 2048) become much slower when used on embedded hardware (even high-end smartphones). In some cases it may be impossible to support keys longer than 2048 bits due to hardware constraints (i.e. smart meters, security cards, etc). I believe that the Fortinet firewalls support SSL offloading up to only 2048 bit key length. On the other extreme, an 8192-bit RSA key for an Apache server will cause a user-noticeable delay on an otherwise unloaded server while performing the initial handshake. Large numbers of sessions would bring such an installation to its knees. A denial of service attack would be easy to accomplish against such a configuration. A 4096-bit key seems a bit extreme as well, but is probably useful for low-volume installations where key material must have high assurance. Last I heard, the largest key which has been publicly factored was 768 bits. Unless practical quantum computers become available, a 2048-bit key should be more than sufficient for most use cases. Mike On Thu, Feb 21, 2013 at 11:38 PM, Ashok C ash@gmail.com wrote: Hi, What is the current industry standard for private key lengths? As of now, my application supports 2048 bit-wide keys. I'm planning to support higher key lengths now, and want your suggestions on how big a key I should support? -- Ashok
Re: Use TLS over UDP connection
On 22/02/2013 6:41 p.m., saurav barik wrote: Hello, I am trying to implement TLS security (in the client side) over a UDP connection. I have a parallel TCP connection(to the same server) over which TLS is already done and it works fine. In the same session of my application I am creating a UDP connection to the same server (UDP socket) and am trying to do a TLS handshake. When I call SSL_connect() over UDP connection, it fails with SSL_ERROR_SYSCALL error. When I checked the error with ERR_get_error() I get a value of 0. Can I use TLS over a UDP connection(I understand DTLS can be used but my project needs TLS)? Please share some pointers. Thanks for your time. Regards, Saurav __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org You can use DTLS (TLS over UDP). OpenSSL supports it. Have you checked out sctp.fh-muenster.de ?
Re: Private key support at openssl
On 2/22/2013 9:16 AM, Rajeswari K wrote: Hello Team, We have a requirement to support onboard crypto engine which doesn't share private keys to openssl. Current openssl code requires private keys in its possession to succeed with handshake process. Is there any way to skip updation of private keys in the ssl context and still proceed with handshake? If so, how we need to configure? Can you please provide pointers? Yes, it is called engines. OpenSSL comes with a collection of engine plugins for various crypto hardware, plus generic engines for hardware that makes its crypto operations available via a PKCS#11 or Microsoft CryptoAPI driver. There is also documentation for writing your own engine if none of the available engines are good enough. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: CVE-2013-0169
On 2/21/2013 11:12 AM, Mozes, Rachel wrote: Hi all, Recently, OpenSSL Security Advisory sent a message about a new vulnerability which was found and numbered as CVE-2013-0169. This announce advises to all SSL and TLS users to upgrade the OpenSSL version. But from a quick Google search, it looks like there is a contradiction between the OpenSSL details description to the description of this issue in many sites on the web: http://en.securitylab.ru/nvd/437439.php , http://www.cvedetails.com/cve/CVE-2013-0169/ and http://en.securitylab.ru/nvd/437439.php describe that this vulnerability affects just The TLS protocol *_1.1 and 1.2_ *and the DTLS protocol 1.0 and 1.2, but in the OpenSSL announcements it's described that this effects also SSL and TLS 1.0: **They also apply to implementations of SSL 3.0 and *_TLS 1.0_* that incorporate countermeasures to previous padding oracle attacks. This is critical for us to know whether it's a typo mistake in the OpenSSL announcements or in the sites I noted above. Can anyone please assist us to in clearing up this point? The OpenSSL security advisory links directly to the original vulnerability report from a serious University. This report explains in great detail that the security issue is in the countermeasures against the old padding attacks. Those countermeasures are mandatory in TLS 1.1 and 1.2 implementations but are also necessary in any implementations of older SSL versions (whose specifications were printed before the countermeasures could be mentioned in their text). So yes, this applies to all SSL and TLS versions (with the possible exception of the insecure SSL 2), except for the following cases: - If an SSL/TLS library is vulnerable to the much more serious old padding attack, the new attack cannot make it worse than using the old attack. - If you use the (mostly insecure) RC4 algorithm, the issue does not occur. - If you use the brand new AES-GCM mode (officially supported only under TLS 1.2), this is safe from the attack and is believed to be secure against all known attacks, but unlike the other algorithm options, AES-GCM stands and falls on the strength of a single key and a single cryptographic primitive, which increases the risk if an attack is ever found against that one key/primitive. The report explains new improved countermeasures that combat both the old and the new attack, and specifically praises the OpenSSL fix for being even better than their own demonstration code for the countermeasures. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Recommended/allowed private key lengths Reg.
Hope this helps : http://www.keylength.com/en/3/ Le 22/02/2013 08:38, Ashok C a écrit : Hi, What is the current industry standard for private key lengths? As of now, my application supports 2048 bit-wide keys. I'm planning to support higher key lengths now, and want your suggestions on how big a key I should support? -- Ashok __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: check certificate chain in a pem file
On 2/21/2013 2:29 PM, ashish2881 wrote: I have a certificate chain in a file chain.pem .it also has root certificate(self signed) . How can i verify the chain,if all certificates are present in the chain . Thanks Good question! I recently tested this myself, and here are my (preliminary) results: If using the OpenSSL API in a program, you can load the chain and the CA cert into two X509 stores, then loop over the store calling a function to validate each certificate in the chain store against the CA store with options to use the chain store to locate intermediary certificates. But on the command line, things are unnecessarily difficult. Here is what you need to do: 1. Split the chain file into one file per certificate, noting the order 2. For each certificate starting with the one above root: 2.1 Concatenate all the previous certificates and the root certificate to one temporary file (This example is for when you are checking the third certifate from the bottom, having already checked cert1.pem and cert2.pem Unix:cat cert2.pem cert1.pem root.pem cert2-chain.pem Windows: copy /A cert1.pem+cert1.pem+root.pem cert2-chain.pem /A 2.2 Run this command openssl verify -CAfile cert2-chain.pem cert3.pem 2.3 If this is OK, proceed to the next one (cert4.pem in this case) Thus for the first round through the commands would be Unix: cat root.pem root-chain.pem Windows: copy /A root.pem root-chain.pem Both: openssl verify -CAfile root-chain.pem cert1.pem And the second round would be Unix: cat cert1.pem root.pem cert1-chain.pem Windows: copy /A cert1.pem+root.pem cert1-chain.pem Both: openssl verify -CAfile cert1-chain.pem cert2.pem Etc. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Recommended/allowed private key lengths Reg.
http://csrc.nist.gov/groups/ST/key_mgmt/documents/Transitioning_CryptoAlgos_070209.pdf On 2/22/2013 2:38 AM, Ashok C wrote: What is the current industry standard for private key lengths? As of now, my application supports 2048 bit-wide keys. I'm planning to support higher key lengths now, and want your suggestions on how big a key I should support? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Dead indirect link to http://www.openssl.org in lucky 13 security advisory
Att. openssl.org web server maintenance team. The latest security advisory for OpenSSL links to the research site for the lucky 13 attack analysis, which links to their report in pdf format. That report in its list of references includes a link to an old (2004) document by Bodo Moeller at http://www.openssl.org/~bodo/tls-cbc.txt However that document seems to be missing. Would you mind restoring the document, even if you are not otherwise allowing Mr. Moeller to host stuff on www.openssl.org? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Dead indirect link to http://www.openssl.org in lucky 13 security advisory
On 02/22/2013 04:13 PM, Jakob Bohm wrote: Att. openssl.org web server maintenance team. The latest security advisory for OpenSSL links to the research site for the lucky 13 attack analysis, which links to their report in pdf format. That report in its list of references includes a link to an old (2004) document by Bodo Moeller at http://www.openssl.org/~bodo/tls-cbc.txt However that document seems to be missing. I have copied over the files from the old to the new server. Would you mind restoring the document, even if you are not otherwise allowing Mr. Moeller to host stuff on www.openssl.org? There is no reason why Bodo might not be able to copy his own stuff from the old to the new server. Best regards, Lutz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Solaris 10 config confused : Makefile:17: *** mixed implicit and normal rules. Stop.
I don't know what this is saying. I want to build openssl as 64-bit only on a Niagara T2 with fairly specific CFLAGS which specifiy memory cache options and other flags that work great for everything from autoconf to zlib .. but not openssl. What is my confusion here please ? $ ./Configure threads zlib-dynamic shared -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_REENTRANT \ -L/usr/local/lib/\$ISALIST:/usr/local/ssl/lib/\$ISALIST:/usr/local/lib:/usr/local/ssl/lib \ -R/usr/local/lib/\$ISALIST:/usr/local/ssl/lib/\$ISALIST:/usr/local/lib:/usr/local/ssl/lib \ solaris64-sparcv9-cc:$CFLAGS Configuring for solaris64-sparcv9-cc no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-gmp [default] OPENSSL_NO_GMP (skip dir) no-jpake[experimental] OPENSSL_NO_JPAKE (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-store[experimental] OPENSSL_NO_STORE (skip dir) IsMK1MF=0 CC=/opt/solarisstudio12.3/bin/cc CFLAG =-DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_REENTRANT -R/usr/local/lib/$ISALIST:/usr/local/ssl/lib/$ISALIST:/usr/local/lib:/usr/local/ssl/lib -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no ppl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE EX_LIBS =-L/usr/local/lib/$ISALIST:/usr/local/ssl/lib/$ISALIST:/usr/local/lib:/usr/local/ssl/lib CPUID_OBJ =mem_clr.o BN_ASM=bn_asm.o DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes_core.o aes_cbc.o BF_ENC=bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4_enc.o rc4_skey.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM = SHA1_OBJ_ASM = RMD160_OBJ_ASM= CMLL_ENC =camellia.o cmll_misc.o cmll_cbc.o MODES_OBJ = ENGINES_OBJ = PROCESSOR = RANLIB=/usr/ccs/bin/ranlib ARFLAGS = PERL =/usr/local/bin/perl THIRTY_TWO_BIT mode RC4_CHUNK is undefined Makefile:17: *** mixed implicit and normal rules. Stop. $ Why do I see THIRTY_TWO_BIT mode there ? Please, what is the magic incantation required to compile openssl 1.0.1e purely 64-bit with shared libs ? Dennis __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
EXP-RC2-CBC-MD5
EXP-RC2-CBC-MD5 does not appear to work in 0.9.8y. It does in 0.9.8x. system:user/openssl-0.9.8y/apps 27% ./openssl s_client -connect 10.1.1.1:443 -tls1 -cipher EXP-RC2-CBC-MD5 CONNECTED(0003) certificate stuff deleted 95776:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:435: system:user/openssl-0.9.8x/apps 16% ./openssl s_client -connect 10.1.1.1:443 -tls1 -cipher EXP-RC2-CBC-MD5 CONNECTED(0003) server certificate stuff deleted --- No client certificate CA names sent --- SSL handshake has read 1362 bytes and written 184 bytes --- New, TLSv1/SSLv3, Cipher is EXP-RC2-CBC-MD5 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : EXP-RC2-CBC-MD5 Session-ID: deleted Session-ID-ctx: Master-Key: deleted Key-Arg : None Start Time: 1361574211 Timeout : 7200 (sec) Verify return code: 18 (self signed certificate) --- connected
Re: EXP-RC2-CBC-MD5
On Fri, Feb 22, 2013, no_spam...@yahoo.com wrote: EXP-RC2-CBC-MD5 does not appear to work in 0.9.8y. It does in 0.9.8x. A known issue, fixed in recent snapshots. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Seg fault from d2i_RSAPrivateKey_fp
On Thu, 2013-02-21 at 05:15 -0500, Jeffrey Walton wrote: You enabled it with -Wextra, then you turned it off with -Wno-missing-field-initializers. Its not latched - the last option wins. Good catch! I forgot to remove that while doing some rapid prototyping. In addition, GCC's analysis may not have caught the issue since its a static analyzer. For better analysis of uninitialized values, its often better to use dynamic analysis - Valgrind at runtime. Ack. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
