OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [05 Feb 2013] SSL, TLS and DTLS Plaintext Recovery Attack (CVE-2013-0169) Nadhem Alfardan and Kenny Paterson have discovered a weakness in the handling of CBC ciphersuites in SSL, TLS and DTLS. Their attack exploits timing differences arising during MAC processing. Details of this attack can be found at: http://www.isg.rhul.ac.uk/tls/ All versions of OpenSSL are affected including 1.0.1c, 1.0.0j and 0.9.8x Note: this vulnerability is only partially mitigated when OpenSSL is used in conjuction with the OpenSSL FIPS Object Module and the FIPS mode of operation is enabled. Thanks go to Nadhem J. AlFardan and Kenneth G. Paterson of the Information Security Group Royal Holloway, University of London for discovering this flaw. An initial fix was prepared by Adam Langley a...@chromium.org and Emilia Käsper ekas...@google.com of Google. Additional refinements were added by Ben Laurie, Andy Polyakov and Stephen Henson of the OpenSSL group. Affected users should upgrade to OpenSSL 1.0.1d, 1.0.0k or 0.9.8y TLS 1.1 and 1.2 AES-NI crash (CVE-2012-2686) = A flaw in the OpenSSL handling of CBC ciphersuites in TLS 1.1 and TLS 1.2 on AES-NI supporting platforms can be exploited in a DoS attack. If you are unsure if you are using AES-NI see References below. Anyone using an AES-NI platform for TLS 1.2 or TLS 1.1 on OpenSSL 1.0.1c is affected. Platforms which do not support AES-NI or versions of OpenSSL which do not implement TLS 1.2 or 1.1 (for example OpenSSL 0.9.8 and 1.0.0) are not affected. Thanks go to Adam Langley a...@chromium.org for initially discovering the bug and developing a fix and to Wolfgang Ettlingers wolfgang.ettlin...@gmail.com for independently discovering this issue. Affected users should upgrade to OpenSSL 1.0.1d OCSP invalid key DoS issue (CVE-2013-0166) A flaw in the OpenSSL handling of OCSP response verification can be exploitedin a denial of service attack. All versions of OpenSSL are affected including 1.0.1c, 1.0.0j and 0.9.8x This flaw was discovered and fixed by Stephen Henson of the OpenSSL core team. Affected users should upgrade to OpenSSL 1.0.1d, 1.0.0k or 0.9.8y. References == URL for this Security Advisory: http://www.openssl.org/news/secadv_20130204.txt Wikipedia AES-NI description: http://en.wikipedia.org/wiki/AES-NI -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBURETXqLSm3vylcdZAQLE2QgAuHTRN3khjkmt/NRS4hg/mT+YRD+aJMsU mhCoqYvVuW0GVJHCY4yiBUoj0bgTfwWyazQRaWSFX8ewc/mHqNKYoVBSczb9nxqZ Kh41maLcKGMHtDNQlb5bINa95+9Ix9+J9Izdd7dWycpApN/azCV+r/kkXVArAq8J jYZ5Wl7PtSELArAtN5R56TgmSpcZvnIkqm7dV9rkJZGE9PBXskiLJjozWqPHgvQC HcAXNuAgrWJjuCKimictGoC0gP+tmF7tMIqYKT8/16qAqWs4vBk/Z0rxpQ4wV6pU 6jWjcFL+dVQm/59RKtYwsnBPmXgH9zg7kS2y0xcHTWJG3EKucxe8zQ== =BgHn -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Request for Elliptic Curve Documentation
On 2/3/2013 3:59 PM, Stefan Schindler wrote: Good evening everybody I'm setting up 3 servers for mobile clients. Because the data is allways very small, i think the curve sect571r1 fit's best. I didn't find much helpful documentation on the net, so it would be very cool if you could provide some. You did not say what you will do with ECC. authentication, signature, key agreement, etc. There are a number of IETF RFCs dealing with ECC in different protocols, as well as NSA and NIST recommendations for how to use ECC. This spells out the key sizes/curves to be used on PIV smart cards: http://csrc.nist.gov/publications/nistpubs/800-78-3/sp800-78-3.pdf You might find it useful. I created my first keys with these commands: openssl ecparam -out defaultServer-key.pem -name sect571r1 -genkey openssl req -newkey ec:defaultServer-key.pem -x509 -nodes -days 365 -keyout defaultServer-pkey.pem -out defaultServer-cert.pem I will try to setup a CA, so the clients can verify the 3 servers. Documentation would be appreciated too. Regards Stefan -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
diffs for changes to fix CVEs
How does one find the diffs corresponding to the fixes (on the 0.9.8 line) for today's CVEs using the git web interface? Thanks. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OCB Authenticated Encryption
At last month's Workshop on Real-World Cryptography at Stanford University, Phil Rogaway released a new license for OCB, granting free use for all open-source implementations. http://www.cs.ucdavis.edu/~rogaway/ocb/license1.pdf OCB is the fastest authenticated-encryption scheme that I know of, and I encourage OpenSSL to incorporate it. My C implementation achieves a rate of 0.87 CPU cycles per byte processed on Sandy Bridge processors, which is just slightly slower that CTR mode encryption and more than twice as fast as GCM. The difference is even greater on other architectures. On ARM, OCB's authentication overhead (ie, cost beyond CTR encryption) is reported to be 3.5 cpb whereas GCM's is at least 15 cpb (according to OpenSSL's notes in ghash-armv4.pl). More about OCB, including the C code, timing results, academic papers and a draft RFC, can be found at its website http://www.cs.ucdavis.edu/~rogaway/ocb I'd be happy to help with integration. Thank you, Ted Krovetz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OCB Authenticated Encryption
On Tue, Feb 5, 2013 at 9:20 AM, Ted Krovetz t...@krovetz.net wrote: At last month's Workshop on Real-World Cryptography at Stanford University, Phil Rogaway released a new license for OCB, granting free use for all open-source implementations. http://www.cs.ucdavis.edu/~rogaway/ocb/license1.pdf There's a problem with that license, though: Open Source Software Implementation does not include any Software Implementation in which the software implicating the Licensed Patents is combined, so as to form a larger program, with software that is not Open Source Software. This restriction seems OK for GPL'ed libraries (because they have a similar restriction anyway), but not for libraries that are meant to be available for use in programs that are not necessarily open source. Thus, as much as I like OCB, I'd rather keep it out of OpenSSL for now. Bodo
RE: Request for Elliptic Curve Documentation
From: owner-openssl-...@openssl.org On Behalf Of Stefan Schindler Sent: Sunday, 03 February, 2013 17:00 I'm setting up 3 servers for mobile clients. Because the data is allways very small, i think the curve sect571r1 fit's best. If you mean SSL/TLS (connections to) server(s), the size of the data is irrelevant. The ECC cert/key and algorithms are used only in the handshake. Data encryption uses a symmetric algorithm. For other usage, see below. I didn't find much helpful documentation on the net, so it would be very cool if you could provide some. If you mean EC crypto in general, I don't know anything very good. It's arcane and nearly magic -- but it works. If you mean EC usage in SSL/TLS, RFC 4492 (several places, canonically rfc-editor.org). If you mean EC support in OpenSSL: man pages for the current version are under www.openssl.org/docs and the ones for any version you have installed on Unix should be available there. I have usually found what I need for commands/options, and EVP. man page coverage of EC low-level primitives is even spottier than the rest of OpenSSL, but the (newish) ec*.h headers do have much better comments than old ones. Aside from the specific routines and utilities or options (including pkeygen etc. in 1.0.0+) to handle EC parameters and keys, it's mostly the same as non-EC. ECDSA primitives, and suites, work much like DSA. ECDH primitives, and ECDH ECDHE AECDH suites, work much like DH ones. Certs containing EC keys work much like DSA (or DH, but certifying DH is even rarer than DSA). Two sometimes-gotchas: in libssl before 1.0.0 the EC suites are implemented but disabled by default; you must specify a cipherstring including ECCdraft to use them. And in all versions libssl server will (silently) suppress an EC cert and/or ECDH temp key that uses a curve excluded from a client's supported_curves extension. (TLS1.2 can also exclude based on sigalg for both EC and non-EC, but EC sigalgs might be a little more likely to be unsupported.) I created my first keys with these commands: openssl ecparam -out defaultServer-key.pem -name sect571r1 -genkey openssl req -newkey ec:defaultServer-key.pem -x509 -nodes -days 365 -keyout defaultServer-pkey.pem -out defaultServer-cert.pem That creates two different keypairs, with a selfsigned cert for (the public half of) one of them. Is that what you want? I will try to setup a CA, so the clients can verify the 3 servers. Documentation would be appreciated too. If you use the selfsigned cert (from req -x509) you don't need a CA. You do need to make the clients trust the selfsigned cert, which sometimes means *calling* it a CA cert. But it's not really a CA unless you use it to issue child certs, or at least plan to. If you do want a private CA, don't bother creating selfsigned EE cert(s). You do need to make the clients trust your CA cert, but if you have multiple servers (with different keys/certs) trusting one CA may be easier than trusting N servers or server versions. If you're doing something other than SSL/TLS, you may or may not need a cert, or a cert with particular features, depending. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: diffs for changes to fix CVEs
On 2013-02-05 at 16:35 +, geoff_l...@mcafee.com wrote: How does one find the diffs corresponding to the fixes (on the 0.9.8 line) for today's CVEs using the git web interface? You don't, yet, because the changes haven't been pushed to the master repo, nor the new release tags, so the release tarballs can't be verified against git. When they have been: 1. Go to http://git.openssl.org/ 2. Choose the openssl.git repo. 3. Go down to the heads section, look for OpenSSL_0_9_8-stable and choose the shortlog link. Above the heads section is tags, which will gain the new release tags when the changes have been pushed. In the meantime, it looks like the changes are in private copies of the repositories and not publicly shared. -Phil __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OCB Authenticated Encryption
On Tue, Feb 5, 2013 at 1:41 PM, Ted Krovetz t...@krovetz.net wrote: There are actually two licenses. The second allows all software (even closed), but only for non-military use. http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm Thanks. Is some explanation of the non-military use condition available? This seems to imply you still can't use the software for any public service (that could be used for military purposes), unless the open source license applies. Note that in any case, given the specifics of the two licenses, the new code would be excluded from default builds (so that those agreeing with the conditions of the license can explicitly enable it) -- we're doing that in other similar cases, to ensure that default builds wouldn't be considered non-free. Bodo
diffs for changes to fix CVEs
How does one find the diffs corresponding to the fixes (on the 0.9.8 line) for today's CVEs using the git web interface? I can't seem to find them there. Thanks.
Re: OCB Authenticated Encryption
There are actually two licenses. The second allows all software (even closed), but only for non-military use. http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm Does that make OCB any more acceptable? -Ted__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
