From jb-openssl at wisemo.com Sat Aug 1 04:56:16 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Sat, 1 Aug 2015 06:56:16 +0200 Subject: [openssl-users] [openssl-1.0.2d] default SSL handshake fails In-Reply-To: <20150731210650.GW4347@mournblade.imrryr.org> References: <20150731210650.GW4347@mournblade.imrryr.org> Message-ID: <55BC5170.7080900@wisemo.com> On 31-07-2015 23:06, Viktor Dukhovni wrote: > On Fri, Jul 31, 2015 at 08:47:45PM +0000, Felix Almeida wrote: > >> I've tested other OpenSSL versions and everything goes well up to version >> 1.0.1o, starting from 1.0.2 I see this handshake error. > It seems you're posting follow-ups without checking whether your > original post was answered. > >> I also tried to disable TLS on 1.0.2d by passing "no-tls" to the config >> script, but this broke the building process (make stopped with an error). >> So I believe I will stick with version 1.0.1o for now. :-\ > Or configure a cipherlist more compatible with a long obsolete and > no longer supported Windows 2003 TLS stack. > The Windows 2003 TLS stack became unsupported for most (but /not all/) users less than 20 days ago. Treating it as marginal and not as something that any core networking library needs to be compatible (even *tested* with) out of the box is another symptom of the useless attitudes that permeate the new OpenSSL leadership. The old OpenSSL project belonged to the long standing tradition of making sure that Internet software needs to work with the quirks of anything it could reasonably encounter on any real world network, including both the Internet, the US military networks (which have allegedly paid a boatload of money for continued Win2003 support) and any closed site networks that reuse Internet protocols for their internal operations. It would have been a serious brown bag moment for the old maintainers to discover this in a release made that close to (if not even overlapping) the vendor support period for such a widely deployed system. There is a lot of utility software which is linked to OpenSSL libraries with very little user configurability and which is simply expected to "just work" when transferring data off a (not so) old Windows computer. The old team would have gone out of their way to make sure the standard OpenSSL code would generate backward compatible hello records by default, e.g. by ensuring that the strongest enabled Win 5.x compatible cipher was within the first 64 ciphers if that is indeed the technical solution. Such real world quality issues are much more important than making sure broken test tools don't complain that code to prevent accidental heap corruption is not being called by the current test suite because the relevant coding errors have not yet happened. OpenSSL is supposed to make sure that practical tools such as wget, curl, fetchmail etc. etc. can talk to almost any old SSL/TLS implementation that might be found in a dusty basement or on an old backup tape somewhere. Talking to an old Netscape Navigator 3.x or a clunky old printer should have a high chance of working, while talking to anything popular that was up to date with official security updates less than 2 years ago (let alone a month) is a simple must. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Soborg, 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 From openssl-users at dukhovni.org Sat Aug 1 06:00:30 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 1 Aug 2015 06:00:30 +0000 Subject: [openssl-users] [openssl-1.0.2d] default SSL handshake fails In-Reply-To: <55BC5170.7080900@wisemo.com> References: <20150731210650.GW4347@mournblade.imrryr.org> <55BC5170.7080900@wisemo.com> Message-ID: <20150801060030.GA4347@mournblade.imrryr.org> On Sat, Aug 01, 2015 at 06:56:16AM +0200, Jakob Bohm wrote: > >Or configure a cipherlist more compatible with a long obsolete and > >no longer supported Windows 2003 TLS stack. Note, I am suggesting compatibility. Yes while the obsolescence is long-standing, I was aware that the support status changed just recently. The problem with 3DES (for Exchange) is known since 2007, but the fix was never made mainstream, you had to request an obscure Hotfix (no longer available). > The Windows 2003 TLS stack became unsupported for most > (but /not all/) users less than 20 days ago. Treating > it as marginal and not as something that any core > networking library needs to be compatible (even *tested* > with) out of the box is another symptom of the useless > attitudes that permeate the new OpenSSL leadership. You should apologize, I resent that remark. Behind the scenes I am working to ensure that we maintain reasonable compatibility with that stack while it still exists in the field, and have helped many users craft sensible work-arounds for the bugs in that platform. It is not so easy to work around the rather severe limitations of Schannel in Windows 2003. OpenSSL would have to by default disable many of the new ciphers in TLS 1.2. Are you suggesting that the exclusions I am recommending should have been on by default? To accommodate a relatively rare and clearly broken peer? We could consider such an accommodation, but I think that the wiser course of action is to document the work-around for those who need it. This is the first report of this problem I've seen for an application protocol other SMTP. It was however immediately recognizable. > The old OpenSSL project belonged to the long standing > tradition of making sure that Internet software needs to > work with the quirks of anything it could reasonably > encounter on any real world network, including both the > Internet, the US military networks (which have allegedly > paid a boatload of money for continued Win2003 support) > and any closed site networks that reuse Internet protocols > for their internal operations. You seem to be pining for the project that lacked any resources to pay attention to documentation or code quality. I think on the whole more sensible trade-offs are being made now. And compatibility is still important. > It would have been a serious brown bag moment for the old > maintainers to discover this in a release made that close > to (if not even overlapping) the vendor support period for > such a widely deployed system. There is a lot of utility > software which is linked to OpenSSL libraries with very > little user configurability and which is simply expected > to "just work" when transferring data off a (not so) old > Windows computer. Who are these "old maintainers" who aren't around any more? > The old team would have gone out of their way to make sure > the standard OpenSSL code would generate backward compatible > hello records by default, e.g. by ensuring that the > strongest enabled Win 5.x compatible cipher was within the > first 64 ciphers if that is indeed the technical solution. The technical solution is correct, and can be deployed by users who need it. By default radical trimming of the cipherlist in new OpenSSL releases to accommodate a rather obsolete and already relatively rare platform is likely not the right call. Perhaps some of that "old team" you pine for might speak up as to what they would like to see done. Keep in mind that users who want to keep running legacy servers, can also keep running legacy clients, they don't need to uprade to anything beyond 1.0.1, that's still supported, and interoperates with Schannel from 2003 by default. $ for r in *; do echo "=== $r ==="; $r/bin/openssl ciphers -v 'DEFAULT:!PSK:!SRP' | grep -n '^RC4-SHA'; done === OpenSSL_0_9_8 === 11:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 === OpenSSL_1_0_0 === 29:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 === OpenSSL_1_0_1 === 57:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 === OpenSSL_1_0_2 === 75:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 === OpenSSL_master === 93:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 [ The reason I'm excluding PSK and SRP is that IIRC the client only actually includes these in the HELLO cipher list when an appropriate password callback is enabled). ] > OpenSSL is supposed to make sure that practical tools such > as wget, curl, fetchmail etc. etc. can talk to almost any > old SSL/TLS implementation that might be found in a dusty > basement or on an old backup tape somewhere. Talking to an > old Netscape Navigator 3.x or a clunky old printer should > have a high chance of working, while talking to anything > popular that was up to date with official security updates > less than 2 years ago (let alone a month) is a simple must. Yes, open source projects rightly pay more attention to interoperability than vendors do. Microsoft's own email stack at outlook.com hangs up on TLS email connections from Windows 2003 Schannel. They don't support RC4 at all. However at some point it is time to move on. I am not strongly opposed to trimming off more of the cruft, we just need to lose 9 ciphers to squeak by with 1.0.2. It's just that this problem though well known to me, has not been widely reported in contexts outside of email. The team may decide to make some accommodation, but frankly posts like the above, that are whining about past glory, are not particularly motivating. Would you like to see my work-around exclusions in the DEFAULT cipherlist? $ for r in *; do echo "=== $r ==="; $r/bin/openssl ciphers -v 'DEFAULT:!PSK:!SRP:!kDH:!kECDH:!IDEA:!RC2:!RC5:!MD5:' | grep -n '^RC4-SHA'; done === OpenSSL_0_9_8 === 10:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 === OpenSSL_1_0_0 === 22:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 === OpenSSL_1_0_1 === 42:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 === OpenSSL_1_0_2 === 42:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 === OpenSSL_master === 52:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 That might be good enough, until some ChaCha20 ciphers appear, and perhaps CCM, I can't promise there'll be fewer than 20 new ciphers in total. At some point soon, even the above band-aid will not be flexible enough to provide both all the modern ciphers we want (that will actually be used) and still keep RC4-SHA around. The simplest work-around is to explicitly disable TLS 1.2 and higher when communicating with a known obsolete peer, it will only do TLS 1.0 anyway. -- Viktor. From kurt at roeckx.be Sat Aug 1 14:23:54 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 1 Aug 2015 16:23:54 +0200 Subject: [openssl-users] [openssl-1.0.2d] default SSL handshake fails In-Reply-To: <55BC5170.7080900@wisemo.com> References: <20150731210650.GW4347@mournblade.imrryr.org> <55BC5170.7080900@wisemo.com> Message-ID: <20150801142354.GA17235@roeckx.be> On Sat, Aug 01, 2015 at 06:56:16AM +0200, Jakob Bohm wrote: > > The old team would have gone out of their way to make sure > the standard OpenSSL code would generate backward compatible > hello records by default So it's my understanding that you suggest the default OpenSSL client should: - Only support SSLv2, SSLv3 and TLS1.0 because things break when we we try to talk to some sites indicating we support TLS 1.1 and/or 1.2? Maybe we should even disable TLS 1.0 and SSLv3? - Don't send any TLS extentions, since some sites don't support it? - Don't send any cipher strings with the first byte different from 0 because some implemantation don't look at the first byte and might then select a cipher we didn't announce? - Enable all the work arounds for broken implementations again, even when they can be exploited? - Give RC4 such a priority by default that it's in the list before much stronger ciphers because that's the only cipher from our default list that works with some implementations, even when the RFCs say we should disable RC4 by default? I guess we should just stop trying to improve in general. Kurt From doctor at doctor.nl2k.ab.ca Sat Aug 1 15:02:07 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sat, 1 Aug 2015 09:02:07 -0600 Subject: [openssl-users] NEed help Message-ID: <20150801150207.GA14960@doctor.nl2k.ab.ca> I am trying to compile openssl 1.0.2 SNAP 20150801 and now I get if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then (cd ..; make libcrypto.so.1.0.0); fi [ -z "" ] || gcc -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -march=pentium3 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso fips_premain.c fipscanister.o libcrypto.a -ldl -lm -lc /usr/lib/libc.a(sha.o): In function `SHA': sha.o(.text+0x0): multiple definition of `SHA' libcrypto.a(sha_one.o):/usr/source/openssl-1.0.2-stable-SNAP-20150801/crypto/sha/sha_one.c:66: first defined here ld: Warning: size of symbol `SHA' changed from 142 to 92 in /usr/lib/libc.a(sha.o) /usr/lib/libc.a(malloc.o)(.text+0x16): undefined reference to `__progname' /usr/lib/libc.a(malloc.o)(.text+0xe0): undefined reference to `__progname' /usr/lib/libc.a(syslog.o): In function `vsyslog': syslog.o(.text+0x3a5): undefined reference to `__progname' /usr/lib/libc.a(getenv.o): In function `__findenv': getenv.o(.text+0x65): undefined reference to `environ' getenv.o(.text+0x72): undefined reference to `environ' /usr/lib/libc.a(exec.o): In function `execl': exec.o(.text+0x103): undefined reference to `environ' /usr/lib/libc.a(exec.o): In function `execv': exec.o(.text+0x26b): undefined reference to `environ' /usr/lib/libc.a(exec.o): In function `execvp': exec.o(.text+0x400): undefined reference to `environ' /usr/lib/libc.a(exec.o)(.text+0x4da): more undefined references to `environ' follow *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. Pointers please on how to fix. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Abuse a man unjustly, and you will make friends for him. -Edgar Watson Howe From doctor at doctor.nl2k.ab.ca Sat Aug 1 15:25:32 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sat, 1 Aug 2015 09:25:32 -0600 Subject: [openssl-users] Debugging a compile issue Message-ID: <20150801152531.GA15397@doctor.nl2k.ab.ca> A few weeks ago, I overloaded my server and compiler and now I get signed content test streaming BER format, 2 DSA and 2 RSA keys, no attributes: OK signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: verify error *** Error code 1 Stop. *** Error code 1 Stop. How can debug and rectify the situation? I do need to move forward. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Abuse a man unjustly, and you will make friends for him. -Edgar Watson Howe From steve at openssl.org Sat Aug 1 16:15:16 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Sat, 1 Aug 2015 16:15:16 +0000 Subject: [openssl-users] Debugging a compile issue In-Reply-To: <20150801152531.GA15397@doctor.nl2k.ab.ca> References: <20150801152531.GA15397@doctor.nl2k.ab.ca> Message-ID: <20150801161516.GA4910@openssl.org> On Sat, Aug 01, 2015, The Doctor wrote: > A few weeks ago, I overloaded my server and compiler and > now I get > > signed content test streaming BER format, 2 DSA and 2 RSA keys, no attributes: OK > signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: verify error > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > > How can debug and rectify the situation? > > I do need to move forward. > I answered this a while back. You should have some files called cms.err and cms.out in the test directory. What is in them? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From openssl-users at dukhovni.org Sat Aug 1 17:23:26 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 1 Aug 2015 17:23:26 +0000 Subject: [openssl-users] [openssl-1.0.2d] default SSL handshake fails In-Reply-To: <20150801142354.GA17235@roeckx.be> References: <20150731210650.GW4347@mournblade.imrryr.org> <55BC5170.7080900@wisemo.com> <20150801142354.GA17235@roeckx.be> Message-ID: <20150801172326.GE4347@mournblade.imrryr.org> On Sat, Aug 01, 2015 at 04:23:54PM +0200, Kurt Roeckx wrote: > > The old team would have gone out of their way to make sure > > the standard OpenSSL code would generate backward compatible > > hello records by default > > So it's my understanding that you suggest the default OpenSSL > client should: > > - Only support SSLv2, SSLv3 and TLS1.0 because things break when > we we try to talk to some sites indicating we support TLS 1.1 > and/or 1.2? Maybe we should even disable TLS 1.0 and SSLv3? > - Don't send any TLS extentions, since some sites don't support > it? > - Don't send any cipher strings with the first byte different from > 0 because some implemantation don't look at the first byte and > might then select a cipher we didn't announce? > - Enable all the work arounds for broken implementations again, > even when they can be exploited? > - Give RC4 such a priority by default that it's in the list before > much stronger ciphers because that's the only cipher from our > default list that works with some implementations, even when the > RFCs say we should disable RC4 by default? > > I guess we should just stop trying to improve in general. There is a pragmatic "middle-ground" that I think we're actually largely successful at achieving. Nobody will adopt all the cool new stuff if it significantly breaks interoperability with the old. So we have, for example, the padding extension for the client HELLO to work around F5 problems, and various bug work-arounds are still enabled via SSL_OP_ALL. Neither full-steam ahead, nor maintaining compatibility crutches forever is the right answer. It turns out that the Windows 2003 stack issue has not received much attention outside the Postfix user community (Postfix enables anon_DH and anon_ECDH ciphers and so ran into this sooner than other applications). But even with Postfix, the impact has been rather modest, these systems are not that common. Should I have a made a greater fuss about ensuring interop with Windows 2003, I don't know. I certainly mentioned it on various non-Postfix lists at various times. Various members of the "old team" were on some of those lists. Perhaps more effort should have been made to accommodate such systems for a longer time, by enabling fewer new ciphers by default, but that's not what happened, and there have not been very many problem reports. All this I think points to a reasonably responsible process, with a largely reasonable outcome. If a consensus emerges around a "concise" cipherlist (note that to get there I had to disable DSS, which might not be popular in .gov circles, where perhaps it was actually used), I'd support that, but it is not clear to me that there's a compelling case to make this a default configuration. -- Viktor. From doctor at doctor.nl2k.ab.ca Sat Aug 1 18:04:55 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sat, 1 Aug 2015 12:04:55 -0600 Subject: [openssl-users] Debugging a compile issue In-Reply-To: <20150801161516.GA4910@openssl.org> References: <20150801152531.GA15397@doctor.nl2k.ab.ca> <20150801161516.GA4910@openssl.org> Message-ID: <20150801180454.GA108@doctor.nl2k.ab.ca> On Sat, Aug 01, 2015 at 04:15:16PM +0000, Dr. Stephen Henson wrote: > On Sat, Aug 01, 2015, The Doctor wrote: > > > A few weeks ago, I overloaded my server and compiler and > > now I get > > > > signed content test streaming BER format, 2 DSA and 2 RSA keys, no attributes: OK > > signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: verify error > > *** Error code 1 > > > > Stop. > > *** Error code 1 > > > > Stop. > > > > How can debug and rectify the situation? > > > > I do need to move forward. > > > > I answered this a while back. Sorry for missing the inital reply. > You should have some files called cms.err and > cms.out in the test directory. What is in them? > cme.err file ls: error initializing month strings Error reading S/MIME message 135072992:error:0D0D40D1:asn1 encoding routines:SMIME_read_ASN1:no content type: asn_mime.c:440: amd cms.out is blank > 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 -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Abuse a man unjustly, and you will make friends for him. -Edgar Watson Howe From steve at openssl.org Sat Aug 1 21:52:12 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Sat, 1 Aug 2015 21:52:12 +0000 Subject: [openssl-users] Debugging a compile issue In-Reply-To: <20150801180454.GA108@doctor.nl2k.ab.ca> References: <20150801152531.GA15397@doctor.nl2k.ab.ca> <20150801161516.GA4910@openssl.org> <20150801180454.GA108@doctor.nl2k.ab.ca> Message-ID: <20150801215212.GA9106@openssl.org> On Sat, Aug 01, 2015, The Doctor wrote: > On Sat, Aug 01, 2015 at 04:15:16PM +0000, Dr. Stephen Henson wrote: > > On Sat, Aug 01, 2015, The Doctor wrote: > > > > > A few weeks ago, I overloaded my server and compiler and > > > now I get > > > > > > signed content test streaming BER format, 2 DSA and 2 RSA keys, no attributes: OK > > > signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: verify error > > > *** Error code 1 > > > > > > Stop. > > > *** Error code 1 > > > > > > Stop. > > > > > > How can debug and rectify the situation? > > > > > > I do need to move forward. > > > > > > > I answered this a while back. > > Sorry for missing the inital reply. > > > You should have some files called cms.err and > > cms.out in the test directory. What is in them? > > > > cme.err file > > ls: error initializing month strings > Error reading S/MIME message > 135072992:error:0D0D40D1:asn1 encoding routines:SMIME_read_ASN1:no content type: > asn_mime.c:440: > That's weird, what kind of system is this? Not sure what is causing that ls error. There should also be a file test.cms created which is 6879 bytes long for that test on my system. The only immediate possibility I can think of is that the file isn't written to properly for some reason (disk full?). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From vlad.kharam48 at gmail.com Sun Aug 2 15:58:07 2015 From: vlad.kharam48 at gmail.com (Vladimir_Kharam4802) Date: Sun, 2 Aug 2015 08:58:07 -0700 (MST) Subject: [openssl-users] Linking errors hen linking test project with OpenSSl Libraries using Visual Studio 2015 Message-ID: <1438531087140-59506.post@n7.nabble.com> We Have the problems when linking test project with OpenSSl Libraries using Visual Studio 2015 (RTM). OpenSSL Version is "1.0.1j 15 Oct 2014" The errors are following: ------ Build started: Project: test, Configuration: Release Win32 ------ 1>libeay32.lib(x86cpuid.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(des-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(rc4-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(aes-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(vpaes-x86.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(aesni-x86.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(cmll-x86.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(sha1-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(sha256-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(sha512-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(md5-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(bn-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(co-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(ghash-x86.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(x86-mont.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(bf-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(cast-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(x86-gf2m.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(rmd-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(wp-mmx.obj) : error LNK2026: module unsafe for SAFESEH image. 1>..\Win32\Bin\Release\test.exe : fatal error LNK1281: Unable to generate SAFESEH image. The error can be resolved by disable (/SAFESEH:NO) in Link Option. If we are specifying "/SAFESEH:NO", our concern is that we may be ignoring an issue here: https://msdn.microsoft.com/en-us/library/9a89h429.aspx Thank in advance for any suggestions. Best Regards, Vladimir Kharam -- View this message in context: http://openssl.6102.n7.nabble.com/Linking-errors-hen-linking-test-project-with-OpenSSl-Libraries-using-Visual-Studio-2015-tp59506.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From vlad.kharam48 at gmail.com Sun Aug 2 16:03:53 2015 From: vlad.kharam48 at gmail.com (Vladimir_Kharam4802) Date: Sun, 2 Aug 2015 09:03:53 -0700 (MST) Subject: [openssl-users] Errors when linking test project with OpenSSl Libraries using Visual Studio 2015 Message-ID: <1438531433848-59507.post@n7.nabble.com> We Have the problems when linking test project with OpenSSl Libraries using Visual Studio 2015 (RTM). OpenSSL Version is "1.0.1j 15 Oct 2014" The errors are following: ------ Build started: Project: test, Configuration: Release Win32 ------ 1>libeay32.lib(x86cpuid.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(des-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(rc4-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(aes-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(vpaes-x86.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(aesni-x86.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(cmll-x86.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(sha1-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(sha256-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(sha512-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(md5-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(bn-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(co-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(ghash-x86.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(x86-mont.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(bf-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(cast-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(x86-gf2m.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(rmd-586.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libeay32.lib(wp-mmx.obj) : error LNK2026: module unsafe for SAFESEH image. 1>..\Win32\Bin\Release\test.exe : fatal error LNK1281: Unable to generate SAFESEH image. The error can be resolved by disable (/SAFESEH:NO) in Link Option. If we are specifying "/SAFESEH:NO", our concern is that we may be ignoring an issue here: https://msdn.microsoft.com/en-us/library/9a89h429.aspx Thank in advance for any suggestions. Best Regards, Vladimir Kharam -- View this message in context: http://openssl.6102.n7.nabble.com/Errors-when-linking-test-project-with-OpenSSl-Libraries-using-Visual-Studio-2015-tp59507.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From rahul1991.arora at gmail.com Mon Aug 3 11:00:01 2015 From: rahul1991.arora at gmail.com (Rahul Arora) Date: Mon, 3 Aug 2015 16:30:01 +0530 Subject: [openssl-users] Openssl Performance with and without Cryptodev Message-ID: Hi Team, I want to test openssl performance with and without using cryptodev driver.I tried 2 things but my both cases are fluctuating. *1. "Openssl speed test" with and without HW* When i am running openssl speed test using the below command, "openssl speed -evp aes-128-cbc" *I am getting outstanding improved performance difference in openssl while using with the cryptodev engine*.Below are the the numbers. Without Cryptodev =========== The 'numbers' are in 1000s of bytes per second processed. 64B Bytes = 27056.32k 256 Bytes = 28244.65k 1024 Bytes = 28558.34k 8192 Bytes = 28639.23k With Cryptodev =========== The 'numbers' are in 1000s of bytes per second processed. 64B Bytes = 77508.52k 256 Bytes = 428194.13k 1024 Bytes = 1285770.97k 8192 Bytes = 32507084.80k *2. Openssl encryption test with and without HW* I tried running this openssl command on my box: date ; cat bigfile | openssl enc -e -aes-128-cbc -bufsize 8192 -pass pass:testing123 > /dev/null ; date where 'bigfile' is some large file of > 2 GB in size. Then i rerun it using date ; cat bigfile | openssl enc *-engine cryptodev* -e -aes-128-cbc -bufsize 8192 -pass pass:testing123 > /dev/null ; date and compare the results of the dates of 'before' and 'after'. Below are the results i got. *Without HW it takes 4secs only. **with cryptodev it takes 3min 15 secs* Looks like in *first case cryptodev is increasing the performance but in second case it is decreasing it.* If some body knows this issue,can you please point me to the source code path where i can tweak something to improve performance with cryptodev case. I am using below versions of the sources. *OpenSSL 1.0.1g 7 Apr 2014* *Cryptodev 1.6 version* Please help me on this. Thanks Rahul Arora -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgoldman at us.ibm.com Mon Aug 3 14:19:03 2015 From: kgoldman at us.ibm.com (Ken Goldman) Date: Mon, 3 Aug 2015 10:19:03 -0400 Subject: [openssl-users] We're working on license changes In-Reply-To: <70db214b09054cf1897cacf512a5f54d@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <70db214b09054cf1897cacf512a5f54d@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: On 7/31/2015 10:37 AM, Salz, Rich wrote: > Please see https://www.openssl.org/blog/blog/2015/08/01/cla/ for some > more details. > > Summary: Moving to Apache 2, CLA?s coming, it will take time. This is great news. Do you have any sense of this will permit linking with GPL code? Is that implicit in Apache 2? This will help us on an immediate project. Do you have any rough time frame. Months? Years? From doctor at doctor.nl2k.ab.ca Tue Aug 4 06:48:05 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 4 Aug 2015 00:48:05 -0600 Subject: [openssl-users] Debugging a compile issue In-Reply-To: <20150801215212.GA9106@openssl.org> References: <20150801152531.GA15397@doctor.nl2k.ab.ca> <20150801161516.GA4910@openssl.org> <20150801180454.GA108@doctor.nl2k.ab.ca> <20150801215212.GA9106@openssl.org> Message-ID: <20150804064804.GA2151@doctor.nl2k.ab.ca> On Sat, Aug 01, 2015 at 09:52:12PM +0000, Dr. Stephen Henson wrote: > On Sat, Aug 01, 2015, The Doctor wrote: > > > On Sat, Aug 01, 2015 at 04:15:16PM +0000, Dr. Stephen Henson wrote: > > > On Sat, Aug 01, 2015, The Doctor wrote: > > > > > > > A few weeks ago, I overloaded my server and compiler and > > > > now I get > > > > > > > > signed content test streaming BER format, 2 DSA and 2 RSA keys, no attributes: OK > > > > signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: verify error > > > > *** Error code 1 > > > > > > > > Stop. > > > > *** Error code 1 > > > > > > > > Stop. > > > > > > > > How can debug and rectify the situation? > > > > > > > > I do need to move forward. > > > > > > > > > > I answered this a while back. > > > > Sorry for missing the inital reply. > > > > > You should have some files called cms.err and > > > cms.out in the test directory. What is in them? > > > > > > > cme.err file > > > > ls: error initializing month strings > > Error reading S/MIME message > > 135072992:error:0D0D40D1:asn1 encoding routines:SMIME_read_ASN1:no content type: > > asn_mime.c:440: > > > > That's weird, what kind of system is this? BSD system > Not sure what is causing that ls > error. There should also be a file test.cms created which is 6879 bytes long > for that test on my system. The only immediate possibility I can think of is > that the file isn't written to properly for some reason (disk full?). Disk not full, however file not being written properly is a clue. > > 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 -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Time for Stephen to move on on Oct 19 2015!! From doctor at doctor.nl2k.ab.ca Tue Aug 4 06:52:19 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 4 Aug 2015 00:52:19 -0600 Subject: [openssl-users] Debugging a compile issue In-Reply-To: <20150804064804.GA2151@doctor.nl2k.ab.ca> References: <20150801152531.GA15397@doctor.nl2k.ab.ca> <20150801161516.GA4910@openssl.org> <20150801180454.GA108@doctor.nl2k.ab.ca> <20150801215212.GA9106@openssl.org> <20150804064804.GA2151@doctor.nl2k.ab.ca> Message-ID: <20150804065219.GA4403@doctor.nl2k.ab.ca> On Tue, Aug 04, 2015 at 12:48:05AM -0600, The Doctor wrote: > On Sat, Aug 01, 2015 at 09:52:12PM +0000, Dr. Stephen Henson wrote: > > On Sat, Aug 01, 2015, The Doctor wrote: > > > > > On Sat, Aug 01, 2015 at 04:15:16PM +0000, Dr. Stephen Henson wrote: > > > > On Sat, Aug 01, 2015, The Doctor wrote: > > > > > > > > > A few weeks ago, I overloaded my server and compiler and > > > > > now I get > > > > > > > > > > signed content test streaming BER format, 2 DSA and 2 RSA keys, no attributes: OK > > > > > signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: verify error > > > > > *** Error code 1 > > > > > > > > > > Stop. > > > > > *** Error code 1 > > > > > > > > > > Stop. > > > > > > > > > > How can debug and rectify the situation? > > > > > > > > > > I do need to move forward. > > > > > > > > > > > > > I answered this a while back. > > > > > > Sorry for missing the inital reply. > > > > > > > You should have some files called cms.err and > > > > cms.out in the test directory. What is in them? > > > > > > > > > > cme.err file > > > > > > ls: error initializing month strings > > > Error reading S/MIME message > > > 135072992:error:0D0D40D1:asn1 encoding routines:SMIME_read_ASN1:no content type: > > > asn_mime.c:440: > > > > > > > That's weird, what kind of system is this? > > BSD system > > > Not sure what is causing that ls > > error. There should also be a file test.cms created which is 6879 bytes long > > for that test on my system. The only immediate possibility I can think of is > > that the file isn't written to properly for some reason (disk full?). > > Disk not full, however file not being written properly is a clue. Just tried a variety of perl commands and all turned up the same. > > > > > 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 > > -- > Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca > God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! > http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism > Time for Stephen to move on on Oct 19 2015!! > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Time for Stephen to move on on Oct 19 2015!! From doctor at doctor.nl2k.ab.ca Tue Aug 4 15:18:02 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 4 Aug 2015 09:18:02 -0600 Subject: [openssl-users] Compile question Message-ID: <20150804151801.GA26020@doctor.nl2k.ab.ca> Just compile openssl 1.0.2 daily 20150804 and got making all in crypto/cmac... if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then (cd ..; make libcrypto.so.1.0.0); fi [ -z "" ] || gcc -dPIC -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -march=pentium3 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso fips_premain.c fipscanister.o libcrypto.a -lgmp -lc -ldl -lm /usr/lib/libc.a(sha.o): In function `SHA': sha.o(.text+0x0): multiple definition of `SHA' libcrypto.a(sha_one.o):/usr/source/openssl-1.0.2-stable-SNAP-20150804/crypto/sha/sha_one.c:66: first defined here ld: Warning: size of symbol `SHA' changed from 142 to 92 in /usr/lib/libc.a(sha.o) /usr/lib/libc.a(syslog.o): In function `vsyslog': syslog.o(.text+0x3a5): undefined reference to `__progname' /usr/lib/libc.a(exec.o): In function `execl': exec.o(.text+0x103): undefined reference to `environ' /usr/lib/libc.a(exec.o): In function `execv': exec.o(.text+0x26b): undefined reference to `environ' /usr/lib/libc.a(exec.o): In function `execvp': exec.o(.text+0x400): undefined reference to `environ' exec.o(.text+0x4da): undefined reference to `environ' *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. used ./Configure 386 threads shared no-sse2 no-srtp no-ssl2 no-ssl3 experimental-li bunbound experimental-dane experimental-jpake experimental-store disable-sctp e nable-ssl-trace enable-whrlpool enable-montasm enable-capieng enable-cms enable -seed enable-tlsext enable-camellia enable-rfc3779 enable-md2 enable-gmp enable -mdc2 enable-md5 enable-rc5 experimental-multiblock enable-unit-test zlib-dynam ic --prefix=/usr/contrib --openssldir=/usr/contrib debug-bsdi-x86-elf ; make u pdate; make depend with call "debug-bsdi-x86-elf", "gcc:-DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -march=pentium3 -Wall -g::${BSDthreads}::-lgmp -lc -ldl -lm :THIRY_TWO_BIT_ LONG RC4_CHUNK BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:bsd -gcc-shared:-dPIC -fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Time for Stephen to move on on Oct 19 2015!! From doctor at doctor.nl2k.ab.ca Tue Aug 4 15:20:55 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 4 Aug 2015 09:20:55 -0600 Subject: [openssl-users] New compile web server will not start up Message-ID: <20150804152055.GB26020@doctor.nl2k.ab.ca> Tryng to run Apache 2.2 using recent SSL and got [Wed Dec 31 16:26:58 1969] [error] Init: Unable to read server certificate from file /var/www/SSLconf/conf/secure.nl2k.ab.ca.2015.crt [Wed Dec 31 16:26:58 1969] [error] SSL Library Error: 218529960 error:0D0680A8: lib(13):func(104):wrong tag [Wed Dec 31 16:26:58 1969] [error] SSL Library Error: 218595386 error:0D07803A: lib(13):func(120):nested asn1 error [Wed Dec 31 17:02:32 1969] [error] Init: Unable to read server certificate from file /var/www/SSLconf/conf/secure.nl2k.ab.ca.2015b.crt [Wed Dec 31 17:02:32 1969] [error] SSL Library Error: 218529960 error:0D0680A8: lib(13):func(104):wrong tag [Wed Dec 31 17:02:32 1969] [error] SSL Library Error: 218595386 error:0D07803A: lib(13):func(120):nested asn1 error [Wed Dec 31 17:14:03 1969] [error] Init: Unable to read server certificate from file /var/www/SSLconf/conf/secure.nl2k.ab.ca.2015.crt [Wed Dec 31 17:14:03 1969] [error] SSL Library Error: 218529960 error:0D0680A8: lib(13):func(104):wrong tag [Wed Dec 31 17:14:03 1969] [error] SSL Library Error: 218595386 error:0D07803A: lib(13):func(120):nested asn1 error [Wed Dec 31 17:18:04 1969] [error] Init: Unable to read server certificate from file /var/www/SSLconf/conf/secure.nl2k.ab.ca.2015b.crt [Wed Dec 31 17:18:04 1969] [error] SSL Library Error: 218529960 error:0D0680A8: lib(13):func(104):wrong tag [Wed Dec 31 17:18:04 1969] [error] SSL Library Error: 218595386 error:0D07803A: lib(13):func(120):nested asn1 error One cert secure.nl2k.ab.ca.2015.crt was brought over from a server backup and the other secure.nl2k.ab.ca.2015b.crt was generated on this server. What is causing this issue? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Time for Stephen to move on on Oct 19 2015!! From doctor at doctor.nl2k.ab.ca Wed Aug 5 04:32:57 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 4 Aug 2015 22:32:57 -0600 Subject: [openssl-users] Debugging a compile issue In-Reply-To: <20150804065219.GA4403@doctor.nl2k.ab.ca> References: <20150801152531.GA15397@doctor.nl2k.ab.ca> <20150801161516.GA4910@openssl.org> <20150801180454.GA108@doctor.nl2k.ab.ca> <20150801215212.GA9106@openssl.org> <20150804064804.GA2151@doctor.nl2k.ab.ca> <20150804065219.GA4403@doctor.nl2k.ab.ca> Message-ID: <20150805043257.GA23407@doctor.nl2k.ab.ca> On Tue, Aug 04, 2015 at 12:52:19AM -0600, The Doctor wrote: > On Tue, Aug 04, 2015 at 12:48:05AM -0600, The Doctor wrote: > > On Sat, Aug 01, 2015 at 09:52:12PM +0000, Dr. Stephen Henson wrote: > > > On Sat, Aug 01, 2015, The Doctor wrote: > > > > > > > On Sat, Aug 01, 2015 at 04:15:16PM +0000, Dr. Stephen Henson wrote: > > > > > On Sat, Aug 01, 2015, The Doctor wrote: > > > > > > > > > > > A few weeks ago, I overloaded my server and compiler and > > > > > > now I get > > > > > > > > > > > > signed content test streaming BER format, 2 DSA and 2 RSA keys, no attributes: OK > > > > > > signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: verify error > > > > > > *** Error code 1 > > > > > > > > > > > > Stop. > > > > > > *** Error code 1 > > > > > > > > > > > > Stop. > > > > > > > > > > > > How can debug and rectify the situation? > > > > > > > > > > > > I do need to move forward. > > > > > > > > > > > > > > > > I answered this a while back. > > > > > > > > Sorry for missing the inital reply. > > > > > > > > > You should have some files called cms.err and > > > > > cms.out in the test directory. What is in them? > > > > > > > > > > > > > cme.err file > > > > > > > > ls: error initializing month strings > > > > Error reading S/MIME message > > > > 135072992:error:0D0D40D1:asn1 encoding routines:SMIME_read_ASN1:no content type: > > > > asn_mime.c:440: > > > > > > > > > > That's weird, what kind of system is this? > > > > BSD system > > > > > Not sure what is causing that ls > > > error. There should also be a file test.cms created which is 6879 bytes long > > > for that test on my system. The only immediate possibility I can think of is > > > that the file isn't written to properly for some reason (disk full?). > > > > Disk not full, however file not being written properly is a clue. > > Just tried a variety of perl commands and all turned up the same. > > > > > > In perl debug mode I got DB<1> signed content test streaming BER format, 2 DSA and 2 RSA keys, no attributes: OK main::run_smime_tests(cms-test.pl:531): 531: my ( $tnam, $rscmd, $rvcmd ) = @$smtst; DB<1> main::run_smime_tests(cms-test.pl:532): 532: if ($ossl8) 533: { DB<1> main::run_smime_tests(cms-test.pl:541): 541: if ($no_ec && $tnam =~ /ECDH/) 542: { DB<1> main::run_smime_tests(cms-test.pl:546): 546: if ($no_ecdh && $tnam =~ /ECDH/) 547: { DB<1> main::run_smime_tests(cms-test.pl:551): 551: if ($no_ec2m && $tnam =~ /K-283/) 552: { DB<1> main::run_smime_tests(cms-test.pl:556): 556: system("$scmd$rscmd$redir"); DB<1> main::run_smime_tests(cms-test.pl:557): 557: if ($?) { DB<1> main::run_smime_tests(cms-test.pl:563): 563: system("$vcmd$rvcmd$redir"); DB<1> main::run_smime_tests(cms-test.pl:564): 564: if ($?) { DB<1> main::run_smime_tests(cms-test.pl:565): 565: print "$tnam: verify error\n"; DB<1> signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: verify error main::run_smime_tests(cms-test.pl:566): 566: $$rv++; DB<1> main::run_smime_tests(cms-test.pl:567): 567: exit 1 if $halt_err; DB<1> -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Time for Stephen to move on on Oct 19 2015!! From colin.foeparker at aclima.io Wed Aug 5 17:12:12 2015 From: colin.foeparker at aclima.io (Colin Foe-Parker) Date: Wed, 5 Aug 2015 10:12:12 -0700 Subject: [openssl-users] TLS_PSK_WITH_AES_128_CCM_8 Cipher Suite Support? Message-ID: Good Morning, I am trying to set up a TLS connection between an embedded processor and remote server using the TLS_PSK_WITH_AES_128_CCM_8 cipher suite. This cipher suite is supported on the device side and I can find aes-128-ccm as a possibility on the fresh git clone of openssl. (using ./openssl enc -help) I have also found the "Making AES-CCM available as a TLS-negotiated cipher suite" post by Paul Muschick in 2012. http://www.mail-archive.com/openssl-users%40openssl.org/msg67169.html This is my first foray into the openssl realm, so please for my ignorance, but is there is a reason why this cipher suite isn't currently supported? (I.e. saving society from itself :)) And if not, does anyone have any relevant guidance so that I can start looking into creating a patch? Thanks in advance, Colin -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Wed Aug 5 17:40:23 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 5 Aug 2015 17:40:23 +0000 Subject: [openssl-users] TLS_PSK_WITH_AES_128_CCM_8 Cipher Suite Support? In-Reply-To: References: Message-ID: <20150805174023.GA22250@openssl.org> On Wed, Aug 05, 2015, Colin Foe-Parker wrote: > Good Morning, > > I am trying to set up a TLS connection between an embedded processor and > remote server using the TLS_PSK_WITH_AES_128_CCM_8 cipher suite. This > cipher suite is supported on the device side and I can find aes-128-ccm as > a possibility on the fresh git clone of openssl. (using ./openssl enc > -help) > > I have also found the "Making AES-CCM available as a TLS-negotiated cipher > suite" post by Paul Muschick in 2012. > http://www.mail-archive.com/openssl-users%40openssl.org/msg67169.html > > This is my first foray into the openssl realm, so please for my ignorance, > but is there is a reason why this cipher suite isn't currently supported? > (I.e. saving society from itself :)) And if not, does anyone have any > relevant guidance so that I can start looking into creating a patch? > The enc command just uses ciphers for bulk encryption and doesn't support AEAD ciphers at all currently. Support in a ciphersuites is a different thing and the "ciphers" utility reports that. However CCM mode is not currently supported in OpenSSL. I have some prototype code that does add CCM support but it has not currently been included in OpenSSL itself (it is undergoing internal review). It does include the TLS_PSK_WITH_AES_128_CCM_8 ciphersuite. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From pauljosephhebert at gmail.com Thu Aug 6 12:48:33 2015 From: pauljosephhebert at gmail.com (Paul Hebert) Date: Thu, 6 Aug 2015 08:48:33 -0400 Subject: [openssl-users] Broken ChangeCipherspec record in TLS 1.2 with OpenSSL 1.0.2d? Message-ID: We are using a wildcard certificate requiring SNI and are also requiring client certificate authentication. Our TLS 1.2 client is seeing a ChangeCipherspec record with length 30 bytes (x19) instead of the expected 0x01. The broken ChangeCipherspec record looks like this (hex) *14 03 03 00 01 19*. Is this a problem with the TLS 1.2 client, or a problem with the OpenSSL 1.0.2d patch (for CVE-2015-1793)? Thanks, Paul Hebert/State University of New York -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Aug 6 13:34:43 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 06 Aug 2015 14:34:43 +0100 Subject: [openssl-users] Broken ChangeCipherspec record in TLS 1.2 with OpenSSL 1.0.2d? In-Reply-To: References: Message-ID: <55C36273.6050709@openssl.org> On 06/08/15 13:48, Paul Hebert wrote: > We are using a wildcard certificate requiring SNI and are also requiring > client certificate authentication. > > Our TLS 1.2 client is seeing a ChangeCipherspec record with length 30 > bytes (x19) instead of the expected 0x01. The broken ChangeCipherspec > record looks like this (hex) *14 03 03 00 01 19*. That isn't the length byte: 14 = Record Content Type is a CCS message 03 03 = TLS 1.2 00 01 = Length of 1 byte 19 = 1 byte content of the CCS The RFCs only define one valid value for the content of a CCS, and that is the value 1 so this is an invalid message. > Is this a problem > with the TLS 1.2 client, or a problem with the OpenSSL 1.0.2d patch (for > CVE-2015-1793)? It is highly unlikely to be a problem with the 1.0.2d patch since CVE-2015-1793 fixes a libcrypto problem. CCS messages are entirely generated within libssl. Looking at the code I can't see any way how the CCS content could be anything other than one - it's hard coded in. I assume from your description above that your client is not OpenSSL. I would look there first, or perhaps some middleware box? Can you get a packet capture of what OpenSSL is actually sending? Matt From reinier.torenbeek at gmail.com Thu Aug 6 20:18:23 2015 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Thu, 06 Aug 2015 17:18:23 -0300 Subject: [openssl-users] EVP-level load_key functions Message-ID: <55C3C10F.3030202@gmail.com> I am interested in leveraging the following three functions: ENGINE_load_private_key() ENGINE_load_public_key() ENGINE_load_certificate() Unfortunately, the latter is missing. This was mentioned in a recent thread on this list as well (see http://www.mail-archive.com/openssl-users at openssl.org/msg77566.html). Is it planned for any future release? The former two functions are present though and I was looking for their EVP-level counterparts to access them in the proper way. Apparently, those do not exist either. Previously, I was under the impression that the EVP API exposes all engine-implemented functions. Are these EVP_load_xxx functions missing from EVP because they are "todo in a future release" or are they omitted by design? By the way, I did find functions in apps/apps.c called load_key(), load_pubkey() and load_cert(). The look quite like the EVP-level functions I was expecting. Thanks, Reinier From steve at openssl.org Thu Aug 6 23:06:18 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 6 Aug 2015 23:06:18 +0000 Subject: [openssl-users] EVP-level load_key functions In-Reply-To: <55C3C10F.3030202@gmail.com> References: <55C3C10F.3030202@gmail.com> Message-ID: <20150806230618.GA26266@openssl.org> On Thu, Aug 06, 2015, Reinier Torenbeek wrote: > I am interested in leveraging the following three functions: > > ENGINE_load_private_key() > ENGINE_load_public_key() > ENGINE_load_certificate() > > Unfortunately, the latter is missing. This was mentioned in a recent > thread on this list as well (see > http://www.mail-archive.com/openssl-users at openssl.org/msg77566.html). Is > it planned for any future release? > At some point yes but it's quite complex decided what the parameters should be: e.g. to lookup certificates matching one or more criteria. > The former two functions are present though and I was looking for their > EVP-level counterparts to access them in the proper way. Apparently, > those do not exist either. Previously, I was under the impression that > the EVP API exposes all engine-implemented functions. Are these > EVP_load_xxx functions missing from EVP because they are "todo in a > future release" or are they omitted by design? > The ENGINE_load*key functions rerturn an EVP_PKEY structure which can be used by EVP directly. There are other functions which can load an EVP_PKEY structure too like the PEM and PKCS12 functions. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From jb-openssl at wisemo.com Thu Aug 6 23:44:44 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 7 Aug 2015 01:44:44 +0200 Subject: [openssl-users] EVP-level load_key functions In-Reply-To: <20150806230618.GA26266@openssl.org> References: <55C3C10F.3030202@gmail.com> <20150806230618.GA26266@openssl.org> Message-ID: <55C3F16C.8020007@wisemo.com> On 07/08/2015 01:06, Dr. Stephen Henson wrote: > On Thu, Aug 06, 2015, Reinier Torenbeek wrote: > >> I am interested in leveraging the following three functions: >> >> ENGINE_load_private_key() >> ENGINE_load_public_key() >> ENGINE_load_certificate() >> >> Unfortunately, the latter is missing. This was mentioned in a recent >> thread on this list as well (see >> http://www.mail-archive.com/openssl-users at openssl.org/msg77566.html). Is >> it planned for any future release? >> > At some point yes but it's quite complex decided what the parameters should > be: e.g. to lookup certificates matching one or more criteria. > > >> The former two functions are present though and I was looking for their >> EVP-level counterparts to access them in the proper way. Apparently, >> those do not exist either. Previously, I was under the impression that >> the EVP API exposes all engine-implemented functions. Are these >> EVP_load_xxx functions missing from EVP because they are "todo in a >> future release" or are they omitted by design? >> > The ENGINE_load*key functions rerturn an EVP_PKEY structure which can be > used by EVP directly. > > There are other functions which can load an EVP_PKEY structure too like the > PEM and PKCS12 functions. I think what one wants as a first approximation is functions that can enumerate and load keys and certificates from "engine storage", such as smart cards (most engines would obviously load only "proxy structures/handles" when asked to load a private key). E.g. PSOME_PRIVKEY_TYPE EVP_EnumPrivKeys(T hEngine, ofs_t i); PSOME_PUBKEY_TYPE EVP_EnumPubKeys(T hEngine, ofs_t i); PSOME_CERT_TYPE EVP_EnumCerts(T hEngine, ofs_t i); Each will return either: The item at index i in engine storage NULL for no such item at index i (void*)(size_t)(1) for "i past last currently valid index for such items" Engines would have some leeway if they will return NULL or 1 for some values slightly past last index, and if there will be any relationships between indexes for different types. A second order approximation would be functions that can look for matching triplets: Given a public key, private key or certificate, load a matching item of one of the other 2 kinds, if present in storage, or return a "not found" error (of cause the cases of private key or cert to public key mapping are already trivial without calling the engine, the remaining 4 cases are the interesting ones, some engines can do them efficiently others would fall back to generic EVP layer loops over the first order enumeration functions and a generic EVP layer public key compare). Note, I can imagine engines that can quickly go between private keys and certs, but not from public key to either, so all 4 cases need to be exposed to the engine level, even if (PrivToCert and CertToPriv methods have defaults that call PubToCert and PubToPriv). With these two simpler approximations, application code should be able to do most of the needed real world jobs, such as figuring out which useful certificates with matching private keys are present on an inserted smart card or key fob. A third item that might be wanted for some engines (such as the generic "engine" that can look in /etc/ssl/certs) would be a search for certs by exact subject distinguished name match, with the possibility of returning more than one result (think different serials/keyids). Arbitrary criteria searching would typically end up as a loop over enumeration functions anyway. Searching for chain building purposes can be built on top of all this without bloating the EVP and engine interfaces with all that code. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mynidiravichandra at gmail.com Fri Aug 7 09:15:02 2015 From: mynidiravichandra at gmail.com (Ravichandra) Date: Fri, 7 Aug 2015 14:45:02 +0530 Subject: [openssl-users] Performance applications for SSL performance measurement Message-ID: Hi, Can someone suggest me some open source performance measurement tools which will help me benchmark SSL stack performance like number of handshakes/sec and throughput(data rate/connection). openssl speed only provides raw crypto performance. I need to find the SSL stack performance as mentioned above. Appreciate any suggestions.. Thanks Ravichandra -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marcus.Daniel at profil.com Sat Aug 8 10:22:54 2015 From: Marcus.Daniel at profil.com (Marcus.Daniel at profil.com) Date: Sat, 8 Aug 2015 12:22:54 +0200 Subject: [openssl-users] =?iso-8859-1?q?AUTO=3A_Marcus_Daniel_is_out_of_th?= =?iso-8859-1?q?e_office_=28R=FCckkehr_am_24=2E08=2E2015=29?= Message-ID: Ich kehre zur?ck am 24.08.2015. Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht "[openssl-announce] 1.0.2 long term support" gesendet am 08.08.2015 09:11:04. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, w?hrend diese Person abwesend ist. From reinier.torenbeek at gmail.com Sun Aug 9 18:50:09 2015 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Sun, 09 Aug 2015 15:50:09 -0300 Subject: [openssl-users] EVP-level load_key functions In-Reply-To: <20150806230618.GA26266@openssl.org> References: <55C3C10F.3030202@gmail.com> <20150806230618.GA26266@openssl.org> Message-ID: <55C7A0E1.6040308@gmail.com> Thanks for your pointers. I searched a bit further and noticed the existence of a STORE method and the associated (un)register functions with an engine. Looking at its API, it looks like it provides the key and certificate loading function signatures that I need. Therefore, I was considering implementing (a subset of) the STORE method functions in my engine. From the README in crypto/store in master , I conclude that future versions will provide X509_STORE as a default implementation for the store as well. Therefore, this seems the right approach in the long run. I am currently using a 1.0.1 version. However, I could not find any example of any engine implementing a store. There do not seem to be any tests either. Can you/someone confirm that implementing (a subset of) a store in my engine is a valid approach at the moment (and in the future)? Thanks, Reinier On 8/6/15 8:06 PM, Dr. Stephen Henson wrote: > On Thu, Aug 06, 2015, Reinier Torenbeek wrote: > >> I am interested in leveraging the following three functions: >> >> ENGINE_load_private_key() >> ENGINE_load_public_key() >> ENGINE_load_certificate() >> >> Unfortunately, the latter is missing. This was mentioned in a recent >> thread on this list as well (see >> http://www.mail-archive.com/openssl-users at openssl.org/msg77566.html). Is >> it planned for any future release? >> > At some point yes but it's quite complex decided what the parameters should > be: e.g. to lookup certificates matching one or more criteria. > > >> The former two functions are present though and I was looking for their >> EVP-level counterparts to access them in the proper way. Apparently, >> those do not exist either. Previously, I was under the impression that >> the EVP API exposes all engine-implemented functions. Are these >> EVP_load_xxx functions missing from EVP because they are "todo in a >> future release" or are they omitted by design? >> > The ENGINE_load*key functions rerturn an EVP_PKEY structure which can be > used by EVP directly. > > There are other functions which can load an EVP_PKEY structure too like the > PEM and PKCS12 functions. > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From reinier.torenbeek at gmail.com Sun Aug 9 18:56:27 2015 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Sun, 09 Aug 2015 15:56:27 -0300 Subject: [openssl-users] EVP-level load_key functions In-Reply-To: <55C3F16C.8020007@wisemo.com> References: <55C3C10F.3030202@gmail.com> <20150806230618.GA26266@openssl.org> <55C3F16C.8020007@wisemo.com> Message-ID: <55C7A25B.7070600@gmail.com> Hello Jakob, Looking at crypt/store/store.h, do you agree that a store implementation is the place where the functionality that you describe below belongs? Thanks, Reinier On 8/6/15 8:44 PM, Jakob Bohm wrote: > I think what one wants as a first approximation is > functions that can enumerate and load keys and > certificates from "engine storage", such as smart > cards (most engines would obviously load only > "proxy structures/handles" when asked to load a > private key). > > E.g. > > PSOME_PRIVKEY_TYPE EVP_EnumPrivKeys(T hEngine, ofs_t i); > > PSOME_PUBKEY_TYPE EVP_EnumPubKeys(T hEngine, ofs_t i); > > PSOME_CERT_TYPE EVP_EnumCerts(T hEngine, ofs_t i); > > Each will return either: > > The item at index i in engine storage > > NULL for no such item at index i > > (void*)(size_t)(1) for "i past last currently > valid index for such items" > > Engines would have some leeway if they will return > NULL or 1 for some values slightly past last index, > and if there will be any relationships between indexes > for different types. > > A second order approximation would be functions > that can look for matching triplets: > Given a public key, private key or certificate, > load a matching item of one of the other 2 kinds, > if present in storage, or return a "not found" > error (of cause the cases of private key or cert > to public key mapping are already trivial without > calling the engine, the remaining 4 cases are the > interesting ones, some engines can do them > efficiently others would fall back to generic EVP > layer loops over the first order enumeration > functions and a generic EVP layer public key > compare). Note, I can imagine engines that can > quickly go between private keys and certs, but not > from public key to either, so all 4 cases need to > be exposed to the engine level, even if (PrivToCert > and CertToPriv methods have defaults that call > PubToCert and PubToPriv). > > With these two simpler approximations, application > code should be able to do most of the needed real > world jobs, such as figuring out which useful > certificates with matching private keys are present > on an inserted smart card or key fob. > > A third item that might be wanted for some engines > (such as the generic "engine" that can look in > /etc/ssl/certs) would be a search for certs by exact > subject distinguished name match, with the > possibility of returning more than one result (think > different serials/keyids). > > Arbitrary criteria searching would typically end up > as a loop over enumeration functions anyway. > > Searching for chain building purposes can be built > on top of all this without bloating the EVP and engine > interfaces with all that code. > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Sun Aug 9 23:56:04 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 10 Aug 2015 01:56:04 +0200 Subject: [openssl-users] EVP-level load_key functions In-Reply-To: <55C7A25B.7070600@gmail.com> References: <55C3C10F.3030202@gmail.com> <20150806230618.GA26266@openssl.org> <55C3F16C.8020007@wisemo.com> <55C7A25B.7070600@gmail.com> Message-ID: <55C7E894.7070909@wisemo.com> I don't know, I have not studied that part of OpenSSL closely enough to decide. I was mostly trying to come up with a reasonable counterargument to "designing a comprehensive certificate and key loading engine API is too hard to bother" reasoning. On 09/08/2015 20:56, Reinier Torenbeek wrote: > Hello Jakob, > > Looking at crypt/store/store.h, do you agree that a store > implementation is the place where the functionality that you describe > below belongs? > > Thanks, > Reinier > > > On 8/6/15 8:44 PM, Jakob Bohm wrote: >> I think what one wants as a first approximation is >> functions that can enumerate and load keys and >> certificates from "engine storage", such as smart >> cards (most engines would obviously load only >> "proxy structures/handles" when asked to load a >> private key). >> >> E.g. >> >> PSOME_PRIVKEY_TYPE EVP_EnumPrivKeys(T hEngine, ofs_t i); >> >> PSOME_PUBKEY_TYPE EVP_EnumPubKeys(T hEngine, ofs_t i); >> >> PSOME_CERT_TYPE EVP_EnumCerts(T hEngine, ofs_t i); >> >> Each will return either: >> >> The item at index i in engine storage >> >> NULL for no such item at index i >> >> (void*)(size_t)(1) for "i past last currently >> valid index for such items" >> >> Engines would have some leeway if they will return >> NULL or 1 for some values slightly past last index, >> and if there will be any relationships between indexes >> for different types. >> >> A second order approximation would be functions >> that can look for matching triplets: >> Given a public key, private key or certificate, >> load a matching item of one of the other 2 kinds, >> if present in storage, or return a "not found" >> error (of cause the cases of private key or cert >> to public key mapping are already trivial without >> calling the engine, the remaining 4 cases are the >> interesting ones, some engines can do them >> efficiently others would fall back to generic EVP >> layer loops over the first order enumeration >> functions and a generic EVP layer public key >> compare). Note, I can imagine engines that can >> quickly go between private keys and certs, but not >> from public key to either, so all 4 cases need to >> be exposed to the engine level, even if (PrivToCert >> and CertToPriv methods have defaults that call >> PubToCert and PubToPriv). >> >> With these two simpler approximations, application >> code should be able to do most of the needed real >> world jobs, such as figuring out which useful >> certificates with matching private keys are present >> on an inserted smart card or key fob. >> >> A third item that might be wanted for some engines >> (such as the generic "engine" that can look in >> /etc/ssl/certs) would be a search for certs by exact >> subject distinguished name match, with the >> possibility of returning more than one result (think >> different serials/keyids). >> >> Arbitrary criteria searching would typically end up >> as a loop over enumeration functions anyway. >> >> Searching for chain building purposes can be built >> on top of all this without bloating the EVP and engine >> interfaces with all that code. 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 From kurt at roeckx.be Mon Aug 10 08:39:37 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Mon, 10 Aug 2015 10:39:37 +0200 Subject: [openssl-users] 1.0.2 long term support Message-ID: <20150810083937.GA14110@roeckx.be> 1.0.2 long term support ======================= The OpenSSL project team would like to announce that the 1.0.2 version will be supported until 2019-12-31. Further details about the OpenSSL Release Strategy can be found here: https://www.openssl.org/about/releasestrat.html The OpenSSL Project Team -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From jb-openssl at wisemo.com Mon Aug 10 11:58:14 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 10 Aug 2015 13:58:14 +0200 Subject: [openssl-users] [openssl-1.0.2d] default SSL handshake fails In-Reply-To: <20150801060030.GA4347@mournblade.imrryr.org> References: <20150731210650.GW4347@mournblade.imrryr.org> <55BC5170.7080900@wisemo.com> <20150801060030.GA4347@mournblade.imrryr.org> Message-ID: <55C891D6.4010702@wisemo.com> On 01/08/2015 08:00, Viktor Dukhovni wrote: >> The Windows 2003 TLS stack became unsupported for most >> (but /not all/) users less than 20 days ago. Treating >> it as marginal and not as something that any core >> networking library needs to be compatible (even *tested* >> with) out of the box is another symptom of the useless >> attitudes that permeate the new OpenSSL leadership. > You should apologize, I resent that remark. Behind the scenes I > am working to ensure that we maintain reasonable compatibility with > that stack while it still exists in the field, and have helped many > users craft sensible work-arounds for the bugs in that platform. > > It is not so easy to work around the rather severe limitations of > Schannel in Windows 2003. OpenSSL would have to by default disable > many of the new ciphers in TLS 1.2. Are you suggesting that the > exclusions I am recommending should have been on by default? To > accommodate a relatively rare and clearly broken peer? > > We could consider such an accommodation, but I think that the wiser > course of action is to document the work-around for those who need > it. This is the first report of this problem I've seen for an > application protocol other SMTP. It was however immediately > recognizable. > >> The old OpenSSL project belonged to the long standing >> tradition of making sure that Internet software needs to >> work with the quirks of anything it could reasonably >> encounter on any real world network, including both the >> Internet, the US military networks (which have allegedly >> paid a boatload of money for continued Win2003 support) >> and any closed site networks that reuse Internet protocols >> for their internal operations. > You seem to be pining for the project that lacked any resources to > pay attention to documentation or code quality. I think on the > whole more sensible trade-offs are being made now. And compatibility > is still important. > >> It would have been a serious brown bag moment for the old >> maintainers to discover this in a release made that close >> to (if not even overlapping) the vendor support period for >> such a widely deployed system. There is a lot of utility >> software which is linked to OpenSSL libraries with very >> little user configurability and which is simply expected >> to "just work" when transferring data off a (not so) old >> Windows computer. > Who are these "old maintainers" who aren't around any more? I have taken my time to answer this, as it deserved some careful thinking. The problem over the past year or so is not as much that any old maintainers have left, as that the entire project seems to have given off a "vibe" of being "under new management". Specifically, a number of decisions have the feel of a project that has been co-opted or taken over by someone eager to make sweeping changes for little apparent reason, someone with lots of idle lawyers on hand, like "Microsoft, various corporate partners, the CII, and/or the SFLC" (using a list from the latest public blog post), yet seemingly unaware of the dangers of combining a UK jurisdiction with phrases such as "the public benefit" in an area of technology which has historically been subject to much UK government interference over the past 70 years. I also see a tendency to throw historical decisions overboard with little effort to understand why such decisions might actually be or have been good decisions. For instance, in the penultimate blog post, most of the things removed under "dynamic memory cleanup" actually serve real purposes: protective parameter validation against future code bugs, thus by definition not counted in automated "coverage tools" (NULL checking before free), making malloc calls compile with C++ compilers (casting the return value of malloc to specific pointer type), forcing compiler errors if variable types change (that same cast!). 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 From rsalz at akamai.com Mon Aug 10 18:12:55 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 10 Aug 2015 18:12:55 +0000 Subject: [openssl-users] [openssl-1.0.2d] default SSL handshake fails In-Reply-To: <55C891D6.4010702@wisemo.com> References: <20150731210650.GW4347@mournblade.imrryr.org> <55BC5170.7080900@wisemo.com> <20150801060030.GA4347@mournblade.imrryr.org> <55C891D6.4010702@wisemo.com> Message-ID: <38459fb51365459bac33b09152f18658@ustx2ex-dag1mb2.msg.corp.akamai.com> > Specifically, a number of decisions have the feel of a project that has been > co-opted or taken over by someone eager to make sweeping changes for > little apparent reason, someone with lots of idle lawyers on hand, like > "Microsoft, various corporate partners, the CII, and/or the SFLC" (using a list > from the latest public blog post) Do you mean me? Or did you make a typo, and mean "members" rather than "someone" ? From rsandila at netscape.net Tue Aug 11 16:24:31 2015 From: rsandila at netscape.net (Robert Sandilands) Date: Tue, 11 Aug 2015 12:24:31 -0400 Subject: [openssl-users] Custom OID strange characters Message-ID: <6C6DE020-3E00-4EAE-A16D-A4A82E30F62B@netscape.net> I am trying to build a certificate request with a custom OID and it is encoding strange characters in the certificate. For example I specify the following line in the .cnf file: bla_policy = ASN1:PRINTABLESTRING:blabla Then I get the following when I dump the csr: 1.2.3.4.5.6.7: ..blabla The ?..? seems to be somewhat random and does not seem to encode a length or anything else. Any ideas on how I can get rid of those two random characters or why I am getting them? More detail: OpenSSL version: 1.0.1e on Windows and 1.0.1e.42.el7.9 on Centos 7. Given the following script: #!/bin/bash KEYNAME=test.key CSRNAME=test.csr SUBJECT="/C=US/ST=Georgia/L=Atlanta/O=Bla/CN=test/emailAddress=certs at bla.com " DAYS=365 echo Cleaning up rm $KEYNAME $CSRNAME echo Generating key $KEYNAME openssl genrsa -out $KEYNAME 2048 echo Generating req $CSRNAME openssl req -new -key $KEYNAME -out $CSRNAME -nodes -subj "$SUBJECT" -verbose -config req.cnf if [ -f $CSRNAME ]; then openssl req -in $CSRNAME -text -noout | less fi And the following req.cnf: oid_section = new_oids [ new_oids ] bla_policy = 1.2.3.4.5.6.7 [ req ] default_bits = 2048 default_md = sha256 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes req_extensions = v3_req [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = XX countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) localityName = Locality Name (eg, city) localityName_default = Default City 0.organizationName = Organization Name (eg, company) 0.organizationName_default = Default Company Ltd organizationalUnitName = Organizational Unit Name (eg, section) commonName = Common Name (eg, your name or your server\'s hostname) commonName_max = 64 emailAddress = Email Address emailAddress_max = 64 [ req_attributes ] challengePassword = A challenge password challengePassword_min = 4 challengePassword_max = 20 unstructuredName = An optional company name [ v3_req ] basicConstraints=critical,CA:FALSE keyUsage=digitalSignature, nonRepudiation, digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement extendedKeyUsage=clientAuth, emailProtection bla_policy = ASN1:PRINTABLESTRING:blabla Get the following output: Certificate Request: Data: Version: 0 (0x0) Subject: C=US, ST=Georgia, L=Atlanta, O=Bla, CN=test/emailAddress=certs at bla.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: ? (Deleted for clarity) Exponent: 65537 (0x10001) Attributes: Requested Extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, Key Agreement X509v3 Extended Key Usage: TLS Web Client Authentication, E-mail Protection 1.2.3.4.5.6.7: ..blabla Signature Algorithm: sha256WithRSAEncryption ? (Deleted for clarity) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wiml at omnigroup.com Tue Aug 11 18:24:34 2015 From: wiml at omnigroup.com (Wim Lewis) Date: Tue, 11 Aug 2015 11:24:34 -0700 Subject: [openssl-users] Custom OID strange characters In-Reply-To: <6C6DE020-3E00-4EAE-A16D-A4A82E30F62B@netscape.net> References: <6C6DE020-3E00-4EAE-A16D-A4A82E30F62B@netscape.net> Message-ID: <4B76E29F-3356-4526-91E3-7BFE5500CAF1@omnigroup.com> On Aug 11, 2015, at 9:24 AM, Robert Sandilands wrote: > I am trying to build a certificate request with a custom OID and it is encoding strange characters in the certificate. > > For example I specify the following line in the .cnf file: > bla_policy = ASN1:PRINTABLESTRING:blabla > Then I get the following when I dump the csr: > 1.2.3.4.5.6.7: > ..blabla This is because openssl doesn't know the format of the value of your custom extension. Running the result of your script through asn1parse shows the extension section like this (snipped some entries for brevity): 417:d=3 hl=2 l= 93 cons: SEQUENCE 419:d=4 hl=2 l= 9 prim: OBJECT :Extension Request 430:d=4 hl=2 l= 80 cons: SET 432:d=5 hl=2 l= 78 cons: SEQUENCE 434:d=6 hl=2 l= 12 cons: SEQUENCE 436:d=7 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 441:d=7 hl=2 l= 1 prim: BOOLEAN :255 444:d=7 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000 448:d=6 hl=2 l= 11 cons: SEQUENCE 450:d=7 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage 455:d=7 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:030203F8 492:d=6 hl=2 l= 18 cons: SEQUENCE 494:d=7 hl=2 l= 6 prim: OBJECT :1.2.3.4.5.6.7 502:d=7 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:1306626C61626C61 Notice that the "value" of each constraint is an OCTET STRING, regardless of its type. (The BOOLEAN field in the basic constraints extension is the Critical flag.) As is usual with X.500 stuff, tracking down the actual definition of this field is a pain, but you can find it in the PKIX RFC3280/5280 (via PKCS#10/RFC2986 and PKCS#9/RFC2985): Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING } If you ask asn1parse to dump just the contents of your extension, you'll see exactly the PRINTABLESTRING which you requested: % openssl asn1parse -i -offset 504 -length 8 -in test.csr 0:d=0 hl=2 l= 6 prim: PRINTABLESTRING :blabla The two bytes, 13 06, are the DER encoding of a 6-byte string (13 contains the tag and class, indicating in this case PRINTABLESTRING, and 06 is the length in bytes of the string which follows). Similarly, the basicConstraints value is an empty (0-length) SEQUENCE because all of its contents have the default values and are omitted; and the keyUsage value is a BIT STRING (tag=3, length=0x02, number of unused bits = 0x03, bits=0x1F once you remove the padding) with a bitmap of the selected constraints. extendedKeyUsage, which I snipped, is a SEQUENCE of OIDs. If this is a custom extension, you can define its contents to be whatever you like. The standardized extensions I know about are all DER-encoded values, but I don't think that's an actual requirement. From marquess at openssl.com Tue Aug 11 20:05:28 2015 From: marquess at openssl.com (Steve Marquess) Date: Tue, 11 Aug 2015 16:05:28 -0400 Subject: [openssl-users] FIPS 140-2 casualty list (continued) Message-ID: <55CA5588.6060205@openssl.com> If you don't know or care what FIPS 140-2 is then heave a big sigh of relief and move on. Over a month ago[1] I noted that the four typographical errors from the CMVP "execution" of the "hostage" platforms[2] had still not been corrected. Ten weeks have now passed, and not only are those typos still present but I'm told by our test lab that the CMVP has stated they will deliberately remain uncorrected until the oldest of our pending "change letter" submissions is accepted (2.0.10; a 2.0.11 change letter is also pending). That could take months still; in the past change letter approvals have taken as long as six months. That connection makes no sense at all to me, but it's not the first time I've been completely befuddled. -Steve M. [1] https://mta.openssl.org/pipermail/openssl-users/2015-July/001706.html [2] http://openssl.com/fips/aftermath.html -- 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 marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From rsandila at netscape.net Tue Aug 11 21:03:50 2015 From: rsandila at netscape.net (Robert Sandilands) Date: Tue, 11 Aug 2015 17:03:50 -0400 Subject: [openssl-users] Custom OID strange characters In-Reply-To: <4B76E29F-3356-4526-91E3-7BFE5500CAF1@omnigroup.com> References: <6C6DE020-3E00-4EAE-A16D-A4A82E30F62B@netscape.net> <4B76E29F-3356-4526-91E3-7BFE5500CAF1@omnigroup.com> Message-ID: <1C6B2F9B-B09D-4AC5-9760-4479A568E5BB@netscape.net> So this leads to the next question: How do I teach OpenSSL the format of the value for a custom extension without writing code? I have been poring over man pages and I don?t find anything obvious. Robert > On Aug 11, 2015, at 2:24 PM, Wim Lewis wrote: > > On Aug 11, 2015, at 9:24 AM, Robert Sandilands wrote: >> I am trying to build a certificate request with a custom OID and it is encoding strange characters in the certificate. >> >> For example I specify the following line in the .cnf file: >> bla_policy = ASN1:PRINTABLESTRING:blabla >> Then I get the following when I dump the csr: >> 1.2.3.4.5.6.7: >> ..blabla > > This is because openssl doesn't know the format of the value of your custom extension. > > Running the result of your script through asn1parse shows the extension section like this (snipped some entries for brevity): > > 417:d=3 hl=2 l= 93 cons: SEQUENCE > 419:d=4 hl=2 l= 9 prim: OBJECT :Extension Request > 430:d=4 hl=2 l= 80 cons: SET > 432:d=5 hl=2 l= 78 cons: SEQUENCE > 434:d=6 hl=2 l= 12 cons: SEQUENCE > 436:d=7 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints > 441:d=7 hl=2 l= 1 prim: BOOLEAN :255 > 444:d=7 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000 > 448:d=6 hl=2 l= 11 cons: SEQUENCE > 450:d=7 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage > 455:d=7 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:030203F8 > 492:d=6 hl=2 l= 18 cons: SEQUENCE > 494:d=7 hl=2 l= 6 prim: OBJECT :1.2.3.4.5.6.7 > 502:d=7 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:1306626C61626C61 > > > Notice that the "value" of each constraint is an OCTET STRING, regardless of its type. (The BOOLEAN field in the basic constraints extension is the Critical flag.) As is usual with X.500 stuff, tracking down the actual definition of this field is a pain, but you can find it in the PKIX RFC3280/5280 (via PKCS#10/RFC2986 and PKCS#9/RFC2985): > > Extension ::= SEQUENCE { > extnID OBJECT IDENTIFIER, > critical BOOLEAN DEFAULT FALSE, > extnValue OCTET STRING } > > If you ask asn1parse to dump just the contents of your extension, you'll see exactly the PRINTABLESTRING which you requested: > > % openssl asn1parse -i -offset 504 -length 8 -in test.csr > 0:d=0 hl=2 l= 6 prim: PRINTABLESTRING :blabla > > > The two bytes, 13 06, are the DER encoding of a 6-byte string (13 contains the tag and class, indicating in this case PRINTABLESTRING, and 06 is the length in bytes of the string which follows). Similarly, the basicConstraints value is an empty (0-length) SEQUENCE because all of its contents have the default values and are omitted; and the keyUsage value is a BIT STRING (tag=3, length=0x02, number of unused bits = 0x03, bits=0x1F once you remove the padding) with a bitmap of the selected constraints. extendedKeyUsage, which I snipped, is a SEQUENCE of OIDs. > > If this is a custom extension, you can define its contents to be whatever you like. The standardized extensions I know about are all DER-encoded values, but I don't think that's an actual requirement. > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From rsalz at akamai.com Tue Aug 11 21:20:04 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 11 Aug 2015 21:20:04 +0000 Subject: [openssl-users] Custom OID strange characters In-Reply-To: <1C6B2F9B-B09D-4AC5-9760-4479A568E5BB@netscape.net> References: <6C6DE020-3E00-4EAE-A16D-A4A82E30F62B@netscape.net> <4B76E29F-3356-4526-91E3-7BFE5500CAF1@omnigroup.com> <1C6B2F9B-B09D-4AC5-9760-4479A568E5BB@netscape.net> Message-ID: <4139e3ef74114152af38b7110840d16b@ustx2ex-dag1mb2.msg.corp.akamai.com> > How do I teach OpenSSL the format of the value for a custom extension > without writing code? You can't. The closest you can do is encode a binary string into the config file. But something has to write that string :) From wiml at omnigroup.com Tue Aug 11 21:49:42 2015 From: wiml at omnigroup.com (Wim Lewis) Date: Tue, 11 Aug 2015 14:49:42 -0700 Subject: [openssl-users] Custom OID strange characters In-Reply-To: <1C6B2F9B-B09D-4AC5-9760-4479A568E5BB@netscape.net> References: <6C6DE020-3E00-4EAE-A16D-A4A82E30F62B@netscape.net> <4B76E29F-3356-4526-91E3-7BFE5500CAF1@omnigroup.com> <1C6B2F9B-B09D-4AC5-9760-4479A568E5BB@netscape.net> Message-ID: <028C7701-7BBE-4310-8F55-A2BA802DFA03@omnigroup.com> On Aug 11, 2015, at 2:03 PM, Robert Sandilands wrote: > So this leads to the next question: > > How do I teach OpenSSL the format of the value for a custom extension without writing code? What do you want OpenSSL to do with that knowledge? Presumably, the reason you're adding a custom extension is that some software, somewhere, is going to look for it and act upon it. That software will need some coding, right? From rsandila at netscape.net Wed Aug 12 00:42:41 2015 From: rsandila at netscape.net (Robert Sandilands) Date: Tue, 11 Aug 2015 20:42:41 -0400 Subject: [openssl-users] Custom OID strange characters In-Reply-To: <028C7701-7BBE-4310-8F55-A2BA802DFA03@omnigroup.com> References: <6C6DE020-3E00-4EAE-A16D-A4A82E30F62B@netscape.net> <4B76E29F-3356-4526-91E3-7BFE5500CAF1@omnigroup.com> <1C6B2F9B-B09D-4AC5-9760-4479A568E5BB@netscape.net> <028C7701-7BBE-4310-8F55-A2BA802DFA03@omnigroup.com> Message-ID: <22D2B497-0B0B-4105-8603-81C09E8E097B@netscape.net> It?s complicated. I either need to convince somebody to fix a bug in their software and break other dependencies in other code that depends on this behavior or I need to write code to reproduce the buggy behavior. I am trying to avoid the latter as it annoys me to write code to reproduce buggy behavior ;-) It seems like I don?t really have a choice. If it does not make sense, it is okay, it is not intended to make sense. It just implies that I don?t like either of my alternatives. Robert > On Aug 11, 2015, at 5:49 PM, Wim Lewis wrote: > > > On Aug 11, 2015, at 2:03 PM, Robert Sandilands wrote: >> So this leads to the next question: >> >> How do I teach OpenSSL the format of the value for a custom extension without writing code? > > What do you want OpenSSL to do with that knowledge? > > Presumably, the reason you're adding a custom extension is that some software, somewhere, is going to look for it and act upon it. That software will need some coding, right? > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From openssl-users at dukhovni.org Wed Aug 12 00:53:26 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 12 Aug 2015 00:53:26 +0000 Subject: [openssl-users] Custom OID strange characters In-Reply-To: <22D2B497-0B0B-4105-8603-81C09E8E097B@netscape.net> References: <6C6DE020-3E00-4EAE-A16D-A4A82E30F62B@netscape.net> <4B76E29F-3356-4526-91E3-7BFE5500CAF1@omnigroup.com> <1C6B2F9B-B09D-4AC5-9760-4479A568E5BB@netscape.net> <028C7701-7BBE-4310-8F55-A2BA802DFA03@omnigroup.com> <22D2B497-0B0B-4105-8603-81C09E8E097B@netscape.net> Message-ID: <20150812005326.GL9139@mournblade.imrryr.org> On Tue, Aug 11, 2015 at 08:42:41PM -0400, Robert Sandilands wrote: > It's complicated. I either need to convince somebody to fix a bug in their > software and break other dependencies in other code that depends on this > behavior or I need to write code to reproduce the buggy behavior. I am > trying to avoid the latter as it annoys me to write code to reproduce > buggy behavior ;-) It seems like I don't really have a choice. > > If it does not make sense, it is okay, it is not intended to make sense. It just implies that I don?t like either of my alternatives. If the extension value is supposed to just be raw binary data (with no ASN.1 type), you can just do that. You don't have to encapsulate it as an ASN.1 PRINTABLESTRING. OpenSSL can just store a value decoded from hex. -- Viktor. From jb-openssl at wisemo.com Wed Aug 12 04:01:49 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 12 Aug 2015 06:01:49 +0200 Subject: [openssl-users] [openssl-1.0.2d] default SSL handshake fails In-Reply-To: <38459fb51365459bac33b09152f18658@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <20150731210650.GW4347@mournblade.imrryr.org> <55BC5170.7080900@wisemo.com> <20150801060030.GA4347@mournblade.imrryr.org> <55C891D6.4010702@wisemo.com> <38459fb51365459bac33b09152f18658@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <55CAC52D.4060206@wisemo.com> On 10/08/2015 20:12, Salz, Rich wrote: >> Specifically, a number of decisions have the feel of a project that has been >> co-opted or taken over by someone eager to make sweeping changes for >> little apparent reason, someone with lots of idle lawyers on hand, like >> "Microsoft, various corporate partners, the CII, and/or the SFLC" (using a list >> from the latest public blog post) > Do you mean me? Or did you make a typo, and mean "members" rather than "someone" ? No, I meant someone like the examples at the end of the sentence. 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 From hokusai at gmx.ch Wed Aug 12 13:29:21 2015 From: hokusai at gmx.ch (hokusai at gmx.ch) Date: Wed, 12 Aug 2015 15:29:21 +0200 Subject: [openssl-users] X509_STORE manipulations and thread-safety Message-ID: An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Aug 12 13:38:35 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 12 Aug 2015 13:38:35 +0000 Subject: [openssl-users] X509_STORE manipulations and thread-safety In-Reply-To: References: Message-ID: <6e770a73c4f6477798f2f76402b81ed5@ustx2ex-dag1mb2.msg.corp.akamai.com> > Is it safe to have a thread reload trusted certificates and crls into a SSL_CTX's X509_STORE while connections are running in other threads, especially when considering renegotiations? As a general rule, multi-thread simultaneous access doesn't work and will often make things go ka-boom. But generally ongoing connections use SSL objects, not SSL_CTX, so a brief locking scheme should be okay. Objects are copied and ref-counted when an SSL is created from an SSL_CTX... -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From k.klein at gmx.de Thu Aug 13 22:08:40 2015 From: k.klein at gmx.de (Klaus Klein) Date: Fri, 14 Aug 2015 00:08:40 +0200 Subject: [openssl-users] input_password setting in openssl.cnf ignored Message-ID: <55CD1568.9090501@gmx.de> Hi all, I just starting to play around with OpenSSL and want to create a private CA. If I put all of the required information into the openssl.cnf and request a certificate with the following command openssl req \ -config ./openssl.cnf \ -newkey rsa \ -subj /CN=CA.klein.homenet \ -out requests/ca.req.pem \ -keyout private/ca.key.pem the key and request files are created. If I then sign the request with the following command openssl ca \ -selfsign \ -config ./openssl.cnf \ -create_serial \ -in requests/ca.req.pem \ -keyfile private/ca.key.pem \ -extensions v3_ca \ -out certs/ca.cert.pem I'm prompted for the pass phrase of the key file, despite that the input_password is set within the openssl.cnf Is this a bug or behavior by design? Cheers, Klaus From hokusai at gmx.ch Fri Aug 14 09:19:09 2015 From: hokusai at gmx.ch (hokusai at gmx.ch) Date: Fri, 14 Aug 2015 11:19:09 +0200 Subject: [openssl-users] X509_STORE manipulations and thread-safety In-Reply-To: <6e770a73c4f6477798f2f76402b81ed5@ustx2ex-dag1mb2.msg.corp.akamai.com> References: , <6e770a73c4f6477798f2f76402b81ed5@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Aug 14 20:26:21 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 14 Aug 2015 20:26:21 +0000 Subject: [openssl-users] FW: Website changing this weekend In-Reply-To: References: Message-ID: <68b20d461e3844cda6918348abf00dc8@ustx2ex-dag1mb2.msg.corp.akamai.com> From: Salz, Rich [mailto:rsalz at akamai.com] Sent: Friday, August 14, 2015 4:20 PM To: openssl-announce at openssl.org Subject: [openssl-announce] Website changing this weekend We're bringing up a new website this weekend. Please be patient if you have problems. If you notice any broken links, let us know. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajaygargnsit at gmail.com Sun Aug 16 09:14:54 2015 From: ajaygargnsit at gmail.com (Ajay Garg) Date: Sun, 16 Aug 2015 14:44:54 +0530 Subject: [openssl-users] SSL Signalling Message-ID: Hi All. We wish to exhange data over sockets in embedded-environments, and unfortunately can't afford to use the de-facto openssl implementation, which I believe uses dynamic memory allocations/deallocations in its code (we intend to deploy our solution using bare-metal C, in environments where even no RTOS are available). I googled a lot, but somehow managed to fail in finding the native SSL-signalling steps. We are wishing to gain some information on native SSL-signalling, much like what GET/POST/PUT/DELETE are for HTTP. Since OpenSSL is the de-facto/expert in this field, may I please put forward my earnest request for directing us to some literature in this regard, wherein we can set up a SSL-context using absolute native SS7-signalling. Our plan is pretty straighforward :: 1) Connect to a nginix-erver on its HTTPS port. 2) 3) Just before what would have been a normal socket "send", we encrypt the data using the server-public-key obtained from step 2, and then send the encrypted data (over the socket of step 1). 4) Just after what would have been a normal socket "recv", we decrypt the data (obtained from the socket of step 1) using the client-private-key obtained from step 2, and then have it available to the client's software. Looking forward to some pointers... Thanks and Regards, Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sun Aug 16 17:38:29 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 16 Aug 2015 17:38:29 +0000 Subject: [openssl-users] SSL Signalling In-Reply-To: References: Message-ID: <20150816173829.GP9139@mournblade.imrryr.org> On Sun, Aug 16, 2015 at 02:44:54PM +0530, Ajay Garg wrote: > We wish to exhange data over sockets in embedded-environments, and > unfortunately can't afford to use the de-facto openssl implementation, > which I believe uses dynamic memory allocations/deallocations in its code > (we intend to deploy our solution using bare-metal C, in environments where > even no RTOS are available). Why do you want to use TLS? Is this a closed communication protocol only betweent these devices? Or do you need this to interoperate with with other TLS clients or servers? For closed environments, there are simpler secure communications options than TLS, DJBs crypto box comes to mind: http://nacl.cr.yp.to/features.html http://nacl.cr.yp.to/box.html -- Viktor. From secaficionado at gmail.com Sun Aug 16 22:42:08 2015 From: secaficionado at gmail.com (Sec_Aficiondado) Date: Sun, 16 Aug 2015 18:42:08 -0400 Subject: [openssl-users] Online manuals no longer accessible Message-ID: <8B5BE038-D5D0-40B0-AA66-36FC6A5A56DF@gmail.com> Hi there, I noticed this weekend that the man pages are no longer available from the OpenSSL.org site. The site is beautiful, but the man pages are really needed. For example: try openssl.org/docs/ssl/ or openssl.org/docs/apps/ I noticed that the search engine results point to http pages while the site is now using https. Could that be the reason? Thanks in advance for your help! Sent from my mobile From rsalz at akamai.com Sun Aug 16 22:43:54 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 16 Aug 2015 22:43:54 +0000 Subject: [openssl-users] Online manuals no longer accessible In-Reply-To: <8B5BE038-D5D0-40B0-AA66-36FC6A5A56DF@gmail.com> References: <8B5BE038-D5D0-40B0-AA66-36FC6A5A56DF@gmail.com> Message-ID: > I noticed this weekend that the man pages are no longer available from the > OpenSSL.org site. The site is beautiful, but the man pages are really needed. > For example: try openssl.org/docs/ssl/ or openssl.org/docs/apps/ Please see the blog. We're working on it. Might be a couple of days. From noloader at gmail.com Mon Aug 17 02:56:00 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 16 Aug 2015 22:56:00 -0400 Subject: [openssl-users] How to disable DSO support at runtime? Message-ID: We can disable DSO support at configure time with 'no-dso'. But its not clear to me how to explicitly disable the feature at runtime if the platform/distro provided the OpenSSL libraries (and they were enabled). I took a look at config(5), but that's more for configuration files, and less of running configs. How do I disable the DSO interface at runtime? From ajaygargnsit at gmail.com Mon Aug 17 05:55:47 2015 From: ajaygargnsit at gmail.com (Ajay Garg) Date: Mon, 17 Aug 2015 11:25:47 +0530 Subject: [openssl-users] SSL Signalling In-Reply-To: <20150816173829.GP9139@mournblade.imrryr.org> References: <20150816173829.GP9139@mournblade.imrryr.org> Message-ID: Hi Viktor. Thanks for the reply. Yes, we need our (embedded-)clients to talk to our TLS-server. We are using Vertx2 as our server. Its SSL-support APIs are in "SSLSupport" class at http://vertx.io/vertx2/api/java/index.html Going by the APIs, it is not exactly clear what TLS-Algorithm and Cipher-Suites are used in Vertx2 (I have put an email on the Vertx2 mailing-list with this query, will let know as soon as I have some answers). So, in the interim, I will be grateful if you guys could let us know the generic native SSL-signalling steps (if at all there are any steps that are independent of the TLS-Algorithm and Cipher-Suite). I know I sound incredibly clueless, kindly bear with me ... Thanks and Regards, Ajay On Sun, Aug 16, 2015 at 11:08 PM, Viktor Dukhovni < openssl-users at dukhovni.org> wrote: > On Sun, Aug 16, 2015 at 02:44:54PM +0530, Ajay Garg wrote: > > > We wish to exhange data over sockets in embedded-environments, and > > unfortunately can't afford to use the de-facto openssl implementation, > > which I believe uses dynamic memory allocations/deallocations in its code > > (we intend to deploy our solution using bare-metal C, in environments > where > > even no RTOS are available). > > Why do you want to use TLS? Is this a closed communication protocol > only betweent these devices? Or do you need this to interoperate > with with other TLS clients or servers? > > For closed environments, there are simpler secure communications > options than TLS, DJBs crypto box comes to mind: > > http://nacl.cr.yp.to/features.html > http://nacl.cr.yp.to/box.html > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Regards, Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Aug 17 06:14:01 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 17 Aug 2015 06:14:01 +0000 Subject: [openssl-users] SSL Signalling In-Reply-To: References: <20150816173829.GP9139@mournblade.imrryr.org> Message-ID: <20150817061401.GD24426@mournblade.imrryr.org> On Mon, Aug 17, 2015 at 11:25:47AM +0530, Ajay Garg wrote: > Yes, we need our (embedded-)clients to talk to our TLS-server. The protocol is documented at: https://tools.ietf.org/html/rfc5246 However you SHOULD NOT attempt to write your own TLS implementation. This is much too difficult, even for experts. > So, in the interim, I will be grateful if you guys could let us know the > generic native SSL-signalling steps (if at all there are any steps that are > independent of the TLS-Algorithm and Cipher-Suite). > > I know I sound incredibly clueless, kindly bear with me ... Peter Gutmann's cryptlib supports various embedded devices, and seems to not require dynamic memory allocation. Perhaps you should license that: http://www.cryptlib.com/ http://www.cryptlib.com/security-software/embedded-systems -- Viktor. From jb-openssl at wisemo.com Mon Aug 17 06:29:08 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 17 Aug 2015 08:29:08 +0200 Subject: [openssl-users] SSL Signalling In-Reply-To: References: <20150816173829.GP9139@mournblade.imrryr.org> Message-ID: <55D17F34.4040507@wisemo.com> A few tips: 1. The tool "openssl s_client" (with appropriate command line options) can be used (on a PC) to figure out which SSL/TLS options and variations a server is using, this may or may not be easier than waiting for an answer from vertx2. I would link to the online documentation, but it is down today. 2. The SSL/TLS protocols are documented in a number of RFCs. There is one main RFC for each SSL/TLS protocol version (SSL 3.0, TLS 1.0==SSL3.1, TLS 1.1==SSL3.2, TLS 1.2==SSL3.3), then there are a number of additional RFCs listing various standalone additions/extensions, such as additional choices for the algorithm numbers, and workaround for various issues. V.D. already provided a link to the TLS 1.2 RFC. 3. If you are making an embedded client that will talk only to one server model (as I understand your description), you can reduce your embedded implementation to only implement a single strong algorithm set for the latest SSL/TLS protocol version supported by that server. This will eliminate a lot of code in any SSL/TLS library. 4. There are available SSL/TLS libraries that are designed specifically for embedded systems. One such library (which I have not studied or tested, only heard of) is MatrixSSL. P.S. When I write that TLS 1.2==SSL3.3 etc., I mean that those protocols are named e.g. "TLS 1.2", but transmit a protocol version number such as 3.3 to indicate that they are more recent than Netscape SSL 3.0 . P.P.S. If you try to implement SSL/TLS yourself, note that skipping even the slightest detail from the specification (such as testing that some byte has the exact value it always has) can ruin the security. And skipping even the slightest extra security precaution discovered over the years by experts will also ruin the security. And doing stuff in new ways that others have never done might ruin the security in ways that others have never experienced. On 17/08/2015 07:55, Ajay Garg wrote: > Hi Viktor. > > Thanks for the reply. > > Yes, we need our (embedded-)clients to talk to our TLS-server. > > We are using Vertx2 as our server. > Its SSL-support APIs are in "SSLSupport" class at > http://vertx.io/vertx2/api/java/index.html > > Going by the APIs, it is not exactly clear what TLS-Algorithm and > Cipher-Suites are used in Vertx2 (I have put an email on the Vertx2 > mailing-list with this query, will let know as soon as I have some > answers). > > > > So, in the interim, I will be grateful if you guys could let us know > the generic native SSL-signalling steps (if at all there are any steps > that are independent of the TLS-Algorithm and Cipher-Suite). > > I know I sound incredibly clueless, kindly bear with me ... > > > Thanks and Regards, > Ajay > > On Sun, Aug 16, 2015 at 11:08 PM, Viktor Dukhovni > > wrote: > > On Sun, Aug 16, 2015 at 02:44:54PM +0530, Ajay Garg wrote: > > > We wish to exhange data over sockets in embedded-environments, and > > unfortunately can't afford to use the de-facto openssl > implementation, > > which I believe uses dynamic memory allocations/deallocations in > its code > > (we intend to deploy our solution using bare-metal C, in > environments where > > even no RTOS are available). > > Why do you want to use TLS? Is this a closed communication protocol > only betweent these devices? Or do you need this to interoperate > with with other TLS clients or servers? > > For closed environments, there are simpler secure communications > options than TLS, DJBs crypto box comes to mind: > > http://nacl.cr.yp.to/features.html > http://nacl.cr.yp.to/box.html > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > -- > Regards, > Ajay > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users 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 From secaficionado at gmail.com Mon Aug 17 12:40:24 2015 From: secaficionado at gmail.com (Sec_Aficiondado) Date: Mon, 17 Aug 2015 08:40:24 -0400 Subject: [openssl-users] Online manuals no longer accessible In-Reply-To: References: <8B5BE038-D5D0-40B0-AA66-36FC6A5A56DF@gmail.com> Message-ID: <3EA11F47-295A-4925-ADE5-E84CB4B5A8E4@gmail.com> Great, thanks! Good luck with all the efforts. You guys are keeping very busy these days. > On Aug 16, 2015, at 6:43 PM, Salz, Rich wrote: > > >> I noticed this weekend that the man pages are no longer available from the >> OpenSSL.org site. The site is beautiful, but the man pages are really needed. >> For example: try openssl.org/docs/ssl/ or openssl.org/docs/apps/ > > Please see the blog. We're working on it. Might be a couple of days. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From jonetsu at teksavvy.com Tue Aug 18 18:31:33 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Tue, 18 Aug 2015 11:31:33 -0700 (MST) Subject: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS In-Reply-To: <55AF9C0A.2070901@wisemo.com> References: <55AF9C0A.2070901@wisemo.com> Message-ID: <1439922693333-59732.post@n7.nabble.com> Does this mean, since the 'no insert fragments' is part of SSL_OP_ALL, that OpenSSL is BEAST-proof since some time regarding it's use of TLS 1.0 and SSL 3.0 ? Thanks. -- View this message in context: http://openssl.6102.n7.nabble.com/BEAST-and-SSL-OP-DONT-INSERT-EMPTY-FRAGMENTS-tp59291p59732.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From rsalz at akamai.com Tue Aug 18 19:21:58 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 18 Aug 2015 19:21:58 +0000 Subject: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS In-Reply-To: <1439922693333-59732.post@n7.nabble.com> References: <55AF9C0A.2070901@wisemo.com> <1439922693333-59732.post@n7.nabble.com> Message-ID: <679d0147562043e9bab9e48fa20efdd8@ustx2ex-dag1mb2.msg.corp.akamai.com> > Does this mean, since the 'no insert fragments' is part of SSL_OP_ALL, that > OpenSSL is BEAST-proof since some time regarding it's use of TLS 1.0 and SSL > 3.0 ? No. From jonetsu at teksavvy.com Tue Aug 18 21:06:15 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Tue, 18 Aug 2015 14:06:15 -0700 (MST) Subject: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS In-Reply-To: <679d0147562043e9bab9e48fa20efdd8@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <55AF9C0A.2070901@wisemo.com> <1439922693333-59732.post@n7.nabble.com> <679d0147562043e9bab9e48fa20efdd8@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <1439931975276-59734.post@n7.nabble.com> OK. So this means that the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is not the solution for the BEAST attack. Is there a solution while keeping TLS 1.0 and SSL v3.0 ? Thanks. -- View this message in context: http://openssl.6102.n7.nabble.com/BEAST-and-SSL-OP-DONT-INSERT-EMPTY-FRAGMENTS-tp59291p59734.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From openssl-users at openssl.org Tue Aug 18 21:15:29 2015 From: openssl-users at openssl.org (openssl-users at openssl.org) Date: Tue, 18 Aug 2015 21:15:29 +0000 (UTC) Subject: Violação dos Termos de Uso! (10618) Message-ID: <20150818211529.969A220FCB@li910-172.members.linode.com> An HTML attachment was scrubbed... URL: From dan at kohlbek.com Tue Aug 18 21:39:12 2015 From: dan at kohlbek.com (dan at kohlbek.com) Date: Tue, 18 Aug 2015 14:39:12 -0700 Subject: [openssl-users] Vacation reply Message-ID: An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Aug 18 22:19:05 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 19 Aug 2015 00:19:05 +0200 Subject: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS In-Reply-To: <1439931975276-59734.post@n7.nabble.com> References: <55AF9C0A.2070901@wisemo.com> <1439922693333-59732.post@n7.nabble.com> <679d0147562043e9bab9e48fa20efdd8@ustx2ex-dag1mb2.msg.corp.akamai.com> <1439931975276-59734.post@n7.nabble.com> Message-ID: <55D3AF59.3080400@wisemo.com> On 18/08/2015 23:06, jonetsu wrote: > OK. So this means that the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is not the > solution for the BEAST attack. Is there a solution while keeping TLS 1.0 > and SSL v3.0 ? > > Thanks. The solution is NOT setting SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS and hoping the other end doesn't have whatever bug caused the OpenSSL team to disable the workaround by default. 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 From rsalz at akamai.com Tue Aug 18 22:26:24 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 18 Aug 2015 22:26:24 +0000 Subject: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS In-Reply-To: <55D3AF59.3080400@wisemo.com> References: <55AF9C0A.2070901@wisemo.com> <1439922693333-59732.post@n7.nabble.com> <679d0147562043e9bab9e48fa20efdd8@ustx2ex-dag1mb2.msg.corp.akamai.com> <1439931975276-59734.post@n7.nabble.com> <55D3AF59.3080400@wisemo.com> Message-ID: <4071e45942e94deeb723ca39d8d74deb@ustx2ex-dag1mb2.msg.corp.akamai.com> There are *no* secure SSLv3 ciphers. If you need to support it (for legacy clients), then best you can do is use the "poodle patch," the SCSV indicator which will at least prevents clients that are capable of more from being downgraded. From jb-openssl at wisemo.com Wed Aug 19 09:06:30 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 19 Aug 2015 11:06:30 +0200 Subject: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS In-Reply-To: <4071e45942e94deeb723ca39d8d74deb@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <55AF9C0A.2070901@wisemo.com> <1439922693333-59732.post@n7.nabble.com> <679d0147562043e9bab9e48fa20efdd8@ustx2ex-dag1mb2.msg.corp.akamai.com> <1439931975276-59734.post@n7.nabble.com> <55D3AF59.3080400@wisemo.com> <4071e45942e94deeb723ca39d8d74deb@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <55D44716.3090004@wisemo.com> On 19/08/2015 00:26, Salz, Rich wrote: > There are *no* secure SSLv3 ciphers. If you need to support it (for legacy clients), then best you can do is use the "poodle patch," the SCSV indicator which will at least prevents clients that are capable of more from being downgraded. What about 3DES with appropriate IV, downgrade and replay countermeasures, what exactly is wrong with those ciphers that is beyond salvage?(By salvage I mean significantly better than plain text when talking to clients that don't support anything more modern, such as certain Microsoft systems). Specifically: If the SSL library aborts session on first bad decryption, the adversary gets only one use of the padding oracle per key. Shouldn't this kill off those attacks. With 1/n-1 or 0/n splitting, the predictable IV issue should be reasonably mitigated.(Hence the prior discussion of the need to not disable thatvia SSL_OP_ALL). With export-RSA and export-DH properly disabled, attempts to downgrade to 40/56 bit symmetric keys should be detected, or is there a bug in the way strong RSA/DSA keys are used to authenticate the negotiation that would allow a downgradeto downgrade its own check? With SCSV handling enabled, shouldn't that prevent downgrade-via-browser-retry attacks (Poodle)? Except of cause with browsers that lack the feature. Which attack scenario did I forget? Of cause it is more safe to insist that everybody else uses only TLS 1.2 with ECDH, AES and SHA-2, but I think that wold rule out too many clients in practice. 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 From srinivasan.v39 at gmail.com Wed Aug 19 12:12:04 2015 From: srinivasan.v39 at gmail.com (V Srinivasan) Date: Wed, 19 Aug 2015 17:42:04 +0530 Subject: [openssl-users] Problem in installing gem puma Message-ID: <55D47294.2020803@gmail.com> Dear All, I am using Windows 7 ruby version :: ruby 2.1.6p336 (2015-04-13 revision 50298) [i386-mingw32] gem version :: 2.2.3 I have a problem in installing gem puma |PS C:\Users\VSrinivasan\mystuff\SampleApp> gem install puma Temporarily enhancing PATH to include DevKit... Building native extensions. This could take a while... ERROR: Error installing puma: ERROR: Failed to build gem native extension. C:/Ruby21/bin/ruby.exe extconf.rb checking for BIO_read() in -lcrypto... no checking for BIO_read() in -llibeay32... no *** extconf.rb failed *** Could not create Makefile due to some reason, probably lack of necessary libraries and/or headers. Check the mkmf.log file for more details. You may need configuration options. Provided configuration options: --with-opt-dir --without-opt-dir --with-opt-include --without-opt-include=${opt-dir}/include --with-opt-lib --without-opt-lib=${opt-dir}/lib --with-make-prog --without-make-prog --srcdir=. --curdir --ruby=C:/Ruby21/bin/ruby --with-puma_http11-dir --without-puma_http11-dir --with-puma_http11-include --without-puma_http11-include=${puma_http11-dir}/include --with-puma_http11-lib --without-puma_http11-lib=${puma_http11-dir}/lib --with-cryptolib --without-cryptolib --with-libeay32lib --without-libeay32lib extconf failed, exit code 1 Gem files will remain installed in C:/Ruby21/lib/ruby/gems/2.1.0/gems/puma-2.13.4 for inspection. Results logged to C:/Ruby21/lib/ruby/gems/2.1.0/extensions/x86-mingw32/2.1.0/puma-2.13.4/gem_make.out | mkmf.log have_library: checking for BIO_read() in -lcrypto... -------------------- no "gcc -o conftest.exe -IC:/Ruby21/include/ruby-2.1.0/i386-mingw32 -IC:/Ruby21/include/ruby-2.1.0/ruby/backward -IC:/Ruby21/include/ruby-2.1.0 -I. -DFD_SETSIZE=2048 -D_WIN32_WINNT=0x0501 -D__MINGW_USE_VC2005_COMPAT -D_FILE_OFFSET_BITS=64 -O3 -fno-omit-frame-pointer -fno-fast-math -g -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement -Wimplicit-function-declaration conftest.c -L. -LC:/Ruby21/lib -L. -lmsvcrt-ruby210 -lshell32 -lws2_32 -liphlpapi -limagehlp -lshlwapi " checked program was: /* begin */ 1: #include "ruby.h" 2: 3: #include 4: #include 5: int main(int argc, char **argv) 6: { 7: return 0; 8: } /* end */ "gcc -o conftest.exe -IC:/Ruby21/include/ruby-2.1.0/i386-mingw32 -IC:/Ruby21/include/ruby-2.1.0/ruby/backward -IC:/Ruby21/include/ruby-2.1.0 -I. -DFD_SETSIZE=2048 -D_WIN32_WINNT=0x0501 -D__MINGW_USE_VC2005_COMPAT -D_FILE_OFFSET_BITS=64 -O3 -fno-omit-frame-pointer -fno-fast-math -g -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement -Wimplicit-function-declaration conftest.c -L. -LC:/Ruby21/lib -L. -lmsvcrt-ruby210 -lcrypto -lshell32 -lws2_32 -liphlpapi -limagehlp -lshlwapi " conftest.c: In function 't': conftest.c:16:57: error: 'BIO_read' undeclared (first use in this function) conftest.c:16:57: note: each undeclared identifier is reported only once for each function it appears in conftest.c:16:32: warning: variable 'p' set but not used [-Wunused-but-set-variable] checked program was: /* begin */ 1: #include "ruby.h" 2: 3: #include 4: #include 5: 6: /*top*/ 7: extern int t(void); 8: int main(int argc, char **argv) 9: { 10: if (argc > 1000000) { 11: printf("%p", &t); 12: } 13: 14: return 0; 15: } 16: int t(void) { void ((*volatile p)()); p = (void ((*)()))BIO_read; return 0; } /* end */ "gcc -o conftest.exe -IC:/Ruby21/include/ruby-2.1.0/i386-mingw32 -IC:/Ruby21/include/ruby-2.1.0/ruby/backward -IC:/Ruby21/include/ruby-2.1.0 -I. -DFD_SETSIZE=2048 -D_WIN32_WINNT=0x0501 -D__MINGW_USE_VC2005_COMPAT -D_FILE_OFFSET_BITS=64 -O3 -fno-omit-frame-pointer -fno-fast-math -g -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement -Wimplicit-function-declaration conftest.c -L. -LC:/Ruby21/lib -L. -lmsvcrt-ruby210 -lcrypto -lshell32 -lws2_32 -liphlpapi -limagehlp -lshlwapi " conftest.c: In function 't': conftest.c:16:1: warning: implicit declaration of function 'BIO_read' [-Wimplicit-function-declaration] c:/devkit/mingw/bin/../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lcrypto collect2.exe: error: ld returned 1 exit status checked program was: /* begin */ 1: #include "ruby.h" 2: 3: #include 4: #include 5: 6: /*top*/ 7: extern int t(void); 8: int main(int argc, char **argv) 9: { 10: if (argc > 1000000) { 11: printf("%p", &t); 12: } 13: 14: return 0; 15: } 16: int t(void) { BIO_read(); return 0; } /* end */ -------------------- have_library: checking for BIO_read() in -llibeay32... -------------------- no "gcc -o conftest.exe -IC:/Ruby21/include/ruby-2.1.0/i386-mingw32 -IC:/Ruby21/include/ruby-2.1.0/ruby/backward -IC:/Ruby21/include/ruby-2.1.0 -I. -DFD_SETSIZE=2048 -D_WIN32_WINNT=0x0501 -D__MINGW_USE_VC2005_COMPAT -D_FILE_OFFSET_BITS=64 -O3 -fno-omit-frame-pointer -fno-fast-math -g -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement -Wimplicit-function-declaration conftest.c -L. -LC:/Ruby21/lib -L. -lmsvcrt-ruby210 -llibeay32 -lshell32 -lws2_32 -liphlpapi -limagehlp -lshlwapi " conftest.c: In function 't': conftest.c:16:57: error: 'BIO_read' undeclared (first use in this function) conftest.c:16:57: note: each undeclared identifier is reported only once for each function it appears in conftest.c:16:32: warning: variable 'p' set but not used [-Wunused-but-set-variable] checked program was: /* begin */ 1: #include "ruby.h" 2: 3: #include 4: #include 5: 6: /*top*/ 7: extern int t(void); 8: int main(int argc, char **argv) 9: { 10: if (argc > 1000000) { 11: printf("%p", &t); 12: } 13: 14: return 0; 15: } 16: int t(void) { void ((*volatile p)()); p = (void ((*)()))BIO_read; return 0; } /* end */ "gcc -o conftest.exe -IC:/Ruby21/include/ruby-2.1.0/i386-mingw32 -IC:/Ruby21/include/ruby-2.1.0/ruby/backward -IC:/Ruby21/include/ruby-2.1.0 -I. -DFD_SETSIZE=2048 -D_WIN32_WINNT=0x0501 -D__MINGW_USE_VC2005_COMPAT -D_FILE_OFFSET_BITS=64 -O3 -fno-omit-frame-pointer -fno-fast-math -g -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement -Wimplicit-function-declaration conftest.c -L. -LC:/Ruby21/lib -L. -lmsvcrt-ruby210 -llibeay32 -lshell32 -lws2_32 -liphlpapi -limagehlp -lshlwapi " conftest.c: In function 't': conftest.c:16:1: warning: implicit declaration of function 'BIO_read' [-Wimplicit-function-declaration] c:/devkit/mingw/bin/../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -llibeay32 collect2.exe: error: ld returned 1 exit status checked program was: /* begin */ 1: #include "ruby.h" 2: 3: #include 4: #include 5: 6: /*top*/ 7: extern int t(void); 8: int main(int argc, char **argv) 9: { 10: if (argc > 1000000) { 11: printf("%p", &t); 12: } 13: 14: return 0; 15: } 16: int t(void) { BIO_read(); return 0; } /* end */ -------------------- Request your help please Rgds V.Srinivasan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonetsu at teksavvy.com Wed Aug 19 12:59:47 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Wed, 19 Aug 2015 05:59:47 -0700 (MST) Subject: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS In-Reply-To: <55D44716.3090004@wisemo.com> References: <55AF9C0A.2070901@wisemo.com> <1439922693333-59732.post@n7.nabble.com> <679d0147562043e9bab9e48fa20efdd8@ustx2ex-dag1mb2.msg.corp.akamai.com> <1439931975276-59734.post@n7.nabble.com> <55D3AF59.3080400@wisemo.com> <4071e45942e94deeb723ca39d8d74deb@ustx2ex-dag1mb2.msg.corp.akamai.com> <55D44716.3090004@wisemo.com> Message-ID: <1439989187137-59743.post@n7.nabble.com> Thanks for your comments - much appreciated. What is exactly the "poodle patch" and how doe sit come into providing some form of protection against the BEAST attack ? -- View this message in context: http://openssl.6102.n7.nabble.com/BEAST-and-SSL-OP-DONT-INSERT-EMPTY-FRAGMENTS-tp59291p59743.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From rsalz at akamai.com Wed Aug 19 14:27:54 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 19 Aug 2015 14:27:54 +0000 Subject: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS In-Reply-To: <55D44716.3090004@wisemo.com> References: <55AF9C0A.2070901@wisemo.com> <1439922693333-59732.post@n7.nabble.com> <679d0147562043e9bab9e48fa20efdd8@ustx2ex-dag1mb2.msg.corp.akamai.com> <1439931975276-59734.post@n7.nabble.com> <55D3AF59.3080400@wisemo.com> <4071e45942e94deeb723ca39d8d74deb@ustx2ex-dag1mb2.msg.corp.akamai.com> <55D44716.3090004@wisemo.com> Message-ID: <146d9a08acf94bf199311dd5ca21802b@ustx2ex-dag1mb2.msg.corp.akamai.com> > What about 3DES with appropriate IV, downgrade and replay > countermeasures, what exactly is wrong with those ciphers that is beyond > salvage?(By salvage I mean significantly better than plain text when talking to > clients that don't support anything more modern, such as certain Microsoft > systems). I don't know. I am not a cryptographer, and I try not to come across as if I were. "There are no safe SSL3 ciphers" is something several cryptographers and other members of the security community, have said loudly and often. From rsalz at akamai.com Wed Aug 19 14:37:23 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 19 Aug 2015 14:37:23 +0000 Subject: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS In-Reply-To: <1439989187137-59743.post@n7.nabble.com> References: <55AF9C0A.2070901@wisemo.com> <1439922693333-59732.post@n7.nabble.com> <679d0147562043e9bab9e48fa20efdd8@ustx2ex-dag1mb2.msg.corp.akamai.com> <1439931975276-59734.post@n7.nabble.com> <55D3AF59.3080400@wisemo.com> <4071e45942e94deeb723ca39d8d74deb@ustx2ex-dag1mb2.msg.corp.akamai.com> <55D44716.3090004@wisemo.com> <1439989187137-59743.post@n7.nabble.com> Message-ID: <3925573ddf1543beb769f154abf60317@ustx2ex-dag1mb2.msg.corp.akamai.com> Try this as a starting point: https://security.ias.edu/poodle-and-beast-isnt-love-story-sslv3-cipher-vulnerability From Michael.Wojcik at microfocus.com Wed Aug 19 13:55:39 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 19 Aug 2015 13:55:39 +0000 Subject: [openssl-users] Problem in installing gem puma In-Reply-To: <55D47294.2020803@gmail.com> References: <55D47294.2020803@gmail.com> Message-ID: This is not an OpenSSL issue; it's an autoconf one. From your installation log: ----- "gcc -o conftest.exe -IC:/Ruby21/include/ruby-2.1.0/i386-mingw32 -IC:/Ruby21/include/ruby-2.1.0/ruby/backward -IC:/Ruby21/include/ruby-2.1.0 -I. -DFD_SETSIZE=2048 -D_WIN32_WINNT=0x0501 -D__MINGW_USE_VC2005_COMPAT -D_FILE_OFFSET_BITS=64 -O3 -fno-omit-frame-pointer -fno-fast-math -g -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement -Wimplicit-function-declaration conftest.c -L. -LC:/Ruby21/lib -L. -lmsvcrt-ruby210 -lcrypto -lshell32 -lws2_32 -liphlpapi -limagehlp -lshlwapi " conftest.c: In function 't': conftest.c:16:57: error: 'BIO_read' undeclared (first use in this function) conftest.c:16:57: note: each undeclared identifier is reported only once for each function it appears in conftest.c:16:32: warning: variable 'p' set but not used [-Wunused-but-set-variable] checked program was: /* begin */ 1: #include "ruby.h" 2: 3: #include 4: #include 5: 6: /*top*/ 7: extern int t(void); 8: int main(int argc, char **argv) 9: { 10: if (argc > 1000000) { 11: printf("%p", &t); 12: } 13: 14: return 0; 15: } 16: int t(void) { void ((*volatile p)()); p = (void ((*)()))BIO_read; return 0; } /* end */ ----- Note: - The conftest.c generated by autoconf does not include any OpenSSL headers - gcc correctly complains that BIO_read has not been declared It's not a linker failure - it's a compiler diagnostic. autoconf isn't successfully checking whether the symbol can be resolved by the library because the test program it's generating is rubbish. Autoconf should be generating an extern declaration for BIO_read in conftest.c; apparently whoever wrote that bit of autoconf doesn't know C. (No surprise there.) I suspect it normally works because gcc is configured with different default settings and treats the lack of a declaration as non-fatal. I don't know why it's different in your case, and I have no idea how to fix it, as I've never had to poke into the implementation of autoconf and don't know what's making your gcc behave differently. -- Michael Wojcik Technology Specialist, Micro Focus From jb-openssl at wisemo.com Wed Aug 19 14:52:30 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 19 Aug 2015 16:52:30 +0200 Subject: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS In-Reply-To: <3925573ddf1543beb769f154abf60317@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <55AF9C0A.2070901@wisemo.com> <1439922693333-59732.post@n7.nabble.com> <679d0147562043e9bab9e48fa20efdd8@ustx2ex-dag1mb2.msg.corp.akamai.com> <1439931975276-59734.post@n7.nabble.com> <55D3AF59.3080400@wisemo.com> <4071e45942e94deeb723ca39d8d74deb@ustx2ex-dag1mb2.msg.corp.akamai.com> <55D44716.3090004@wisemo.com> <1439989187137-59743.post@n7.nabble.com> <3925573ddf1543beb769f154abf60317@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <55D4982E.4070403@wisemo.com> On 19/08/2015 16:37, Salz, Rich wrote: > Try this as a starting point: https://security.ias.edu/poodle-and-beast-isnt-love-story-sslv3-cipher-vulnerability > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users That's just some guy pontificating before the SCSV countermeasure was available. Absolutely no technical arguments. The list of "sources" is equally random and non-detailed as to why there is nothing salvageable. For instance, one is a link where Bodo Moeller explains why something like the _EMPTY_FRAGMENTS countermeasure is needed for the IV issue. I know a lot of people said the sky was falling, I am trying to remember why. 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 From rsalz at akamai.com Wed Aug 19 21:51:24 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 19 Aug 2015 21:51:24 +0000 Subject: [openssl-users] The manpages are on the website now Message-ID: <76ec7205b8b641678049f593f2485c34@ustx2ex-dag1mb2.msg.corp.akamai.com> As a new feature, all releases are now online, including master. There is still some links broken. We could use some Perl hacking help. If you know how to add "-podpath" searching into Pod::XHTML, please get in touch. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From srinivasan.v39 at gmail.com Thu Aug 20 00:45:41 2015 From: srinivasan.v39 at gmail.com (Venkataraman Srinivasan) Date: Thu, 20 Aug 2015 06:15:41 +0530 Subject: [openssl-users] Problem in installing gem puma In-Reply-To: References: <55D47294.2020803@gmail.com> Message-ID: <55D52335.6010503@gmail.com> Thank you Michael Wojcik On 19-Aug-15 7:25 PM, Michael Wojcik wrote: > This is not an OpenSSL issue; it's an autoconf one. > > From your installation log: > > ----- > "gcc -o conftest.exe -IC:/Ruby21/include/ruby-2.1.0/i386-mingw32 -IC:/Ruby21/include/ruby-2.1.0/ruby/backward -IC:/Ruby21/include/ruby-2.1.0 -I. -DFD_SETSIZE=2048 -D_WIN32_WINNT=0x0501 -D__MINGW_USE_VC2005_COMPAT -D_FILE_OFFSET_BITS=64 -O3 -fno-omit-frame-pointer -fno-fast-math -g -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement -Wimplicit-function-declaration conftest.c -L. -LC:/Ruby21/lib -L. -lmsvcrt-ruby210 -lcrypto -lshell32 -lws2_32 -liphlpapi -limagehlp -lshlwapi" > conftest.c: In function 't': > conftest.c:16:57: error: 'BIO_read' undeclared (first use in this function) > conftest.c:16:57: note: each undeclared identifier is reported only once for each function it appears in > conftest.c:16:32: warning: variable 'p' set but not used [-Wunused-but-set-variable] > checked program was: > /* begin */ > 1: #include "ruby.h" > 2: > 3: #include > 4: #include > 5: > 6: /*top*/ > 7: extern int t(void); > 8: int main(int argc, char **argv) > 9: { > 10: if (argc > 1000000) { > 11: printf("%p", &t); > 12: } > 13: > 14: return 0; > 15: } > 16: int t(void) { void ((*volatile p)()); p = (void ((*)()))BIO_read; return 0; } > /* end */ > ----- > > Note: > - The conftest.c generated by autoconf does not include any OpenSSL headers > - gcc correctly complains that BIO_read has not been declared > > It's not a linker failure - it's a compiler diagnostic. autoconf isn't successfully checking whether the symbol can be resolved by the library because the test program it's generating is rubbish. > > Autoconf should be generating an extern declaration for BIO_read in conftest.c; apparently whoever wrote that bit of autoconf doesn't know C. (No surprise there.) I suspect it normally works because gcc is configured with different default settings and treats the lack of a declaration as non-fatal. I don't know why it's different in your case, and I have no idea how to fix it, as I've never had to poke into the implementation of autoconf and don't know what's making your gcc behave differently. > From a.chris.clark at gmail.com Thu Aug 20 20:11:41 2015 From: a.chris.clark at gmail.com (Chris Clark) Date: Thu, 20 Aug 2015 13:11:41 -0700 Subject: [openssl-users] FW: Website changing this weekend In-Reply-To: <68b20d461e3844cda6918348abf00dc8@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <68b20d461e3844cda6918348abf00dc8@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: Hi Rich, I'm curious why the new download page lists version 1.01p before version 1.02d? Is it suggesting that users download the 1.01 branch instead of the later one? -Chris On Fri, Aug 14, 2015 at 1:26 PM, Salz, Rich wrote: > > > From: Salz, Rich [mailto:rsalz at akamai.com] > Sent: Friday, August 14, 2015 4:20 PM > To: openssl-announce at openssl.org > Subject: [openssl-announce] Website changing this weekend > > > > We?re bringing up a new website this weekend. Please be patient if you have > problems. If you notice any broken links, let us know. > > > > Thanks. > > > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From rsalz at akamai.com Thu Aug 20 21:54:04 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 20 Aug 2015 21:54:04 +0000 Subject: [openssl-users] FW: Website changing this weekend In-Reply-To: References: <68b20d461e3844cda6918348abf00dc8@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <891f52d2fab548409092ecb6172cd370@ustx2ex-dag1mb2.msg.corp.akamai.com> > I'm curious why the new download page lists version 1.01p before version > 1.02d? > Is it suggesting that users download the 1.01 branch instead of the later one? They're listed in time-order, not alpha order. Should perhaps fix that. From richmoore44 at gmail.com Thu Aug 20 22:07:22 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Thu, 20 Aug 2015 23:07:22 +0100 Subject: [openssl-users] [openssl-announce] Website changing this weekend In-Reply-To: References: Message-ID: On 14 August 2015 at 21:20, Salz, Rich wrote: > We?re bringing up a new website this weekend. Please be patient if you > have problems. If you notice any broken links, let us know. > > > ?Many of the changelogs have disappeared - for example try finding the changelog between 0.9.8n and 0.9.8o on https://www.openssl.org/news/changelog.html. This applies to lots of other releases too. Cheers Rich. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Aug 21 02:36:31 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 21 Aug 2015 02:36:31 +0000 Subject: [openssl-users] [openssl-announce] Website changing this weekend In-Reply-To: References: Message-ID: >Many of the changelogs have disappeared - for example try finding the changelog between 0.9.8n and 0.9.8o on https://www.openssl.org/news/changelog.html. This applies to lots of other releases too. Thanks. It seems that the 0.9.8n -> 0.9.8o changes are only in the 0.9.8 branch. We pull the changelog from master. Looks like some changelog entries didn't get carried over to there. If you come across others,post and we can maybe update master.? From viktor.s.wold.eide at gmail.com Fri Aug 21 07:58:32 2015 From: viktor.s.wold.eide at gmail.com (Viktor S. Wold Eide) Date: Fri, 21 Aug 2015 09:58:32 +0200 Subject: [openssl-users] Privacy considerations - identity hiding from eavesdropping in (D)TLS Message-ID: Hi, When using openssl to establish an authenticated DTLS 1.2 connection, certificates for both the client and the server are sent in cleartext during the handshake. From what I understand, this is a protocol issue, for example addressed in the draft: "Transport Layer Security (TLS) Encrypted Handshake Extension, draft-ray-tls-encrypted-handshake-00" (expired in 2012). Are there any recommended ways to avoid certificates being sent in cleartext? That is, to first establish an anonymous encrypted channel, and then to authenticate within the encrypted channel. I am also aware of some of the work in progress on TLS 1.3. It would be helpful to understand what is reasonable to expect from the changes introduced in (D)TLS 1.3 in this respect. Best regards Viktor S. Wold Eide -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.browder at gmail.com Fri Aug 21 11:51:55 2015 From: tom.browder at gmail.com (Tom Browder) Date: Fri, 21 Aug 2015 06:51:55 -0500 Subject: [openssl-users] FW: Website changing this weekend In-Reply-To: <891f52d2fab548409092ecb6172cd370@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <68b20d461e3844cda6918348abf00dc8@ustx2ex-dag1mb2.msg.corp.akamai.com> <891f52d2fab548409092ecb6172cd370@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: On Thu, Aug 20, 2015 at 4:54 PM, Salz, Rich wrote: > >> I'm curious why the new download page lists version 1.01p before version >> 1.02d? >> Is it suggesting that users download the 1.01 branch instead of the later one? > > They're listed in time-order, not alpha order. Should perhaps fix that. The way you name versions doesn't help, but, IMHO, you should have two listings: 1. Something like "Latest Version" (latest version only of openssl and FIPS). 2. Then something like "Other Versions" (whatever else you want to show on the page). Much less confusing to me. Best, -Tom From rsalz at akamai.com Fri Aug 21 14:07:44 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 21 Aug 2015 14:07:44 +0000 Subject: [openssl-users] Privacy considerations - identity hiding from eavesdropping in (D)TLS In-Reply-To: References: Message-ID: <64aca50605a044c89958b7792f8ab688@ustx2ex-dag1mb2.msg.corp.akamai.com> >Are there any recommended ways to avoid certificates being sent in cleartext? That is, to first establish an anonymous encrypted channel, and then to authenticate within the encrypted channel. Not without breaking the protocol. >I am also aware of some of the work in progress on TLS 1.3. It would be helpful to understand what is reasonable to expect from the changes introduced in (D)TLS 1.3 in this respect. Perhaps the tls at ietf list is a better place to discuss this. From richmoore44 at gmail.com Fri Aug 21 15:06:16 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Fri, 21 Aug 2015 16:06:16 +0100 Subject: [openssl-users] [openssl-announce] Website changing this weekend In-Reply-To: References: Message-ID: On 21 August 2015 at 03:36, Salz, Rich wrote: > > >Many of the changelogs have disappeared - for example try finding the > changelog between 0.9.8n and 0.9.8o on > https://www.openssl.org/news/changelog.html. This applies to lots of > other releases too. > > Thanks. > > It seems that the 0.9.8n -> 0.9.8o changes are only in the 0.9.8 branch. > We pull the changelog from master. Looks like some changelog entries > didn't get carried over to there. If you come across others,post and we > can maybe update master. > > ?It seems to be that when a new branch was released then none of the ?subsequent changes for older branches are available. So almost all the recent 0.9.8 changelogs, and 1.0.0 changelogs are missing. Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Aug 21 15:08:54 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 21 Aug 2015 15:08:54 +0000 Subject: [openssl-users] [openssl-announce] Website changing this weekend In-Reply-To: References: Message-ID: <7f22f89e4cf34812864f53895b867bb9@ustx2ex-dag1mb2.msg.corp.akamai.com> > It seems to be that when a new branch was released then none of the ?subsequent changes for older branches are available. So almost all the recent 0.9.8 changelogs, and 1.0.0 changelogs are missing. Yeah, we need to figure out how to fix that. I'll make sure the team sees it. From spate at hytrust.com Fri Aug 21 22:40:18 2015 From: spate at hytrust.com (Steve Pate) Date: Fri, 21 Aug 2015 22:40:18 +0000 Subject: [openssl-users] CTR_DRBG with or without a derivation function (re: FIPS 140-2) Message-ID: To quote from several places: Once you call FIPS_mode_set (and assuming it returns non-zero), you are using the NIST approved DRBGs. >From OpenSSL's Random Numbers wiki page: The default DRBG is 256-bit CTR AES using a derivation function ... To use the FIPS random number generator, simply use RAND_bytes as described earlier. Note that the call to FIPS_mode_set must succeed in order to operate in FIPS 140 mode. But if I look at the OpenSSL/FIPS security policy it lists: CTR DRBG (AES), no derivation function as being approved but there is no mention of whether CTR DRBG (AES) with a derivation function is approved or not. Thoughts? Thanks in advance, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Aug 24 02:50:12 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 24 Aug 2015 02:50:12 +0000 Subject: [openssl-users] [openssl-announce] Website changing this weekend In-Reply-To: References: Message-ID: >It seems to be that when a new branch was released then none of the ?subsequent changes for older branches are available. So almost all the recent 0.9.8 changelogs, and 1.0.0 changelogs are missing. Well, yeah, kinda. I updated the page to explain this a bit. And I also put all the branch changelogs online too From viktor.s.wold.eide at gmail.com Mon Aug 24 10:39:49 2015 From: viktor.s.wold.eide at gmail.com (Viktor S. Wold Eide) Date: Mon, 24 Aug 2015 12:39:49 +0200 Subject: [openssl-users] Privacy considerations - identity hiding from eavesdropping in (D)TLS In-Reply-To: <64aca50605a044c89958b7792f8ab688@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <64aca50605a044c89958b7792f8ab688@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: On Fri, Aug 21, 2015 at 4:07 PM, Salz, Rich wrote: > > >Are there any recommended ways to avoid certificates being sent in > cleartext? That is, to first establish an anonymous encrypted channel, and > then to authenticate within the encrypted channel. > > Not without breaking the protocol. > If interoperability with other software (clients / servers) is not an issue, are there any known configuration / tweaks / minor changes that could be used in openssl? As I understand from the "Transport Layer Security (TLS) Encrypted Handshake Extension, draft-ray-tls-encrypted-handshake-00", the defined way would be to perform an anonymous unencrypted handshake and then to renegotiate the connection, within the encrypted channel. However, it appears that renegotiation will be removed in TLS 1.3, < https://tools.ietf.org/html/draft-ietf-tls-tls13-07>. So, I am looking for a way to achieve identity hiding for DTLS 1.2, which also hopefully can be used in (D)TLS 1.3, when available. > > >I am also aware of some of the work in progress on TLS 1.3. It would be > helpful to understand what is reasonable to expect from the changes > introduced in (D)TLS 1.3 in this respect. > > Perhaps the tls at ietf list is a better place to discuss this. > Yes, I will do that, but I wanted to see what the options for (D)TLS 1.2 would be first. Thanks Viktor S. Wold Eide -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignacio.casal at nice-software.com Mon Aug 24 12:41:00 2015 From: ignacio.casal at nice-software.com (Ignacio Casal) Date: Mon, 24 Aug 2015 14:41:00 +0200 Subject: [openssl-users] Openssl backend for glib Message-ID: Hey guys, I am currently working on an openssl backend for glib and I got to a point where I am blocked and maybe you can help me understand what I am doing wrong. First of all the source code can be found here: https://github.com/nice-software/glib-networking/tree/wip/openssl The problem is the next, on one of our unit tests we require a specific authentication, meaning that I endup calling SSL_set_verify, as you can see here: https://github.com/nice-software/glib-networking/blob/wip/openssl/tls/openssl/gtlsserverconnection-openssl.c#L127 This should make the server require the client to send the certificate but for some reason this certificate is never sent and I endup having an error when handshaking. I was reading that I can just simply set the certificate callback as I do here: https://github.com/nice-software/glib-networking/blob/wip/openssl/tls/openssl/gtlsclientconnection-openssl.c#L437 This callback gets called and I set the certificate but adding some debugging on openssl's code I see I keep getting that the server does not get the certificate. Here is a extract of the printfs I added to the openssl code. Any ideas? server, accept server, get client hello: 1 server, send server hello: 1 server, send server cert: 1 server, send cert request: 1 connect1 get server hello: 1 get key exchange: 1 get cert request: 1 get server done: 1 do client cert cb: 1 do client cert cb2: 1 do client cert cb4: 1 do client cert cb do write send client cert: 1 send client key exchange: 1 send client verify: 1 change cipher spec: 1 send finished: 1 server, check client hello: 1 server, get client cert: -1 server, accept2: -1 finish not ok get finsihed: 0 connect2: 0 Cheers. -- Ignacio Casal Quinteiro -------------- next part -------------- An HTML attachment was scrubbed... URL: From dluengo at rti.com Mon Aug 24 18:33:23 2015 From: dluengo at rti.com (=?UTF-8?Q?David_Luengo_L=C3=B3pez?=) Date: Mon, 24 Aug 2015 20:33:23 +0200 Subject: [openssl-users] OPENSSL_SYS_VOS meaning Message-ID: Hello openssl-ers, Anyone knows what does OPENSSL_SYS_VOS macro means? I'm building OpenSSL (1.0.1l) for Vxworks and I when I ran some tests I got some errors while generating a new session ID because it seems it is running out of entropy in the entropy pool. I've been looking into the code and I have observed that, in the end, my entropy pool is being filled by calling the ssleay_rand_add() function in file crypto/rand/md_rand.c: 435 #if MD_DIGEST_LENGTH > 20 436 # error "Please adjust DUMMY_SEED." 437 #endif 438 439 #define DUMMY_SEED "...................." /* at least MD_DIGEST_LENGTH */ 440 /* Note that the seed does not matter, it's just that 441 * ssleay_rand_add expects to have something to hash. */ *442 ssleay_rand_add(DUMMY_SEED, MD_DIGEST_LENGTH, 0.0);* I don't know why the 0.0 parameter, since we are not adding anything here I never get more entropy in the pool. Any explanation for this 0.0? I realized then the RAND_poll() function in the crypto/rand/rand_unix.c file: 426 #if defined(OPENSSL_SYS_VXWORKS) 427 int RAND_poll(void) 428 { 429 return 0; 430 } 431 #endif I'm confused about this, but I also realized that, surrounded by #if defined(OPENSSL_SYS_VOS) there is a nice implementation of the RAND_poll(), so I built my library using it and now it seems to work. So, going back to the main question, does anybody knows what is the OPENSSL_SYS_VOS and for what is it used? And for some extra points, why that RAND_poll for vxworks... I'll keep investigating in all this. Thank you in advance, Best regards, -- [image: RTI] *David Luengo L?pez* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 2461 bytes Desc: not available URL: From wiml at omnigroup.com Mon Aug 24 20:34:08 2015 From: wiml at omnigroup.com (Wim Lewis) Date: Mon, 24 Aug 2015 13:34:08 -0700 Subject: [openssl-users] OPENSSL_SYS_VOS meaning In-Reply-To: References: Message-ID: <740A3D59-D503-4C80-87FB-5568CA11D60B@omnigroup.com> On Aug 24, 2015, at 11:33 AM, David Luengo L?pez wrote: > 439 #define DUMMY_SEED "...................." /* at least MD_DIGEST_LENGTH */ > 440 /* Note that the seed does not matter, it's just that > 441 * ssleay_rand_add expects to have something to hash. */ > 442 ssleay_rand_add(DUMMY_SEED, MD_DIGEST_LENGTH, 0.0); > > I don't know why the 0.0 parameter, since we are not adding anything here I never get more entropy in the pool. Any explanation for this 0.0? Because there is actually no entropy in DUMMY_SEED --- it's a constant. This piece of code is "stirring" the pool; it doesn't increase the amount of entropy (unpredictability) in the pool, it just makes sure that all the bits of the pool are equally unpredictable. Actual entropy must be added by some other piece of code. > Anyone knows what does OPENSSL_SYS_VOS macro means? The notes from the patch from Paul Green adding randomness support for VOS might have useful information for you: https://rt.openssl.org/Ticket/Display.html?id=2563&user=guest&pass=guest (I do not know enough about VxWorks or VOS to say whether defining OPENSSL_SYS_VOS safely solves your problem, though it seems plausible) From rsalz at akamai.com Mon Aug 24 21:55:31 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 24 Aug 2015 21:55:31 +0000 Subject: [openssl-users] [openssl-dev] FW: Website changing this weekend In-Reply-To: References: <68b20d461e3844cda6918348abf00dc8@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: > From the https://www.openssl.org/docs/manmaster/crypto/crypto.html > page > > - the links to x509v3, asn1, stack and txt_db are broken. Yes, cross-refs within the manpages are still often broke. We're working on that. > - it's unclear what "INTERNAL FUNCTIONS" means. UTILITY is a better word, I'll change that. > - The ec link is under internal functions. A more obvious place would be > under PUBLIC KEY CRYPTOGRAPHY AND KEY AGREEMENT. Yup, we'll fix. > It wold be nice to document the AES API: Moving forward, the EVP API is the only real public interface we want to expose. From dluengo at rti.com Tue Aug 25 09:52:14 2015 From: dluengo at rti.com (=?UTF-8?Q?David_Luengo_L=C3=B3pez?=) Date: Tue, 25 Aug 2015 11:52:14 +0200 Subject: [openssl-users] OPENSSL_SYS_VOS meaning In-Reply-To: <740A3D59-D503-4C80-87FB-5568CA11D60B@omnigroup.com> References: <740A3D59-D503-4C80-87FB-5568CA11D60B@omnigroup.com> Message-ID: Thank you Wim, I'll take a look to the notes you linked. And talking about the entropy pool, do you know where in the code is the entropy pool filled with more entropy? I'm doing some searches looking for /dev/u?random (I still need to invest more time on this though), but it would be great if you can put me on the way. Thank you, Best regards, On Mon, Aug 24, 2015 at 10:34 PM, Wim Lewis wrote: > On Aug 24, 2015, at 11:33 AM, David Luengo L?pez wrote: > > 439 #define DUMMY_SEED "...................." /* at least > MD_DIGEST_LENGTH */ > > 440 /* Note that the seed does not matter, it's just that > > 441 * ssleay_rand_add expects to have something to hash. */ > > 442 ssleay_rand_add(DUMMY_SEED, MD_DIGEST_LENGTH, 0.0); > > > > I don't know why the 0.0 parameter, since we are not adding anything > here I never get more entropy in the pool. Any explanation for this 0.0? > > Because there is actually no entropy in DUMMY_SEED --- it's a constant. > This piece of code is "stirring" the pool; it doesn't increase the amount > of entropy (unpredictability) in the pool, it just makes sure that all the > bits of the pool are equally unpredictable. Actual entropy must be added by > some other piece of code. > > > Anyone knows what does OPENSSL_SYS_VOS macro means? > > The notes from the patch from Paul Green adding randomness support for VOS > might have useful information for you: > > https://rt.openssl.org/Ticket/Display.html?id=2563&user=guest&pass=guest > > (I do not know enough about VxWorks or VOS to say whether defining > OPENSSL_SYS_VOS safely solves your problem, though it seems plausible) > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- [image: RTI] *David Luengo L?pez* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 2461 bytes Desc: not available URL: From ignacio.casal at nice-software.com Tue Aug 25 09:53:48 2015 From: ignacio.casal at nice-software.com (Ignacio Casal) Date: Tue, 25 Aug 2015 11:53:48 +0200 Subject: [openssl-users] Openssl backend for glib In-Reply-To: References: Message-ID: So I made a bit more research on this issue. The certificate seems to be loaded and sent to the server. But then the server fails to verify that certificate since it does not have the ca-list that was loaded for the client. The error that I get server side is X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY. Any idea how to deal with this issue? Should I try to skip this kind of verification server side? Regards On Mon, Aug 24, 2015 at 2:41 PM, Ignacio Casal < ignacio.casal at nice-software.com> wrote: > Hey guys, > > I am currently working on an openssl backend for glib and I got to a point > where I am blocked and maybe you can help me understand what I am doing > wrong. > > First of all the source code can be found here: > https://github.com/nice-software/glib-networking/tree/wip/openssl > > The problem is the next, on one of our unit tests we require a specific > authentication, meaning that I endup calling SSL_set_verify, as you can see > here: > https://github.com/nice-software/glib-networking/blob/wip/openssl/tls/openssl/gtlsserverconnection-openssl.c#L127 > > This should make the server require the client to send the certificate but > for some reason this certificate is never sent and I endup having an error > when handshaking. > > I was reading that I can just simply set the certificate callback as I do > here: > https://github.com/nice-software/glib-networking/blob/wip/openssl/tls/openssl/gtlsclientconnection-openssl.c#L437 > > This callback gets called and I set the certificate but adding some > debugging on openssl's code I see I keep getting that the server does not > get the certificate. > > Here is a extract of the printfs I added to the openssl code. Any ideas? > > server, accept > server, get client hello: 1 > server, send server hello: 1 > server, send server cert: 1 > server, send cert request: 1 > connect1 > get server hello: 1 > get key exchange: 1 > get cert request: 1 > get server done: 1 > do client cert cb: 1 > do client cert cb2: 1 > do client cert cb4: 1 > do client cert cb do write > send client cert: 1 > send client key exchange: 1 > send client verify: 1 > change cipher spec: 1 > send finished: 1 > server, check client hello: 1 > server, get client cert: -1 > server, accept2: -1 > finish not ok > get finsihed: 0 > connect2: 0 > > > Cheers. > > > -- > Ignacio Casal Quinteiro > -- Ignacio Casal Quinteiro -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Aug 25 21:40:16 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 25 Aug 2015 21:40:16 +0000 Subject: [openssl-users] [openssl-dev] FW: Website changing this weekend In-Reply-To: References: <68b20d461e3844cda6918348abf00dc8@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <1515cbd9c0c14befa7e94a42fd431a81@ustx2ex-dag1mb2.msg.corp.akamai.com> > > Yes, cross-refs within the manpages are still often broke. We're working on > that. Thanks to the generous help of Phil Pearl, the links within the manpages are fixed! From Matthias.St.Pierre at ncp-e.com Wed Aug 26 15:14:22 2015 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 26 Aug 2015 17:14:22 +0200 Subject: [openssl-users] FIPS_drbg_*() are not exported from FIPS capable libeay32.dll on Windows (OpenSSL 1.0.2x and 1.0.1x) Message-ID: <55DDD7CE.5080007@ncp-e.com> Dear Mr. Henson, I noticed that for OpenSSL 1.0.2x and 1.0.1x on Windows the FIPS capable libeay32.dll does not export any of the FIPS_drbg_*() functions, although they are officially documented by the OpenSSL FIPS 2.0 User Guide. Is this an oversight or was this done on purpose? (IOW, is it a bug or a feature? ;-) I checked the git repository and found out that the symbols are listed in util/libeay.num on the master branch but are missing on the OpenSSL_1_0_2-stable and OpenSSL_1_0_1-stable branch (see [1]). In fact, the entire log of the OpenSSL_1_0_{1,2}-stable branch shows no indication that these symbols were ever added to or removed from libeay.num (see [2]). This is strange, because the symbols were initially added by you in the following commit, where you state that symbol ordinals are in sync with the 1.0.1 stable branch. commit 7bd4095b127f7376bafd9010c45673c7d354fe81 Author: Dr. Stephen Henson Date: Sun Oct 9 15:29:43 2011 +0000 Sync ordinals with 1.0.1-stable. It would be nice if you could be so kind to shed some light on this to clear up my confusion. Best regards, MSP [1] ~/src/openssl$ git checkout master Switched to branch 'master' Your branch is up-to-date with 'origin/master'. ~/src/openssl$ grep FIPS_drbg_ util/libeay.num FIPS_drbg_set_check_interval 4808 NOEXIST::FUNCTION: FIPS_drbg_set_callbacks 4811 NOEXIST::FUNCTION: FIPS_drbg_free 4812 NOEXIST::FUNCTION: FIPS_drbg_get_strength 4813 NOEXIST::FUNCTION: FIPS_drbg_set_reseed_interval 4814 NOEXIST::FUNCTION: (...) ~/src/openssl$ git checkout OpenSSL_1_0_2-stable Switched to branch 'OpenSSL_1_0_2-stable' Your branch is up-to-date with 'origin/OpenSSL_1_0_2-stable'. ~/src/openssl$ grep FIPS_drbg_ util/libeay.num [2] ~/src/openssl$ git log -p OpenSSL_1_0_2-stable -- util/libeay.num | grep FIPS_drbg_ ~/src/openssl$ git log -p OpenSSL_1_0_1-stable -- util/libeay.num | grep FIPS_drbg_ msp at msppc:~/src/openssl$ git log -p master -- util/libeay.num | grep FIPS_drbg_ FIPS_drbg_set_check_interval 4808 NOEXIST::FUNCTION: FIPS_drbg_get_app_data 4870 NOEXIST::FUNCTION: FIPS_drbg_get_app_data 4870 NOEXIST::FUNCTION: FIPS_drbg_set_check_interval 4808 NOEXIST::FUNCTION: -FIPS_drbg_set_check_interval 4685 EXIST:OPENSSL_FIPS:FUNCTION: -FIPS_drbg_set_rand_callbacks 4687 EXIST:OPENSSL_FIPS:FUNCTION: From vikas.tm at gmail.com Fri Aug 28 08:05:35 2015 From: vikas.tm at gmail.com (Vikas TM) Date: Fri, 28 Aug 2015 13:35:35 +0530 Subject: [openssl-users] RSA silently downgraded to EXPORT_RSA [client] Message-ID: Hi All, I have following two queries, 1. When I specify option -cipher EXPORT in the s_client command, it says connected and cipher changed new cipher EXP-EDH-RSA-DES-CBC-SHA. If I am not requesting -cipher of EXPORT type then it returns DHE-RSA-AES256-SHA Here, when I request cipher of type EXPORT, then new cipher EXP-EDH-RSA-DES-CBC-SHA accepted by client. It means my openSSL is Vulnerable? 2. From many post I have understood that if webserver uses vulnerable openSSL version (0.9.x version previous of 0.9.8zd) for https service, they are vulnerable to Middle Man Attack. Here, if FTP server uses vulnerble openSSL version (0.9.x version previous of 0.9.8zd), is FTP over openSSL service also vulnerable to Middle Man Attack? Please let me know the answer for queries. It will be helpful for me to understand this threat. Thank you, Vikas -------------- next part -------------- An HTML attachment was scrubbed... URL: From vikas.tm at gmail.com Fri Aug 28 07:36:25 2015 From: vikas.tm at gmail.com (Vikas) Date: Fri, 28 Aug 2015 00:36:25 -0700 (MST) Subject: [openssl-users] RSA silently downgrades to EXPORT_RSA [Client] In-Reply-To: <1440596612219-59835.post@n7.nabble.com> References: <1440596612219-59835.post@n7.nabble.com> Message-ID: <1440747385917-59854.post@n7.nabble.com> Hi All, Can you please someone answer for my queries. Thanks & Regards, Vikas -- View this message in context: http://openssl.6102.n7.nabble.com/RSA-silently-downgrades-to-EXPORT-RSA-Client-tp59835p59854.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From John.Unsworth at owmessaging.com Fri Aug 28 15:50:07 2015 From: John.Unsworth at owmessaging.com (John Unsworth) Date: Fri, 28 Aug 2015 15:50:07 +0000 Subject: [openssl-users] [openssl.org #3804] AutoReply: BUG: OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: Message-ID: I have now successfully built and tested 1.0.2c on Solaris 10 with gcc 4.7.2 from unixpackages.com. ./Configure solaris-sparcv9-gcc no-shared -m32 -fPIC -fvisibility=hidden ./Configure solaris64-sparcv9-gcc no-shared -m64 -fPIC -fvisibility=hidden Looks like Solaris Studio is buggy. This bug should be closed. From rt at openssl.org Fri Aug 28 16:23:43 2015 From: rt at openssl.org (John Unsworth via RT) Date: Fri, 28 Aug 2015 16:23:43 +0000 Subject: [openssl-users] [openssl.org #3804] AutoReply: BUG: OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: Message-ID: I have now successfully built and tested 1.0.2c on Solaris 10 with gcc 4.7.2 from unixpackages.com. ./Configure solaris-sparcv9-gcc no-shared -m32 -fPIC -fvisibility=hidden ./Configure solaris64-sparcv9-gcc no-shared -m64 -fPIC -fvisibility=hidden Looks like Solaris Studio is buggy. This bug should be closed. From rt at openssl.org Fri Aug 28 16:37:22 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 28 Aug 2015 16:37:22 +0000 Subject: [openssl-users] [openssl.org #3804] BUG: OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: Message-ID: apparently a Sun library bug, closing this report as requested by the original poster. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From director at openca.org Sat Aug 29 22:56:33 2015 From: director at openca.org (Massimiliano Pala) Date: Sat, 29 Aug 2015 18:56:33 -0400 Subject: [openssl-users] ASN.1: Parsing a 'private' class Message-ID: <55E238A1.1010001@openca.org> Hi all, I am trying to parse a sequence that has, after an integer, a 'private' (xclass) item. I was wondering what is the right templates / macros to be able to generate the ASN1 functions with the usual macro. An example of the structure I have to parse (B64 - DER), is the following: MGICAQOAFGZKq8/wIYS7Iueq6NuaC3ESPqUKMAkGBSsOAwIaBQAwCwYHKoZIzjgEAQUABC8wLQIVAJTJ6W2QjBIbVQdAtLbPO3y1wazHAhRsXivNO/Eg4GMEgcmEx8OgsIxGzQ== [ you can paste it into http://www.lapo.it/asn1js/ to get useful info. ] The field that is giving me issues is the 2nd field in the sequence - offest 5, length 20 (i.e., after SEQUENCE (2 bytes) + INTEGER (3 bytes) and then the 20bytes field that I want to parse). The type is 0x80 - context specific. By using the ASN1_get_object() function, I get the correct size (20), the tag (0), and the xclass (128). Now, how do I go in order to generate the useful ASN1 function with teh usual macros ? Here's an example (besides the second field) for what I am trying to do: ASN1_SEQUENCE(TYPE) = { ASN1_SIMPLE(TYPE, field1, ASN1_INTEGER), XXXXXXX(TYPE, field2, YYYYY), <<-- What shall be used here ? What Macro ? ASN1_SEQUENCE_OF(TYPE, field3, ASN1_OBJECT), ASN1_SEQUENCE_OF(TYPE, field3, ASN1_OBJECT), ASN1_SIMPLE(TYPE, field3, ASN1_OCTET_STRING) <<-- This might be wrong as well - just noticed it is a very } ASN1_SEQUENCE_END(TYPE) weird encoding (octet-string that encapsulates a sequence of integers) Is there a way to have the macros do the work (e.g., shall I use other macros - template? - to define the field somehow) ? Or shall I just write my own d2i_ and i2d_ functions ? Please let me know, Cheers, Max From director at openca.org Mon Aug 31 23:10:41 2015 From: director at openca.org (Massimiliano Pala) Date: Mon, 31 Aug 2015 19:10:41 -0400 Subject: [openssl-users] ASN.1: Parsing a 'private' class In-Reply-To: <55E238A1.1010001@openca.org> References: <55E238A1.1010001@openca.org> Message-ID: <55E4DEF1.7080302@openca.org> Hi all, I actually figured it out, if anybody is curious about the solution for parsing this CRYPTLIB signature envelope (in this case DSA) - write to me directly, I will be happy to share the solution. Cheers, Max On 8/29/15 6:56 PM, Massimiliano Pala wrote: > Hi all, > > I am trying to parse a sequence that has, after an integer, a > 'private' (xclass) item. I was wondering what is the right templates / > macros to be able to generate the ASN1 functions with the usual macro. > An example of the structure I have to parse (B64 - DER), is the > following: > > MGICAQOAFGZKq8/wIYS7Iueq6NuaC3ESPqUKMAkGBSsOAwIaBQAwCwYHKoZIzjgEAQUABC8wLQIVAJTJ6W2QjBIbVQdAtLbPO3y1wazHAhRsXivNO/Eg4GMEgcmEx8OgsIxGzQ== > > > [ you can paste it into http://www.lapo.it/asn1js/ to get useful info. ] > > The field that is giving me issues is the 2nd field in the sequence - > offest 5, length 20 (i.e., after SEQUENCE (2 bytes) + INTEGER (3 > bytes) and then the 20bytes field that I want to parse). The type is > 0x80 - context specific. By using the ASN1_get_object() function, I > get the correct size (20), the tag (0), and the xclass (128). Now, how > do I go in order to generate the useful ASN1 function with teh usual > macros ? Here's an example (besides the second field) for what I am > trying to do: > > ASN1_SEQUENCE(TYPE) = { > > ASN1_SIMPLE(TYPE, field1, ASN1_INTEGER), > > XXXXXXX(TYPE, field2, YYYYY), <<-- What shall > be used here ? What Macro ? > > ASN1_SEQUENCE_OF(TYPE, field3, ASN1_OBJECT), > > ASN1_SEQUENCE_OF(TYPE, field3, ASN1_OBJECT), > > ASN1_SIMPLE(TYPE, field3, ASN1_OCTET_STRING) <<-- This might > be wrong as well - just noticed it is a very > > } ASN1_SEQUENCE_END(TYPE) weird > encoding (octet-string that encapsulates a sequence of integers) > > > Is there a way to have the macros do the work (e.g., shall I use other > macros - template? - to define the field somehow) ? Or shall I just > write my own d2i_ and i2d_ functions ? > > Please let me know, > > Cheers, > Max > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users