[openssl.org #2990] Bug Report:openssl timezone issue
Hello, I’ve found there is issue in opensssl for timezone. As I understood if I add time zone then it will be create as per that time zone but it has been created by adding that much amount of time. As shown below. When I am going to create certificate with –startdate and –enddate in format YYMMDDHHMMSSZ as following. -startdate 13021400+0530 –enddate 14123100+0530 then +0530 for IST timezone. As per IST time zone certificate has been created for time startdate 2013-02-14 11:00:00 and enddate 2014-12-31 11:00:00. Why this thing happen? Regards, Kavan Modi Software Engineer Cyberoam Technologies Pvt Ltd. Ahmedabad, Gujarat India __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2981] BUG: 1.0.1e 64-bit C implementation ECDHE* chiphersuites incompatible with https://google.com
Probably this strict aliasing 64-bit optimization bug for
crypto/bn/bn_nist.c
What bug are you talking about? There doesn't seem to be a strict
aliasing warning in that file, and they use a union to get around
the problem.
Mac OSX compiler fail test/ectest: cc [Apple LLVM version 4.2
(clang-425.0.24) (based on LLVM 3.2svn)] gcc-mp-4.3 gcc-mp-4.4 gcc-mp-4.5
gcc-mp-4.6 clang-mp-3.0 clang-mp-3.1 clang-mp-3.2
Mac OSX compiler test/ectest OK: gcc-apple-4.2 gcc-mp-4.7 gcc-mp-4.8
[gcc-mp-4.8 (MacPorts gcc48 4.8-20130203_0+universal) 4.8.0 20130203
(experimental)] clang-mp-2.9 clang-mp-3.3 [clang version 3.3 (trunk 173279)]
I can at least reproduce the problem with clang 3.0.
Oh, that I managed to reproduce.
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=750398acd85a7ae220d272d28a76dff7bb269c31
works around this one.
Serguei, could you test if it fixes even your problem[s]?
PS: I think at least this patch makes sense, but doesn't change anything:
--- a/crypto/bn/bn_nist.c
+++ b/crypto/bn/bn_nist.c
@@ -530,7 +530,7 @@ int BN_nist_mod_224(BIGNUM *r, const BIGNUM *a, const
BIGNUM *field,
{
NIST_INT64 acc;/* accumulator */
unsigned int*rp=(unsigned int *)r_d;
- const unsigned int *bp=(const unsigned int *)buf;
+ const unsigned int *bp=(const unsigned int *)buf.ui;
acc = rp[0]; acc -= bp[7-7];
acc -= bp[11-7]; rp[0] = (unsigned int)acc; acc =
32;
The typo will be fixed as we go.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2981] BUG: 1.0.1e 64-bit C implementation ECDHE* chiphersuites incompatible with https://google.com
Hi,
For reference. Why does it show up with no-asm? bn_nist.c is
collection of functions for specific moduli, but it's perfectly
possible to calculate the result using general-purpose subroutines.
It was found that general-purpose *assembly* code paths deliver
better performance and it was arranged so that bn_nist is not
invoked in asm builds (look for #if defined(OPENSSL_BN_ASM_MONT) in
crypto/ec/ec_cvt.c).
If Configure invoke without no-asm flag, then bn_nist.c compiled,
but function BN_nist_mod_{192,224,256,384} don't called. If
Configure invoke with no-asm, OpenSSL use
BN_nist_mod_{192,224,256,384} functions. Right?
Yes.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2978] CVS repositories serving stale data
On 02/07/13 23:35, Andy Polyakov via RT wrote: The CVS repositories on cvs.openssl.org are still up and serving stale data. Please turn them off If you're referring to http://cvs.openssl.org, then removal would hardly be appropriate, because there are references to it in lists and RT. It would be appropriate to switch off anonymous CVS access. That's what I meant. Thanks, v. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2988] Makefiles should (usually) remove target before re-generating
On Thu Feb 14 04:35:05 2013, rs...@akamai.com wrote: Unfortunately some platforms can't automatically build the files e.g. WIN32, VMS. Okay, so those targets shouldn't get invoked? Or are you saying that you WANT the build to fail on those platforms? Ah so you're saying the files would be retained in tarballs and under version control just deleted before being recreated? [I might have misinterpeted this. Sometimes it is suggested that all auto generated files should be deleted from the tarballs... which we can't do for the reasons stated] # objects.pl both reads and writes obj_mac.num obj_mac.h: objects.pl objects.txt obj_mac.num + $(RM) obj_mac.num $@ $(PERL) objects.pl objects.txt obj_mac.num $@ @sleep 1; touch obj_mac.h; sleep 1 + chmod 444 obj_mac.num $@ Deleting obj_mac.num is a bad idea. It contains the NID values which are added to over time. If you delete that file the recreated version is almost certain to have a different NID assignment which breaks binary compatibility. Okay. Then would you be interested in patch to objects.pl and the Makefile that created obj_mac.new and the Makefile replaced the file? Can you explain the problem with the current system? 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
RE: [openssl.org #2988] Makefiles should (usually) remove target before re-generating
We extract a tarball and make everything read-only. Sometimes an item in the distribution gets re-made. This can fail because of permissions. So, on platforms where this would happen, we'd like to remove the file first. I wasn't advocating to remove them from the distro, I understand we need to be kind to our crippled (cough vms:) brethren. Is this more clear? -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Adding more options
I see that we've used up all 32 bits of options in the SSL structure. Any thought given on how to extend that? A 64-bit long long seems simplest, but might have issues with some of your older platforms. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA
1.0.1e test suite fails with OPENSSL_NO_TLS1_2_CLIENT
Hi, if openssl 1.0.1e is compiled with the -DOPENSSL_NO_TLS1_2_CLIENT option make test fails with: Testing AES256-GCM-SHA384 Available compression methods: 1: zlib compression ERROR in CLIENT 4147160712:error:140740B5:SSL routines:SSL23_CLIENT_HELLO:no ciphers available:s23_clnt.c:486: TLSv1.2, cipher (NONE) (NONE) 1 handshakes of 256 bytes done Failed AES256-GCM-SHA384 This still fails when using the latest git 1.0.1 stable branch. We use this option as a workaround for PR#2771. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2279] Bug Report
This bug about an incompatibility of cms-test.pl with old Perl versions has been fixed in 2011 for trunk by Andy (thanks!), but not been backported to any release branch. I verified it today for 1.0.1 on Solaris 8. It would be nice if the simple change could be applied to at least some of the release branches. http://rt.openssl.org/Ticket/Display.html?id=2279 populated. thanks for reminder. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Fwd: Openssl-0.9.8q
Forwarding to dev team as well -- Forwarded message -- From: Rajeswari K raji.kotamr...@gmail.com Date: Thu, Feb 14, 2013 at 4:58 PM Subject: Openssl-0.9.8q To: openssl-us...@openssl.org Hello Team, Our project uses openssl to perform ssl handshake and uses hardware crypto engine to encrypt and decrypt. Once we receive first Encrypted message in ssl handshake (i.e FINISHED message), we forward it to hardware crypto engine to decrypt. When used* openssl0.9.8g* version, and tried to connect from browser handshake was successful and hardware crypto engine successfully decrypted the FINISHED message. When ported with *OPENSSL0.9.8q* version, and tried to connect from browser handshake is not successful and hardware crypto engine is returning an error. After contacting hardware crypto engine team for the reason for failure, they responded that AUTH key used at openssl for the MAC calculation is incorrect/wrong. Observations : 1) TLS1.0 SSL3.0 handshakes were successful with OPENSSL0.9.8g 2) SSL3.0 handshake with OPENSSL0.9.8q is successful 3) *TLS1.0* handshake with *OPENSSL0.9.8q is failed*. Please provide some pointers if anyone come across similar kind of situation. Thanks in advance, Rajeswari.
[openssl.org #2991] Certifacte verification with a RSA-SHA512 hash algorithm fails
Hi, there is a problem with certificate verification. Windows allows the generation of CA certificates which uses RSA-SHA512 as the hash algorithm. But this hash algorithm is currently not supported by OpenSSL. Will this issue be fixed in future or is there a workaround for this? Regards, Dominic Dominic Wollner Dipl.-Inf. (FH) Development Research Linux IGEL Technology - The world's most advanced thin clients Many Functions. One Device. ® IGEL Technology GmbH Annastr. 11 86150 Augsburg, Germany Email: woll...@igel.com mailto:mate...@igel.com Phone: +49 (0)821 34 32 08 - 233 Fax: +49 (0)821 34 32 08 - 9 www.igel.com http://www.igel.com/ - www.igel.de http://www.igel.de/ IGEL Technology is a member of the Melchers group. Managing Directors: Heiko Gloge, Nicolas C. S. Helms, Dirk Dördelmann, Andreas Schönduve District Court Bremen (Germany) HRB 20636, VAT: DE 219524359 Confidentiality Note: The information contained in this transmission is legally privileged and confidential, intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you receive this communication in error, please notify us immediately by telephone call to +49 (0)821 34 32 08 - 233 and delete the message. Thank you! P Please consider the environment before printing this email or its attachments. Many thanks... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2991] Certifacte verification with a RSA-SHA512 hash algorithm fails
On Thu Feb 14 18:14:37 2013, woll...@igel.com wrote: Hi, there is a problem with certificate verification. Windows allows the generation of CA certificates which uses RSA-SHA512 as the hash algorithm. But this hash algorithm is currently not supported by OpenSSL. Will this issue be fixed in future or is there a workaround for this? SHA512 has been supported in OpenSSL for some time. What version are you using and what verification error do you get? If possible please include a sample certificate that fails with the command line utilities. 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
Re: Adding more options
On Thu, Feb 14, 2013, Salz, Rich wrote: I see that we've used up all 32 bits of options in the SSL structure. Any thought given on how to extend that? A 64-bit long long seems simplest, but might have issues with some of your older platforms. OpenSSL 1.0.2 has added an extra cert_flags field as part of the CERT structure. Adding things to CERT has the advantage that it is one of the few structures in the ssl library that has always been opaque. 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
RE: Adding more options
OpenSSL 1.0.2 has added an extra cert_flags field as part of the CERT structure. Adding things to CERT has the advantage that it is one of the few structures in the ssl library that has always been opaque. And so do you change the options from a raw hex number (0x08000 etc) to a bitnumber (17)? We have some additional options on the SSL structure that we'd like to contribute. Right now we use long long What should we do, in order to make it most likely you'll take them? /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
