Re: [openssl-users] [openssl-dev] OpenSSL Security Advisory
On Thu, Jul 09, 2015 at 01:13:30PM +, Salz, Rich wrote: This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o. In other words, if you are not using those specific releases -- i.e., the ones that came out less than 30 days ago -- you do not need to upgrade. More accurately, you should upgrade anyway, to address the issues resolved by those earlier releases, even though the specific issue in the most recent release applies only to its immediate predecessors. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] X509_STORE crash in CMS_verify
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 ok, i have a crash in CMS_verify that suggests i'm not setting up the store of CAs properly, or i may have made an error setting up the CA. what should i be looking at with this error? (gdb) bt #0 0x77909b6c in X509_STORE_get_by_subject () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 #1 0x7790a3ca in X509_STORE_CTX_get1_issuer () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 #2 0x77906055 in X509_verify_cert () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 #3 0x7792a8af in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 #4 0x7792aeb0 in CMS_verify () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 #5 0x00401f7e in nts_cms_verify (cms_content=0x6281a0, certs=0x6206d0, store=0x0, content_data=content_data@entry=0x7fffde88, content_length=content_length@entry=0x7fffde84) at cms.c:154 #6 0x00401b70 in test_nts_cms_sign_and_verify () at cms.c:184 #7 0x0040165e in main (argc=optimized out, argv=optimized out) at run-cms.c:49 ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On Thu, Jul 09, 2015 at 09:47:00AM -0500, Tom Browder wrote: I get the following warnings from compiling the latest openssl with gcc 4.7.2: ecp_nistp224.c: In function 'batch_mul': ecp_nistp224.c:1105:29: warning: array subscript is above array bounds [-Warray-bounds] In my copy of 1.0.2d, line 1105 of that file is in select_point(), not batch_mul(). Are you sure you're compiling the right code? -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On 09/07/15 15:47, Tom Browder wrote: I get the following warnings from compiling the latest openssl with gcc 4.7.2: ec_key.c: In function 'EC_KEY_set_public_key_affine_coordinates': ec_key.c:369:26: warning: variable 'is_char_two' set but not used [-Wunused-but-set-variable] I don't get this by default, but can force it by compiling with no-ec2m. I assume that is what you are using? Its harmless but should be fixed. ecp_nistp224.c: In function 'batch_mul': ecp_nistp224.c:1105:29: warning: array subscript is above array bounds [-Warray-bounds] ecp_nistp256.c: In function 'batch_mul': ecp_nistp256.c:1631:28: warning: array subscript is above array bounds [-Warray-bounds] ecp_nistp521.c: In function 'batch_mul': ecp_nistp521.c:1457:29: warning: array subscript is above array bounds [-Warray-bounds] These only get compiled with enable-ec_nistp_64_gcc_128, but even with that I don't see these warnings. Perhaps a gcc issue fixed in later versions? I'm using gcc 4.9.2 Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Warnings Compiling openssl 1.0.2d
I get the following warnings from compiling the latest openssl with gcc 4.7.2: ec_key.c: In function 'EC_KEY_set_public_key_affine_coordinates': ec_key.c:369:26: warning: variable 'is_char_two' set but not used [-Wunused-but-set-variable] ecp_nistp224.c: In function 'batch_mul': ecp_nistp224.c:1105:29: warning: array subscript is above array bounds [-Warray-bounds] ecp_nistp256.c: In function 'batch_mul': ecp_nistp256.c:1631:28: warning: array subscript is above array bounds [-Warray-bounds] ecp_nistp521.c: In function 'batch_mul': ecp_nistp521.c:1457:29: warning: array subscript is above array bounds [-Warray-bounds] I'm not real current with C so I'm not in a great position to criticize, but can't those warnings (if there is truly no problem) be eliminated (at least in gcc) with a pragma? Thanks. Best regards, -Tom ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] setting content types in CMS
On Thu, Jul 09, 2015, Richard Welty wrote: how does one set a content type for a signed CMS object? i am creating it with a call to CMS_sign (with flag CMS_PARTIAL set among others), then when i call CMS_set1_eContentType it crashes. That should work because that's what the cms utility does. Are you checking that the return value from CMS_sign() is not NULL? What arguments are you passing to CMS_set1_eContentType()? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On Thu, Jul 9, 2015 at 10:25 AM, Matt Caswell m...@openssl.org wrote:
On 09/07/15 15:47, Tom Browder wrote:
I get the following warnings from compiling the latest openssl with gcc
4.7.2:
ec_key.c: In function 'EC_KEY_set_public_key_affine_coordinates':
ec_key.c:369:26: warning: variable 'is_char_two' set but not used
[-Wunused-but-set-variable]
I don't get this by default, but can force it by compiling with no-ec2m.
I assume that is what you are using? Its harmless but should be fixed.
Yes, you are correct. I should have been more specific: I am using
openssl version 1.0.2d, and here is my configuration script:
$ cat openssl-config.sh
SSLDIR=/opt/openssl
./config \
no-ec2m \
no-rc5 \
no-idea \
threads \
zlib-dynamic\
shared \
--prefix=${SSLDIR} \
--openssldir=${SSLDIR} \
enable-ec_nistp_64_gcc_128
ecp_nistp521.c: In function 'batch_mul':
ecp_nistp521.c:1457:29: warning: array subscript is above array bounds
[-Warray-bounds]
These only get compiled with enable-ec_nistp_64_gcc_128, but even with
that I don't see these warnings. Perhaps a gcc issue fixed in later
versions? I'm using gcc 4.9.2
Hm, I've been looking for an excuse to build the latest gcc, now I have.
But I haven't tried clang yet so here goes...
Thanks, Matt.
Best,
-Tom
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On Thu, Jul 9, 2015 at 10:22 AM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Thu, Jul 09, 2015 at 09:47:00AM -0500, Tom Browder wrote: ... ecp_nistp224.c: In function 'batch_mul': ecp_nistp224.c:1105:29: warning: array subscript is above array bounds ... In my copy of 1.0.2d, line 1105 of that file is in select_point(), not batch_mul(). Are you sure you're compiling the right code? Yes, and you're right about the function--weird, but maybe Matt's e-mail points out the real problem. Thanks, Viktor. -Tom ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On Thu, Jul 09, 2015 at 11:50:25AM -0500, Tom Browder wrote: On Thu, Jul 9, 2015 at 10:22 AM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Thu, Jul 09, 2015 at 09:47:00AM -0500, Tom Browder wrote: ... ecp_nistp224.c: In function 'batch_mul': ecp_nistp224.c:1105:29: warning: array subscript is above array bounds ... In my copy of 1.0.2d, line 1105 of that file is in select_point(), not batch_mul(). Are you sure you're compiling the right code? Yes, and you're right about the function--weird, but maybe Matt's e-mail points out the real problem. That surely means that you're compiling some patched version or not even 1.0.2d. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Help with OpenSSL running on OSX
On Thu, Jul 9, 2015 at 2:14 AM, Matthew Donald
matthew.b.don...@gmail.com wrote:
One of Imapfilter's users is having problems verifying certificates. They
are running Imapfilter on OSX, which I don't have access to. In addition, I
understand that OSX runs a custom version of OpenSSL, which has changes to
the way certificates are verified.
1.1.0 added hostname verification. It affects all version of OpenSSL,
and is not related to OS X or Macs. Its based on Viktor's work. See
X509_check_host(3) and friends
(https://www.openssl.org/docs/crypto/X509_check_host.html).
OS X itself provides OpenSSL 0.9.8. Its pretty anemic by current yardsticks.
OS X also has twists, like it always links to a shared version of the
library is available (even if -Bstatic is used; and even on iOS, where
dylibs are not allowed). It also uses DYLD_LIBRARY_PATH rather than
LD_LIBRARY_PATH (see
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html).
Also, OS X does not honor RPATHs.
Could someone help me debug the issue by telling me:
1. Does OSX use a certificates file (like other FreeBSD-style systems) to
hold trusted/root certificates, or does it use some other mechanism?
2. If it uses a file, what is the file name
3. if OSX uses some other mechanism to store trusted/root certs, please give
a link to documentation on how it works.
Yes and no. OS X natively uses a Keychain. See, for example, these
instructions at http://wiki.cacert.org/FAQ/ImportRootCert#Mac_OS_X.
Just because the OS provides a Keychain, does not mean utilities
actually use it. For example, cURL and Subversion, provided by Apple,
does not use it.
However, OpenSSL has its own mechanisms to use a trust store (re:
c_hash and friends). So it depends on how OpenSSL was configured,
which also depends on how ImapFilter configured things.
And I seem to recall OpenSSL does not use it (the project could
probably use an ENGINE to interface to it).
*
Because of issues with downlevel versions of the library on nearly all
platforms, I use similar to the following to ensure I get what I
compiled and linked against:
ostringstream oss;
long version = SSLeay();
if (version != OPENSSL_VERSION_NUMBER)
{
oss expected OpenSSL version std::dec
OPENSSL_VERSION_NUMBER;
oss ( std::hex OPENSSL_VERSION_NUMBER ), but
got version ;
oss std::dec version ( std::hex version );
throw runtime_error(oss.str().c_str());
}
You can actually relax that a bit by only comparing the high bytes.
But I'm not interested in binary compatibility. I want to ensure I'm
linking to precisely what I expect.
For details on versioning and binary compatibility, see How does the
versioning scheme work?,
https://www.openssl.org/support/faq.html#MISC8.
Jeff
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Help with OpenSSL running on OSX
One of Imapfilter's users is having problems verifying certificates. They are running Imapfilter on OSX, which I don't have access to. In addition, I understand that OSX runs a custom version of OpenSSL, which has changes to the way certificates are verified. Could someone help me debug the issue by telling me: 1. Does OSX use a certificates file (like other FreeBSD-style systems) to hold trusted/root certificates, or does it use some other mechanism? 2. If it uses a file, what is the file name 3. if OSX uses some other mechanism to store trusted/root certs, please give a link to documentation on how it works. regards Matthew ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssh_DSA_verify_inFIPS EVP_VerifyFinal BAD SIG code:-1 ERROR
Hi All, We are getting the below error in syslog file in FIPS mode. sshd[5939]: error: openssh_DSA_verify_inFIPS EVP_VerifyFinal BAD SIG code:-1 This is hitting when connecting between two servers using ssh authentication. Please let me know how can I solve this issue. Openssl version : 0.9.8.zf Thanks, Gayathri ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL version 1.0.2d released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.2d released === OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2d of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2d is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2d.tar.gz Size: 5295447 MD5 checksum: 38dd619b2e77cbac69b99f52a053d25a SHA1 checksum: d01d17b44663e8ffa6a33a5a30053779d9593c3d SHA256 checksum: 671c36487785628a703374c652ad2cebea45fa920ae5681515df25d9f2c9a8c8 The checksums were calculated using the following commands: openssl md5 openssl-1.0.2d.tar.gz openssl sha1 openssl-1.0.2d.tar.gz openssl sha256 openssl-1.0.2d.tar.gz Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVnmMAAAoJENnE0m0OYESRszEH/RFG+H+im2svvgRoTLI/J8YH czX5u5aNqVWDPqQCZz7OQZOq8l7c9lQ8RMuB6AZWECSzn8IUaAF7dNdKC9qSM2Ax 1Sl1fwFeWHXRASvMm4SDUIQxmU8tBmiopBWM4J2a5LWO3zK6pG8pN72HIBIjuJmk 5Sp02BUMCbI5+FpZju1SOClfkZiAappAcdvJiWhv5ef3dJfdIUE3YBtLlEhzH4Ou cfX64gHcsFHWo8ZnHSwrB+blL6Eb8SnGOn+lBAUCIJhh5MY91PSjhfUVL5e2AYY7 Xqm5EFsghLrfxOZeUUNaCHlkdodR0XAabqvq8TQkSk3QQg8N8UFKxr+HnymtMGc= =ay5A -END PGP SIGNATURE- ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL version 1.0.1p released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.1p released === OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.1p of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.1-notes.html OpenSSL 1.0.1p is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.1p.tar.gz Size: 4560208 MD5 checksum: 7563e92327199e0067ccd0f79f436976 SHA1 checksum: 9d1977cc89242cd11471269ece2ed4650947c046 SHA256 checksum: bd5ee6803165c0fb60bbecbacacf244f1f90d2aa0d71353af610c29121e9b2f1 The checksums were calculated using the following commands: openssl md5 openssl-1.0.1p.tar.gz openssl sha1 openssl-1.0.1p.tar.gz openssl sha256 openssl-1.0.1p.tar.gz Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVnmeDAAoJENnE0m0OYESR30AIAL5Dj1V2k1/eGDxAbThI4Ics +YEozTm8q6ymBFcInczADe3qe8mXllOu5mBCdOqesdxuuaE0VnsVo0Vm241LMUee blcelAD8pqqlHPenPRPVO+bpvqdJrWGFTOpdJbaTBCslT9E6YaTfpG1xZI1x4yrM VMR57CkdksDi4mm7TuG0m1w3liUN93pdDyIyesI+nkO7NwZpQ2xeM44z4wlUaxiB oZwnB4VTysVOOM7ZZqdZkDH2BO0nDs0SnPd4byL4AdjhrTIxf0qEKTIcm7WTvnU4 FGpkVJT7/Sm15xdJQ1keZLcRJ5oTHgWuLT7rsX01T4MLWQ8qT1afDkx/O2oF07o= =1BNN -END PGP SIGNATURE- ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [9 Jul 2015] === Alternative chains certificate forgery (CVE-2015-1793) == Severity: High During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and issue an invalid certificate. This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication. This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o. OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p This issue was reported to OpenSSL on 24th June 2015 by Adam Langley/David Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL project. Note As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these releases are advised to upgrade. References == URL for this Security Advisory: https://www.openssl.org/news/secadv_20150709.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/about/secpolicy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVnml8AAoJENnE0m0OYESRlcYH/iUe62/m2oZiuBHkKQvLBUbH VrLDp7xEXEg6ozByLyxughAFwY9XD2r9WkXehxw66af2pmNHphXH3Gbfpcebki0r HuZJ3CbGD/RSomWdAqkzRfV8MjNxmN4Pyi+sTsf7F+nKv80Ts51iUN1pPjkddAR8 ooKw0VMIENeMboWQ9SyQ3r7TYYywK+lXUG71Ekva9ByzABBwC/1CzZeSLJmuewnJ +9TjwQ4otH/mUJ/klvw+G2eTSn64AnA6UEFR+sBL4aNpIgdrtjonJRt2ko05Z92N HN/ibu5okd3iUbtkM0dTMGAr2NCrNYPr2dYLMPemwkAq1cRlhjGouRDDeb6TUYk= =oUAa -END PGP SIGNATURE- ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] OpenSSL Security Advisory
This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o. In other words, if you are not using those specific releases -- i.e., the ones that came out less than 30 days ago -- you do not need to upgrade. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] setting content types in CMS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 how does one set a content type for a signed CMS object? i am creating it with a call to CMS_sign (with flag CMS_PARTIAL set among others), then when i call CMS_set1_eContentType it crashes. thanks, richard -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVnncwAAoJEBg+LdNh/YEcF4kP/RCrVw4BSJciNQrGY3ObZU8N hmrUklA6IFCeuHn1LMkA8em8d5zwqvuMrse+xROTMK66ZAtklGaB7RZYduonl6qH tmn6x1wACxMGjE73dZOrwID8Ipatb0kpu/lslgkiHlHK80JyKMNU7xXRwRPbkpdI da4/CDzlaMMyBBEbGeLvvYemVnbiFmnmHX+WU7rE84r2C6FnHd1B5jjyLwRsbNsA k5c/hVewpaBCDHDGlczMLctcgBi5zUvT/EaMVh6kapInf21ndZZpss2WSLRjvLaa i6NcqxwKlsfz8m0Djc1TfuzbYyJh1zUb+EoepMV36BGz/Z7RdJsuLrgoSi5L/jr+ s1NNiaicSzVhiqZTveykcBUr77bw9ZLTRyGdxnBQAOl1GrugRNgBq1OCl6kFh+Z7 2gRAEUUG32JRG6WL6We+wbsCKD0XuVXJTu+ljvB51KF9GuxXW6KkYWoPOTQy9K+m aSA34xNTzGTsOS4u15zAtl0K1DoawEOp1halX/qAmMGRtfejkwSW/zTaEJ+xAY23 9ROOtC0azCCHF/8eukfkaHJarQB+3RWCLtvbModgA1NzqvDeSMCwlW25g48Al+vv +JPk4E1oWcE6rsCNSQbC+TFmb2uPkYK5oAXrQq/tfaRJFjz8HEELH8F+1m0PKL/+ cC/fkd00VQFyiiG6XjMy =9t4B -END PGP SIGNATURE- ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] s_client bug or expected behavior?
On Debian and Macports, the script below returns Verify return code: 0 (ok). Effectively, it claims Google's CA is certifying Microsoft properties. Some folks claim this is expected behavior. s_client(3) does not discuss the expected behavior, so I'm not sure what should be expected. (I thought expected behavior was to use a default Trust Store if both -CApath and -CAfile was *not* specified; otherwise, only use what was specified). For the folks who claim its expected, I think their reasoning reduces to s_client has a trust store, and specifying -CAfile means Trust Store + CAfile is used to verify the connection, rather than just CAfile. Is it expected behavior that s_client will effectively use Trust Store + CAfile (or Trust Store + CApath)? (I'm happy to update s_client(3) man page to remove all ambiguity once I know what the documented behavior is supposed to be). Thanks in advance. * $ cat s_client-test.sh #!/bin/bash wget https://pki.google.com/GIAG2.crt openssl x509 -in GIAG2.crt -inform DER -out GIAG2.pem -outform PEM # Intuitively, this should fail, but it does not. openssl s_client -connect www.microsoft.com:443 -tls1 -servername www.microsoft.com -CAfile GIAG2.pem ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Old RSA_NET key format
On 09/07/2015 21:52, Karl Vogel wrote: On 08/07/2015 20:23, Salz, Rich wrote: 1. Is there any good reason to remove this code? R Yes. If it's not tested, reviewed, or in general use, then it's R more likely to be harmful (source of bugs) than useful. On Wed, 08 Jul 2015 20:47:43 +0200, Jakob Bohm replied: J That's an overly general criteria... Nope, Rich is right on the money. You are obviously quoting others without deep understanding. J To objectively consider the potential harm of rarely used code, J one must clearly determine if there is any way this code could be J invoked inadvertently or remotely. How do stack-smashers work? Don't they trick a system into running part of a program inadvertently, often with elevated privileges? Actually, mostly they work by tricking a system into running code that was *part of* the stack smasher itself. Second most popular option is to use parts of the general system code (libc etc.) loaded in every process (because attackers like their attack code to be reusable across different victims). Reusing part of whichever program or library that had the remote code execution flaw is typically last on their list, because it is so much more work. How many of us build and run OpenSSL using compiler optimization? Have a look at http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf From the blurb: What if you put security into your code but your compiler took it out without you realizing it? That's exactly what's happening when you use most compilers on the market, according to researchers at MIT as disclosed in a 2013 paper. The authors describe some security operations (null pointer checks, buffer overflow safeguards, etc) seen by the compiler as being unnecessary, and hence removed. I don't know that this is actually happening anywhere in the codebase, but it's a *big* codebase, and that's the problem. That paper was hopefully a major wake up for compiler writers, nothing anyone else can do about (short of writing pure assembler or turning off optimizations, both very ugly solutions). How about the NTP reflection attacks we saw recently? From http://www.mail-archive.com/tech@openbsd.org/msg21729.html [...] openntpd is a modern piece of code 5000 lines long written using best known practices of the time, whereas ntp.org's codebase is reportedly 100,000 lines of unknown or *largely unused code*, poorly smithed in the past when these kinds of programming mistakes were not a significant consideration. Generalization beyond relevance, yes ntpd contains lots of hard to fathom code, and yes some of that may have been involved in attacks. But most of the recent ntpd related attacks didn't actually involve bugs in the code *at all*. Those were attacks on the protocol and on the incompetent ISPs not implementing standard anti- spoofing filters. So by sending a *valid* but obscure query with a false return address, people got the ntp servers to respond with *valid* larger replies to the victims whose address had been falsified. The primary changes added to ntpd were to actively detect and block overly frequent info queries pretending to be from the same address. Openntpd just happened not to support the diagnostic protocolcommands used in the attacks, it was too simple to fall victim. The code in question was probably some of the most heavily tested in ntpd, since its heaviest users are the NTP expert teams diagnosing and fine tuning production servers. J For example the heartbeat code was obviously callable from network J packets (even if it had no bugs), so needed this kind of cleanup, Was this only obvious after the fact? By definition, this code was intended to handle specific network packets and generate responses. The bug was a massive input validation failure. The code could *only* beinvoked from the network. J while the original eay DES API is only invokable from code that J knows about it, and would thus not need to be removed for lack of J use/testing. What about Apple's SSL/TLS bug (AKA CVE-2014-1266, or the goto fail bug) in February 2014? That was caused by unreachable code that needed to be reached in order to work properly. The point is, more code == more eyes and mind-share that have to be devoted to finding unintended consequences. I have not reviewed that in detail, but it sounds like there was a bug in a primary code path, not in a rarely invoked separate function. Have a look here for more reasons to trim out old code: http://www.techrepublic.com/blog/software-engineer/why-you-need-to-clean-out-dead-code-paths/ Just some guys opinion on a site that carries all sorts of opinion pieces. Not even worth reading. Cliff-notes version: * Code changes gets ugly because you are trying to keep orphaned code in line with the rest of the system, but there is often no real
Re: [openssl-users] Old RSA_NET key format
OpenSSL is a critical part of security in too many places for us to take on any unnecessary technical debt. This is a somewhat empty argument as long as no one bothers to properly determine if a piece of code is a debt or an asset. I claim that we are being careful and doing the proper determination. Consensus seems to agree. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Old RSA_NET key format
On 09/07/2015 23:09, Salz, Rich wrote: OpenSSL is a critical part of security in too many places for us to take on any unnecessary technical debt. This is a somewhat empty argument as long as no one bothers to properly determine if a piece of code is a debt or an asset. I claim that we are being careful and doing the proper determination. Consensus seems to agree. However, it seems that your determination process goes like this: 1. If you think you know, you don't ask anyone if they use the feature. 2. If you do bother to ask the customers if there is a business case for a feature, you still ignore all arguments as to why it is an asset. Because both methods confirm your prior decisions, you therefore conclude that you were always right in the first place. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, 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-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Old RSA_NET key format
Because both methods confirm your prior decisions, you therefore conclude that you were always right in the first place. Provably wrong. I wanted to get rid of Netware support as the first example that comes to mind. As the second, I want to move all uses of RC4 and MD5 to LOW strength ciphers. Neither one of those things is happening. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Old RSA_NET key format
On 08/07/2015 20:23, Salz, Rich wrote: 1. Is there any good reason to remove this code? R Yes. If it's not tested, reviewed, or in general use, then it's R more likely to be harmful (source of bugs) than useful. On Wed, 08 Jul 2015 20:47:43 +0200, Jakob Bohm replied: J That's an overly general criteria... Nope, Rich is right on the money. J To objectively consider the potential harm of rarely used code, J one must clearly determine if there is any way this code could be J invoked inadvertently or remotely. How do stack-smashers work? Don't they trick a system into running part of a program inadvertently, often with elevated privileges? How many of us build and run OpenSSL using compiler optimization? Have a look at http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf From the blurb: What if you put security into your code but your compiler took it out without you realizing it? That's exactly what's happening when you use most compilers on the market, according to researchers at MIT as disclosed in a 2013 paper. The authors describe some security operations (null pointer checks, buffer overflow safeguards, etc) seen by the compiler as being unnecessary, and hence removed. I don't know that this is actually happening anywhere in the codebase, but it's a *big* codebase, and that's the problem. How about the NTP reflection attacks we saw recently? From http://www.mail-archive.com/tech@openbsd.org/msg21729.html [...] openntpd is a modern piece of code 5000 lines long written using best known practices of the time, whereas ntp.org's codebase is reportedly 100,000 lines of unknown or *largely unused code*, poorly smithed in the past when these kinds of programming mistakes were not a significant consideration. J For example the heartbeat code was obviously callable from network J packets (even if it had no bugs), so needed this kind of cleanup, Was this only obvious after the fact? J while the original eay DES API is only invokable from code that J knows about it, and would thus not need to be removed for lack of J use/testing. What about Apple's SSL/TLS bug (AKA CVE-2014-1266, or the goto fail bug) in February 2014? That was caused by unreachable code that needed to be reached in order to work properly. The point is, more code == more eyes and mind-share that have to be devoted to finding unintended consequences. Have a look here for more reasons to trim out old code: http://www.techrepublic.com/blog/software-engineer/why-you-need-to-clean-out-dead-code-paths/ Cliff-notes version: * Code changes gets ugly because you are trying to keep orphaned code in line with the rest of the system, but there is often no real regression testing or anything else. * Maintaining code after a long period away from it (or by someone else) is very difficult, because no one really knows why a piece of code is there, they just know that it is there. * The code is no longer a faithful representation of the business logic, because it contains logic that the specifications and business logic are not aware of. * It presents potential security risks, as unmaintained code can be reached (especially in Web applications, where tweaking parameters may trigger something you never intended). OpenSSL is a critical part of security in too many places for us to take on any unnecessary technical debt. -- Karl Vogel I don't speak for the USAF or my company Sign on a long-established New Mexico dry cleaners: 38 years on the same spot ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] OpenSSL Security Advisory
On 09/07/15 22:46, Jakob Bohm wrote: On 09/07/2015 15:10, OpenSSL wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [9 Jul 2015] === Alternative chains certificate forgery (CVE-2015-1793) == Severity: High During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and issue an invalid certificate. Why was this introduced in a patch release? I thought improved chain building was a new feature, and thus delineated by a library version number such as 1.0.2or 1.0.3. In fact, I thought that was the reason we all had to wait ages before this long standing shortcoming was fixed. Is it a new feature or a defect fix? On the one hand OpenSSL has never been able to handle alternative certificate chains. If the first chain attempted fails to verify then we stop. Its always been done that way and from that point of view the ability to handle alternative cert chains is a new feature. On the other hand, from a users perspective, if you present OpenSSL with a perfectly valid certificate, and a perfectly valid trust store, then you expect it to successfully verify the certificate no matter what. OpenSSL was failing to do that, and therefore this would suggest it is a defect. My initial view was the former. This issue was raised a number of times within RT and on the openssl-dev list and also via other routes. It was clearly causing real problems for end users (and increasingly so). There was much discussion on this topic, but ultimately the decision was taken to change our mind, and treat it as a defect. For that reason it was included in a patch release. This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication. Does this vulnerability also affect applications that use OpenSSL or the openssl command line to handle S/MIME or other CMS messages? Yes. Ultimately it affects all applications that verify certificates. That includes the openssl command line applications. Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] setting content types in CMS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 7/9/15 9:53 AM, Dr. Stephen Henson wrote: On Thu, Jul 09, 2015, Richard Welty wrote: how does one set a content type for a signed CMS object? i am creating it with a call to CMS_sign (with flag CMS_PARTIAL set among others), then when i call CMS_set1_eContentType it crashes. That should work because that's what the cms utility does. Are you checking that the return value from CMS_sign() is not NULL? What arguments are you passing to CMS_set1_eContentType()? i had commented out the problem code in order to move forward; i just uncommented it and reran the test and now it works. there must have been some commenting error on my part. now i have a stack trace in CMS_verify to chase down. as i've spotted some things in my code that need to be adjusted, i'll not bother anyone with questions about that just now. thanks for the help, richard -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVnoVyAAoJEBg+LdNh/YEcfTMQALSPliel6eFXx6xQUIp6bi+D wtR2hifU1Y6/AhvyO9osW/QiqPdXobkX94acFmj2cj5as9NwpriETNEYn3TF12Uu YYhfrEa/JP2kyDTFTR+zzS8bN0WZTxVNnTBx7zy3oZsZ/modr+1wHfBSe9BOeUc5 uwc1xLkl82b5rZGbtmjkxHEFp776lsXkzDUkZEbNLbfjLpOY+NEBTmQXr8DJvxMP Xsu6DnbRTNiM80TIi4LdMMaSBdEPiusOYYxxFygDtEwqi2vveQ9iQPCrITLsu0Zd 1M1pobRtUMcBaEE69+F5dagYDKcdJm5LiS4nkn9sGS2OQDRUWYLeJJBWI+/SmHpm t+jkP8UTVy1XaUGgknHZB435Fv1o71X+pWllDOO3L79G4Jcp7Nrs4soJrBFkgTSc K5Y3eHdfKIqG0349obghHR9uYQme90eqexA2reih3Lfy6uFqK1UZutkB70v+IdEx sxkA11zrM3DtAYBEBg7exGxyqS823USRSVXSE+CkwPghypYyalmZSxaHL0GMn+bM 3QK2OUWUqfjkizzOub1NRnTxtK1kBjrGpQpzWf6JqnToo//rn12mmJpeyIWA4m6X PBtJwLxZqkeThU49uJzm6nfM0saWdeM33IfmCj2pTvAESbf2Tfp7VOpJ1xDS03xy vq8HBJXtSomGiel31rfB =X9xM -END PGP SIGNATURE- ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] OpenSSL Security Advisory
On 09/07/2015 15:10, OpenSSL wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [9 Jul 2015] === Alternative chains certificate forgery (CVE-2015-1793) == Severity: High During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and issue an invalid certificate. Why was this introduced in a patch release? I thought improved chain building was a new feature, and thus delineated by a library version number such as 1.0.2or 1.0.3. In fact, I thought that was the reason we all had to wait ages before this long standing shortcoming was fixed. This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication. Does this vulnerability also affect applications that use OpenSSL or the openssl command line to handle S/MIME or other CMS messages? For example, the mail client mutt handles S/MIME by invoking the openssl command line via macros in the default configuration file. P.S. Sorry for first trying to send to -announce, MUA must have ignored the Reply-To. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S.http://www.wisemo.com Transformervej 29, 2860 Søborg, 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-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
