From sampei02 at tiscali.it Sat Jun 2 05:39:35 2018 From: sampei02 at tiscali.it (sampei02 at tiscali.it) Date: Sat, 2 Jun 2018 07:39:35 +0200 Subject: [openssl-users] database openssl In-Reply-To: <7e821a16-2219-4e48-f9fc-e691c81f6cca@nikhef.nl> References: <1283ec38-fefc-a8ce-845d-b79b79952cdc@nikhef.nl> <7e821a16-2219-4e48-f9fc-e691c81f6cca@nikhef.nl> Message-ID: <320E1FC3-AA47-456B-9C1B-9930992C9B40@tiscali.it> I think It?s installed 2 version OpenSSL; the former by rpm package while the latter by source tar infact I see following files into /usr/local/openssl-0.9.7e : drwxr-xr-x 21 root root 4096 Feb 4 2005 . drwxr-xr-x 19 root root 4096 Jan 20 2011 .. drwxr-xr-x 4 root root 4096 May 31 11:51 apps drwxr-xr-x 2 root root 4096 Oct 25 2004 bugs drwxr-xr-x 3 root root 4096 Oct 25 2004 certs -rw-rw-r-- 1 root root 287307 Oct 25 2004 CHANGES -rw-rw-r-- 1 root root 42751 Dec 23 1998 CHANGES.SSLeay -rw-rw-r-- 1 root root 27 Sep 30 2003 comms.txt -rw-rw-r-- 1 root root 17 Sep 30 2003 comm.txt -rwxrwxr-x 1 root root 23980 Jun 29 2004 config -rwxrwxr-x 1 root root 83455 Oct 1 2004 Configure drwxr-xr-x 46 root root 4096 Feb 4 2005 crypto drwxr-xr-x 15 root root 4096 Oct 25 2004 demos -rw-rw-r-- 1 root root 3058 Sep 30 2003 diffs.6 -rw-rw-r-- 1 root root 4930 Sep 30 2003 diffs.6e -rw-rw-r-- 1 root root 6721 Sep 30 2003 diffs.6x -rw-rw-r-- 1 root root 4868 Sep 30 2003 diffs.7 -rw-rw-r-- 1 root root 4948 Sep 30 2003 diffs.sec -rw-rw-r-- 1 root root 1814 Sep 30 2003 diffs.sec6 -rw-rw-r-- 1 root root 1898 Sep 30 2003 diffs.sec6e -rw-rw-r-- 1 root root 3627 Sep 30 2003 diffs.sec7 -rw-rw-r-- 1 root root 5080 Sep 30 2003 diffs.secfix drwxr-xr-x 6 root root 4096 Oct 25 2004 doc -rw-rw-r-- 1 root root 456 Sep 30 2003 do_patch.sh -rw-rw-r-- 1 root root 9539 Oct 20 2004 e_os2.h -rw-rw-r-- 1 root root 17254 May 14 2004 e_os.h -rw-rw-r-- 1 root root 35375 Oct 25 2004 FAQ drwxr-xr-x 9 root root 4096 Oct 25 2004 fips drwxr-xr-x 3 root root 4096 Oct 25 2004 include -rw-rw-r-- 1 root root 13301 May 11 2004 INSTALL -rw-rw-r-- 1 root root 2757 May 27 2004 install.com -rw-rw-r-- 1 root root 1527 Dec 4 2002 INSTALL.DJGPP -rw-rw-r-- 1 root root 3264 Oct 1 2001 INSTALL.MacOS -rw-rw-r-- 1 root root 744 Jul 17 2002 INSTALL.OS2 -rw-rw-r-- 1 root root 11363 Sep 7 2001 INSTALL.VMS -rw-rw-r-- 1 root root 10134 May 11 2004 INSTALL.W32 -rw-rw-r-- 1 root root 2409 Dec 3 2002 INSTALL.WCE -rw-rw-r-- 1 root root 6279 Mar 17 2004 LICENSE drwxr-xr-x 3 root root 4096 Oct 25 2004 MacOS -rw-r--r-- 1 root root 34102 Feb 4 2005 Makefile -rw-r--r-- 1 root root 34081 Feb 4 2005 Makefile.bak -rw-rw-r-- 1 root root 33715 Sep 28 2004 Makefile.org -rwxrwxr-x 1 root root 26776 Aug 9 2004 makevms.com drwxr-xr-x 2 root root 4096 Oct 25 2004 ms -rw-rw-r-- 1 root root 13986 Oct 20 2004 NEWS -rw-rw-r-- 1 root root 183560 Oct 25 2004 op -rw-rw-r-- 1 root root 137 Feb 28 1999 openssl.doxy -rw-rw-r-- 1 root root 7858 Oct 25 2004 openssl.spec drwxr-xr-x 2 root root 4096 Oct 25 2004 os2 drwxr-xr-x 2 root root 4096 Oct 25 2004 perl -rw-rw-r-- 1 root root 5424 May 11 2004 PROBLEMS -rw-rw-r-- 1 root root 7910 Oct 25 2004 README -rw-rw-r-- 1 root root 7699 Dec 8 2000 README.ASN1 -rw-rw-r-- 1 root root 16100 Jul 8 2002 README.ENGINE drwxr-xr-x 2 root root 4096 Oct 25 2004 shlib drwxr-xr-x 2 root root 4096 Oct 25 2004 ssl drwxr-xr-x 2 root root 4096 May 31 11:39 test drwxr-xr-x 5 root root 4096 Oct 25 2004 times drwxr-xr-x 2 root root 4096 Feb 4 2005 tools drwxr-xr-x 3 root root 4096 Oct 25 2004 util drwxr-xr-x 2 root root 4096 Oct 25 2004 VMS I can see Makefile, config, ? which make to think to source files to compile. If 2 ways have been used to install Openssl, what files .cnf I have to copy new system to keep every existing database? I know system Administrators created come test certificates several times. Here my cnf files list : /usr/local/openssl-0.9.7e/apps/oid.cnf /usr/local/openssl-0.9.7e/apps/oid.cnf /usr/local/openssl-0.9.7e/apps/openssl.cnf /usr/local/openssl-0.9.7e/apps/openssl.cnf /usr/local/openssl-0.9.7e/apps/openssl-vms.cnf /usr/local/openssl-0.9.7e/apps/openssl-vms.cnf /usr/local/openssl-0.9.7e/crypto/conf/ssleay.cnf /usr/local/openssl-0.9.7e/crypto/conf/ssleay.cnf /usr/local/openssl-0.9.7e/test/CAss.cnf /usr/local/openssl-0.9.7e/test/CAss.cnf /usr/local/openssl-0.9.7e/test/CAssdh.cnf /usr/local/openssl-0.9.7e/test/CAssdh.cnf /usr/local/openssl-0.9.7e/test/CAssdsa.cnf /usr/local/openssl-0.9.7e/test/CAssdsa.cnf /usr/local/openssl-0.9.7e/test/CAssrsa.cnf /usr/local/openssl-0.9.7e/test/CAssrsa.cnf /usr/local/openssl-0.9.7e/test/Sssdsa.cnf /usr/local/openssl-0.9.7e/test/Sssdsa.cnf /usr/local/openssl-0.9.7e/test/Sssrsa.cnf /usr/local/openssl-0.9.7e/test/Sssrsa.cnf /usr/local/openssl-0.9.7e/test/test.cnf /usr/local/openssl-0.9.7e/test/test.cnf /usr/local/openssl-0.9.7e/test/Uss.cnf /usr/local/openssl-0.9.7e/test/Uss.cnf /usr/share/ssl/openssl.cnf /usr/share/ssl/openssl.cnf thanks > On 31 May 2018, at 17:40, Jan Just Keijser wrote: > > Hi, > > On 31/05/18 13:23, Sampei wrote: >> Oh, It's a good starter point. >> Openssl, installed in old server, is 0.9.7e version. > smells like RHEL 3 ?!?!?!? >> Openssl, installed in new server, is -0.9.8e verson. > smells like RHEL 5, which is out of support; you should upgrade to RHEL or CentOS 6 (which lasts until 2020) or preferably 7 >> In old server I searched .cnf files and I found several files which are /usr/local/openssl-0.9.7e/xxx/yyyyy.cnf >> where >> xxx= is directory, >> yyyy = name of .cnf file >> I queried to /var/cache/yum/updates-released/packages/openssl-0.9.7a-33.10.i686.rpm in old server, I got: >> /lib/libcrypto.so.0.9.7a >> /lib/libssl.so.0.9.7a >> /usr/bin/openssl >> /usr/share/doc/openssl-0.9.7a >> /usr/share/doc/openssl-0.9.7a/CHANGES >> /usr/share/doc/openssl-0.9.7a/FAQ >> /usr/share/doc/openssl-0.9.7a/INSTALL >> /usr/share/doc/openssl-0.9.7a/LICENSE >> /usr/share/doc/openssl-0.9.7a/NEWS >> /usr/share/doc/openssl-0.9.7a/README >> /usr/share/doc/openssl-0.9.7a/c-indentation.el >> /usr/share/doc/openssl-0.9.7a/openssl.txt >> /usr/share/doc/openssl-0.9.7a/openssl_button.gif >> /usr/share/doc/openssl-0.9.7a/openssl_button.html >> /usr/share/doc/openssl-0.9.7a/ssleay.txt >> /usr/share/man/man1/asn1parse.1ssl.gz >> /usr/share/man/man1/ca.1ssl.gz >> /usr/share/man/man1/ciphers.1ssl.gz >> /usr/share/man/man1/crl.1ssl.gz >> /usr/share/man/man1/crl2pkcs7.1ssl.gz >> /usr/share/man/man1/dgst.1ssl.gz >> /usr/share/man/man1/dhparam.1ssl.gz >> /usr/share/man/man1/dsa.1ssl.gz >> /usr/share/man/man1/dsaparam.1ssl.gz >> /usr/share/man/man1/enc.1ssl.gz >> /usr/share/man/man1/gendsa.1ssl.gz >> /usr/share/man/man1/genrsa.1ssl.gz >> /usr/share/man/man1/md2.1ssl.gz >> /usr/share/man/man1/md4.1ssl.gz >> /usr/share/man/man1/md5.1ssl.gz >> /usr/share/man/man1/mdc2.1ssl.gz >> /usr/share/man/man1/nseq.1ssl.gz >> /usr/share/man/man1/ocsp.1ssl.gz >> /usr/share/man/man1/openssl.1ssl.gz >> /usr/share/man/man1/pkcs12.1ssl.gz >> /usr/share/man/man1/pkcs7.1ssl.gz >> /usr/share/man/man1/pkcs8.1ssl.gz >> /usr/share/man/man1/req.1ssl.gz >> /usr/share/man/man1/ripemd160.1ssl.gz >> /usr/share/man/man1/rsa.1ssl.gz >> /usr/share/man/man1/rsautl.1ssl.gz >> /usr/share/man/man1/s_client.1ssl.gz >> /usr/share/man/man1/s_server.1ssl.gz >> /usr/share/man/man1/sess_id.1ssl.gz >> /usr/share/man/man1/sha.1ssl.gz >> /usr/share/man/man1/sha1.1ssl.gz >> /usr/share/man/man1/smime.1ssl.gz >> /usr/share/man/man1/speed.1ssl.gz >> /usr/share/man/man1/spkac.1ssl.gz >> /usr/share/man/man1/sslpasswd.1ssl.gz >> /usr/share/man/man1/sslrand.1ssl.gz >> /usr/share/man/man1/verify.1ssl.gz >> /usr/share/man/man1/version.1ssl.gz >> /usr/share/man/man1/x509.1ssl.gz >> /usr/share/man/man5/config.5ssl.gz >> /usr/share/man/man7/DES.7ssl.gz >> /usr/share/man/man7/Modes.7ssl.gz >> /usr/share/man/man7/des_modes.7ssl.gz >> /usr/share/man/man7/of.7ssl.gz > > ****** >> /usr/share/ssl >> /usr/share/ssl/CA >> /usr/share/ssl/CA/private >> /usr/share/ssl/cert.pem >> /usr/share/ssl/certs >> /usr/share/ssl/certs/Makefile >> /usr/share/ssl/certs/ca-bundle.crt >> /usr/share/ssl/certs/make-dummy-cert >> /usr/share/ssl/lib >> /usr/share/ssl/misc >> /usr/share/ssl/misc/CA >> /usr/share/ssl/misc/c_hash >> /usr/share/ssl/misc/c_info >> /usr/share/ssl/misc/c_issuer >> /usr/share/ssl/misc/c_name >> /usr/share/ssl/openssl.cnf >> /usr/share/ssl/private > ******* > that's the location to look for the openssl.cnf file and thus the old files; simply do a > find /usr/share/ssl -mtime -200 > to find any recent files - that should point you in the right direction. > > > HTH, > > JJK > From levitte at openssl.org Sat Jun 2 06:53:17 2018 From: levitte at openssl.org (Richard Levitte) Date: Sat, 02 Jun 2018 08:53:17 +0200 (CEST) Subject: [openssl-users] database openssl In-Reply-To: <320E1FC3-AA47-456B-9C1B-9930992C9B40@tiscali.it> References: <7e821a16-2219-4e48-f9fc-e691c81f6cca@nikhef.nl> <320E1FC3-AA47-456B-9C1B-9930992C9B40@tiscali.it> Message-ID: <20180602.085317.626941122186777422.levitte@openssl.org> In message <320E1FC3-AA47-456B-9C1B-9930992C9B40 at tiscali.it> on Sat, 2 Jun 2018 07:39:35 +0200, "sampei02 at tiscali.it" said: sampei02> I think It?s installed 2 version OpenSSL; the former by rpm package while the latter by source tar infact I see following files into /usr/local/openssl-0.9.7e : sampei02> sampei02> drwxr-xr-x 21 root root 4096 Feb 4 2005 . sampei02> drwxr-xr-x 19 root root 4096 Jan 20 2011 .. sampei02> drwxr-xr-x 4 root root 4096 May 31 11:51 apps sampei02> drwxr-xr-x 2 root root 4096 Oct 25 2004 bugs sampei02> drwxr-xr-x 3 root root 4096 Oct 25 2004 certs sampei02> -rw-rw-r-- 1 root root 287307 Oct 25 2004 CHANGES sampei02> -rw-rw-r-- 1 root root 42751 Dec 23 1998 CHANGES.SSLeay ... This is not an *installation* per se, it's a source tree. As far as I can see from your listing, that's all it is, it hasn't even been built (or you would see a libcrypto.a and a libssl.a) In all likelyhood, you can ignore this directory tree, entirely. sampei02> Here my cnf files list : sampei02> sampei02> /usr/local/openssl-0.9.7e/apps/oid.cnf sampei02> /usr/local/openssl-0.9.7e/apps/openssl.cnf sampei02> /usr/local/openssl-0.9.7e/apps/openssl-vms.cnf sampei02> /usr/local/openssl-0.9.7e/crypto/conf/ssleay.cnf sampei02> /usr/local/openssl-0.9.7e/test/CAss.cnf sampei02> /usr/local/openssl-0.9.7e/test/CAssdh.cnf sampei02> /usr/local/openssl-0.9.7e/test/CAssdsa.cnf sampei02> /usr/local/openssl-0.9.7e/test/CAssrsa.cnf sampei02> /usr/local/openssl-0.9.7e/test/Sssdsa.cnf sampei02> /usr/local/openssl-0.9.7e/test/Sssrsa.cnf sampei02> /usr/local/openssl-0.9.7e/test/test.cnf sampei02> /usr/local/openssl-0.9.7e/test/Uss.cnf The above are standard distribution configuration files, most of them used for testing. Unless you can see that they are modified (i.e. have been updated after Feb 4 2005, which is when /usr/local/openssl-0.9.7e was created), you can ignore them. sampei02> /usr/share/ssl/openssl.cnf This one is part of your installation and is the most likely to represent your database. You might want to look if you have a index.txt somewhere within /usr/share/ssl. That's the index file for your cert database. If you don't have one, or if it's empty (it's a text file, you can display it), then you have no database on that machine. Cheers, Richard sampei02> sampei02> thanks sampei02> sampei02> sampei02> sampei02> sampei02> sampei02> > On 31 May 2018, at 17:40, Jan Just Keijser wrote: sampei02> > sampei02> > Hi, sampei02> > sampei02> > On 31/05/18 13:23, Sampei wrote: sampei02> >> Oh, It's a good starter point. sampei02> >> Openssl, installed in old server, is 0.9.7e version. sampei02> > smells like RHEL 3 ?!?!?!? sampei02> >> Openssl, installed in new server, is -0.9.8e verson. sampei02> > smells like RHEL 5, which is out of support; you should upgrade to RHEL or CentOS 6 (which lasts until 2020) or preferably 7 sampei02> >> In old server I searched .cnf files and I found several files which are /usr/local/openssl-0.9.7e/xxx/yyyyy.cnf sampei02> >> where sampei02> >> xxx= is directory, sampei02> >> yyyy = name of .cnf file sampei02> >> I queried to /var/cache/yum/updates-released/packages/openssl-0.9.7a-33.10.i686.rpm in old server, I got: sampei02> >> /lib/libcrypto.so.0.9.7a sampei02> >> /lib/libssl.so.0.9.7a sampei02> >> /usr/bin/openssl sampei02> >> /usr/share/doc/openssl-0.9.7a sampei02> >> /usr/share/doc/openssl-0.9.7a/CHANGES sampei02> >> /usr/share/doc/openssl-0.9.7a/FAQ sampei02> >> /usr/share/doc/openssl-0.9.7a/INSTALL sampei02> >> /usr/share/doc/openssl-0.9.7a/LICENSE sampei02> >> /usr/share/doc/openssl-0.9.7a/NEWS sampei02> >> /usr/share/doc/openssl-0.9.7a/README sampei02> >> /usr/share/doc/openssl-0.9.7a/c-indentation.el sampei02> >> /usr/share/doc/openssl-0.9.7a/openssl.txt sampei02> >> /usr/share/doc/openssl-0.9.7a/openssl_button.gif sampei02> >> /usr/share/doc/openssl-0.9.7a/openssl_button.html sampei02> >> /usr/share/doc/openssl-0.9.7a/ssleay.txt sampei02> >> /usr/share/man/man1/asn1parse.1ssl.gz sampei02> >> /usr/share/man/man1/ca.1ssl.gz sampei02> >> /usr/share/man/man1/ciphers.1ssl.gz sampei02> >> /usr/share/man/man1/crl.1ssl.gz sampei02> >> /usr/share/man/man1/crl2pkcs7.1ssl.gz sampei02> >> /usr/share/man/man1/dgst.1ssl.gz sampei02> >> /usr/share/man/man1/dhparam.1ssl.gz sampei02> >> /usr/share/man/man1/dsa.1ssl.gz sampei02> >> /usr/share/man/man1/dsaparam.1ssl.gz sampei02> >> /usr/share/man/man1/enc.1ssl.gz sampei02> >> /usr/share/man/man1/gendsa.1ssl.gz sampei02> >> /usr/share/man/man1/genrsa.1ssl.gz sampei02> >> /usr/share/man/man1/md2.1ssl.gz sampei02> >> /usr/share/man/man1/md4.1ssl.gz sampei02> >> /usr/share/man/man1/md5.1ssl.gz sampei02> >> /usr/share/man/man1/mdc2.1ssl.gz sampei02> >> /usr/share/man/man1/nseq.1ssl.gz sampei02> >> /usr/share/man/man1/ocsp.1ssl.gz sampei02> >> /usr/share/man/man1/openssl.1ssl.gz sampei02> >> /usr/share/man/man1/pkcs12.1ssl.gz sampei02> >> /usr/share/man/man1/pkcs7.1ssl.gz sampei02> >> /usr/share/man/man1/pkcs8.1ssl.gz sampei02> >> /usr/share/man/man1/req.1ssl.gz sampei02> >> /usr/share/man/man1/ripemd160.1ssl.gz sampei02> >> /usr/share/man/man1/rsa.1ssl.gz sampei02> >> /usr/share/man/man1/rsautl.1ssl.gz sampei02> >> /usr/share/man/man1/s_client.1ssl.gz sampei02> >> /usr/share/man/man1/s_server.1ssl.gz sampei02> >> /usr/share/man/man1/sess_id.1ssl.gz sampei02> >> /usr/share/man/man1/sha.1ssl.gz sampei02> >> /usr/share/man/man1/sha1.1ssl.gz sampei02> >> /usr/share/man/man1/smime.1ssl.gz sampei02> >> /usr/share/man/man1/speed.1ssl.gz sampei02> >> /usr/share/man/man1/spkac.1ssl.gz sampei02> >> /usr/share/man/man1/sslpasswd.1ssl.gz sampei02> >> /usr/share/man/man1/sslrand.1ssl.gz sampei02> >> /usr/share/man/man1/verify.1ssl.gz sampei02> >> /usr/share/man/man1/version.1ssl.gz sampei02> >> /usr/share/man/man1/x509.1ssl.gz sampei02> >> /usr/share/man/man5/config.5ssl.gz sampei02> >> /usr/share/man/man7/DES.7ssl.gz sampei02> >> /usr/share/man/man7/Modes.7ssl.gz sampei02> >> /usr/share/man/man7/des_modes.7ssl.gz sampei02> >> /usr/share/man/man7/of.7ssl.gz sampei02> > sampei02> > ****** sampei02> >> /usr/share/ssl sampei02> >> /usr/share/ssl/CA sampei02> >> /usr/share/ssl/CA/private sampei02> >> /usr/share/ssl/cert.pem sampei02> >> /usr/share/ssl/certs sampei02> >> /usr/share/ssl/certs/Makefile sampei02> >> /usr/share/ssl/certs/ca-bundle.crt sampei02> >> /usr/share/ssl/certs/make-dummy-cert sampei02> >> /usr/share/ssl/lib sampei02> >> /usr/share/ssl/misc sampei02> >> /usr/share/ssl/misc/CA sampei02> >> /usr/share/ssl/misc/c_hash sampei02> >> /usr/share/ssl/misc/c_info sampei02> >> /usr/share/ssl/misc/c_issuer sampei02> >> /usr/share/ssl/misc/c_name sampei02> >> /usr/share/ssl/openssl.cnf sampei02> >> /usr/share/ssl/private sampei02> > ******* sampei02> > that's the location to look for the openssl.cnf file and thus the old files; simply do a sampei02> > find /usr/share/ssl -mtime -200 sampei02> > to find any recent files - that should point you in the right direction. sampei02> > sampei02> > sampei02> > HTH, sampei02> > sampei02> > JJK sampei02> > sampei02> sampei02> From chris.gray at kiffer.be Sat Jun 2 17:20:37 2018 From: chris.gray at kiffer.be (chris.gray at kiffer.be) Date: Sat, 2 Jun 2018 18:20:37 +0100 Subject: [openssl-users] PRNG is not seeded In-Reply-To: <2c8ab346-1279-28a3-bc09-49ef0ac025ce@binect.de> References: <2c8ab346-1279-28a3-bc09-49ef0ac025ce@binect.de> Message-ID: As it happens I am the proud owner of a made-in-UK Mathmos Lava Lamp and a couple of their Space Projectors : however I don't use them as a RNG. I am thinking more about the fact that there are a lot of devices which * have no hardware TRNG on board * do have one or more connections to wired or wireless internet and/or wide-area networks and/or various other communications channels such as BTLE or ZigBee * need to make a TLS/DTLS connection somewhere in order to be useful. By "literally in the air" I mean the entropy that is flying around in those radio channels or shared media; not the data which is being transmitted, but the inter-arrival times / collisions / etc. generated by a number of physically independent sources. I am sceptical of using haveged on such devices; of course I should be willing to test it and measure the results, but "measuring randomness" is a tricky business so I would be happy to see the results of some research. My own experiments in the past (with devices which had only a dial-up connection to the mother ship) were singularly unsuccessful in generating any useful degree of randomness. Thanks anyway for the suggestions everyone. > On 05/31/2018 03:03 PM, openssl-users-request at openssl.org distributed: >> Date: Thu, 31 May 2018 18:45:02 +1000 >> From: FooCrypt >> >> Place a teaspoon of fine grade white sand onto the skin of a snare drum > > Macroscopic hardware TRNGs are a *tad* yesteryear > > https://en.wikipedia.org/wiki/Lavarand > > because observing *quantum* random events doesn't require large devices > > https://en.wikipedia.org/wiki/Hardware_random_number_generator > > (not to mention being IIUC harder to influence by an attacker so as to > make them lose randomness). Nonetheless, if you don't have the hardware > (builtin TPM?) and cannot easily connect one to the given platform (as I > suspect for the OP's architecture) ... > > For general computing platforms, I've taken to installing (and, of > course, running and monitoring) haveged as a standard - on hosts *and* > VMs. It can run in an AIS-31 test mode if you want to check out the > entropy it collects. > > https://wiki.archlinux.org/index.php/Haveged > >>> On 31 May 2018, at 6:07 PM, chris.gray at kiffer.be wrote: >>> I've also encountered this quite often, and I have a feeling that on >>> today's connected devices there may be a lot of entropy "in the air" >>> (quite literally) which is not being captured. Does any one know of >>> research in this area? > > Not specifically for mobile phones or WiFi interfaces, if that's what > you're referring to with "in the air". However, squeezing available > entropy out of various less-than-predictable hardware and OS states is > what *all* non-hardware entropy gatherers ultimately do, from the Linux > kernel's /dev/random mechanisms to haveged to what-have-you. > > Regards, > -- > Jochen Bern > Systemingenieur > > www.binect.de > www.facebook.de/binect > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From jb-openssl at wisemo.com Sun Jun 3 23:23:20 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 4 Jun 2018 01:23:20 +0200 Subject: [openssl-users] PRNG is not seeded In-Reply-To: <2c8ab346-1279-28a3-bc09-49ef0ac025ce@binect.de> References: <2c8ab346-1279-28a3-bc09-49ef0ac025ce@binect.de> Message-ID: On 31/05/2018 19:14, Jochen Bern wrote: > On 05/31/2018 03:03 PM, openssl-users-request at openssl.org distributed: >> Date: Thu, 31 May 2018 18:45:02 +1000 >> From: FooCrypt >> >> Place a teaspoon of fine grade white sand onto the skin of a snare drum > Macroscopic hardware TRNGs are a *tad* yesteryear > > https://en.wikipedia.org/wiki/Lavarand > > because observing *quantum* random events doesn't require large devices > > https://en.wikipedia.org/wiki/Hardware_random_number_generator > > (not to mention being IIUC harder to influence by an attacker so as to > make them lose randomness). Nonetheless, if you don't have the hardware > (builtin TPM?) and cannot easily connect one to the given platform (as I > suspect for the OP's architecture) ... > > For general computing platforms, I've taken to installing (and, of > course, running and monitoring) haveged as a standard - on hosts *and* > VMs. It can run in an AIS-31 test mode if you want to check out the > entropy it collects. > > https://wiki.archlinux.org/index.php/Haveged From what I have seen, haveged seems highly bogus, with no significant arguments as to how their method gathers anything other than a highly indirect and obfuscated form of process statistics.? The wording used in their design summaries suggests they confuse "not documented outside the CPU design team" with "random and unpredictable". Haveged might be able to indirectly apply statistics of internal states in other processes, but that seems about it. The best alternative I have tried so far is to use what little entropy is available to connect to a trusted (self-owned) machine that serves TRNG bits over a variant of the EGD protocol, then using those bits to handle other randomness needs.? The key benefit here is that the trusted TRNG machine will contribute a lot of entropy to its own TLS connection, and the independence from any ability to mess with the architectural limitations of the receiving machine. >>> On 31 May 2018, at 6:07 PM, chris.gray at kiffer.be wrote: >>> I've also encountered this quite often, and I have a feeling that on >>> today's connected devices there may be a lot of entropy "in the air" >>> (quite literally) which is not being captured. Does any one know of >>> research in this area? > Not specifically for mobile phones or WiFi interfaces, if that's what > you're referring to with "in the air". However, squeezing available > entropy out of various less-than-predictable hardware and OS states is > what *all* non-hardware entropy gatherers ultimately do, from the Linux > kernel's /dev/random mechanisms to haveged to what-have-you. > > Regards, > > 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 sampei02 at tiscali.it Mon Jun 4 05:47:14 2018 From: sampei02 at tiscali.it (Sampei) Date: Mon, 04 Jun 2018 07:47:14 +0200 Subject: [openssl-users] =?utf-8?q?2_openssl_installed=3F?= Message-ID: Can you help to understand if I have 2 OPenSSL installed into my "old old" server please? rpm -qa | grep openssl gives: openssl-0.9.7a-33.10 Furthermore I found out following files into /usr/local/openssl-0.9.7e (perhaps a uncompressed tar file) : apps CHANGES.SSLeay Configure diffs.6e diffs.sec6 doc FAQ install.com INSTALL.VMS MacOS makevms.com openssl.doxy PROBLEMS shlib tools bugs comms.txt crypto diffs.6x diffs.sec6e do_patch.sh fips INSTALL.DJGPP INSTALL.W32 Makefile ms openssl.spec README ssl util certs comm.txt demos diffs.7 diffs.sec7 e_os2.h include INSTALL.MacOS INSTALL.WCE Makefile.bak NEWS os2 README.ASN1 test VMS CHANGES config diffs.6 diffs.sec diffs.secfix e_os.h INSTALL INSTALL.OS2 LICENSE Makefile.org op perl README.ENGINE times If I find .cnf files: /usr/local/openssl-0.9.7e/apps/oid.cnf /usr/local/openssl-0.9.7e/apps/openssl.cnf /usr/local/openssl-0.9.7e/apps/openssl-vms.cnf /usr/local/openssl-0.9.7e/crypto/conf/ssleay.cnf /usr/local/openssl-0.9.7e/test/CAss.cnf /usr/local/openssl-0.9.7e/test/CAssdh.cnf /usr/local/openssl-0.9.7e/test/CAssdsa.cnf /usr/local/openssl-0.9.7e/test/CAssrsa.cnf /usr/local/openssl-0.9.7e/test/Sssdsa.cnf /usr/local/openssl-0.9.7e/test/Sssrsa.cnf /usr/local/openssl-0.9.7e/test/test.cnf /usr/local/openssl-0.9.7e/test/Uss.cnf /usr/share/ssl/openssl.cnf What do you think? Con Mobile Open 6 GB hai 6 Giga, 600 minuti e 300 SMS per il tuo smartphone a 9? al mese per sempre. Passa ora a Tiscali Mobile, il nostro mese ? vero! http://tisca.li/Open6GB0318 -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at foocrypt.net Mon Jun 4 06:30:37 2018 From: openssl at foocrypt.net (FooCrypt) Date: Mon, 4 Jun 2018 16:30:37 +1000 Subject: [openssl-users] 2 openssl installed? In-Reply-To: References: Message-ID: <4ABD19A2-FCB1-49DE-9AF6-AF6E7592D344@foocrypt.net> find / -type f -name openssl -exec {} version \; repeat with objdump -x & ldd to determine which libraries, etc are being used. > On 4 Jun 2018, at 3:47 PM, Sampei wrote: > > Can you help to understand if I have 2 OPenSSL installed into my "old old" server please? > > rpm -qa | grep openssl gives: > openssl-0.9.7a-33.10 > > Furthermore I found out following files into /usr/local/openssl-0.9.7e (perhaps a uncompressed tar file) : > > apps > CHANGES.SSLeay > Configure > diffs.6e > diffs.sec6 > doc > FAQ > install.com > INSTALL.VMS > MacOS > makevms.com > openssl.doxy > PROBLEMS > shlib > tools > bugs > comms.txt > crypto > diffs.6x > diffs.sec6e > do_patch.sh > fips > INSTALL.DJGPP > INSTALL.W32 > Makefile > ms > openssl.spec > README > ssl > util > certs > comm.txt > demos > diffs.7 > diffs.sec7 > e_os2.h > include > INSTALL.MacOS > INSTALL.WCE > Makefile.bak > NEWS > os2 > README.ASN1 > test > VMS > CHANGES config > diffs.6 > diffs.sec > diffs.secfix > e_os.h > INSTALL > INSTALL.OS2 > LICENSE > Makefile.org > op > perl > README.ENGINE > times > > If I find .cnf files: > > /usr/local/openssl-0.9.7e/apps/oid.cnf > /usr/local/openssl-0.9.7e/apps/openssl.cnf > /usr/local/openssl-0.9.7e/apps/openssl-vms.cnf > /usr/local/openssl-0.9.7e/crypto/conf/ssleay.cnf > /usr/local/openssl-0.9.7e/test/CAss.cnf > /usr/local/openssl-0.9.7e/test/CAssdh.cnf > /usr/local/openssl-0.9.7e/test/CAssdsa.cnf > /usr/local/openssl-0.9.7e/test/CAssrsa.cnf > /usr/local/openssl-0.9.7e/test/Sssdsa.cnf > /usr/local/openssl-0.9.7e/test/Sssrsa.cnf > /usr/local/openssl-0.9.7e/test/test.cnf > /usr/local/openssl-0.9.7e/test/Uss.cnf > /usr/share/ssl/openssl.cnf > > What do you think? > > > > Con Mobile Open 6 GB hai 6 Giga, 600 minuti e 300 SMS per il tuo smartphone a 9? al mese per sempre. Passa ora a Tiscali Mobile, il nostro mese ? vero! http://tisca.li/Open6GB0318 > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From sampei02 at tiscali.it Mon Jun 4 12:18:47 2018 From: sampei02 at tiscali.it (Sampei) Date: Mon, 04 Jun 2018 14:18:47 +0200 Subject: [openssl-users] =?utf-8?q?2_openssl_installed=3F?= In-Reply-To: <4ABD19A2-FCB1-49DE-9AF6-AF6E7592D344@foocrypt.net> References: <4ABD19A2-FCB1-49DE-9AF6-AF6E7592D344@foocrypt.net> Message-ID: Here is result for first command: find / -type f -name openssl -exec {} version ; OpenSSL 0.9.7a Feb 19 2003 What means repeat with? What I have to type for next comand exactly please? objdump -x & ldd..... Il 04.06.2018 08:30 FooCrypt ha scritto: > find / -type f -name openssl -exec {} version ; > > repeat with > > objdump -x & ldd to determine which libraries, etc are being used. > >> On 4 Jun 2018, at 3:47 PM, Sampei wrote: Can you help to understand if I have 2 OPenSSL installed into my "old old" server please? rpm -qa | grep openssl gives: openssl-0.9.7a-33.10 Furthermore I found out following files into /usr/local/openssl-0.9.7e (perhaps a uncompressed tar file) : apps CHANGES.SSLeay Configure diffs.6e diffs.sec6 doc FAQ install.com INSTALL.VMS MacOS makevms.com openssl.doxy PROBLEMS shlib tools bugs comms.txt crypto diffs.6x diffs.sec6e do_patch.sh fips INSTALL.DJGPP INSTALL.W32 Makefile ms openssl.spec README ssl util certs comm.txt demos diffs.7 diffs.sec7 e_os2.h include INSTALL.MacOS INSTALL.WCE Makefile.bak NEWS os2 README.ASN1 test VMS CHANGES config diffs.6 diffs.sec diffs.secfix e_os.h INSTALL INSTALL.OS2 LICENSE Makefile.org op perl README.ENGINE times If I find .cnf files: /usr/local/openssl-0.9.7e/apps/oid.cnf /usr/local/openssl-0.9.7e/apps/openssl.cnf /usr/local/openssl-0.9.7e/apps/openssl-vms.cnf /usr/local/openssl-0.9.7e/crypto/conf/ssleay.cnf /usr/local/openssl-0.9.7e/test/CAss.cnf /usr/local/openssl-0.9.7e/test/CAssdh.cnf /usr/local/openssl-0.9.7e/test/CAssdsa.cnf /usr/local/openssl-0.9.7e/test/CAssrsa.cnf /usr/local/openssl-0.9.7e/test/Sssdsa.cnf /usr/local/openssl-0.9.7e/test/Sssrsa.cnf /usr/local/openssl-0.9.7e/test/test.cnf /usr/local/openssl-0.9.7e/test/Uss.cnf /usr/share/ssl/openssl.cnf What do you think? Con Mobile Open 6 GB hai 6 Giga, 600 minuti e 300 SMS per il tuo smartphone a 9EUR al mese per sempre. Passa ora a Tiscali Mobile, il nostro mese ? vero! http://tisca.li/Open6GB0318 [2] -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users [3] > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users [4] Con Mobile Open 6 GB hai 6 Giga, 600 minuti e 300 SMS per il tuo smartphone a 9? al mese per sempre. Passa ora a Tiscali Mobile, il nostro mese ? vero! http://tisca.li/Open6GB0318 -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at foocrypt.net Mon Jun 4 12:35:18 2018 From: openssl at foocrypt.net (FooCrypt) Date: Mon, 4 Jun 2018 22:35:18 +1000 Subject: [openssl-users] 2 openssl installed? In-Reply-To: References: <4ABD19A2-FCB1-49DE-9AF6-AF6E7592D344@foocrypt.net> Message-ID: find / -type f -exec {} version \; find / -type f -exec objdump -x {} \; find / -type f -exec ldd {} \; looks like you only have 1 openssl binary, 0.9.7.a on your host. objdump -x & ldd will show you which libraries the openssl binary is compiled to use on your host. so?. objdump -x [ full path to your openssl binary ] ldd [ full path to your openssl binary ] > On 4 Jun 2018, at 10:18 PM, Sampei wrote: > > Here is result for first command: > find / -type f -name openssl -exec {} version \; > OpenSSL 0.9.7a Feb 19 2003 > What means repeat with? > What I have to type for next comand exactly please? > objdump -x & ldd..... > Il 04.06.2018 08:30 FooCrypt ha scritto: > >> find / -type f -name openssl -exec {} version \; >> >> repeat with >> >> objdump -x & ldd to determine which libraries, etc are being used. >> >>> On 4 Jun 2018, at 3:47 PM, Sampei wrote: Can you help to understand if I have 2 OPenSSL installed into my "old old" server please? rpm -qa | grep openssl gives: openssl-0.9.7a-33.10 Furthermore I found out following files into /usr/local/openssl-0.9.7e (perhaps a uncompressed tar file) : apps CHANGES.SSLeay Configure diffs.6e diffs.sec6 doc FAQ install.com INSTALL.VMS MacOS makevms.com openssl.doxy PROBLEMS shlib tools bugs comms.txt crypto diffs.6x diffs.sec6e do_patch.sh fips INSTALL.DJGPP INSTALL.W32 Makefile ms openssl.spec README ssl util certs comm.txt demos diffs.7 diffs.sec7 e_os2.h include INSTALL.MacOS INSTALL.WCE Makefile.bak NEWS os2 README.ASN1 test VMS CHANGES config diffs.6 diffs.sec diffs.secfix e_os.h INSTALL INSTALL.OS2 LICENSE Makefile.org op perl README.ENGINE times If I find .cnf files: /usr/local/openssl-0.9.7e/apps/oid.cnf /usr/local/openssl-0.9.7e/apps/openssl.cnf /usr/local/openssl-0.9.7e/apps/openssl-vms.cnf /usr/local/openssl-0.9.7e/crypto/conf/ssleay.cnf /usr/local/openssl-0.9.7e/test/CAss.cnf /usr/local/openssl-0.9.7e/test/CAssdh.cnf /usr/local/openssl-0.9.7e/test/CAssdsa.cnf /usr/local/openssl-0.9.7e/test/CAssrsa.cnf /usr/local/openssl-0.9.7e/test/Sssdsa.cnf /usr/local/openssl-0.9.7e/test/Sssrsa.cnf /usr/local/openssl-0.9.7e/test/test.cnf /usr/local/openssl-0.9.7e/test/Uss.cnf /usr/share/ssl/openssl.cnf What do you think? Con Mobile Open 6 GB hai 6 Giga, 600 minuti e 300 SMS per il tuo smartphone a 9? al mese per sempre. Passa ora a Tiscali Mobile, il nostro mese ? vero! http://tisca.li/Open6GB0318 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > Con Mobile Open 6 GB hai 6 Giga, 600 minuti e 300 SMS per il tuo smartphone a 9? al mese per sempre. Passa ora a Tiscali Mobile, il nostro mese ? vero! http://tisca.li/Open6GB0318 > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From Michael.Wojcik at microfocus.com Mon Jun 4 13:56:26 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 4 Jun 2018 13:56:26 +0000 Subject: [openssl-users] PRNG is not seeded In-Reply-To: References: <2c8ab346-1279-28a3-bc09-49ef0ac025ce@binect.de>, Message-ID: Of course people have been harvesting entropy, or trying to, from network sources for decades. There's a famous paragraph regarding it in RFC 4086, which is an expanded version of a similar statement from RFC 1750 (1994): Other external events, such as network packet arrival times and lengths, can also be used, but only with great care. In particular, the possibility of manipulation of such network traffic measurements by an adversary and the lack of history at system start-up must be carefully considered. If this input is subject to manipulation, it must not be trusted as a source of entropy. (RFC 4086, 3.5) More generally: It's often possible to harvest quite a bit of information that can't be adequately predicted or statistically modeled by an attacker from network sources, and these days distilling CPRNG entropy from such inputs is straightforward thanks to the use of cryptographic compression functions. It's the edge cases that bite you. 4086 mentions attacker manipulation (flooding network sources with known data to flush entropy out of the pool) and start-up (if you don't have persistent storage of adequate seed material). Embedded devices may suffer from too little, or too predictable, network traffic in their limited reception area. You can get stronger guarantees from hardware entropy devices, which are cheap (in every sense: component cost, power consumption, size, ...). So there's not a lot of incentive to do more research into gathering entropy from external sources - it makes more sense to lean on device manufacturers, or use add-on devices. From klein.stefan1 at googlemail.com Mon Jun 4 16:51:05 2018 From: klein.stefan1 at googlemail.com (klein.stefan1 at googlemail.com) Date: Mon, 4 Jun 2018 18:51:05 +0200 Subject: [openssl-users] Polling fd before SSL_read() and renegotiations Message-ID: <20180604165105.GA12983@thinkpad-l470> Hi everybody! I am working on a program where each peer may write at any time, so the other side has to be able to read incoming data when it gets available. If the peer sent nothing my program must be able to call SSL_write() to send its own data to the other side. My code currently does this using non-blocking I/O like this: 1. If the underlying socket is not readable go to #2 immediately to be able to send data. If the socket is reported to be readable, call SSL_read() to get that data. If that call cannot be completed due to SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE, poll the fd until that condition is met. Then repeat calling SSL_read(). So I'm repeatedly calling SSL_read() until it reports SSL_ERROR_NONE. With this I satisfy the requirement of the OpenSSL-API to repeat an incomplete call until it completes. Although I did not read that exactly in the man-pages, the non-blocking-example in "Network Security with OpenSSL" by Viega et al. takes care not to interleave the calls to SSL_write()/SSL_read(). 2. (The program reaches here only after SSL_read() has succeeded or if it has not even tried to call SSL_read() as the socket was not readable) If the peer has data that needs to be sent to the other side, call SSL_write() for it. If that function returns with SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE poll the fd accordingly and repeat SSL_write() until it ends with SSL_ERROR_NONE. Then go to #1 to check for incoming data. The code above does what I want - except for renegotiations! If the peer receives a renegotiation-request its socket becomes readable just like if it received a normal SSL-record with user-data. Thus my program enters #1 and repeats SSL_read() until SSL_ERROR_NONE is returned. But this never happens in that case, because the other peer just sent the renegotiation-packet(s) but no other data. So I'm stuck in repeating SSL_read() and won't enter #2 until the peer that forced the renegotiation has sent any other data to make SSL_read() finish (which may take very long in my program). Well, I can force that behavior only using "openssl s_client/s_server" as peer. And if other peers do it exactly like my code, a renogatioation can only be initiated by calling SSL_write(). So some data will be sent after the renegotiation to prevent the described situation. But can I really trust on that behavior for other peers? Even if they are using other SSL-libraries? And what if the other side detects an session-timeout while it waits on data and immediately intiates a renegotiation without sending data? If not, how can I use the OpenSSL-API and not stuck in SSL_read() when there is no data available for read? Thanks a lot for your help! Stefan From rsalz at akamai.com Mon Jun 4 17:07:18 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 4 Jun 2018 17:07:18 +0000 Subject: [openssl-users] Polling fd before SSL_read() and renegotiations In-Reply-To: <20180604165105.GA12983@thinkpad-l470> References: <20180604165105.GA12983@thinkpad-l470> Message-ID: <80CC8DED-A105-44F5-B5DF-69B2FCB63387@akamai.com> > The code above does what I want - except for renegotiations! Do you absolutely, positively, HAVE TO support renegotiation? From klein.stefan1 at googlemail.com Mon Jun 4 17:21:41 2018 From: klein.stefan1 at googlemail.com (klein.stefan1 at googlemail.com) Date: Mon, 4 Jun 2018 19:21:41 +0200 Subject: [openssl-users] Polling fd before SSL_read() and renegotiations In-Reply-To: <80CC8DED-A105-44F5-B5DF-69B2FCB63387@akamai.com> References: <20180604165105.GA12983@thinkpad-l470> <80CC8DED-A105-44F5-B5DF-69B2FCB63387@akamai.com> Message-ID: <20180604172141.GA13174@thinkpad-l470> The connection is open for verly long time (>24h), so I thought that the peer may force a renogatioation due to the session timeout. Or have I got something wrong and a renogatioation is not necessary for long-running sessions? From jb-openssl at wisemo.com Tue Jun 5 06:46:03 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 5 Jun 2018 08:46:03 +0200 Subject: [openssl-users] PRNG is not seeded In-Reply-To: References: <2c8ab346-1279-28a3-bc09-49ef0ac025ce@binect.de> Message-ID: <487e2eef-d55e-c6b0-fd40-9cde0948e395@wisemo.com> On 04/06/2018 15:56, Michael Wojcik wrote: > Of course people have been harvesting entropy, or trying to, from network sources for decades. There's a famous paragraph regarding it in RFC 4086, which is an expanded version of a similar statement from RFC 1750 (1994): > > Other external events, such as network packet arrival times and > lengths, can also be used, but only with great care. In particular, > the possibility of manipulation of such network traffic measurements > by an adversary and the lack of history at system start-up must be > carefully considered. If this input is subject to manipulation, it > must not be trusted as a source of entropy. > > (RFC 4086, 3.5) > > More generally: It's often possible to harvest quite a bit of information that can't be adequately predicted or statistically modeled by an attacker from network sources, and these days distilling CPRNG entropy from such inputs is straightforward thanks to the use of cryptographic compression functions. It's the edge cases that bite you. 4086 mentions attacker manipulation (flooding network sources with known data to flush entropy out of the pool) and start-up (if you don't have persistent storage of adequate seed material). Embedded devices may suffer from too little, or too predictable, network traffic in their limited reception area. > > You can get stronger guarantees from hardware entropy devices, which are cheap (in every sense: component cost, power consumption, size, ...). So there's not a lot of incentive to do more research into gathering entropy from external sources - it makes more sense to lean on device manufacturers, or use add-on devices. Hence my solution of using a hardware TRNG shared over the network with devices that lack the ability to have one added locally. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 sampei02 at tiscali.it Tue Jun 5 06:53:50 2018 From: sampei02 at tiscali.it (Sampei) Date: Tue, 05 Jun 2018 08:53:50 +0200 Subject: [openssl-users] =?utf-8?q?2_openssl_installed=3F?= In-Reply-To: References: <4ABD19A2-FCB1-49DE-9AF6-AF6E7592D344@foocrypt.net> Message-ID: <4bf2b9503033c86b944951950fab9390@tiscali.it> Perhaps it's missing -'name openssl' in the 3 commands. However I run: 1) find / -type f -name openssl -exec ldd {} ; libssl.so.4 => /lib/libssl.so.4 (0x0098f000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00718000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00830000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x006ee000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x0080c000) libresolv.so.2 => /lib/libresolv.so.2 (0x006d9000) libcrypto.so.4 => /lib/libcrypto.so.4 (0x0089b000) libdl.so.2 => /lib/libdl.so.2 (0x0067c000) libz.so.1 => /usr/lib/libz.so.1 (0x00682000) libc.so.6 => /lib/libc.so.6 (0x0052a000) /lib/ld-linux.so.2 (0x0050c000) 2) find / -type f -name openssl -exec objdump -x {} ; /usr/bin/openssl: file format elf32-i386 /usr/bin/openssl architecture: i386, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x08054490 Program Header: PHDR off 0x00000034 vaddr 0x08048034 paddr 0x08048034 align 2**2 filesz 0x000000e0 memsz 0x000000e0 flags r-x INTERP off 0x00000114 vaddr 0x08048114 paddr 0x08048114 align 2**0 filesz 0x00000013 memsz 0x00000013 flags r-- LOAD off 0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12 filesz 0x0004f678 memsz 0x0004f678 flags r-x LOAD off 0x00050000 vaddr 0x08098000 paddr 0x08098000 align 2**12 filesz 0x00007174 memsz 0x00007174 flags rw- DYNAMIC off 0x00052420 vaddr 0x0809a420 paddr 0x0809a420 align 2**2 filesz 0x00000110 memsz 0x00000110 flags rw- NOTE off 0x00000128 vaddr 0x08048128 paddr 0x08048128 align 2**2 filesz 0x00000020 memsz 0x00000020 flags r-- STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2 filesz 0x00000000 memsz 0x00000000 flags rw- Dynamic Section: NEEDED libssl.so.4 NEEDED libgssapi_krb5.so.2 NEEDED libkrb5.so.3 NEEDED libcom_err.so.2 NEEDED libk5crypto.so.3 NEEDED libresolv.so.2 NEEDED libcrypto.so.4 NEEDED libdl.so.2 NEEDED libz.so.1 NEEDED libc.so.6 INIT 0x80516f8 FINI 0x8086ca8 HASH 0x8048148 STRTAB 0x809becc SYMTAB 0x804958c STRSZ 0x3295 SYMENT 0x10 DEBUG 0x0 PLTGOT 0x809a544 PLTRELSZ 0x16b8 PLTREL 0x11 JMPREL 0x8050040 REL 0x804fed0 RELSZ 0x170 RELENT 0x8 VERNEED 0x804fe90 VERNEEDNUM 0x1 VERSYM 0x804f882 0x6ffffef9 0x804c5ec 0x6ffffdf7 0xdc 0x6ffffef8 0x804c6c8 0x6ffffdf6 0x108 Version References: required from libc.so.6: 0x0d696913 0x00 04 GLIBC_2.3 0x0d696911 0x00 03 GLIBC_2.1 0x0d696910 0x00 02 GLIBC_2.0 Sections: Idx Name Size VMA LMA File off Algn 0 .interp 00000013 08048114 08048114 00000114 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .note.ABI-tag 00000020 08048128 08048128 00000128 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .hash 00001444 08048148 08048148 00000148 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .dynsym 00003060 0804958c 0804958c 0000158c 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .gnu.liblist 000000dc 0804c5ec 0804c5ec 000045ec 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .gnu.conflict 00000108 0804c6c8 0804c6c8 000046c8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .gnu.version 0000060c 0804f882 0804f882 00007882 2**1 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .gnu.version_r 00000040 0804fe90 0804fe90 00007e90 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .rel.dyn 00000170 0804fed0 0804fed0 00007ed0 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 9 .rel.plt 000016b8 08050040 08050040 00008040 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 10 .init 00000017 080516f8 080516f8 000096f8 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 11 .plt 00002d80 08051710 08051710 00009710 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 12 .text 00032818 08054490 08054490 0000c490 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 13 .fini 0000001b 08086ca8 08086ca8 0003eca8 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 14 .rodata 00010991 08086ce0 08086ce0 0003ece0 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 15 .eh_frame 00000004 08097674 08097674 0004f674 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 16 .data 00002420 08098000 08098000 00050000 2**5 CONTENTS, ALLOC, LOAD, DATA 17 .dynamic 00000110 0809a420 0809a420 00052420 2**2 CONTENTS, ALLOC, LOAD, DATA 18 .ctors 00000008 0809a530 0809a530 00052530 2**2 CONTENTS, ALLOC, LOAD, DATA 19 .dtors 00000008 0809a538 0809a538 00052538 2**2 CONTENTS, ALLOC, LOAD, DATA 20 .jcr 00000004 0809a540 0809a540 00052540 2**2 CONTENTS, ALLOC, LOAD, DATA 21 .got 00000c20 0809a544 0809a544 00052544 2**2 CONTENTS, ALLOC, LOAD, DATA 22 .bss 00000d4c 0809b180 0809b180 00053180 2**5 CONTENTS, ALLOC, LOAD, DATA 23 .dynstr 000032a8 0809becc 0809becc 00053ecc 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 24 .gnu_debuglink 00000014 00000000 00000000 00057174 2**2 CONTENTS, READONLY 25 .gnu.prelink_undo 000004d4 00000000 00000000 00057188 2**2 CONTENTS, READONLY SYMBOL TABLE: no symbols 3) find / -type f -name openssl - exec {} version ; OpenSSL 0.9.7a Feb 19 2003 Il 04.06.2018 14:35 FooCrypt ha scritto: > find / -type f -exec {} version ; > > find / -type f -exec objdump -x {} ; > > find / -type f -exec ldd {} ; > > looks like you only have 1 openssl binary, 0.9.7.a on your host. > > objdump -x & ldd will show you which libraries the openssl binary is compiled to use on your host. > > so?. > > objdump -x [ full path to your openssl binary ] > > ldd [ full path to your openssl binary ] > >> On 4 Jun 2018, at 10:18 PM, Sampei wrote: Here is result for first command: find / -type f -name openssl -exec {} version ; OpenSSL 0.9.7a Feb 19 2003 What means repeat with? What I have to type for next comand exactly please? objdump -x & ldd..... Il 04.06.2018 08:30 FooCrypt ha scritto: >> >>> find / -type f -name openssl -exec {} version ; repeat with objdump -x & ldd to determine which libraries, etc are being used. >>> >>>> On 4 Jun 2018, at 3:47 PM, Sampei wrote: Can you help to understand if I have 2 OPenSSL installed into my "old old" server please? rpm -qa | grep openssl gives: openssl-0.9.7a-33.10 Furthermore I found out following files into /usr/local/openssl-0.9.7e (perhaps a uncompressed tar file) : apps CHANGES.SSLeay Configure diffs.6e diffs.sec6 doc FAQ install.com INSTALL.VMS MacOS makevms.com openssl.doxy PROBLEMS shlib tools bugs comms.txt crypto diffs.6x diffs.sec6e do_patch.sh fips INSTALL.DJGPP INSTALL.W32 Makefile ms openssl.spec README ssl util certs comm.txt demos diffs.7 diffs.sec7 e_os2.h include INSTALL.MacOS INSTALL.WCE Makefile.bak NEWS os2 README.ASN1 test VMS CHANGES config diffs.6 diffs.sec diffs.secfix e_os.h INSTALL INSTALL.OS2 LICENSE Makefile.org op perl README.ENGINE times If I find .cnf files: /usr/local/openssl-0.9.7e/apps/oid.cnf /usr/local/openssl-0.9.7e/apps/openssl.cnf /usr/local/openssl-0.9.7e/apps/openssl-vms.cnf /usr/local/openssl-0.9.7e/crypto/conf/ssleay.cnf /usr/local/openssl-0.9.7e/test/CAss.cnf /usr/local/openssl-0.9.7e/test/CAssdh.cnf /usr/local/openssl-0.9.7e/test/CAssdsa.cnf /usr/local/openssl-0.9.7e/test/CAssrsa.cnf /usr/local/openssl-0.9.7e/test/Sssdsa.cnf /usr/local/openssl-0.9.7e/test/Sssrsa.cnf /usr/local/openssl-0.9.7e/test/test.cnf /usr/local/openssl-0.9.7e/test/Uss.cnf /usr/share/ssl/openssl.cnf What do you think? Con Mobile Open 6 GB hai 6 Giga, 600 minuti e 300 SMS per il tuo smartphone a 9EUR al mese per sempre. Passa ora a Tiscali Mobile, il nostro mese ? vero! http://tisca.li/Open6GB0318 [2] -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users [3] >>> -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users [4] >> Con Mobile Open 6 GB hai 6 Giga, 600 minuti e 300 SMS per il tuo smartphone a 9EUR al mese per sempre. Passa ora a Tiscali Mobile, il nostro mese ? vero! http://tisca.li/Open6GB0318 [6] -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users [7] > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users [8] Con Mobile Open 6 GB hai 6 Giga, 600 minuti e 300 SMS per il tuo smartphone a 9? al mese per sempre. Passa ora a Tiscali Mobile, il nostro mese ? vero! http://tisca.li/Open6GB0318 -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at foocrypt.net Tue Jun 5 07:37:43 2018 From: openssl at foocrypt.net (FooCrypt) Date: Tue, 5 Jun 2018 17:37:43 +1000 Subject: [openssl-users] 2 openssl installed? In-Reply-To: <4bf2b9503033c86b944951950fab9390@tiscali.it> References: <4ABD19A2-FCB1-49DE-9AF6-AF6E7592D344@foocrypt.net> <4bf2b9503033c86b944951950fab9390@tiscali.it> Message-ID: <32F957BF-B7F1-48B6-AC55-9BF0688893D1@foocrypt.net> Yeah, typo, forgot -name looks like its using all the usr & lib libraries and nothing from /usr/local/?.. where you 97e files are. I don?t know what you are using that system for, but is there a reason why you are not running 1.0.2g or g+ ? Are there other apps on the host which are using the e configs ? > On 5 Jun 2018, at 4:53 PM, Sampei wrote: > > Perhaps it's missing -'name openssl' in the 3 commands. > However I run: > 1) find / -type f -name openssl -exec ldd {} \; > libssl.so.4 => /lib/libssl.so.4 (0x0098f000) > libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00718000) > libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00830000) > libcom_err.so.2 => /lib/libcom_err.so.2 (0x006ee000) > libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x0080c000) > libresolv.so.2 => /lib/libresolv.so.2 (0x006d9000) > libcrypto.so.4 => /lib/libcrypto.so.4 (0x0089b000) > libdl.so.2 => /lib/libdl.so.2 (0x0067c000) > libz.so.1 => /usr/lib/libz.so.1 (0x00682000) > libc.so.6 => /lib/libc.so.6 (0x0052a000) > /lib/ld-linux.so.2 (0x0050c000) > 2) find / -type f -name openssl -exec objdump -x {} \; > > /usr/bin/openssl: file format elf32-i386 > /usr/bin/openssl > architecture: i386, flags 0x00000112: > EXEC_P, HAS_SYMS, D_PAGED > start address 0x08054490 > > Program Header: > PHDR off 0x00000034 vaddr 0x08048034 paddr 0x08048034 align 2**2 > filesz 0x000000e0 memsz 0x000000e0 flags r-x > INTERP off 0x00000114 vaddr 0x08048114 paddr 0x08048114 align 2**0 > filesz 0x00000013 memsz 0x00000013 flags r-- > LOAD off 0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12 > filesz 0x0004f678 memsz 0x0004f678 flags r-x > LOAD off 0x00050000 vaddr 0x08098000 paddr 0x08098000 align 2**12 > filesz 0x00007174 memsz 0x00007174 flags rw- > DYNAMIC off 0x00052420 vaddr 0x0809a420 paddr 0x0809a420 align 2**2 > filesz 0x00000110 memsz 0x00000110 flags rw- > NOTE off 0x00000128 vaddr 0x08048128 paddr 0x08048128 align 2**2 > filesz 0x00000020 memsz 0x00000020 flags r-- > STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2 > filesz 0x00000000 memsz 0x00000000 flags rw- > > Dynamic Section: > NEEDED libssl.so.4 > NEEDED libgssapi_krb5.so.2 > NEEDED libkrb5.so.3 > NEEDED libcom_err.so.2 > NEEDED libk5crypto.so.3 > NEEDED libresolv.so.2 > NEEDED libcrypto.so.4 > NEEDED libdl.so.2 > NEEDED libz.so.1 > NEEDED libc.so.6 > INIT 0x80516f8 > FINI 0x8086ca8 > HASH 0x8048148 > STRTAB 0x809becc > SYMTAB 0x804958c > STRSZ 0x3295 > SYMENT 0x10 > DEBUG 0x0 > PLTGOT 0x809a544 > PLTRELSZ 0x16b8 > PLTREL 0x11 > JMPREL 0x8050040 > REL 0x804fed0 > RELSZ 0x170 > RELENT 0x8 > VERNEED 0x804fe90 > VERNEEDNUM 0x1 > VERSYM 0x804f882 > 0x6ffffef9 0x804c5ec > 0x6ffffdf7 0xdc > 0x6ffffef8 0x804c6c8 > 0x6ffffdf6 0x108 > > Version References: > required from libc.so.6: > 0x0d696913 0x00 04 GLIBC_2.3 > 0x0d696911 0x00 03 GLIBC_2.1 > 0x0d696910 0x00 02 GLIBC_2.0 > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .interp 00000013 08048114 08048114 00000114 2**0 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 1 .note.ABI-tag 00000020 08048128 08048128 00000128 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 2 .hash 00001444 08048148 08048148 00000148 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 3 .dynsym 00003060 0804958c 0804958c 0000158c 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 4 .gnu.liblist 000000dc 0804c5ec 0804c5ec 000045ec 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 5 .gnu.conflict 00000108 0804c6c8 0804c6c8 000046c8 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 6 .gnu.version 0000060c 0804f882 0804f882 00007882 2**1 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 7 .gnu.version_r 00000040 0804fe90 0804fe90 00007e90 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 8 .rel.dyn 00000170 0804fed0 0804fed0 00007ed0 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 9 .rel.plt 000016b8 08050040 08050040 00008040 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 10 .init 00000017 080516f8 080516f8 000096f8 2**2 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 11 .plt 00002d80 08051710 08051710 00009710 2**2 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 12 .text 00032818 08054490 08054490 0000c490 2**4 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 13 .fini 0000001b 08086ca8 08086ca8 0003eca8 2**2 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 14 .rodata 00010991 08086ce0 08086ce0 0003ece0 2**5 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 15 .eh_frame 00000004 08097674 08097674 0004f674 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 16 .data 00002420 08098000 08098000 00050000 2**5 > CONTENTS, ALLOC, LOAD, DATA > 17 .dynamic 00000110 0809a420 0809a420 00052420 2**2 > CONTENTS, ALLOC, LOAD, DATA > 18 .ctors 00000008 0809a530 0809a530 00052530 2**2 > CONTENTS, ALLOC, LOAD, DATA > 19 .dtors 00000008 0809a538 0809a538 00052538 2**2 > CONTENTS, ALLOC, LOAD, DATA > 20 .jcr 00000004 0809a540 0809a540 00052540 2**2 > CONTENTS, ALLOC, LOAD, DATA > 21 .got 00000c20 0809a544 0809a544 00052544 2**2 > CONTENTS, ALLOC, LOAD, DATA > 22 .bss 00000d4c 0809b180 0809b180 00053180 2**5 > CONTENTS, ALLOC, LOAD, DATA > 23 .dynstr 000032a8 0809becc 0809becc 00053ecc 2**0 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 24 .gnu_debuglink 00000014 00000000 00000000 00057174 2**2 > CONTENTS, READONLY > 25 .gnu.prelink_undo 000004d4 00000000 00000000 00057188 2**2 > CONTENTS, READONLY > SYMBOL TABLE: > no symbols > 3) find / -type f -name openssl - > exec {} version \; > OpenSSL 0.9.7a Feb 19 2003 > > Il 04.06.2018 14:35 FooCrypt ha scritto: > >> find / -type f -exec {} version \; >> >> find / -type f -exec objdump -x {} \; >> >> find / -type f -exec ldd {} \; >> >> >> looks like you only have 1 openssl binary, 0.9.7.a on your host. >> >> objdump -x & ldd will show you which libraries the openssl binary is compiled to use on your host. >> >> so?. >> >> objdump -x [ full path to your openssl binary ] >> >> ldd [ full path to your openssl binary ] >> >>> On 4 Jun 2018, at 10:18 PM, Sampei wrote: Here is result for first command: find / -type f -name openssl -exec {} version \; OpenSSL 0.9.7a Feb 19 2003 What means repeat with? What I have to type for next comand exactly please? objdump -x & ldd..... Il 04.06.2018 08:30 FooCrypt ha scritto: >>>> find / -type f -name openssl -exec {} version \; repeat with objdump -x & ldd to determine which libraries, etc are being used. >>>>> On 4 Jun 2018, at 3:47 PM, Sampei wrote: Can you help to understand if I have 2 OPenSSL installed into my "old old" server please? rpm -qa | grep openssl gives: openssl-0.9.7a-33.10 Furthermore I found out following files into /usr/local/openssl-0.9.7e (perhaps a uncompressed tar file) : apps CHANGES.SSLeay Configure diffs.6e diffs.sec6 doc FAQ install.com INSTALL.VMS MacOS makevms.com openssl.doxy PROBLEMS shlib tools bugs comms.txt crypto diffs.6x diffs.sec6e do_patch.sh fips INSTALL.DJGPP INSTALL.W32 Makefile ms openssl.spec README ssl util certs comm.txt demos diffs.7 diffs.sec7 e_os2.h include INSTALL.MacOS INSTALL.WCE Makefile.bak NEWS os2 README.ASN1 test VMS CHANGES config diffs.6 diffs.sec diffs.secfix e_os.h INSTALL INSTALL.OS2 LICENSE Makefile.org op perl README.ENGINE times If I find .cnf files: /usr/local/openssl-0.9.7e/apps/oid.cnf /usr/local/openssl-0.9.7e/apps/openssl.cnf /usr/local/openssl-0.9.7e/apps/openssl-vms.cnf /usr/local/openssl-0.9.7e/crypto/conf/ssleay.cnf /usr/local/openssl-0.9.7e/test/CAss.cnf /usr/local/openssl-0.9.7e/test/CAssdh.cnf /usr/local/openssl-0.9.7e/test/CAssdsa.cnf /usr/local/openssl-0.9.7e/test/CAssrsa.cnf /usr/local/openssl-0.9.7e/test/Sssdsa.cnf /usr/local/openssl-0.9.7e/test/Sssrsa.cnf /usr/local/openssl-0.9.7e/test/test.cnf /usr/local/openssl-0.9.7e/test/Uss.cnf /usr/share/ssl/openssl.cnf What do you think? Con Mobile Open 6 GB hai 6 Giga, 600 minuti e 300 SMS per il tuo smartphone a 9? al mese per sempre. Passa ora a Tiscali Mobile, il nostro mese ? vero! http://tisca.li/Open6GB0318 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>> -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>> Con Mobile Open 6 GB hai 6 Giga, 600 minuti e 300 SMS per il tuo smartphone a 9? al mese per sempre. Passa ora a Tiscali Mobile, il nostro mese ? vero! http://tisca.li/Open6GB0318 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > Con Mobile Open 6 GB hai 6 Giga, 600 minuti e 300 SMS per il tuo smartphone a 9? al mese per sempre. Passa ora a Tiscali Mobile, il nostro mese ? vero! http://tisca.li/Open6GB0318 > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From tmraz at redhat.com Tue Jun 5 11:26:10 2018 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 05 Jun 2018 13:26:10 +0200 Subject: [openssl-users] Polling fd before SSL_read() and renegotiations In-Reply-To: <20180604165105.GA12983@thinkpad-l470> References: <20180604165105.GA12983@thinkpad-l470> Message-ID: <1528197970.8622.7.camel@redhat.com> On Mon, 2018-06-04 at 18:51 +0200, Stefan via openssl-users wrote: > Hi everybody! > > I am working on a program where each peer may write at any time, so > the other side has to be able to read incoming data when it gets > available. If the peer sent nothing my program must be able to call > SSL_write() to send its own data to the other side. > > My code currently does this using non-blocking I/O like this: > > 1. If the underlying socket is not readable go to #2 immediately to > be > able to send data. If the socket is reported to be readable, call > SSL_read() to get that data. If that call cannot be completed due > to SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE, poll the fd until > that > condition is met. Then repeat calling SSL_read(). So I'm > repeatedly > calling SSL_read() until it reports SSL_ERROR_NONE. With this I > satisfy the requirement of the OpenSSL-API to repeat an incomplete > call until it completes. Although I did not read that exactly in > the man-pages, the non-blocking-example in "Network Security with > OpenSSL" by Viega et al. takes care not to interleave the calls to > SSL_write()/SSL_read(). > > 2. (The program reaches here only after SSL_read() has succeeded or > if > it has not even tried to call SSL_read() as the socket was not > readable) If the peer has data that needs to be sent to the other > side, call SSL_write() for it. If that function returns with > SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE poll the fd > accordingly > and repeat SSL_write() until it ends with SSL_ERROR_NONE. Then go > to #1 to check for incoming data. > > The code above does what I want - except for renegotiations! > > If the peer receives a renegotiation-request its socket becomes > readable just like if it received a normal SSL-record with user-data. > Thus my program enters #1 and repeats SSL_read() until SSL_ERROR_NONE > is returned. But this never happens in that case, because the other > peer just sent the renegotiation-packet(s) but no other data. So I'm > stuck in repeating SSL_read() and won't enter #2 until the peer that > forced the renegotiation has sent any other data to make SSL_read() > finish (which may take very long in my program). You've basically answered your question yourself - you cannot do it like this - switching phases #1 and #2, but instead you need to go to the writing phase (i.e. start writing if you have anything to pass to SSL_write) whenever you need to wait on data to be read to appear in the socket. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From Michael.Wojcik at microfocus.com Wed Jun 6 16:12:59 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 6 Jun 2018 16:12:59 +0000 Subject: [openssl-users] PRNG is not seeded In-Reply-To: <487e2eef-d55e-c6b0-fd40-9cde0948e395@wisemo.com> References: <2c8ab346-1279-28a3-bc09-49ef0ac025ce@binect.de> , <487e2eef-d55e-c6b0-fd40-9cde0948e395@wisemo.com> Message-ID: > From: openssl-users on behalf of Jakob Bohm > Sent: Tuesday, June 5, 2018 02:46 > Hence my solution of using a hardware TRNG shared over the > network with devices that lack the ability to have one added > locally. Yes, I think that's a good approach. It reduces the attack surface, since the client device can connect to the entropy-gathering device with considerable assurance (it can be configured with a pinned CA or PSK, etc), and at startup can use some entropy saved from the previous run. An attacker in a privileged position could try active attacks like a DoS against the connection to the entropy server, but a (more dangerous) passive attack looks very difficult. And it's practical for real-world data centers; implementation and equipment costs are low. It should even be possible to do this with one of those SOHO WIFi routers that have USB ports and media-sharing features, for use by smartphone apps and the like. From joshi.sanjaya at gmail.com Wed Jun 6 19:11:51 2018 From: joshi.sanjaya at gmail.com (Sanjaya Joshi) Date: Thu, 7 Jun 2018 00:41:51 +0530 Subject: [openssl-users] Selection of DHE ciphers based on modulus size of DH Message-ID: Hello, I understood that when DHE ciphers are tried to be used between two entities, it's only the server that plays a role about selection of the DH parameters. This is not negotiable with the client. For e.g., the server can freely use a very low not-recommended DH group with 512 bit key length and the client cannot deny it. Is this understanding still correct or this has been changed recently ? Regards, Sanjaya -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochen.bern at binect.de Wed Jun 6 19:56:18 2018 From: jochen.bern at binect.de (Jochen Bern) Date: Wed, 6 Jun 2018 21:56:18 +0200 Subject: [openssl-users] PRNG is not seeded In-Reply-To: References: Message-ID: On 06/06/2018 09:12 PM, openssl-users-request at openssl.org digestributed: > Date: Wed, 6 Jun 2018 16:12:59 +0000 > From: Michael Wojcik > >> Hence my solution of using a hardware TRNG shared over the >> network with devices that lack the ability to have one added >> locally. > > Yes, I think that's a good approach. It reduces the attack surface, > since the client device can connect to the entropy-gathering device > with considerable assurance (it can be configured with a pinned CA > or PSK, etc), and at startup can use some entropy saved from the > previous run. An attacker in a privileged position could try active > attacks like a DoS against the connection to the entropy server, but > a (more dangerous) passive attack looks very difficult. Speaking of attack scenarios, I refreshed my info after this discussion and wondered how likely it is that someone (in a Linux world) would want to attack the entropy *sources* directly. A manipulated source's effect on applications (that read from /dev/random) would be somewhat limited due to the kernel folding in other sources as well (memento Linus' statement about RDRAND), and due to the fact that *many* consumers read from it (you cannot predict who gets which part of your manipulated entropy). For comparison, imagine someone attacking the kernel and manipulating the /dev/random driver so that it feeds predictable sequences to the targets (processes running executables "httpd", "gpg", etc.) but real pool data to all other consumers. Presto, a subverted system that still gets a clean bill of health from rngtest, ent, dieharder, or whatever other analyzer you care to try ... ... by which I mean to ask, since I read a quest for suitable entropy-distribution protocols between the lines here, maybe there is something to be said in favor of signed-at-source chunks of entropy being forwarded *through* the kernel unchanged, and leaving the trust-based selection of sources and final folding to the individual applications? > And it's practical for real-world data centers; implementation and > equipment costs are low. [has been trying to acquire a better *NTP* source than public unsigned servers in certain data centers for 8+ years] :-C Regards, -- Jochen Bern Systemingenieur www.binect.de www.facebook.de/binect -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4278 bytes Desc: S/MIME Cryptographic Signature URL: From rsalz at akamai.com Wed Jun 6 23:15:39 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 6 Jun 2018 23:15:39 +0000 Subject: [openssl-users] Selection of DHE ciphers based on modulus size of DH In-Reply-To: References: Message-ID: <4D643F5F-3C1C-4498-BE7F-7866BA7EB128@akamai.com> Without commenting on whether or not your understanding is correct (the client gets the params and can see how big the key is, no?), I will point out that the way DHE works is defined by the IETF RFC?s, and they have not changed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Jun 7 03:10:48 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 6 Jun 2018 23:10:48 -0400 Subject: [openssl-users] Selection of DHE ciphers based on modulus size of DH In-Reply-To: <4D643F5F-3C1C-4498-BE7F-7866BA7EB128@akamai.com> References: <4D643F5F-3C1C-4498-BE7F-7866BA7EB128@akamai.com> Message-ID: <9F7699CD-9796-46BD-9531-1563CCA9BE09@dukhovni.org> > On Jun 6, 2018, at 7:15 PM, Salz, Rich via openssl-users wrote: > > Without commenting on whether or not your understanding is correct (the client gets the params and can see how big the key is, no?), I will point out that the way DHE works is defined by the IETF RFC?s, and they have not changed. However, in TLS 1.3, the FFDHE groups are pre-defined, and the server does not get to choose ad-hoc (p, g) pairs. -- Viktor. From openssl at jordan.maileater.net Thu Jun 7 03:22:01 2018 From: openssl at jordan.maileater.net (Jordan Brown) Date: Wed, 6 Jun 2018 20:22:01 -0700 Subject: [openssl-users] Selection of DHE ciphers based on modulus size of DH In-Reply-To: References: Message-ID: <6c93f4d3-f808-a037-f7fc-054437c932bc@jordan.maileater.net> On 6/6/2018 12:11 PM, Sanjaya Joshi wrote: > I understood that when DHE ciphers are tried to be used between two > entities, it's only the server that plays a role about selection of > the DH parameters. This is not negotiable with the client. For e.g., > the server can freely use a very low not-recommended DH group with 512 > bit key length and the client cannot deny it. I'm pretty sure that clients can and do refuse to talk to servers with small DH parameters. Current OpenSSL isn't willing to connect to a server using a DH key size below 1024 bits. https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ To protect OpenSSL-based clients, we?re increasing the minimum accepted DH key size to 768 bits immediately in the next release, and to 1024 bits soon after. -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From sampei02 at tiscali.it Thu Jun 7 04:14:26 2018 From: sampei02 at tiscali.it (Sampei) Date: Thu, 07 Jun 2018 06:14:26 +0200 Subject: [openssl-users] =?utf-8?q?2_openssl_installed=3F?= In-Reply-To: <32F957BF-B7F1-48B6-AC55-9BF0688893D1@foocrypt.net> References: <4ABD19A2-FCB1-49DE-9AF6-AF6E7592D344@foocrypt.net> <4bf2b9503033c86b944951950fab9390@tiscali.it> <32F957BF-B7F1-48B6-AC55-9BF0688893D1@foocrypt.net> Message-ID: t's a server installed many many years ago and there are applications which are no used. Server is too late and I have new server (latest Centos 6) for migrating where I installed latest version. I'd like to take to new server all certificate database (certificated included) which I created. Openssl is only tool to create test certificates. I don't know if there are apps which are using the e configs, but I think no. thanks Il 05.06.2018 09:37 FooCrypt ha scritto: > Yeah, typo, forgot -name > > looks like its using all the usr & lib libraries and nothing from /usr/local/?.. where you 97e files are. > > I don't know what you are using that system for, but is there a reason why you are not running 1.0.2g or g+ ? > > Are there other apps on the host which are using the e configs ? > >> On 5 Jun 2018, at 4:53 PM, Sampei wrote: Perhaps it's missing -'name openssl' in the 3 commands. However I run: 1) find / -type f -name openssl -exec ldd {} ; libssl.so.4 => /lib/libssl.so.4 (0x0098f000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00718000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00830000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x006ee000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x0080c000) libresolv.so.2 => /lib/libresolv.so.2 (0x006d9000) libcrypto.so.4 => /lib/libcrypto.so.4 (0x0089b000) libdl.so.2 => /lib/libdl.so.2 (0x0067c000) libz.so.1 => /usr/lib/libz.so.1 (0x00682000) libc.so.6 => /lib/libc.so.6 (0x0052a000) /lib/ld-linux.so.2 (0x0050c000) 2) find / -type f -name openssl -exec objdump -x {} ; /usr/bin/openssl: file format elf32-i386 /usr/bin/openssl architecture: i386, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x08054490 Program Header: PHDR off 0x00000034 vaddr 0x08048034 paddr 0x08048034 align 2**2 filesz 0x000000e0 memsz 0x000000e0 flags r-x INTERP off 0x00000114 vaddr 0x08048114 paddr 0x08048114 align 2**0 filesz 0x00000013 memsz 0x00000013 flags r-- LOAD off 0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12 filesz 0x0004f678 memsz 0x0004f678 flags r-x LOAD off 0x00050000 vaddr 0x08098000 paddr 0x08098000 align 2**12 filesz 0x00007174 memsz 0x00007174 flags rw- DYNAMIC off 0x00052420 vaddr 0x0809a420 paddr 0x0809a420 align 2**2 filesz 0x00000110 memsz 0x00000110 flags rw- NOTE off 0x00000128 vaddr 0x08048128 paddr 0x08048128 align 2**2 filesz 0x00000020 memsz 0x00000020 flags r-- STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2 filesz 0x00000000 memsz 0x00000000 flags rw- Dynamic Section: NEEDED libssl.so.4 NEEDED libgssapi_krb5.so.2 NEEDED libkrb5.so.3 NEEDED libcom_err.so.2 NEEDED libk5crypto.so.3 NEEDED libresolv.so.2 NEEDED libcrypto.so.4 NEEDED libdl.so.2 NEEDED libz.so.1 NEEDED libc.so.6 INIT 0x80516f8 FINI 0x8086ca8 HASH 0x8048148 STRTAB 0x809becc SYMTAB 0x804958c STRSZ 0x3295 SYMENT 0x10 DEBUG 0x0 PLTGOT 0x809a544 PLTRELSZ 0x16b8 PLTREL 0x11 JMPREL 0x8050040 REL 0x804fed0 RELSZ 0x170 RELENT 0x8 VERNEED 0x804fe90 VERNEEDNUM 0x1 VERSYM 0x804f882 0x6ffffef9 0x804c5ec 0x6ffffdf7 0xdc 0x6ffffef8 0x804c6c8 0x6ffffdf6 0x108 Version References: required from libc.so.6: 0x0d696913 0x00 04 GLIBC_2.3 0x0d696911 0x00 03 GLIBC_2.1 0x0d696910 0x00 02 GLIBC_2.0 Sections: Idx Name Size VMA LMA File off Algn 0 .interp 00000013 08048114 08048114 00000114 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .note.ABI-tag 00000020 08048128 08048128 00000128 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .hash 00001444 08048148 08048148 00000148 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .dynsym 00003060 0804958c 0804958c 0000158c 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .gnu.liblist 000000dc 0804c5ec 0804c5ec 000045ec 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .gnu.conflict 00000108 0804c6c8 0804c6c8 000046c8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .gnu.version 0000060c 0804f882 0804f882 00007882 2**1 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .gnu.version_r 00000040 0804fe90 0804fe90 00007e90 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .rel.dyn 00000170 0804fed0 0804fed0 00007ed0 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 9 .rel.plt 000016b8 08050040 08050040 00008040 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 10 .init 00000017 080516f8 080516f8 000096f8 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 11 .plt 00002d80 08051710 08051710 00009710 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 12 .text 00032818 08054490 08054490 0000c490 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 13 .fini 0000001b 08086ca8 08086ca8 0003eca8 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 14 .rodata 00010991 08086ce0 08086ce0 0003ece0 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 15 .eh_frame 00000004 08097674 08097674 0004f674 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 16 .data 00002420 08098000 08098000 00050000 2**5 CONTENTS, ALLOC, LOAD, DATA 17 .dynamic 00000110 0809a420 0809a420 00052420 2**2 CONTENTS, ALLOC, LOAD, DATA 18 .ctors 00000008 0809a530 0809a530 00052530 2**2 CONTENTS, ALLOC, LOAD, DATA 19 .dtors 00000008 0809a538 0809a538 00052538 2**2 CONTENTS, ALLOC, LOAD, DATA 20 .jcr 00000004 0809a540 0809a540 00052540 2**2 CONTENTS, ALLOC, LOAD, DATA 21 .got 00000c20 0809a544 0809a544 00052544 2**2 CONTENTS, ALLOC, LOAD, DATA 22 .bss 00000d4c 0809b180 0809b180 00053180 2**5 CONTENTS, ALLOC, LOAD, DATA 23 .dynstr 000032a8 0809becc 0809becc 00053ecc 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 24 .gnu_debuglink 00000014 00000000 00000000 00057174 2**2 CONTENTS, READONLY 25 .gnu.prelink_undo 000004d4 00000000 00000000 00057188 2**2 CONTENTS, READONLY SYMBOL TABLE: no symbols 3) find / -type f -name openssl - exec {} version ; OpenSSL 0.9.7a Feb 19 2003 Il 04.06.2018 14:35 FooCrypt ha scritto: >> >>> find / -type f -exec {} version ; find / -type f -exec objdump -x {} ; find / -type f -exec ldd {} ; looks like you only have 1 openssl binary, 0.9.7.a on your host. objdump -x & ldd will show you which libraries the openssl binary is compiled to use on your host. so?. objdump -x [ full path to your openssl binary ] ldd [ full path to your openssl binary ] >>> >>>> On 4 Jun 2018, at 10:18 PM, Sampei wrote: Here is result for first command: find / -type f -name openssl -exec {} version ; OpenSSL 0.9.7a Feb 19 2003 What means repeat with? What I have to type for next comand exactly please? objdump -x & ldd..... Il 04.06.2018 08:30 FooCrypt ha scritto: >>>> >>>>> find / -type f -name openssl -exec {} version ; repeat with objdump -x & ldd to determine which libraries, etc are being used. >>>>> >>>>>> On 4 Jun 2018, at 3:47 PM, Sampei wrote: Can you help to understand if I have 2 OPenSSL installed into my "old old" server please? rpm -qa | grep openssl gives: openssl-0.9.7a-33.10 Furthermore I found out following files into /usr/local/openssl-0.9.7e (perhaps a uncompressed tar file) : apps CHANGES.SSLeay Configure diffs.6e diffs.sec6 doc FAQ install.com INSTALL.VMS MacOS makevms.com openssl.doxy PROBLEMS shlib tools bugs comms.txt crypto diffs.6x diffs.sec6e do_patch.sh fips INSTALL.DJGPP INSTALL.W32 Makefile ms openssl.spec README ssl util certs comm.txt demos diffs.7 diffs.sec7 e_os2.h include INSTALL.MacOS INSTALL.WCE Makefile.bak NEWS os2 README.ASN1 test VMS CHANGES config diffs.6 diffs.sec diffs.secfix e_os.h INSTALL INSTALL.OS2 LICENSE Makefile.org op perl README.ENGINE times If I find .cnf files: /usr/local/openssl-0.9.7e/apps/oid.cnf /usr/local/openssl-0.9.7e/apps/openssl.cnf /usr/local/openssl-0.9.7e/apps/openssl-vms.cnf /usr/local/openssl-0.9.7e/crypto/conf/ssleay.cnf /usr/local/openssl-0.9.7e/test/CAss.cnf /usr/local/openssl-0.9.7e/test/CAssdh.cnf /usr/local/openssl-0.9.7e/test/CAssdsa.cnf /usr/local/openssl-0.9.7e/test/CAssrsa.cnf /usr/local/openssl-0.9.7e/test/Sssdsa.cnf /usr/local/openssl-0.9.7e/test/Sssrsa.cnf /usr/local/openssl-0.9.7e/test/test.cnf /usr/local/openssl-0.9.7e/test/Uss.cnf /usr/share/ssl/openssl.cnf What do you think? Con Mobile Open 6 GB hai 6 Giga, 600 minuti e 300 SMS per il tuo smartphone a 9EUR al mese per sempre. Passa ora a Tiscali Mobile, il nostro mese ? vero! http://tisca.li/Open6GB0318 [2] -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users [3] >>>>> -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users [4] >>>> Con Mobile Open 6 GB hai 6 Giga, 600 minuti e 300 SMS per il tuo smartphone a 9EUR al mese per sempre. Passa ora a Tiscali Mobile, il nostro mese ? vero! http://tisca.li/Open6GB0318 [6] -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users [7] >>> -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users [8] >> Con Mobile Open 6 GB hai 6 Giga, 600 minuti e 300 SMS per il tuo smartphone a 9EUR al mese per sempre. Passa ora a Tiscali Mobile, il nostro mese ? vero! http://tisca.li/Open6GB0318 [10] -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users [11] > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users [12] Con Mobile Open 6 GB hai 6 Giga, 600 minuti e 300 SMS per il tuo smartphone a 9? al mese per sempre. Passa ora a Tiscali Mobile, il nostro mese ? vero! http://tisca.li/Open6GB0318 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshi.sanjaya at gmail.com Thu Jun 7 06:22:55 2018 From: joshi.sanjaya at gmail.com (Sanjaya Joshi) Date: Thu, 7 Jun 2018 11:52:55 +0530 Subject: [openssl-users] Selection of DHE ciphers based on modulus size of DH In-Reply-To: <6c93f4d3-f808-a037-f7fc-054437c932bc@jordan.maileater.net> References: <6c93f4d3-f808-a037-f7fc-054437c932bc@jordan.maileater.net> Message-ID: Hello, Thank you all for your responses. I forgot to mention that we are on OpenSSL 1.1.0 and TLS 1.2. I have some more queries though. >>Current OpenSSL isn't willing to connect to a server using a DH key size below 1024 bits. Yes, i have verified this. However, not sure, how my OpenSSL-based client can do this, as our requirement is that we must not use DH key size below 2048 bits. >> I'm pretty sure that clients can and do refuse to talk to servers with small DH parameters. Could you please provide some more clues how a client can do so ? >> However, in TLS 1.3, the FFDHE groups are pre-defined, and the server >>does not get to choose ad-hoc (p, g) pairs Yep; i saw them. Here, client plays a role to offer the supported DHE first and then, the server can use that - just like elliptic curve negotiation. But again, one catch is that custom DH groups are no more allowed, for which i didn't find a good reasoning. Regards, Sanjaya On Thu, Jun 7, 2018 at 8:52 AM, Jordan Brown wrote: > On 6/6/2018 12:11 PM, Sanjaya Joshi wrote: > > I understood that when DHE ciphers are tried to be used between two > entities, it's only the server that plays a role about selection of the DH > parameters. This is not negotiable with the client. For e.g., the server > can freely use a very low not-recommended DH group with 512 bit key length > and the client cannot deny it. > > > I'm pretty sure that clients can and do refuse to talk to servers with > small DH parameters. > > Current OpenSSL isn't willing to connect to a server using a DH key size > below 1024 bits. > > https://www.openssl.org/blog/blog/2015/05/20/logjam-freak- > upcoming-changes/ > > To protect OpenSSL-based clients, we?re increasing the minimum accepted DH > key size to 768 bits immediately in the next release, and to 1024 bits soon > after. > > > -- > Jordan Brown, Oracle Solaris > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajay.nalawade at gmail.com Thu Jun 7 07:03:29 2018 From: ajay.nalawade at gmail.com (Ajay Nalawade) Date: Thu, 7 Jun 2018 12:33:29 +0530 Subject: [openssl-users] Openssl 1.0.2o issue with FIPS mode set. Message-ID: Hello, I have golang based openssl server with FIPS mode set. I am using Openssl library build with fips module 2.0. With Openssl 1.0.1u version, everything was running fine. Recently I upgraded to version 1.0.2o. With this version, under high traffic condition (more than 4k requests per minute), read request fails with following error. "SSL errors: SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac" If I disable FIPS mode, every thing runs fine. Is there any known issue with version 1.0.2o with FIPS mode set. Thanks a lot in advance, Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Jun 7 08:04:32 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 7 Jun 2018 09:04:32 +0100 Subject: [openssl-users] Selection of DHE ciphers based on modulus size of DH In-Reply-To: <9F7699CD-9796-46BD-9531-1563CCA9BE09@dukhovni.org> References: <4D643F5F-3C1C-4498-BE7F-7866BA7EB128@akamai.com> <9F7699CD-9796-46BD-9531-1563CCA9BE09@dukhovni.org> Message-ID: On 07/06/18 04:10, Viktor Dukhovni wrote: > > >> On Jun 6, 2018, at 7:15 PM, Salz, Rich via openssl-users wrote: >> >> Without commenting on whether or not your understanding is correct (the client gets the params and can see how big the key is, no?), I will point out that the way DHE works is defined by the IETF RFC?s, and they have not changed. > > However, in TLS 1.3, the FFDHE groups are pre-defined, and the server > does not get to choose ad-hoc (p, g) pairs. Although OpenSSL does not currently support FFDHE groups in TLSv1.3. Matt From clint at screwtape.co.uk Thu Jun 7 11:50:37 2018 From: clint at screwtape.co.uk (Clint Redwood) Date: Thu, 7 Jun 2018 11:50:37 +0000 Subject: [openssl-users] Building OpenSSL 1.1.0h on HPUX 11 PARISC2 64bit Message-ID: Hi! Since I can?t find any current pre-build versions of OpenSSL for this platform, I am trying to build OpenSSL 1.1.0h with GCC 4.6.1 on HPUX 11.0. I?ve tried a basic ./config approach but that appears to select hpux-parisc1_1-gcc when I want PARISC2. I tried building it, but had problems a) with several .s assembly files not compiling with the gnu assembler (but they do compile with the native hpux assembler) b) when trying to link getting a "missing /opt/langtools/lib/libcomp.sl" which I understand from a few forum entries is redundant in HPUX 11 (I can't see why it's being requested anyway) So I checked wondered if the problem is that it is configuring for the wrong platform, so I have reviewed the code in "config", and in line 778 the OUT variable is set to "hpux-parisc1_1-$(CC)" with a comment saying that PARISC2 is no longer supported in a 32 bit build. However, I'm trying to build it in 64 bit. I've tried commenting this line out, and configuring for hpux-parisc2-gcc, and I still get the assembly failures, but I now also get compile failures in Crypto/dso/dso_dlfcn.c: 314:5 error: unknown type name 'Dl_info' 328:30 error:request for member 'dli_fname' in something not a structure or union 333:25 error:request for member 'dli_fname' in something not a structure or union I've not been able to get past this point, so I don't know if the linking would be a problem. Given I'm trying to build for 64 bit, should this be built for parisc_1_1 or parisc2, and how might I go about fixing these issues? Thanks! Yours, Clint Redwood Screwtape Limited, Registered 06663232, Babington House, 26 College Road, Chilwell, Nottingham NG9 4AS From clint at screwtape.co.uk Thu Jun 7 12:11:58 2018 From: clint at screwtape.co.uk (Clint Redwood) Date: Thu, 7 Jun 2018 12:11:58 +0000 Subject: [openssl-users] Building OpenSSL 1.1.0h on HPUX 11 PARISC2 64bit Message-ID: <1775534A-6FB9-4468-A44B-CA5430D6FF08@screwtape.co.uk> Hi! Since I can?t find any current pre-build versions of OpenSSL for this platform, I am trying to build OpenSSL 1.1.0h with GCC 4.6.1 on HPUX 11.0. I?ve tried a basic ./config approach but that appears to select hpux-parisc1_1-gcc when I want PARISC2. I tried building it, but had problems a) with several .s assembly files not compiling with the gnu assembler (but they do compile with the native hpux assembler) b) when trying to link getting a "missing /opt/langtools/lib/libcomp.sl" which I understand from a few forum entries is redundant in HPUX 11 (I can't see why it's being requested anyway) So I checked wondered if the problem is that it is configuring for the wrong platform, so I have reviewed the code in "config", and in line 778 the OUT variable is set to "hpux-parisc1_1-$(CC)" with a comment saying that PARISC2 is no longer supported in a 32 bit build. However, I'm trying to build it in 64 bit. I've tried commenting this line out, and configuring for hpux-parisc2-gcc, and I still get the assembly failures, but I now also get compile failures in Crypto/dso/dso_dlfcn.c: 314:5 error: unknown type name 'Dl_info' 328:30 error:request for member 'dli_fname' in something not a structure or union 333:25 error:request for member 'dli_fname' in something not a structure or union I've not been able to get past this point, so I don't know if the linking would be a problem. Given I'm trying to build for 64 bit, should this be built for parisc_1_1 or parisc2, and how might I go about fixing these issues? Thanks! Yours, Clint Redwood Screwtape Limited, Registered 06663232, Babington House, 26 College Road, Chilwell, Nottingham NG9 4AS From openssl at foocrypt.net Thu Jun 7 12:52:49 2018 From: openssl at foocrypt.net (FooCrypt) Date: Thu, 7 Jun 2018 22:52:49 +1000 Subject: [openssl-users] Building OpenSSL 1.1.0h on HPUX 11 PARISC2 64bit In-Reply-To: <1775534A-6FB9-4468-A44B-CA5430D6FF08@screwtape.co.uk> References: <1775534A-6FB9-4468-A44B-CA5430D6FF08@screwtape.co.uk> Message-ID: <4A9D7EE1-C132-4D2F-BE6E-19F1D6A5FFB1@foocrypt.net> Hi Clint its been awhile since I built on 11i, have you tried : http://hpux.connect.org.uk/hppd/hpux/Development/Libraries/openssl-1.0.2j/ http://hpux.connect.org.uk/hppd/hpux/Development/Libraries/ ??? They appear to have build notes here : http://hpux.connect.org.uk/hppd/cgi-bin/wwwtar?/hpux/Development/Libraries/openssl-1.0.2o/openssl-1.0.2o-src-11.31.tar.gz+openssl-1.0.2o/HPUX.Install+text > On 7 Jun 2018, at 10:11 PM, Clint Redwood wrote: > > Hi! > > Since I can?t find any current pre-build versions of OpenSSL for this platform, I am trying to build OpenSSL 1.1.0h with GCC 4.6.1 on HPUX 11.0. > > I?ve tried a basic ./config approach but that appears to select hpux-parisc1_1-gcc when I want PARISC2. > > I tried building it, but had problems > a) with several .s assembly files not compiling with the gnu assembler (but they do compile with the native hpux assembler) > b) when trying to link getting a "missing /opt/langtools/lib/libcomp.sl" which I understand from a few forum entries is redundant in HPUX 11 (I can't see why it's being requested anyway) > > So I checked wondered if the problem is that it is configuring for the wrong platform, so I have reviewed the code in "config", and in line 778 the OUT variable is set to "hpux-parisc1_1-$(CC)" with a comment saying that PARISC2 is no longer supported in a 32 bit build. However, I'm trying to build it in 64 bit. > > I've tried commenting this line out, and configuring for hpux-parisc2-gcc, and I still get the assembly failures, but I now also get compile failures in > Crypto/dso/dso_dlfcn.c: > 314:5 error: unknown type name 'Dl_info' > 328:30 error:request for member 'dli_fname' in something not a structure or union > 333:25 error:request for member 'dli_fname' in something not a structure or union > > I've not been able to get past this point, so I don't know if the linking would be a problem. > > Given I'm trying to build for 64 bit, should this be built for parisc_1_1 or parisc2, and how might I go about fixing these issues? > > Thanks! > > Yours, > > Clint Redwood > > Screwtape Limited, Registered 06663232, Babington House, 26 College Road, Chilwell, Nottingham NG9 4AS > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From openssl at jordan.maileater.net Thu Jun 7 15:02:40 2018 From: openssl at jordan.maileater.net (Jordan Brown) Date: Thu, 7 Jun 2018 08:02:40 -0700 Subject: [openssl-users] Selection of DHE ciphers based on modulus size of DH In-Reply-To: References: <6c93f4d3-f808-a037-f7fc-054437c932bc@jordan.maileater.net> Message-ID: On 6/6/2018 11:22 PM, Sanjaya Joshi wrote: > >>Current OpenSSL isn't willing to connect to a server using a DH key size > below 1024 bits. > Yes, i have verified this. However, not sure, how my OpenSSL-based > client can do this, as our requirement is that we must not use DH key > size below 2048 bits. > > >> I'm pretty sure that clients can and do refuse to talk to servers > with small DH parameters. > Could you please provide some more clues how a client can do so ? The 1024-bit DH limit is implemented in the OpenSSL client library.? I don't know if the calling application has any control or any visibility onto that decision. (But note: it's still the client that's making the decision, from the perspective of the TLS protocol.) A bit of searching later... It looks like the key test is here: https://github.com/openssl/openssl/blob/e6e9170d6e28038768895e1af18e3aad8093bf4b/ssl/ssl_cert.c#L921 /* * No EDH keys weaker than 1024-bits even at level 0, otherwise, * anything goes. */ if (op == SSL_SECOP_TMP_DH && bits < 80) return 0; return 1; and it looks like you can plug in your own function using SSL_set_security_callback.? I do not understand, however, how the 80 relates to a 1024-bit limit. Here's the documentation: https://www.openssl.org/docs/man1.1.0/ssl/SSL_set_security_callback.html -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Jun 7 15:13:39 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 7 Jun 2018 16:13:39 +0100 Subject: [openssl-users] Selection of DHE ciphers based on modulus size of DH In-Reply-To: References: <6c93f4d3-f808-a037-f7fc-054437c932bc@jordan.maileater.net> Message-ID: <1694a847-a914-f632-d64e-64d8eea94a1a@openssl.org> On 07/06/18 16:02, Jordan Brown wrote: > I do not understand, however, how the 80 relates to a 1024-bit limit. It's a measure of the "security bits" of an algorithm according to table 2 in this doc: https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r4.pdf Matt From jon.page at pnnl.gov Thu Jun 7 16:57:26 2018 From: jon.page at pnnl.gov (wazzu62) Date: Thu, 7 Jun 2018 09:57:26 -0700 (MST) Subject: [openssl-users] openssl problems Message-ID: <1528390646208-0.post@n7.nabble.com> I will preface this with the fact I am not an ssl expert. I am trying to resolve an issue I am having with apache and a reverse proxy that I think is ssl related. Attempts to connect to the reverse proxy endpoint via a browser generate the following error in the apache log file [Tue May 29 09:14:36.494710 2018] [ssl:info] [pid 23700:tid 139947205977856] SSL Library Error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number When I run the following command on the server the reverse proxy is pointing to I get a similar error *openssl s_client -connect localhost:443* CONNECTED(00000003) 140508314333632:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:252: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 5 bytes and written 176 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1528389016 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no If I run that same command on the front end server running apache that has the reverse proxy configuration I get the following *openssl s_client -connect localhost:443* CONNECTED(00000003) depth=0 CN = 1804-repo verify return:1 --- Certificate chain 0 s:/CN=1804-repo i:/CN=1804-repo --- Server certificate -----BEGIN CERTIFICATE----- MIICzjCCAbagAwIBAgIJAPiVKPiTG4FhMA0GCSqGSIb3DQEBCwUAMBQxEjAQBgNV BAMMCTE4MDQtcmVwbzAeFw0xODAzMjIyMjUyMzNaFw0yODAzMTkyMjUyMzNaMBQx EjAQBgNVBAMMCTE4MDQtcmVwbzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAK3w7ErX2bo7ijEx0jEGi+MzkceAIU6km0G7+q9wRJ7u7qy1HMvfynjKQnrK AmIqwPsKr4kJl4m/cn6Wv1u7E53ZEiNpjs8qO73xOS/C/Sqs0f9vbBFNu1DYGcFZ MtJVWSvPz9aPUnNu5IfL6tUI/yRThKa6YXrjOX35NxxmvK0eQMROGx9LJ8Hz9/Ld 4z0znsLgZFOQL1ssx4xDzJ6M5hnaTBOkfJn/yDiaEOH4RlRKE9rBi5BD6wPa5jIC L9SU2+1VkicWZUoYyXI4N7EYS8dznYMpVaQbUTjsKktgN0R8zZXTdF84CFkI8w11 Buacbsf8B4Ea8qqUSvVoFdreANMCAwEAAaMjMCEwCQYDVR0TBAIwADAUBgNVHREE DTALggkxODA0LXJlcG8wDQYJKoZIhvcNAQELBQADggEBAIHKZbF97JWPrw058upQ 7cngDwOOKYQDkOo1HWWfAfK2rWeBvwEDvZmebM8S6Sx9ccJxjf80o17tJA6dJ+Uz KR2ip45VCbwK64SpKAeKfnqgTEvliUV7eMCjpG6pP+MuTnKCglRtAtS9TiEddj1A h13uXDl2kInNyU+Hbk65mFRWsX4f7JTTDqMB0MCALW3H4RhnAIX5j5viyXL0qbE0 KNkM9S7sgei67RAl6XlAo/KQ8PNU5jWkjWMkGC0TdgeUI0H79R35sGBXKCWJ6w0v mqCh2C5zX9yDzKQoQaFWi0UFzknO+178rGB9FIYBkF4CliQSji8yXhWSwa4K74+M 2AE= -----END CERTIFICATE----- subject=/CN=1804-repo issuer=/CN=1804-repo --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: X25519, 253 bits --- SSL handshake has read 1379 bytes and written 269 bytes Verification: OK --- New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 4F1F7BFC0A73D9CF792319A42D06FB553638D774A9DE31E66A0B094876E2C379 Session-ID-ctx: Master-Key: 6274D9B869D4281E2A538171E282B74DF5476F7A1195E38E5DE6454DA14C2F57654048DC4A774985CE45F290111D976C PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 54 47 a8 3a 25 5f 30 b2-4a d7 69 5a 6b 94 32 ff TG.:%_0.J.iZk.2. 0010 - 12 50 ab e7 8a 46 f4 15-2f 1d 4a 1f 8f fd 2c e4 .P...F../.J...,. 0020 - d5 1a d8 06 74 0a 26 74-3d af 2a f6 81 72 40 33 ....t.&t=.*..r at 3 0030 - 9e 5a 49 a6 a4 3d c5 1c-2e 80 ea d6 30 25 00 4f .ZI..=......0%.O 0040 - 34 06 d8 38 a1 b5 2c 63-38 50 46 ac 15 36 ad dd 4..8..,c8PF..6.. 0050 - ed 10 3c 1e 35 6d 5d 11-46 ab 8f a5 51 8e 51 ea ..<.5m].F...Q.Q. 0060 - cb 22 13 7f 6e ea 8d 9b-08 07 6f 98 24 43 ab 70 ."..n.....o.$C.p 0070 - bf b6 e9 37 b0 b9 51 aa-41 96 3d 55 25 ba 17 78 ...7..Q.A.=U%..x 0080 - dc c0 d5 91 f0 4f 61 d5-c4 46 09 0b 2d c7 35 26 .....Oa..F..-.5& 0090 - ed 2d 51 90 0b 29 08 51-5a 59 19 00 b8 95 ea 16 .-Q..).QZY...... 00a0 - c2 f2 c9 ed f9 13 df a5-c4 f6 d1 69 ba 84 9a c4 ...........i.... 00b0 - bd 68 c7 f1 7f d8 60 d4-27 b4 d4 3c a4 ef cc 5b .h....`.'..<...[ Start Time: 1528389796 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: yes --- closed So I suspect my whole problem stems from the *SSL routines:ssl3_get_record:wrong version number* but I have no idea how to resolve this. I have tried searching for answers, but nothing seems to help. In inherited this problem and the folks who set this up are no longer around to be able to ask questions. Any assistance would be greatly appreciated. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From Michael.Wojcik at microfocus.com Thu Jun 7 18:07:00 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 7 Jun 2018 18:07:00 +0000 Subject: [openssl-users] openssl problems In-Reply-To: <1528390646208-0.post@n7.nabble.com> References: <1528390646208-0.post@n7.nabble.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of wazzu62 > Sent: Thursday, June 07, 2018 10:57 > Attempts to connect to the reverse proxy endpoint via a browser generate > the following error in the apache log file By "the apache log file", you mean the log for the origin server, behind the reverse proxy? Or the log file for the reverse proxy itself? > [Tue May 29 09:14:36.494710 2018] [ssl:info] [pid 23700:tid 139947205977856] > SSL Library Error: error:1408F10B:SSL routines:ssl3_get_record:wrong version > number What version of OpenSSL is Apache using? Or if it's not using OpenSSL, what TLS implementation is it using? (Presumably that appears in the log somewhere, and if not you can find it by running strings or similar against the OpenSSL library it's using.) Assuming it's a fairly recent 1.0.2 build (i.e., a fairly up-to-date release of the LTS branch), there are a few places where the "wrong version number" error is produced. Here we see it's coming from ssl3_get_record. That could mean: - OpenSSL received an SSL record that had a different version number than what the client sent in its ClientHello message. Could be due to a broken client, garbage on the wire, etc. - OpenSSL received an SSL record that didn't have a major version number of 3. Major version 3 is used for SSLv3 and TLSv1, so basically for everything. (If you have a client that's using SSLv2, it's wasting its time; SSLv2 is hopelessly insecure.) So if the major version isn't 3, then something is quite wrong, AFAIK. > When I run the following command on the server the reverse proxy is > pointing > to I get a similar error > *openssl s_client -connect localhost:443* > CONNECTED(00000003) > 140508314333632:error:1408F10B:SSL routines:ssl3_get_record:wrong > version > number:../ssl/record/ssl3_record.c:252: It looks to me like the server has a broken SSL configuration or a broken SSL implementation. If you were running s_client against an endpoint that wasn't using SSL/TLS at all, I'd expect to see an earlier error, such as "unknown protocol", from openssl s_client. So it looks like your server is sending a ServerHello in response to the ClientHello. After that it all goes wrong, though. A wire trace might be informative, if the problem isn't obvious from inspecting the software and configuration being used by the origin server. Wireshark's SSL/TLS dissector does a decent job with the unencrypted parts of the conversation, and it doesn't look like you're getting far enough to have anything encrypted. -- Michael Wojcik Distinguished Engineer, Micro Focus From angus at magsys.co.uk Thu Jun 7 18:48:00 2018 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Thu, 7 Jun 2018 19:48 +0100 (BST) Subject: [openssl-users] Confused about client side session caching Message-ID: I'm reading the TLSv1.3 notes that suggest SSL_CTX_sess_set_get_cb is called for both clients and servers, but am confused by the documentation. The 1.1.1 manual page still starts 'provide callback functions for server side external session caching' with no mention of clients. I'm updating code that supports 1.0.2 to 1.1.1 for external session caching, for clients and servers, so particularly interested when client session callbacks arrived. The TLSv1.3 notes suggest the callback worked for clients in 1.1.0, a quick test suggests it actually gets called in 1.0.2 as well. Is this correct? Has OpenSSL internal session caching improved over the years so that external caching is no longer necessary? Angus From chris.gray at kiffer.be Thu Jun 7 19:38:25 2018 From: chris.gray at kiffer.be (chris.gray at kiffer.be) Date: Thu, 7 Jun 2018 20:38:25 +0100 Subject: [openssl-users] PRNG is not seeded In-Reply-To: References: <2c8ab346-1279-28a3-bc09-49ef0ac025ce@binect.de>, Message-ID: <92ed3e601b96053b44226564b5b289c4.squirrel@koningbalthazar.be> > Of course people have been harvesting entropy, or trying to, from network > sources for decades. There's a famous paragraph regarding it in RFC 4086, > which is an expanded version of a similar statement from RFC 1750 (1994): > > Other external events, such as network packet arrival times and > lengths, can also be used, but only with great care. In particular, > the possibility of manipulation of such network traffic measurements > by an adversary and the lack of history at system start-up must be > carefully considered. If this input is subject to manipulation, it > must not be trusted as a source of entropy. > > (RFC 4086, 3.5) Good point about the possibility of manipulation; it sounds a bit far-fetched but so did a lot of other exploits before they became a reality. > More generally: It's often possible to harvest quite a bit of information > that can't be adequately predicted or statistically modeled by an attacker > from network sources, and these days distilling CPRNG entropy from such > inputs is straightforward thanks to the use of cryptographic compression > functions. It's the edge cases that bite you. 4086 mentions attacker > manipulation (flooding network sources with known data to flush entropy > out of the pool) and start-up (if you don't have persistent storage of > adequate seed material). Embedded devices may suffer from too little, or > too predictable, network traffic in their limited reception area. > > You can get stronger guarantees from hardware entropy devices, which are > cheap (in every sense: component cost, power consumption, size, ...). So > there's not a lot of incentive to do more research into gathering entropy > from external sources - it makes more sense to lean on device > manufacturers, or use add-on devices. Or carry forward entropy across reboots, provided that can be done without exposing another attack surface; or obtaining entropy from a trusted source if you can figure out how to make a secure connection with that source. My experience with "lean[ing] on device manufacturers" is not all that positive. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From matt at openssl.org Thu Jun 7 20:32:00 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 7 Jun 2018 21:32:00 +0100 Subject: [openssl-users] openssl problems In-Reply-To: <1528390646208-0.post@n7.nabble.com> References: <1528390646208-0.post@n7.nabble.com> Message-ID: <6c4f5b89-4bc2-635f-93c1-ff2dc5b7840a@openssl.org> On 07/06/18 17:57, wazzu62 wrote: > When I run the following command on the server the reverse proxy is pointing > to I get a similar error > *openssl s_client -connect localhost:443* > CONNECTED(00000003) > 140508314333632:error:1408F10B:SSL routines:ssl3_get_record:wrong version > number:../ssl/record/ssl3_record.c:252: Can you get a wireshark trace of the above? Or failing that, what is the output from s_client if you add the "-debug" option? Matt From jon.page at pnnl.gov Thu Jun 7 20:40:58 2018 From: jon.page at pnnl.gov (wazzu62) Date: Thu, 7 Jun 2018 13:40:58 -0700 (MST) Subject: [openssl-users] openssl problems In-Reply-To: <6c4f5b89-4bc2-635f-93c1-ff2dc5b7840a@openssl.org> References: <1528390646208-0.post@n7.nabble.com> <6c4f5b89-4bc2-635f-93c1-ff2dc5b7840a@openssl.org> Message-ID: <1528404058222-0.post@n7.nabble.com> I will look into the wireshark trace Here is the output with the debug option CONNECTED(00000003) write to 0x55f11344dea0 [0x55f11345f100] (176 bytes => 176 (0xB0)) 0000 - 16 03 01 00 ab 01 00 00-a7 03 03 8c 1a 33 4f 8e .............3O. 0010 - fb e3 3f 51 82 36 ae 38-5e 86 3c af d2 82 0f d9 ..?Q.6.8^.<..... 0020 - 1a 1c c6 8e 55 98 4e db-16 08 5a 00 00 38 c0 2c ....U.N...Z..8., 0030 - c0 30 00 9f cc a9 cc a8-cc aa c0 2b c0 2f 00 9e .0.........+./.. 0040 - c0 24 c0 28 00 6b c0 23-c0 27 00 67 c0 0a c0 14 .$.(.k.#.'.g.... 0050 - 00 39 c0 09 c0 13 00 33-00 9d 00 9c 00 3d 00 3c .9.....3.....=.< 0060 - 00 35 00 2f 00 ff 01 00-00 46 00 0b 00 04 03 00 .5./.....F...... 0070 - 01 02 00 0a 00 0a 00 08-00 1d 00 17 00 19 00 18 ................ 0080 - 00 23 00 00 00 16 00 00-00 17 00 00 00 0d 00 20 .#............. 0090 - 00 1e 06 01 06 02 06 03-05 01 05 02 05 03 04 01 ................ 00a0 - 04 02 04 03 03 01 03 02-03 03 02 01 02 02 02 03 ................ read from 0x55f11344dea0 [0x55f113455ee3] (5 bytes => 5 (0x5)) 0000 - 48 54 54 50 2f HTTP/ 140415382974912:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:252: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 5 bytes and written 176 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1528403881 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From john.sha.jiang at gmail.com Fri Jun 8 01:48:13 2018 From: john.sha.jiang at gmail.com (John Jiang) Date: Fri, 8 Jun 2018 09:48:13 +0800 Subject: [openssl-users] Call for testing TLS 1.3 In-Reply-To: References: <20180429104326.GA21314@roeckx.be> Message-ID: Is it possible to check Key/IV update feature via these tools? Thanks! 2018-05-23 20:33 GMT+08:00 Matt Caswell : > > > On 23/05/18 12:39, John Jiang wrote: > > Hi, > > If just using s_server and s_client, can I test the TLS 1.3 features, > > likes HelloRetryRequest and resumption? > > Yes. > > To create a normal (full handshake) TLSv1.3 connection just use > s_server/s_client in the normal way, e.g. > > $ openssl s_server -cert cert.pem -key key.pem > $ openssl s_client > > To test resumption first create a full handshake TLSv1.3 connection and > save the session: > > $ openssl s_server -cert cert.pem -key key.pem > $ openssl s_client -sess_out session.pem > > Close the s_client instance by entering "Q" followed by enter. Then > (without closing the s_server instance) resume the session: > > $ openssl s_client -sess_in session.pem > > > A HelloRetryRequest will occur if the key share provided by the client > is not acceptable to the server. By default the client will send an > X25519 key share, so if the server does not accept that group then an > HRR will result, e.g. > > $ openssl s_server -cert cert.pem -key key.pem -groups P-256 > $ openssl s_client > > > Of course a HelloRetryRequest all happens at the protocol layer and is > invisible as far as a user of the command line apps is concerned. You > will have to look at what happens "on the wire" to actually see it in > action - for example by using wireshark. Alternatively you can compile > OpenSSL with the "enable-ssl-trace" option, and pass the "-trace" flag > to s_server or s_client to see what protocol messages are being exchanged. > > Matt > > > > > > > 2018-04-29 18:43 GMT+08:00 Kurt Roeckx > >: > > > > The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS > > 1.3 brings a lot of changes that might cause incompatibility. For > > an overview see https://wiki.openssl.org/index.php/TLS1.3 > > > > > > We are considering if we should enable TLS 1.3 by default or not, > > or when it should be enabled. For that, we would like to know how > > applications behave with the latest beta release. > > > > When testing this, it's important that both sides of the > > connection support the same TLS 1.3 draft version. OpenSSL > > currently implements draft 26. We would like to see tests > > for OpenSSL acting as client and server. > > > > https://github.com/tlswg/tls13-spec/wiki/Implementations > > lists > > other TLS 1.3 implementations and the draft they currently > > support. Note that the versions listed there might not be for the > > latest release. It also lists some https test servers. > > > > We would really like to see a diverse set of applictions being > > tested. Please report any results you have to us. > > > > > > Kurt > > > > -- > > openssl-users mailing list > > To unsubscribe: > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From i_chacha at naver.com Fri Jun 8 07:02:36 2018 From: i_chacha at naver.com (Sangsub) Date: Fri, 8 Jun 2018 00:02:36 -0700 (MST) Subject: [openssl-users] how to import external rsa public key in openssl. Message-ID: <1528441356295-0.post@n7.nabble.com> I would like to perform operations such as RSA signature verification through an RSA public key file received from an external server. Key values are given in der format or pem format as follows. der:"30820122300d06092a864886f70d01010105000382010f003082010a02820101008ab8c549138cc59f605b50265f69ec3b8ce3b3e9af5e174d26cfe242650104bea05101189676c7a292cc6b5ae719e119e3ac29e9d3ad9dadcda496f2f7185f9c0c4872a2db124f01992b238e83fd582d8a290f2973f9cf744f1e53f8aa53a225c12299b1cc3658fb607cb5aba579832d6c2687f71300a4df3df1c1407e17d22a5c19c830ed0c5824072309a612bb3e4fb339f25bbbcfe2999f4342110649abac5f4bfea2a59cd38c173979a679afdc8baacb4e87eb50acf806cfb7407504bdac110cfbcb99c04227031e146b9f3b8377c87035690309fae9872e2c7b93e8375fccdebc4f98be1d574269c513a43594f6b8861f7464832ae99ebaceae0fcc3ac50203010001" pem_base64:"MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAirjFSROMxZ9gW1AmX2nsO4zjs+mvXhdNJs/iQmUBBL6gUQEYlnbHopLMa1rnGeEZ46wp6dOtna3NpJby9xhfnAxIcqLbEk8BmSsjjoP9WC2KKQ8pc/nPdE8eU/iqU6IlwSKZscw2WPtgfLWrpXmDLWwmh/cTAKTfPfHBQH4X0ipcGcgw7QxYJAcjCaYSuz5PsznyW7vP4pmfQ0IRBkmrrF9L/qKlnNOMFzl5pnmv3Iuqy06H61Cs+AbPt0B1BL2sEQz7y5nAQicDHhRrnzuDd8hwNWkDCfrphy4se5PoN1/M3rxPmL4dV0JpxROkNZT2uIYfdGSDKumeus6uD8w6xQIDAQAB" I want to import the above data into "struct rsa_st * rsa", but it is not working. For example, to import the rsa public key in der format, I did the following: ========================================================== char data[] = "30820122300d06092a864886f70d01010105000382010f003082010a02820101008ab8c549138cc59f605b50265f69ec3b8ce3b3e9af5e174d26cfe242650104bea05101189676c7a292cc6b5ae719e119e3ac29e9d3ad9dadcda496f2f7185f9c0c4872a2db124f01992b238e83fd582d8a290f2973f9cf744f1e53f8aa53a225c12299b1cc3658fb607cb5aba579832d6c2687f71300a4df3df1c1407e17d22a5c19c830ed0c5824072309a612bb3e4fb339f25bbbcfe2999f4342110649abac5f4bfea2a59cd38c173979a679afdc8baacb4e87eb50acf806cfb7407504bdac110cfbcb99c04227031e146b9f3b8377c87035690309fae9872e2c7b93e8375fccdebc4f98be1d574269c513a43594f6b8861f7464832ae99ebaceae0fcc3ac50203010001"; unsigned char * pArr = (unsigned char *)malloc(buf_len); RSA *pub_rsa = NULL; fnStr2Hex(pArr, data); // Converts a data array composed of strings to a hex array (pArr). pub_rsa=d2i_RSAPublicKey(NULL,&pArr,(long)buf_len); ========================================================== In this case, In d2i_RSAPublicKey function is returning NULL Pointer. I do not know what went wrong. And I do not know how to change the string data received by pem_base64 to "struct rsa_st * rsa" as well. The sample code uses a function called "ReadPublicKey", which seems to load an X.509 certificate file. I do not read the file, but I need to get the data from the server like above. Please answer the person who knows about this. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From matt at openssl.org Fri Jun 8 08:03:25 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 8 Jun 2018 09:03:25 +0100 Subject: [openssl-users] Confused about client side session caching In-Reply-To: References: Message-ID: On 07/06/18 19:48, Angus Robertson - Magenta Systems Ltd wrote: > I'm reading the TLSv1.3 notes that suggest SSL_CTX_sess_set_get_cb is > called for both clients and servers, but am confused by the > documentation. > The get_session_cb is only ever called for servers. The new_sesion_cb and remove_session_cb can be called for clients and servers. When you refer to the the "TLSv1.3 notes" do you mean this page? https://wiki.openssl.org/index.php/TLS1.3 I couldn't see anywhere on there that suggests that get_session_cb is called on clients. > The 1.1.1 manual page still starts 'provide callback functions for > server side external session caching' with no mention of clients. Ah, good point. That needs fixing. As I said above the new_session_cb and remove_session_cb can be called for clients. > > I'm updating code that supports 1.0.2 to 1.1.1 for external session > caching, for clients and servers, so particularly interested when > client session callbacks arrived. > > The TLSv1.3 notes suggest the callback worked for clients in 1.1.0, a > quick test suggests it actually gets called in 1.0.2 as well. Is this > correct? I think new_session_cb and remove_session_cb should work in 1.0.2 on clients. > Has OpenSSL internal session caching improved over the years so that > external caching is no longer necessary? Not much has changed here. It was never "necessary" on the server side - but of course it depends on what you are trying to do and whether it is appropriate for your needs. Client side caching is a bit more "limited" in its usefulness :-) Matt From matt at openssl.org Fri Jun 8 08:17:20 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 8 Jun 2018 09:17:20 +0100 Subject: [openssl-users] openssl problems In-Reply-To: <1528404058222-0.post@n7.nabble.com> References: <1528390646208-0.post@n7.nabble.com> <6c4f5b89-4bc2-635f-93c1-ff2dc5b7840a@openssl.org> <1528404058222-0.post@n7.nabble.com> Message-ID: On 07/06/18 21:40, wazzu62 wrote: > read from 0x55f11344dea0 [0x55f113455ee3] (5 bytes => 5 (0x5)) > 0000 - 48 54 54 50 2f HTTP/ Here is your problem. s_client sends a TLS ClientHello to the server. And the server responds with HTTP!!! The server is not using TLS on that port. Matt From matt at openssl.org Fri Jun 8 08:26:07 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 8 Jun 2018 09:26:07 +0100 Subject: [openssl-users] Call for testing TLS 1.3 In-Reply-To: References: <20180429104326.GA21314@roeckx.be> Message-ID: <149c2dc6-d1ed-edc8-43cc-4fe8d33ae5cb@openssl.org> On 08/06/18 02:48, John Jiang wrote: > Is it possible to check Key/IV update feature via these tools? > Thanks! Yes. See the "CONNECTED COMMANDS" sections of these pages: https://www.openssl.org/docs/manmaster/man1/s_server.html https://www.openssl.org/docs/manmaster/man1/s_client.html Basically typing "k" or "K" from an s_server/s_client session will issue a KeyUpdate message. Using the capitalised form ("K"), additionally requests a KeyUpdate from the peer. Matt > > 2018-05-23 20:33 GMT+08:00 Matt Caswell >: > > > > On 23/05/18 12:39, John Jiang wrote: > > Hi, > > If just using s_server and s_client, can I test the TLS 1.3 features, > > likes HelloRetryRequest and resumption? > > Yes. > > To create a normal (full handshake) TLSv1.3 connection just use > s_server/s_client in the normal way, e.g. > > $ openssl s_server -cert cert.pem -key key.pem > $ openssl s_client > > To test resumption first create a full handshake TLSv1.3 connection and > save the session: > > $ openssl s_server -cert cert.pem -key key.pem > $ openssl s_client -sess_out session.pem > > Close the s_client instance by entering "Q" followed by enter. Then > (without closing the s_server instance) resume the session: > > $ openssl s_client -sess_in session.pem > > > A HelloRetryRequest will occur if the key share provided by the client > is not acceptable to the server. By default the client will send an > X25519 key share, so if the server does not accept that group then an > HRR will result, e.g. > > $ openssl s_server -cert cert.pem -key key.pem -groups P-256 > $ openssl s_client > > > Of course a HelloRetryRequest all happens at the protocol layer and is > invisible as far as a user of the command line apps is concerned. You > will have to look at what happens "on the wire" to actually see it in > action - for example by using wireshark. Alternatively you can compile > OpenSSL with the "enable-ssl-trace" option, and pass the "-trace" flag > to s_server or s_client to see what protocol messages are being > exchanged. > > Matt > > > > > > > 2018-04-29 18:43 GMT+08:00 Kurt Roeckx > > >>: > > > >? ? ?The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS > >? ? ?1.3 brings a lot of changes that might cause incompatibility. For > >? ? ?an overview see https://wiki.openssl.org/index.php/TLS1.3 > > >? ? ? > > > > >? ? ?We are considering if we should enable TLS 1.3 by default or not, > >? ? ?or when it should be enabled. For that, we would like to know how > >? ? ?applications behave with the latest beta release. > > > >? ? ?When testing this, it's important that both sides of the > >? ? ?connection support the same TLS 1.3 draft version. OpenSSL > >? ? ?currently implements draft 26. We would like to see tests > >? ? ?for OpenSSL acting as client and server. > > > >? ? ?https://github.com/tlswg/tls13-spec/wiki/Implementations > > >? ? ? > lists > >? ? ?other TLS 1.3 implementations and the draft they currently > >? ? ?support. Note that the versions listed there might not be for the > >? ? ?latest release. It also lists some https test servers. > > > >? ? ?We would really like to see a diverse set of applictions being > >? ? ?tested. Please report any results you have to us. > > > > > >? ? ?Kurt > > > >? ? ?-- > >? ? ?openssl-users mailing list > >? ? ?To unsubscribe: > >? ? ?https://mta.openssl.org/mailman/listinfo/openssl-users > > >? ? ? > > > > > > > > > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > From matt at openssl.org Fri Jun 8 08:53:04 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 8 Jun 2018 09:53:04 +0100 Subject: [openssl-users] how to import external rsa public key in openssl. In-Reply-To: <1528441356295-0.post@n7.nabble.com> References: <1528441356295-0.post@n7.nabble.com> Message-ID: On 08/06/18 08:02, Sangsub wrote: > > I would like to perform operations such as RSA signature verification > through an RSA public key file received from an external server. > Key values are given in der format or pem format as follows. > > der:"30820122300d06092a864886f70d01010105000382010f003082010a02820101008ab8c549138cc59f605b50265f69ec3b8ce3b3e9af5e174d26cfe242650104bea05101189676c7a292cc6b5ae719e119e3ac29e9d3ad9dadcda496f2f7185f9c0c4872a2db124f01992b238e83fd582d8a290f2973f9cf744f1e53f8aa53a225c12299b1cc3658fb607cb5aba579832d6c2687f71300a4df3df1c1407e17d22a5c19c830ed0c5824072309a612bb3e4fb339f25bbbcfe2999f4342110649abac5f4bfea2a59cd38c173979a679afdc8baacb4e87eb50acf806cfb7407504bdac110cfbcb99c04227031e146b9f3b8377c87035690309fae9872e2c7b93e8375fccdebc4f98be1d574269c513a43594f6b8861f7464832ae99ebaceae0fcc3ac50203010001" > > pem_base64:"MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAirjFSROMxZ9gW1AmX2nsO4zjs+mvXhdNJs/iQmUBBL6gUQEYlnbHopLMa1rnGeEZ46wp6dOtna3NpJby9xhfnAxIcqLbEk8BmSsjjoP9WC2KKQ8pc/nPdE8eU/iqU6IlwSKZscw2WPtgfLWrpXmDLWwmh/cTAKTfPfHBQH4X0ipcGcgw7QxYJAcjCaYSuz5PsznyW7vP4pmfQ0IRBkmrrF9L/qKlnNOMFzl5pnmv3Iuqy06H61Cs+AbPt0B1BL2sEQz7y5nAQicDHhRrnzuDd8hwNWkDCfrphy4se5PoN1/M3rxPmL4dV0JpxROkNZT2uIYfdGSDKumeus6uD8w6xQIDAQAB" > > I want to import the above data into "struct rsa_st * rsa", but it is not > working. > > For example, to import the rsa public key in der format, I did the > following: > ========================================================== > char data[] = > "30820122300d06092a864886f70d01010105000382010f003082010a02820101008ab8c549138cc59f605b50265f69ec3b8ce3b3e9af5e174d26cfe242650104bea05101189676c7a292cc6b5ae719e119e3ac29e9d3ad9dadcda496f2f7185f9c0c4872a2db124f01992b238e83fd582d8a290f2973f9cf744f1e53f8aa53a225c12299b1cc3658fb607cb5aba579832d6c2687f71300a4df3df1c1407e17d22a5c19c830ed0c5824072309a612bb3e4fb339f25bbbcfe2999f4342110649abac5f4bfea2a59cd38c173979a679afdc8baacb4e87eb50acf806cfb7407504bdac110cfbcb99c04227031e146b9f3b8377c87035690309fae9872e2c7b93e8375fccdebc4f98be1d574269c513a43594f6b8861f7464832ae99ebaceae0fcc3ac50203010001"; > > unsigned char * pArr = (unsigned char *)malloc(buf_len); > RSA *pub_rsa = NULL; > > fnStr2Hex(pArr, data); // Converts a data array composed of strings to a hex Is that really what this function does? i.e. convert *to* hex? The buffer you are working with is already in hex - but you want it in a binary form (i.e. convert *from* hex) for the subsequent call to d2i_RSAPublicKey. But actually, probably you need to call d2i_RSA_PUBKEY instead. This is the function you need for reading a SubjectPublicKeyInfo (SPKI) format, der encoded RSA key. I took your der encoded key above and ran it through asn1parse, and it appears to be in SPKI format. > array (pArr). > pub_rsa=d2i_RSAPublicKey(NULL,&pArr,(long)buf_len); > ========================================================== > > In this case, In d2i_RSAPublicKey function is returning NULL Pointer. > I do not know what went wrong. > > And I do not know how to change the string data received by pem_base64 to > "struct rsa_st * rsa" as well. The equivalent function for reading a pem encoded RSA key in SPKI format is PEM_read_bio_RSA_PUBKEY() (or one of the other similarly named functions) described here: https://www.openssl.org/docs/man1.1.0/crypto/PEM_read_RSA_PUBKEY.html However, you don't actually have a PEM file at all. You are missing the header and footer lines. It needs to look something like this: -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAirjFSROMxZ9gW1AmX2ns O4zjs+mvXhdNJs/iQmUBBL6gUQEYlnbHopLMa1rnGeEZ46wp6dOtna3NpJby9xhf nAxIcqLbEk8BmSsjjoP9WC2KKQ8pc/nPdE8eU/iqU6IlwSKZscw2WPtgfLWrpXmD LWwmh/cTAKTfPfHBQH4X0ipcGcgw7QxYJAcjCaYSuz5PsznyW7vP4pmfQ0IRBkmr rF9L/qKlnNOMFzl5pnmv3Iuqy06H61Cs+AbPt0B1BL2sEQz7y5nAQicDHhRrnzuD d8hwNWkDCfrphy4se5PoN1/M3rxPmL4dV0JpxROkNZT2uIYfdGSDKumeus6uD8w6 xQIDAQAB -----END PUBLIC KEY----- Hope that helps, Matt From angus at magsys.co.uk Fri Jun 8 09:18:00 2018 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Fri, 8 Jun 2018 10:18 +0100 (BST) Subject: [openssl-users] Confused about client side session caching In-Reply-To: Message-ID: > The get_session_cb is only ever called for servers. The > new_sesion_cb and remove_session_cb can be called for clients and > servers. > > When you refer to the the "TLSv1.3 notes" do you mean this page? > https://wiki.openssl.org/index.php/TLS1.3 Yes, sorry I should have said SSL_CTX_sess_set_new_cb not set_get_cb. > I think new_session_cb and remove_session_cb should work in 1.0.2 > on clients. Good, that ties in with my testing, just not with the notes where you said it worked for clients in 1.1.0, suggesting it might have been introduced then. Angus From joshi.sanjaya at gmail.com Fri Jun 8 10:15:13 2018 From: joshi.sanjaya at gmail.com (Sanjaya Joshi) Date: Fri, 8 Jun 2018 15:45:13 +0530 Subject: [openssl-users] Selection of DHE ciphers based on modulus size of DH In-Reply-To: <1694a847-a914-f632-d64e-64d8eea94a1a@openssl.org> References: <6c93f4d3-f808-a037-f7fc-054437c932bc@jordan.maileater.net> <1694a847-a914-f632-d64e-64d8eea94a1a@openssl.org> Message-ID: Hello, Thank you Matt and Jordan. So, it seems that it's possible to modify my client to accept/reject the DH group key length. But i have one more issue to be clarified. Is it possible that if a client does not accept the DH group key length used by the server, then, a different possible cipher (for e.g., RSA) is tried to be negotiated. It seems that the connection is rejected, instead of falling back to a different possible cipher. At least, i tested this quickly using s_client and s_server, and the behavior is as stated above, i.e., no fallback and connection was terminated. Is this the default OpenSSL behavior or this behaviour could be modified somehow by applications ? Regards, Sanjaya On Thu, Jun 7, 2018 at 8:43 PM, Matt Caswell wrote: > > > On 07/06/18 16:02, Jordan Brown wrote: > > I do not understand, however, how the 80 relates to a 1024-bit limit. > > It's a measure of the "security bits" of an algorithm according to table > 2 in this doc: > https://nvlpubs.nist.gov/nistpubs/specialpublications/ > nist.sp.800-57pt1r4.pdf > > Matt > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From appro at openssl.org Fri Jun 8 10:19:54 2018 From: appro at openssl.org (Andy Polyakov) Date: Fri, 8 Jun 2018 12:19:54 +0200 Subject: [openssl-users] Building OpenSSL 1.1.0h on HPUX 11 PARISC2 64bit In-Reply-To: <1775534A-6FB9-4468-A44B-CA5430D6FF08@screwtape.co.uk> References: <1775534A-6FB9-4468-A44B-CA5430D6FF08@screwtape.co.uk> Message-ID: <254a0049-a05f-bb8f-d15f-79276688e722@openssl.org> Hi, > Since I can?t find any current pre-build versions of OpenSSL for this platform, I am trying to build OpenSSL 1.1.0h with GCC 4.6.1 on HPUX 11.0. > > I?ve tried a basic ./config approach but that appears to select hpux-parisc1_1-gcc when I want PARISC2. > > I tried building it, but had problems > a) with several .s assembly files not compiling with the gnu assembler (but they do compile with the native hpux assembler) > b) when trying to link getting a "missing /opt/langtools/lib/libcomp.sl" which I understand from a few forum entries is redundant in HPUX 11 (I can't see why it's being requested anyway) > > So I checked wondered if the problem is that it is configuring for the wrong platform, so I have reviewed the code in "config", and in line 778 the OUT variable is set to "hpux-parisc1_1-$(CC)" with a comment saying that PARISC2 is no longer supported in a 32 bit build. However, I'm trying to build it in 64 bit. You should keep in mind that it takes gcc that actually generates 64-bit code. While it seems to be self-obvious, it was source of confusion earlier. For example you can observe hppa2.0w-hp-hpux11.11 in gcc -v output, yet it would generate 32-bit code [even though "w" customarily is reference to 64 bits]. But let's say that your gcc generates 64-bit code. Trouble is that ./config in 1.1.0 fails to detect bitness correctly. It was corrected in master/1.1.1, but in 1.1.0 you are stuck with manual selection as argument to ./Configure. The choice is between hpux64-parisc2-cc and hpux64-parisc2-gcc. As for gnu assembler, it's known limitation. I mean yes, OpenSSL PA-RISC assembly can be compiled only with vendor assembler. So that if your gcc can't be told to use native HP-UX assembler, then you have to configure with no-asm or configure for hpux64-parirsc2-cc, i.e. vendor compiler. From i_chacha at naver.com Fri Jun 8 10:29:20 2018 From: i_chacha at naver.com (Sangsub) Date: Fri, 8 Jun 2018 03:29:20 -0700 (MST) Subject: [openssl-users] how to import external rsa public key in openssl. In-Reply-To: References: <1528441356295-0.post@n7.nabble.com> Message-ID: <1528453760545-0.post@n7.nabble.com> Thanks Matt for your reply. The purpose I am doing this is to find the modulus and exponent in the RSA public key. My sample code and the current results are shown below. ========================================================= void fnStr2Hex(char* out, char* in) { int data_len = strlen(in); char * pStr = in; int i; for(i=0; in); // print modulus bignum BN_print(STDout,pub_rsa->e); // print exponent bignum return 0; } result : error : failed d2i_RSAPublicKey I wrote the above, but I think data_len is the problem. I do not know how much size I should enter. And do I have to enter the string source without the string to hex in the d2i_RSAPublicKey function? And you said you need prefix and postfix to do PEM format. Is raw_data [] as shown below? raw_data[] = { "-----BEGIN PUBLIC KEY-----"\ "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAirjFSROMxZ9gW1AmX2ns"\ "O4zjs+mvXhdNJs/iQmUBBL6gUQEYlnbHopLMa1rnGeEZ46wp6dOtna3NpJby9xhf"\ "nAxIcqLbEk8BmSsjjoP9WC2KKQ8pc/nPdE8eU/iqU6IlwSKZscw2WPtgfLWrpXmD"\ "LWwmh/cTAKTfPfHBQH4X0ipcGcgw7QxYJAcjCaYSuz5PsznyW7vP4pmfQ0IRBkmr"\ "rF9L/qKlnNOMFzl5pnmv3Iuqy06H61Cs+AbPt0B1BL2sEQz7y5nAQicDHhRrnzuD"\ "d8hwNWkDCfrphy4se5PoN1/M3rxPmL4dV0JpxROkNZT2uIYfdGSDKumeus6uD8w6"\ "xQIDAQAB"\ "-----END PUBLIC KEY----- " After that, I coded as follows. int data_len = strlen(raw_data); BIO *bufio = NULL; RSA *pub_rsa = NULL; unsigned char * pArr = (unsigned char *)malloc(data_len); memset(pArr, 0x00, data_len); fnStr2Hex(pArr, raw_data); // for converting hex bufio = BIO_new_mem_buf((void*)pArr, data_len); if(bufio == NULL) { printf("Error (1) \n"); return -1; } PEM_read_bio_RSAPublicKey(bufio, &pub_rsa, 0, NULL); if(pub_rsa == NULL) { printf("Error (2) \n"); return -1; } } // end of main When I execute the above code, Error (2) is output. I want to be helped with the above two (DER, PEM) situations. Again, I want to find the modulus and public exponent in the RSA public key. BR, -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From jb-openssl at wisemo.com Fri Jun 8 11:00:37 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 8 Jun 2018 13:00:37 +0200 Subject: [openssl-users] Selection of DHE ciphers based on modulus size of DH In-Reply-To: References: <6c93f4d3-f808-a037-f7fc-054437c932bc@jordan.maileater.net> <1694a847-a914-f632-d64e-64d8eea94a1a@openssl.org> Message-ID: <3b7564e5-92ae-3bfe-fc8f-e84516bdfa61@wisemo.com> (Top posting for consistency). Once the client receives the TLS1.2 servers choice of DH group, it can either accept it or abort the connection. However if both client and server support the "supported_groups" extension (RFC4492) with the additional DH group identifiers in RFC7919, they can negotiate a common accepted group of desired strength, though the mechanism (like TLS1.3) is artificially limited to a fixed set of groups listed in the RFC. On 08/06/2018 12:15, Sanjaya Joshi wrote: > Hello, > Thank you Matt and Jordan. So, it seems that it's possible to modify > my client to accept/reject the DH group key length. But i have one > more issue to be clarified. > > Is it possible that if a client does not accept the DH group key > length used by the server, then, a different possible cipher (for > e.g., RSA) is tried to be negotiated. It seems that the connection is > rejected, instead of falling back to a different possible cipher. At > least, i tested this quickly using s_client and s_server, and the > behavior is as stated above, i.e., no fallback and connection was > terminated. Is this the default OpenSSL behavior or this behaviour > could be modified somehow by applications ? > > Regards, > Sanjaya > > On Thu, Jun 7, 2018 at 8:43 PM, Matt Caswell > wrote: > > > > On 07/06/18 16:02, Jordan Brown wrote: > > I do not understand, however, how the 80 relates to a 1024-bit > limit. > > It's a measure of the "security bits" of an algorithm according to > table > 2 in this doc: > https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r4.pdf > > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 matt at openssl.org Fri Jun 8 11:23:28 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 8 Jun 2018 12:23:28 +0100 Subject: [openssl-users] Confused about client side session caching In-Reply-To: References: Message-ID: <577c30d3-8310-45cf-759e-167f3488490f@openssl.org> On 08/06/18 10:18, Angus Robertson - Magenta Systems Ltd wrote: >> The get_session_cb is only ever called for servers. The >> new_sesion_cb and remove_session_cb can be called for clients and >> servers. >> >> When you refer to the the "TLSv1.3 notes" do you mean this page? >> https://wiki.openssl.org/index.php/TLS1.3 > > Yes, sorry I should have said SSL_CTX_sess_set_new_cb not set_get_cb. > >> I think new_session_cb and remove_session_cb should work in 1.0.2 >> on clients. > > Good, that ties in with my testing, just not with the notes where you > said it worked for clients in 1.1.0, suggesting it might have been > introduced then. Ah, no. It wasn't the intention to imply that. I amended the text on the wiki page. Matt From matt at openssl.org Fri Jun 8 13:03:57 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 8 Jun 2018 14:03:57 +0100 Subject: [openssl-users] how to import external rsa public key in openssl. In-Reply-To: <1528453760545-0.post@n7.nabble.com> References: <1528441356295-0.post@n7.nabble.com> <1528453760545-0.post@n7.nabble.com> Message-ID: On 08/06/18 11:29, Sangsub wrote: > char buf[2] = {0,}; > memcpy(buf, pStr, sizeof(buf)); > > out[i] = (unsigned char)strtol(buf, NULL, 16); This looks wrong. "buf" is not NUL terminated so strtol could give an incorrect result. > // raw_data is a string. Not in hex state. So I changed the contents of > raw_data [] to hex in pArr. > // The implementation of this function is above main function. > fnStr2Hex(pArr, raw_data); The function is converting from a hex string to binary data so I find it confusingly named. But it seems to be doing the right thing AFAICT aside from the issue I noted above, although I haven't tested it. > fnStr2Hex(pArr, raw_data); // for converting hex > > bufio = BIO_new_mem_buf((void*)pArr, data_len); > > if(bufio == NULL) { > printf("Error (1) \n"); > return -1; > } > > PEM_read_bio_RSAPublicKey(bufio, &pub_rsa, 0, NULL); PEM_read_bio_RSAPublicKey() expects a PEM encoded string which is what is contained in your raw_data buffer. It is incorrect to call fnStr2Hex() on it first - this will cause it to fail. As I mentioned in my previous email you should be using PEM_read_RSA_PUBKEY() instead (or PEM_read_bio_RSA_PUBKEY() etc). If you use the "non bio" version there is no need to create the mem BIO first. It will just read directly from your memory buffer. Matt From openssl-users at dukhovni.org Fri Jun 8 13:57:49 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 8 Jun 2018 09:57:49 -0400 Subject: [openssl-users] how to import external rsa public key in openssl. In-Reply-To: <1528441356295-0.post@n7.nabble.com> References: <1528441356295-0.post@n7.nabble.com> Message-ID: <9CCBF02D-0F96-4DD4-97A6-E99C98E93A9C@dukhovni.org> > On Jun 8, 2018, at 3:02 AM, Sangsub wrote: > > pem_base64:"MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAirjFSROMxZ9gW1AmX2nsO4zjs+mvXhdNJs/iQmUBBL6gUQEYlnbHopLMa1rnGeEZ46wp6dOtna3NpJby9xhfnAxIcqLbEk8BmSsjjoP9WC2KKQ8pc/nPdE8eU/iqU6IlwSKZscw2WPtgfLWrpXmDLWwmh/cTAKTfPfHBQH4X0ipcGcgw7QxYJAcjCaYSuz5PsznyW7vP4pmfQ0IRBkmrrF9L/qKlnNOMFzl5pnmv3Iuqy06H61Cs+AbPt0B1BL2sEQz7y5nAQicDHhRrnzuDd8hwNWkDCfrphy4se5PoN1/M3rxPmL4dV0JpxROkNZT2uIYfdGSDKumeus6uD8w6xQIDAQAB It is not PEM until it has a PEM header and trailer indicating the data type. That's just the base64 form of the DER encoding. To get actual PEM data: $ b64="MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAirjFSROMxZ9gW1AmX2nsO4zjs+mvXhdNJs/iQmUBBL6gUQEYlnbHopLMa1rnGeEZ46wp6dOtna3NpJby9xhfnAxIcqLbEk8BmSsjjoP9WC2KKQ8pc/nPdE8eU/iqU6IlwSKZscw2WPtgfLWrpXmDLWwmh/cTAKTfPfHBQH4X0ipcGcgw7QxYJAcjCaYSuz5PsznyW7vP4pmfQ0IRBkmrrF9L/qKlnNOMFzl5pnmv3Iuqy06H61Cs+AbPt0B1BL2sEQz7y5nAQicDHhRrnzuDd8hwNWkDCfrphy4se5PoN1/M3rxPmL4dV0JpxROkNZT2uIYfdGSDKumeus6uD8w6xQIDAQAB" $ echo; echo "$b64" | openssl base64 -A -d | openssl pkey -inform DER -pubin -text -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAirjFSROMxZ9gW1AmX2ns O4zjs+mvXhdNJs/iQmUBBL6gUQEYlnbHopLMa1rnGeEZ46wp6dOtna3NpJby9xhf nAxIcqLbEk8BmSsjjoP9WC2KKQ8pc/nPdE8eU/iqU6IlwSKZscw2WPtgfLWrpXmD LWwmh/cTAKTfPfHBQH4X0ipcGcgw7QxYJAcjCaYSuz5PsznyW7vP4pmfQ0IRBkmr rF9L/qKlnNOMFzl5pnmv3Iuqy06H61Cs+AbPt0B1BL2sEQz7y5nAQicDHhRrnzuD d8hwNWkDCfrphy4se5PoN1/M3rxPmL4dV0JpxROkNZT2uIYfdGSDKumeus6uD8w6 xQIDAQAB -----END PUBLIC KEY----- Public-Key: (2048 bit) Modulus: 00:8a:b8:c5:49:13:8c:c5:9f:60:5b:50:26:5f:69: ec:3b:8c:e3:b3:e9:af:5e:17:4d:26:cf:e2:42:65: 01:04:be:a0:51:01:18:96:76:c7:a2:92:cc:6b:5a: e7:19:e1:19:e3:ac:29:e9:d3:ad:9d:ad:cd:a4:96: f2:f7:18:5f:9c:0c:48:72:a2:db:12:4f:01:99:2b: 23:8e:83:fd:58:2d:8a:29:0f:29:73:f9:cf:74:4f: 1e:53:f8:aa:53:a2:25:c1:22:99:b1:cc:36:58:fb: 60:7c:b5:ab:a5:79:83:2d:6c:26:87:f7:13:00:a4: df:3d:f1:c1:40:7e:17:d2:2a:5c:19:c8:30:ed:0c: 58:24:07:23:09:a6:12:bb:3e:4f:b3:39:f2:5b:bb: cf:e2:99:9f:43:42:11:06:49:ab:ac:5f:4b:fe:a2: a5:9c:d3:8c:17:39:79:a6:79:af:dc:8b:aa:cb:4e: 87:eb:50:ac:f8:06:cf:b7:40:75:04:bd:ac:11:0c: fb:cb:99:c0:42:27:03:1e:14:6b:9f:3b:83:77:c8: 70:35:69:03:09:fa:e9:87:2e:2c:7b:93:e8:37:5f: cc:de:bc:4f:98:be:1d:57:42:69:c5:13:a4:35:94: f6:b8:86:1f:74:64:83:2a:e9:9e:ba:ce:ae:0f:cc: 3a:c5 Exponent: 65537 (0x10001) With the above in a file or memory BIO, you can use a suitable PEM_*_PUBKEY() routine, to get an abstract EVP_PKEY or an RSA key. If you want to do signature verification, you should not write any RSA-specific code. An EVP_PKEY can be used with X509_verify() with any supported key type: RSA, DSA, ECDSA, Ed25519, ... -- Viktor. From openssl-users at dukhovni.org Fri Jun 8 14:11:32 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 8 Jun 2018 10:11:32 -0400 Subject: [openssl-users] Confused about client side session caching In-Reply-To: References: Message-ID: > On Jun 8, 2018, at 4:03 AM, Matt Caswell wrote: > > I think new_session_cb and remove_session_cb should work in 1.0.2 on > clients. This has worked since before 0.9.8. -- Viktor. From sandeep.bvb at gmail.com Sat Jun 9 17:35:04 2018 From: sandeep.bvb at gmail.com (Sandeep Deshpande) Date: Sat, 9 Jun 2018 10:35:04 -0700 Subject: [openssl-users] Error compiling openssh with openssl Message-ID: Hi, We have compiled and built older version (6.2p2) of openssh with 1.0.2j version of openssl. When the system in is crypto mode, we are getting the following error when a user logs in : " *OpenSSL internal error, assertion failed: Low level API call to digest SHA256 forbidden in FIPS mode " * How do we overcome this without having to upgrade openssh ? Thanks, Sandeep -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sat Jun 9 17:38:04 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 9 Jun 2018 13:38:04 -0400 Subject: [openssl-users] Error compiling openssh with openssl In-Reply-To: References: Message-ID: > On Jun 9, 2018, at 1:35 PM, Sandeep Deshpande wrote: > > We have compiled and built older version (6.2p2) of openssh with 1.0.2j version of openssl. > When the system in is crypto mode, we are getting the following error when a user logs in : > " > OpenSSL internal error, assertion failed: Low level API call to digest SHA256 forbidden in FIPS mode " > > How do we overcome this without having to upgrade openssh ? Don't enable FIPS mode. -- Viktor. From i_chacha at naver.com Sun Jun 10 00:38:23 2018 From: i_chacha at naver.com (Sangsub) Date: Sat, 9 Jun 2018 17:38:23 -0700 (MST) Subject: [openssl-users] An error occurred while using the d2i_RSAPublicKey function. Message-ID: <1528591103273-0.post@n7.nabble.com> I am getting RSA publickey from the server. I need to extract the modulus and public exponent from the key to do the RSA operation. I have to solve with C language code, not shell command. I have written the following test code, and an error has occurred in the d2i_RSAPublicKey function. A null pointer is returned as the result of the d2i_RSAPublicKey function. void fnStr2Hex(unsigned char* out, char* in) { int data_len = strlen(in); unsigned char * pStr = in; int i; for(i=0; in); // print modulus bignum BN_print(STDout,pub_rsa->e); // print exponent bignum return 0; } int main() { der_test(); return 0; } Please let me know if you know what you need to do in order to get d2i_RSAPublicKey to work properly. Note that the RSA public key in raw_data has the key at the following site: https://crypto.stackexchange.com/questions/18031/how-to-find-modulus-from-a-rsa-public-key This seems to be a key that operates normally. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From openssl-users at dukhovni.org Sun Jun 10 01:04:35 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 9 Jun 2018 21:04:35 -0400 Subject: [openssl-users] An error occurred while using the d2i_RSAPublicKey function. In-Reply-To: <1528591103273-0.post@n7.nabble.com> References: <1528591103273-0.post@n7.nabble.com> Message-ID: > On Jun 9, 2018, at 8:38 PM, Sangsub wrote: > > I have written the following test code, and an error has occurred in the > d2i_RSAPublicKey function. > A null pointer is returned as the result of the d2i_RSAPublicKey function. Your input data is not a PKCS#1 RSA public key as understood by d2i_RSAPublicKey(). Rather, it is an X.509 SPKI public key, as understood by d2i_RSA_PUBKEY(), or, more generally, d2i_PUBKEY(). -- Viktor. From i_chacha at naver.com Sun Jun 10 03:25:22 2018 From: i_chacha at naver.com (Sangsub) Date: Sat, 9 Jun 2018 20:25:22 -0700 (MST) Subject: [openssl-users] An error occurred while using the d2i_RSAPublicKey function. In-Reply-To: References: <1528591103273-0.post@n7.nabble.com> Message-ID: <1528601122690-0.post@n7.nabble.com> Thank you viktor, Actually, I'm begginer so I don't know well. You said that the my input data is not a PKCS # 1 public key type. How do I distinguish between a PKCS # 1 type or an X.509 SPKI Public Key? -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From openssl-users at dukhovni.org Sun Jun 10 14:44:19 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 10 Jun 2018 10:44:19 -0400 Subject: [openssl-users] An error occurred while using the d2i_RSAPublicKey function. In-Reply-To: <1528601122690-0.post@n7.nabble.com> References: <1528591103273-0.post@n7.nabble.com> <1528601122690-0.post@n7.nabble.com> Message-ID: > On Jun 9, 2018, at 11:25 PM, Sangsub wrote: > > Actually, I'm begginer so I don't know well. > You said that the my input data is not a PKCS # 1 public key type. > > How do I distinguish between a PKCS # 1 type or an X.509 SPKI Public Key? You should not have to distinguish. The key type will be the same for a particular method of obtaining the key. In this case, the key will almost surely always be SPKI. You've not explained how you're obtaining the keys, why it is safe to assume they're RSA and not (say) ECDSA keys, or why you're looking to work with the public exponent and modulus, rather than use the existing OpenSSL signature verification functions. -- Viktor. From joshi.sanjaya at gmail.com Mon Jun 11 10:06:39 2018 From: joshi.sanjaya at gmail.com (Sanjaya Joshi) Date: Mon, 11 Jun 2018 15:36:39 +0530 Subject: [openssl-users] Selection of DHE ciphers based on modulus size of DH In-Reply-To: <3b7564e5-92ae-3bfe-fc8f-e84516bdfa61@wisemo.com> References: <6c93f4d3-f808-a037-f7fc-054437c932bc@jordan.maileater.net> <1694a847-a914-f632-d64e-64d8eea94a1a@openssl.org> <3b7564e5-92ae-3bfe-fc8f-e84516bdfa61@wisemo.com> Message-ID: Hi, Thank you for the clarifications. Regards, Sanjaya On Fri, Jun 8, 2018 at 4:30 PM, Jakob Bohm wrote: > (Top posting for consistency). > > Once the client receives the TLS1.2 servers choice of DH group, > it can either accept it or abort the connection. > > However if both client and server support the "supported_groups" > extension (RFC4492) with the additional DH group identifiers in > RFC7919, they can negotiate a common accepted group of desired > strength, though the mechanism (like TLS1.3) is artificially > limited to a fixed set of groups listed in the RFC. > > > On 08/06/2018 12:15, Sanjaya Joshi wrote: > >> Hello, >> Thank you Matt and Jordan. So, it seems that it's possible to modify my >> client to accept/reject the DH group key length. But i have one more issue >> to be clarified. >> >> Is it possible that if a client does not accept the DH group key length >> used by the server, then, a different possible cipher (for e.g., RSA) is >> tried to be negotiated. It seems that the connection is rejected, instead >> of falling back to a different possible cipher. At least, i tested this >> quickly using s_client and s_server, and the behavior is as stated above, >> i.e., no fallback and connection was terminated. Is this the default >> OpenSSL behavior or this behaviour could be modified somehow by >> applications ? >> >> Regards, >> Sanjaya >> >> On Thu, Jun 7, 2018 at 8:43 PM, Matt Caswell > matt at openssl.org>> wrote: >> >> >> >> On 07/06/18 16:02, Jordan Brown wrote: >> > I do not understand, however, how the 80 relates to a 1024-bit >> limit. >> >> It's a measure of the "security bits" of an algorithm according to >> table >> 2 in this doc: >> https://nvlpubs.nist.gov/nistpubs/specialpublications/nist. >> sp.800-57pt1r4.pdf >> > sp.800-57pt1r4.pdf> >> >> > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 sandeep.bvb at gmail.com Mon Jun 11 14:44:37 2018 From: sandeep.bvb at gmail.com (Sandeep Deshpande) Date: Mon, 11 Jun 2018 07:44:37 -0700 Subject: [openssl-users] Error compiling openssh with openssl In-Reply-To: References: Message-ID: Thanks for the reply. Our appliance is enabled in FIPS mode by default. All these days, we were using openssh 6.2 with openssl 0.9.8. Now we need to upgrade openssl to 1.0.2j. But we would not like to upgrade openssh at this time. So is there is any other way we can still make it work without disabling FIPS mode ? Thanks, Sandeep On Sat, Jun 9, 2018 at 10:38 AM, Viktor Dukhovni wrote: > > > > On Jun 9, 2018, at 1:35 PM, Sandeep Deshpande > wrote: > > > > We have compiled and built older version (6.2p2) of openssh with 1.0.2j > version of openssl. > > When the system in is crypto mode, we are getting the following error > when a user logs in : > > " > > OpenSSL internal error, assertion failed: Low level API call to digest > SHA256 forbidden in FIPS mode " > > > > How do we overcome this without having to upgrade openssh ? > > Don't enable FIPS mode. > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Jun 11 14:51:34 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 11 Jun 2018 14:51:34 +0000 Subject: [openssl-users] Error compiling openssh with openssl In-Reply-To: References: Message-ID: * So is there is any other way we can still make it work without disabling FIPS mode ? No. The version of openssh you are using makes API calls that are not allowed in FIPS mode. I suspect later versions of OpenSSH also do this, and therefore ?FIPS mode openssh? will require some coding work. -------------- next part -------------- An HTML attachment was scrubbed... URL: From srikuppa at cisco.com Mon Jun 11 15:44:55 2018 From: srikuppa at cisco.com (Srivalli Kuppa (srikuppa)) Date: Mon, 11 Jun 2018 15:44:55 +0000 Subject: [openssl-users] OpenSSL patch for CHACHA cipher support in OpenSSL 1.0.2 Message-ID: <534C683D-5EDD-4746-9206-F39963B87B14@cisco.com> Hi OpenSSL team, I am Srivalli Kuppa. I have a couple of questions regarding support of CHACHA and Poly1305 cipher suites with OpenSSL. 1. Do we have a stable OpenSSL patch that can be applied to OpenSSL 1.0.2 version to support CHACHA cipher both as a server/client? 2. Can CHACHA+Poly1305 ciphers be used with TLSv1.2 today with different browsers (Chrome/Firefox etc.,)? Thanks. Srivalli -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Jun 11 15:58:43 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 11 Jun 2018 16:58:43 +0100 Subject: [openssl-users] OpenSSL patch for CHACHA cipher support in OpenSSL 1.0.2 In-Reply-To: <534C683D-5EDD-4746-9206-F39963B87B14@cisco.com> References: <534C683D-5EDD-4746-9206-F39963B87B14@cisco.com> Message-ID: On 11/06/18 16:44, Srivalli Kuppa (srikuppa) via openssl-users wrote: > 1. Do we have a stable OpenSSL patch that can be applied to OpenSSL > 1.0.2 version to support CHACHA cipher both as a server/client? No. Chacha/Poly1305 support is only available from version 1.1.0 upwards. > 2. Can CHACHA+Poly1305 ciphers be used with TLSv1.2 today with > different browsers (Chrome/Firefox etc.,)? Yes. Matt From Michael.Wojcik at microfocus.com Mon Jun 11 16:14:03 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 11 Jun 2018 16:14:03 +0000 Subject: [openssl-users] Error compiling openssh with openssl In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich via openssl-users > Sent: Monday, June 11, 2018 08:52 > > So is there is any other way we can still make it work without disabling FIPS mode ? > No. The version of openssh you are using makes API calls that are not allowed in FIPS mode. I suspect > later versions of OpenSSH also do this, and therefore ?FIPS mode openssh? will require some coding work. The OP should also note this also implies this is an issue in OpenSSH, not OpenSSL. OpenSSL is working properly. FIPS 140-2 has various requirements, and OpenSSH is violating one of them. And, further, note that even if there were a way to suppress this check without disabling FIPS mode, that would be pointless. A product that uses non-FIPS cryptography cannot claim FIPS validation or "FIPS Inside" (which is the claim that only FIPS-validated cryptography is used). Consequently, such a product doesn't meet the FIPS requirement, for customers who have such a requirement; and there's little or no other benefit to FIPS. So, since you can't claim FIPS Inside while using OpenSSH, it seems your choices are: 1) disable FIPS mode and do not claim FIPS Inside; 2) find a commercial SSH implementation that is FIPS-validated, if there is such a thing; or 3) as Rich suggested, modify OpenSSH to only use FIPS-allowed APIs, which I suspect would not be trivial (but I haven't looked into it). This is one of several reasons why FIPS 140-2 is a problem. Unfortunately the FIPS 140-3 effort seems to be moribund, and I haven't heard anything about "ISO FIPS" in some time. -- Michael Wojcik Distinguished Engineer, Micro Focus From rsalz at akamai.com Mon Jun 11 16:16:24 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 11 Jun 2018 16:16:24 +0000 Subject: [openssl-users] Error compiling openssh with openssl In-Reply-To: References: Message-ID: <71F2ACD7-7766-4256-BD41-A758172E93C5@akamai.com> > This is one of several reasons why FIPS 140-2 is a problem. Unfortunately the FIPS 140-3 effort seems to be moribund, and I haven't heard anything about "ISO FIPS" in some time. If I understood what was said at the ICMC conference last month, the FIPS 140-3 plan is to just point to the ISO FIPS-equivalent spec. From srikuppa at cisco.com Mon Jun 11 17:34:36 2018 From: srikuppa at cisco.com (Srivalli Kuppa (srikuppa)) Date: Mon, 11 Jun 2018 17:34:36 +0000 Subject: [openssl-users] OpenSSL patch for CHACHA cipher support in OpenSSL 1.0.2 In-Reply-To: References: <534C683D-5EDD-4746-9206-F39963B87B14@cisco.com> Message-ID: Thanks Matt. Appreciate your answers. Just curious, is there a possibility to patch CHACHA cipher specific changes to OpenSSL 1.0.2 version still and get SSL handshake succeed? I am not looking for an upgrade to OpenSSL 1.1.0 at this point. So, I am interested to know if I can get CHACHA to working with OpenSSL 1.0.2. Thanks for your time. -Srivalli ?On 6/11/18, 11:59 AM, "openssl-users on behalf of Matt Caswell" wrote: On 11/06/18 16:44, Srivalli Kuppa (srikuppa) via openssl-users wrote: > 1. Do we have a stable OpenSSL patch that can be applied to OpenSSL > 1.0.2 version to support CHACHA cipher both as a server/client? No. Chacha/Poly1305 support is only available from version 1.1.0 upwards. > 2. Can CHACHA+Poly1305 ciphers be used with TLSv1.2 today with > different browsers (Chrome/Firefox etc.,)? Yes. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From rsalz at akamai.com Mon Jun 11 17:40:02 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 11 Jun 2018 17:40:02 +0000 Subject: [openssl-users] OpenSSL patch for CHACHA cipher support in OpenSSL 1.0.2 In-Reply-To: References: <534C683D-5EDD-4746-9206-F39963B87B14@cisco.com> Message-ID: > Just curious, is there a possibility to patch CHACHA cipher specific changes to OpenSSL 1.0.2 version still and get SSL handshake succeed? It can be done; CloudFlare posted some patches at https://github.com/cloudflare/sslconfig/tree/master/patches but I think they used the pre-IETF version and so might need some tweaks. The OpenSSL project won't do it (we don't add features to existing releases). From tshort at akamai.com Mon Jun 11 18:01:40 2018 From: tshort at akamai.com (Short, Todd) Date: Mon, 11 Jun 2018 18:01:40 +0000 Subject: [openssl-users] Error compiling openssh with openssl In-Reply-To: References: Message-ID: You will need to patch OpenSSH to not call the SHA256_XXX() APIs directly. To work with FIPS enabled, the EVP API must be used for all crypto operations. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Jun 11, 2018, at 10:44 AM, Sandeep Deshpande > wrote: Thanks for the reply. Our appliance is enabled in FIPS mode by default. All these days, we were using openssh 6.2 with openssl 0.9.8. Now we need to upgrade openssl to 1.0.2j. But we would not like to upgrade openssh at this time. So is there is any other way we can still make it work without disabling FIPS mode ? Thanks, Sandeep On Sat, Jun 9, 2018 at 10:38 AM, Viktor Dukhovni > wrote: > On Jun 9, 2018, at 1:35 PM, Sandeep Deshpande > wrote: > > We have compiled and built older version (6.2p2) of openssh with 1.0.2j version of openssl. > When the system in is crypto mode, we are getting the following error when a user logs in : > " > OpenSSL internal error, assertion failed: Low level API call to digest SHA256 forbidden in FIPS mode " > > How do we overcome this without having to upgrade openssh ? Don't enable FIPS mode. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From srikuppa at cisco.com Mon Jun 11 17:53:24 2018 From: srikuppa at cisco.com (Srivalli Kuppa (srikuppa)) Date: Mon, 11 Jun 2018 17:53:24 +0000 Subject: [openssl-users] OpenSSL patch for CHACHA cipher support in OpenSSL 1.0.2 In-Reply-To: References: <534C683D-5EDD-4746-9206-F39963B87B14@cisco.com> Message-ID: Interesting. Yes, I did take a look at Cloudflare patch but wasn't sure if I could use that. Alright. This helps. My only option is to upgrade to OpenSSL 1.1.0 in order to support CHACHA+Poly1305 cipher support. Thanks Rich. -Srivalli ?On 6/11/18, 1:40 PM, "Salz, Rich" wrote: > Just curious, is there a possibility to patch CHACHA cipher specific changes to OpenSSL 1.0.2 version still and get SSL handshake succeed? It can be done; CloudFlare posted some patches at https://github.com/cloudflare/sslconfig/tree/master/patches but I think they used the pre-IETF version and so might need some tweaks. The OpenSSL project won't do it (we don't add features to existing releases). From jb-openssl at wisemo.com Mon Jun 11 23:42:02 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 12 Jun 2018 01:42:02 +0200 Subject: [openssl-users] Error compiling openssh with openssl In-Reply-To: References: Message-ID: <0a0b40e6-1217-0b75-abce-88f42d56650c@wisemo.com> On 11/06/2018 18:14, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich via openssl-users >> Sent: Monday, June 11, 2018 08:52 >>> So is there is any other way we can still make it work without disabling FIPS mode ? >> No. The version of openssh you are using makes API calls that are not allowed in FIPS mode. I suspect >> later versions of OpenSSH also do this, and therefore ?FIPS mode openssh? will require some coding work. > The OP should also note this also implies this is an issue in OpenSSH, not OpenSSL. OpenSSL is working properly. FIPS 140-2 has various requirements, and OpenSSH is violating one of them. > > And, further, note that even if there were a way to suppress this check without disabling FIPS mode, that would be pointless. A product that uses non-FIPS cryptography cannot claim FIPS validation or "FIPS Inside" (which is the claim that only FIPS-validated cryptography is used). Consequently, such a product doesn't meet the FIPS requirement, for customers who have such a requirement; and there's little or no other benefit to FIPS. Note that what seems to be violated here is not the FIPS requirements as such, but the OpenSSL-specific rule that the older crypto functions are not directed to the FIPS blob, just outright rejected.? In this case, that the more easy to use SHA256 OpenSSL 1.0.x API isn't forwarded to the FIPS validated SHA256 implementation. I don't know if FIPS-enabled OpenSSL 0.9.8 forwarded those calls to the old FIPS validated implementation or just left the non-FIPS implementation available by accident. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 stm at pdflib.com Tue Jun 12 09:58:27 2018 From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=) Date: Tue, 12 Jun 2018 11:58:27 +0200 Subject: [openssl-users] OpenSSL 1.1.0: How to get X509_STORE from X509_LOOKUP? Message-ID: <5e44a293-a6fa-3e0a-1186-89e725329036@pdflib.com> Hi, I'm migrating from OpenSSL 1.0.2 to OpenSSL 1.1.0. The application attaches additional data to X509 certificate data structures via the X509_set_ex_data()/X509_get_ex_data() functions. A tricky detail is that the additional data must be attached when OpenSSL loads certificates from PEM files or from directories containing certificates with the hashed names. With OpenSSL 1.0.2 this was implemented by wrapping the X509_LOOKUP_METHODs returned by X509_LOOKUP_file() and X509_LOOKUP_hash_dir() into application-specific X509_LOOKUP_METHODs. Within the context of the application-specific X509_LOOKUP_METHOD instances the original methods are called, and when certificates are loaded then via a callback X509_set_ex_data() is called on the newly loaded certificate. For example for the X509_LOOKUP_file() lookup method the "ctrl" function pointer from the X509_LOOKUP_METHOD structure is overridden: int (*ctrl) (X509_LOOKUP *ctx, int cmd, const char *argc, long argl, char **ret); For this approach it is necessary to retrieve the X509_STORE context pointer from a X509_LOOKUP pointer passed to the function called via the X509_LOOKUP.ctrl function pointer. In OpenSSL 1.0.2 this was no problem as the "X509_STORE *store_ctx" member of the X509_LOOKUP structure was directly accessible. But in OpenSSL 1.1.0 the X509_LOOKUP structure is opaque, and as far as I can see there is no API function available that would retrieve the X509_STORE pointer from a X509_LOOKUP pointer. Is this intentional, or was this an omission when making the X509_LOOKUP structure opaque in OpenSSL 1.1.0? Thanks Stephan From openssl at openssl.org Tue Jun 12 10:18:03 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 12 Jun 2018 10:18:03 +0000 Subject: [openssl-users] OpenSSL Security Advisory Message-ID: <20180612101803.GA31999@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL Security Advisory [12 June 2018] ======================================== Client DoS due to large DH parameter (CVE-2018-0732) ==================================================== Severity: Low During key agreement in a TLS handshake using a DH(E) based ciphersuite a malicious server can send a very large prime value to the client. This will cause the client to spend an unreasonably long period of time generating a key for this prime resulting in a hang until the client has finished. This could be exploited in a Denial Of Service attack. Due to the low severity of this issue we are not issuing a new release of OpenSSL 1.1.0 or 1.0.2 at this time. The fix will be included in OpenSSL 1.1.0i and OpenSSL 1.0.2p when they become available. The fix is also available in commit ea7abeeab (for 1.1.0) and commit 3984ef0b7 (for 1.0.2) in the OpenSSL git repository. This issue was reported to OpenSSL on 5th June 2018 by Guido Vranken who also developed the fix. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20180612.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlsfnTgACgkQ2cTSbQ5g RJE9Twf/VSgXaFPlW+JyA2BAiwGREMr/oMQe8mhmka3WQgNb7oMQRxk4ZqwRvLi2 ggPVOQilJ+tkXgeifEQ3SDRxDnnmcUvxbWB8Lt+7tjhM6O+GYGbGbzupnkBs2IIY 72vll4l7ySMQ8/fcdU/uuNyObfigLC9XndH3tEewxffs6uvDxMyGhZmNQpq1aZNj rGj3dETUuO/Ln8siAD7nkv9xodRINViMP76fSKAtdaikvZa3uhLBMhX5tOzpR/ta tc2+6uthdU9JjSRZZpfDlzzhsOFqMrLfOLrJQIIXshxUNeOZyJCkmT9ED8XZRDMB twb1kOxCKz8Ky+Xm/Rki9uRVoZFjBg== =kKic -----END PGP SIGNATURE----- From matt at openssl.org Tue Jun 12 10:32:21 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 12 Jun 2018 11:32:21 +0100 Subject: [openssl-users] OpenSSL 1.1.0: How to get X509_STORE from X509_LOOKUP? In-Reply-To: <5e44a293-a6fa-3e0a-1186-89e725329036@pdflib.com> References: <5e44a293-a6fa-3e0a-1186-89e725329036@pdflib.com> Message-ID: <3766b295-2914-b3a1-a259-0d9a81a2548f@openssl.org> On 12/06/18 10:58, Stephan M?hlstrasser wrote: > In OpenSSL 1.0.2 this was no problem as the "X509_STORE *store_ctx" > member of the X509_LOOKUP structure was directly accessible. But in > OpenSSL 1.1.0 the X509_LOOKUP structure is opaque, and as far as I can > see there is no API function available that would retrieve the > X509_STORE pointer from a X509_LOOKUP pointer. > > Is this intentional, or was this an omission when making the X509_LOOKUP > structure opaque in OpenSSL 1.1.0? It was an omission that is fixed in the latest dev version of OpenSSL 1.1.0. See this commit: https://github.com/openssl/openssl/commit/6912debb881e669f7a7fb621588e20347111c4f0 This will be in 1.1.0i when it gets released (no released date as yet). Matt From janjust at nikhef.nl Tue Jun 12 16:30:08 2018 From: janjust at nikhef.nl (Jan Just Keijser) Date: Tue, 12 Jun 2018 18:30:08 +0200 Subject: [openssl-users] 2 openssl installed? In-Reply-To: References: <4ABD19A2-FCB1-49DE-9AF6-AF6E7592D344@foocrypt.net> <4bf2b9503033c86b944951950fab9390@tiscali.it> <32F957BF-B7F1-48B6-AC55-9BF0688893D1@foocrypt.net> Message-ID: Hi, On 07/06/18 06:14, Sampei wrote: > > t?s a server installed many many years ago and there are applications > which are no used. > Server is too late and I have new server (latest Centos 6) for > migrating where I installed latest version. > I?d like to take to new server all certificate database (certificated > included) which I created. > Openssl is only tool to create test certificates. > I don?t know if there are apps which are using the e configs, but I > think no. > this has little to do with OpenSSL itself and more with PKI management. Basically, your problem seems to be that you have an older server and you don't know where the certificates and private keys (i.e. the PKI) were stored. What you need to do, is find out where the certifcates are held, together with the index.txt file. In order to do so, you could use something like ? find / -name '*.pem' or ? find / -name index.txt and check all directories where such files are found. This will be a lengthy process, as the find command has to traverse the entire filesystem. good luck, JJK From Brian.Chou at advantech.com.tw Wed Jun 13 05:40:01 2018 From: Brian.Chou at advantech.com.tw (Brian.Chou) Date: Wed, 13 Jun 2018 05:40:01 +0000 Subject: [openssl-users] Advantech openssl compatibility issue In-Reply-To: <5442f90a17204726aa69600d581063aa@taipei08.ADVANTECH.CORP> References: <5442f90a17204726aa69600d581063aa@taipei08.ADVANTECH.CORP> Message-ID: Subscribe and send again. From: Brian.Chou Sent: Wednesday, June 13, 2018 1:21 PM To: 'openssl-users at openssl.org' Cc: Brian.Ng; Mojo.Huang Subject: Advantech openssl compatibility issue Dear support team We met openssl crash issue on our Intel Atom C3000 SoC platform. Openssl crashes when run "s_client -connect IP:Port" command. In win10 event viewer it show "Faulting module name:LIBEAY32.dll, version:1.0.2.8......". (Figure 1) The issue only happened to "1.0.2h" or older version. (Table 1) And other CPU/Chipset on our side can work normally with same command. Can you help to explain what changes are made between "1.0.2h" and "1.0.2i" that may cause this issue? Please let me know if you need more info, thank you. Note: We found similar issue by google, not sure if it's related. (https://forum.filezilla-project.org/viewtopic.php?f=6&t=32837&sid=14d3d99cb60f1a6867d16aba89403015) Table 1.Test under Winsvr 2016/Win10 Openssl version Connect by "s_client -connect IP:Port" 1.0.2g Fail 1.0.2h Fail 1.0.2i Pass 1.0.2o Pass 1.0.0d Pass Figure 1 [cid:image002.jpg at 01D40273.2D91C710] Best regards, Brian Chou Application Engineering of Industrial IoT Group Advantech Co., Ltd. Tel: 886-2-2792-7818 ext,1431 e-mail:Brian.Chou at advantech.com.tw Best regards, Brian Chou Application Engineering of Industrial IoT Group Advantech Co., Ltd. Tel: 886-2-2792-7818 ext,1431 e-mail:Brian.Chou at advantech.com.tw -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 30883 bytes Desc: image001.jpg URL: From jackinter101 at gmail.com Wed Jun 13 05:56:03 2018 From: jackinter101 at gmail.com (NATAWUT SUKRAT) Date: Wed, 13 Jun 2018 12:56:03 +0700 Subject: [openssl-users] openssl-users Digest, Vol 43, Issue 16 In-Reply-To: References: Message-ID: No. NATAWUT SUKRAT @jack ???????? ?. 13 ??.?. 2018 12:51 ????????: > Send openssl-users mailing list submissions to > openssl-users at openssl.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mta.openssl.org/mailman/listinfo/openssl-users > or, via email, send a message with subject or body 'help' to > openssl-users-request at openssl.org > > You can reach the person managing the list at > openssl-users-owner at openssl.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openssl-users digest..." > > > Today's Topics: > > 1. OpenSSL Security Advisory (OpenSSL) > 2. Re: OpenSSL 1.1.0: How to get X509_STORE from X509_LOOKUP? > (Matt Caswell) > 3. Re: 2 openssl installed? (Jan Just Keijser) > 4. Re: Advantech openssl compatibility issue (Brian.Chou) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 12 Jun 2018 10:18:03 +0000 > From: OpenSSL > To: openssl-project at openssl.org, OpenSSL User Support ML > , OpenSSL Announce ML > > Subject: [openssl-users] OpenSSL Security Advisory > Message-ID: <20180612101803.GA31999 at openssl.org> > Content-Type: text/plain; charset=us-ascii > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > OpenSSL Security Advisory [12 June 2018] > ======================================== > > Client DoS due to large DH parameter (CVE-2018-0732) > ==================================================== > > Severity: Low > > During key agreement in a TLS handshake using a DH(E) based ciphersuite a > malicious server can send a very large prime value to the client. This will > cause the client to spend an unreasonably long period of time generating a > key > for this prime resulting in a hang until the client has finished. This > could be > exploited in a Denial Of Service attack. > > Due to the low severity of this issue we are not issuing a new release of > OpenSSL 1.1.0 or 1.0.2 at this time. The fix will be included in OpenSSL > 1.1.0i > and OpenSSL 1.0.2p when they become available. The fix is also available in > commit ea7abeeab (for 1.1.0) and commit 3984ef0b7 (for 1.0.2) in the > OpenSSL git > repository. > > This issue was reported to OpenSSL on 5th June 2018 by Guido Vranken who > also > developed the fix. > > References > ========== > > URL for this Security Advisory: > https://www.openssl.org/news/secadv/20180612.txt > > Note: the online version of the advisory may be updated with additional > details > over time. > > For details of OpenSSL severity classifications please see: > https://www.openssl.org/policies/secpolicy.html > -----BEGIN PGP SIGNATURE----- > > iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlsfnTgACgkQ2cTSbQ5g > RJE9Twf/VSgXaFPlW+JyA2BAiwGREMr/oMQe8mhmka3WQgNb7oMQRxk4ZqwRvLi2 > ggPVOQilJ+tkXgeifEQ3SDRxDnnmcUvxbWB8Lt+7tjhM6O+GYGbGbzupnkBs2IIY > 72vll4l7ySMQ8/fcdU/uuNyObfigLC9XndH3tEewxffs6uvDxMyGhZmNQpq1aZNj > rGj3dETUuO/Ln8siAD7nkv9xodRINViMP76fSKAtdaikvZa3uhLBMhX5tOzpR/ta > tc2+6uthdU9JjSRZZpfDlzzhsOFqMrLfOLrJQIIXshxUNeOZyJCkmT9ED8XZRDMB > twb1kOxCKz8Ky+Xm/Rki9uRVoZFjBg== > =kKic > -----END PGP SIGNATURE----- > > > ------------------------------ > > Message: 2 > Date: Tue, 12 Jun 2018 11:32:21 +0100 > From: Matt Caswell > To: openssl-users at openssl.org > Subject: Re: [openssl-users] OpenSSL 1.1.0: How to get X509_STORE from > X509_LOOKUP? > Message-ID: <3766b295-2914-b3a1-a259-0d9a81a2548f at openssl.org> > Content-Type: text/plain; charset=utf-8 > > > > On 12/06/18 10:58, Stephan M?hlstrasser wrote: > > In OpenSSL 1.0.2 this was no problem as the "X509_STORE *store_ctx" > > member of the X509_LOOKUP structure was directly accessible. But in > > OpenSSL 1.1.0 the X509_LOOKUP structure is opaque, and as far as I can > > see there is no API function available that would retrieve the > > X509_STORE pointer from a X509_LOOKUP pointer. > > > > Is this intentional, or was this an omission when making the X509_LOOKUP > > structure opaque in OpenSSL 1.1.0? > > It was an omission that is fixed in the latest dev version of OpenSSL > 1.1.0. See this commit: > > > https://github.com/openssl/openssl/commit/6912debb881e669f7a7fb621588e20347111c4f0 > > This will be in 1.1.0i when it gets released (no released date as yet). > > Matt > > > > ------------------------------ > > Message: 3 > Date: Tue, 12 Jun 2018 18:30:08 +0200 > From: Jan Just Keijser > To: openssl-users at openssl.org, Sampei > Subject: Re: [openssl-users] 2 openssl installed? > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi, > > On 07/06/18 06:14, Sampei wrote: > > > > t?s a server installed many many years ago and there are applications > > which are no used. > > Server is too late and I have new server (latest Centos 6) for > > migrating where I installed latest version. > > I?d like to take to new server all certificate database (certificated > > included) which I created. > > Openssl is only tool to create test certificates. > > I don?t know if there are apps which are using the e configs, but I > > think no. > > > this has little to do with OpenSSL itself and more with PKI management. > Basically, your problem seems to be that you have an older server and > you don't know where the certificates and private keys (i.e. the PKI) > were stored. What you need to do, is find out where the certifcates are > held, together with the index.txt file. In order to do so, you could use > something like > ? find / -name '*.pem' > or > ? find / -name index.txt > and check all directories where such files are found. This will be a > lengthy process, as the find command has to traverse the entire filesystem. > > good luck, > > JJK > > > > ------------------------------ > > Message: 4 > Date: Wed, 13 Jun 2018 05:40:01 +0000 > From: Brian.Chou > To: "openssl-users at openssl.org" > Cc: "Brian.Ng" , "Mojo.Huang" > > Subject: Re: [openssl-users] Advantech openssl compatibility issue > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Subscribe and send again. > > From: Brian.Chou > Sent: Wednesday, June 13, 2018 1:21 PM > To: 'openssl-users at openssl.org' > Cc: Brian.Ng; Mojo.Huang > Subject: Advantech openssl compatibility issue > > Dear support team > > We met openssl crash issue on our Intel Atom C3000 SoC platform. > Openssl crashes when run "s_client -connect IP:Port" command. > In win10 event viewer it show "Faulting module name:LIBEAY32.dll, > version:1.0.2.8......". (Figure 1) > The issue only happened to "1.0.2h" or older version. (Table 1) > And other CPU/Chipset on our side can work normally with same command. > Can you help to explain what changes are made between "1.0.2h" and > "1.0.2i" that may cause this issue? > Please let me know if you need more info, thank you. > > Note: We found similar issue by google, not sure if it's related. ( > https://forum.filezilla-project.org/viewtopic.php?f=6&t=32837&sid=14d3d99cb60f1a6867d16aba89403015 > < > https://urldefense.proofpoint.com/v2/url?u=https-3A__forum.filezilla-2Dproject.org_viewtopic.php-3Ff-3D6-26t-3D32837-26sid-3D14d3d99cb60f1a6867d16aba89403015&d=DwMFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=lgpGrPZI_ai301hZxt6u5Jb3XQrxd6ed5-1gL-SJmDE&s=cNoUfknWBgsh-JRnghh6TVNsW72g89P7uuSrJLnLn8g&e= > >) > > Table 1.Test under Winsvr 2016/Win10 > Openssl version > > Connect by "s_client -connect IP:Port" > > 1.0.2g > > Fail > > 1.0.2h > > Fail > > 1.0.2i > > Pass > > 1.0.2o > > Pass > > 1.0.0d > > Pass > > > > Figure 1 > [cid:image002.jpg at 01D40273.2D91C710] > Best regards, > Brian Chou > Application Engineering of Industrial IoT Group > Advantech Co., Ltd. > Tel: 886-2-2792-7818 ext,1431 > e-mail:Brian.Chou at advantech.com.tw > > > > Best regards, > Brian Chou > Application Engineering of Industrial IoT Group > Advantech Co., Ltd. > Tel: 886-2-2792-7818 ext,1431 > e-mail:Brian.Chou at advantech.com.tw > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mta.openssl.org/pipermail/openssl-users/attachments/20180613/0053e43a/attachment.html > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image001.jpg > Type: image/jpeg > Size: 30883 bytes > Desc: image001.jpg > URL: < > http://mta.openssl.org/pipermail/openssl-users/attachments/20180613/0053e43a/attachment.jpg > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > openssl-users mailing list > openssl-users at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-users > > > ------------------------------ > > End of openssl-users Digest, Vol 43, Issue 16 > ********************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sampei02 at tiscali.it Wed Jun 13 06:29:46 2018 From: sampei02 at tiscali.it (sampei02 at tiscali.it) Date: Wed, 13 Jun 2018 08:29:46 +0200 Subject: [openssl-users] 2 openssl installed? In-Reply-To: References: <4ABD19A2-FCB1-49DE-9AF6-AF6E7592D344@foocrypt.net> <4bf2b9503033c86b944951950fab9390@tiscali.it> <32F957BF-B7F1-48B6-AC55-9BF0688893D1@foocrypt.net> Message-ID: Yes, that?s right. My target is to migrate old server to new one keeping PKI and certificates (included databases). After this search how can I manage these files into new server? I Should to create multiple directory ? Each one for each index.txt files ? My search found several index.txt files It?s necessary to write this directory immediately under openssl directory? > On 12 Jun 2018, at 18:30, Jan Just Keijser wrote: > > Hi, > > On 07/06/18 06:14, Sampei wrote: >> >> t?s a server installed many many years ago and there are applications which are no used. >> Server is too late and I have new server (latest Centos 6) for migrating where I installed latest version. >> I?d like to take to new server all certificate database (certificated included) which I created. >> Openssl is only tool to create test certificates. >> I don?t know if there are apps which are using the e configs, but I think no. >> > this has little to do with OpenSSL itself and more with PKI management. Basically, your problem seems to be that you have an older server and you don't know where the certificates and private keys (i.e. the PKI) were stored. What you need to do, is find out where the certifcates are held, together with the index.txt file. In order to do so, you could use something like > find / -name '*.pem' > or > find / -name index.txt > and check all directories where such files are found. This will be a lengthy process, as the find command has to traverse the entire filesystem. > > good luck, > > JJK > From lists at rustichelli.net Wed Jun 13 06:58:02 2018 From: lists at rustichelli.net (lists) Date: Wed, 13 Jun 2018 08:58:02 +0200 Subject: [openssl-users] PKCS7 signature process In-Reply-To: <49a2da24-817a-35c4-f9b3-49eeddda7e56@magic.fr> References: <49a2da24-817a-35c4-f9b3-49eeddda7e56@magic.fr> Message-ID: I'm very sorry for the late reply but I only read the list from time to time. To my knowledge, the PKCS7_sign will init the structure taking data from th BIO, so if you put data in the BIO after the call to PKCS7_Sign, that won't go into the PKCS7 structure. Possibly, by adding the flag PKCS7_STREAM you may postpone the signature operation, but I never tried that. On 05/16/2018 05:19 PM, Patrice Gu?rin wrote: > Hello OpenSSL-users > > In the purpose of signing pdf files, I've found a difference of > behaviour that I can't explain between two ways of computing signatures. > The first one leads to an error in the way that Adobe says that the > file was modified after signing, the second does not. > > First Method: > ??? BIO* BioMem = BIO_new( BIO_s_mem() ); > ??? while ( Data ) > BIO_write( BioMem , Data, DataLen ); > ??? MyPKCS7 = PKCS7_sign( Certificate, PrivateKey,NULL, BioMem , > PKCS7_DETACHED | PKCS7_BINARY ); > ??? PKCS7_final( MyPKCS7, BioMem , PKCS7_DETACHED | PKCS7_BINARY ); > ??? BIO* BioOut = BIO_new( BIO_s_mem() ); > ??? i2d_PKCS7_bio( BioOut , MyPKCS7 ); > ??? char*??? OutBuf = NULL; > ??? int OutLen = BIO_get_mem_data( BioOut , &OutBuf ); > > Second Method: > ??? BIO* BioMem = BIO_new( BIO_s_mem() ); > ??? MyPKCS7 = PKCS7_sign( Certificate, PrivateKey,NULL, BioMem , > PKCS7_DETACHED | PKCS7_BINARY ); > ??? while ( Data ) > ??? ??? BIO_write( BioMem , Data, DataLen ); > ??? PKCS7_final( MyPKCS7, BioMem , PKCS7_DETACHED | PKCS7_BINARY ); > ??? BIO* BioOut = BIO_new( BIO_s_mem() ); > ??? i2d_PKCS7_bio( BioOut , MyPKCS7 ); > ??? char*??? OutBuf = NULL; > ??? int OutLen = BIO_get_mem_data( BioOut , &OutBuf ); > > It seems that the order between PKCS7_sign et BIO_Write that feeds the > memory BIO has an importance. > > Can anybody explains why the first method is incorrect ? > > Thank you in advance > Patrice. From wouter.verhelst at bosa.fgov.be Wed Jun 13 07:49:42 2018 From: wouter.verhelst at bosa.fgov.be (Wouter Verhelst) Date: Wed, 13 Jun 2018 09:49:42 +0200 Subject: [openssl-users] 2 openssl installed? In-Reply-To: References: <4ABD19A2-FCB1-49DE-9AF6-AF6E7592D344@foocrypt.net> <4bf2b9503033c86b944951950fab9390@tiscali.it> <32F957BF-B7F1-48B6-AC55-9BF0688893D1@foocrypt.net> Message-ID: <5291631e-765e-6a53-1c12-0b24bcc7d8ca@bosa.fgov.be> Please contact the support channels of whoever set up that server. If that was you, try to remember how you configured things when you set them up, and copy that configuration, including the relevant files. There are a million ways to implement a PKI service, and the details of where you need to drop those files on the new server depend greatly on the choices you've made while configuring things. On 13-06-18 08:29, sampei02 at tiscali.it wrote: > Yes, that?s right. > My target is to migrate old server to new one keeping PKI and certificates (included databases). > After this search how can I manage these files into new server? > I Should to create multiple directory ? Each one for each index.txt files ? My search found several index.txt files > It?s necessary to write this directory immediately under openssl directory? > > >> On 12 Jun 2018, at 18:30, Jan Just Keijser wrote: >> >> Hi, >> >> On 07/06/18 06:14, Sampei wrote: >>> t?s a server installed many many years ago and there are applications which are no used. >>> Server is too late and I have new server (latest Centos 6) for migrating where I installed latest version. >>> I?d like to take to new server all certificate database (certificated included) which I created. >>> Openssl is only tool to create test certificates. >>> I don?t know if there are apps which are using the e configs, but I think no. >>> >> this has little to do with OpenSSL itself and more with PKI management. Basically, your problem seems to be that you have an older server and you don't know where the certificates and private keys (i.e. the PKI) were stored. What you need to do, is find out where the certifcates are held, together with the index.txt file. In order to do so, you could use something like >> find / -name '*.pem' >> or >> find / -name index.txt >> and check all directories where such files are found. This will be a lengthy process, as the find command has to traverse the entire filesystem. >> >> good luck, >> >> JJK >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Wed Jun 13 16:31:33 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 13 Jun 2018 16:31:33 +0000 Subject: [openssl-users] Advantech openssl compatibility issue In-Reply-To: References: <5442f90a17204726aa69600d581063aa@taipei08.ADVANTECH.CORP> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Brian.Chou > Sent: Tuesday, June 12, 2018 23:40 > Can you help to explain what changes are made between ?1.0.2h? and ?1.0.2i? that may cause this issue? The OpenSSL changelog describes the high-level differences between each pair of consecutive versions. For details, you'll need to look at the git history, or extract the sources and diff them. In this case, you're probably only interested in the differences in libcrypto, so diffing the crypto source trees is probably sufficient. (It might be elsewhere, but that's the place to start.) It'd be faster, though, to debug the openssl s_client run and see where the exception is being thrown. It's a c0000005 - an addressing violation - so there's a decent chance that it's raised in or near (in terms of stack frames) where the actual cause exists in the code. (Addressing violations are synchronous exceptions caused by invoking undefined behavior, so they *can* have remote causes, such as earlier heap corruption, but there's a decent probability of hitting the exception soon after generating the invalid address.) You'll need symbol (PDB) files to get much useful information, but if you're building OpenSSL you can easily arrange for those. Of course there are other possibilities, such as changes to the build flags between the two versions. And I haven't looked to see whether the OpenSSL sources for 1.0.2h or 1.0.2i include Atom assembly modules; that would be something else to check. -- Michael Wojcik Distinguished Engineer, Micro Focus From zeyuany at gmail.com Wed Jun 13 16:32:11 2018 From: zeyuany at gmail.com (Zeyuan Yu) Date: Wed, 13 Jun 2018 11:32:11 -0500 Subject: [openssl-users] Access clienthello in openssl1.1.0 Message-ID: Hi All, Is there still a way to access client hello in 1.1.0? Before 1.1.0 I can just access the internal `s->init_msg`. And starting 1.1.1, APIs are provided for the client hello. But there doesn't seem to be similar methods in 1.1.0. -Best, Zeyuan -- [image: work-eat-sleep--400090.jpg] *Zeyuan Yu* Assoc Software Development Engineer, Oath m: 217.369.5086 -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Jun 13 17:39:28 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 13 Jun 2018 13:39:28 -0400 Subject: [openssl-users] Advantech openssl compatibility issue In-Reply-To: References: <5442f90a17204726aa69600d581063aa@taipei08.ADVANTECH.CORP> Message-ID: > On Jun 13, 2018, at 12:31 PM, Michael Wojcik wrote: > > It's a c0000005 - an addressing violation - so there's a decent chance that it's raised in or near (in terms of stack frames) where the actual cause exists in the code. Perhaps a memory alignment issue, that is somewhat peculiar to the SOC in question. I'd try a non ASM build, and if that passes, look for changes in the ASM code, or changes in the build flags. -- Viktor. From jef at steelant.be Thu Jun 14 08:22:02 2018 From: jef at steelant.be (Jef Steelant) Date: Thu, 14 Jun 2018 10:22:02 +0200 Subject: [openssl-users] Engine for an openssl server with a private key Message-ID: Hi, I have a program that sets up multiple server connections with a different private RSA key for each. I want to offload the private key to another process. I did this for client connections with SSL_CTX_set_client_cert_engine but nothing similar exists for a server connection. Can this be done? Regards, Jef Steelant -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Thu Jun 14 08:34:43 2018 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 14 Jun 2018 11:34:43 +0300 Subject: [openssl-users] Engine for an openssl server with a private key In-Reply-To: References: Message-ID: Hello, On Thu, Jun 14, 2018 at 11:22 AM, Jef Steelant wrote: > Hi, > > I have a program that sets up multiple server connections with a different > private RSA key for each. I want to offload the private key to another > process. I did this for client connections with SSL_CTX_set_client_cert_engine > but nothing similar exists for a server connection. Can this be done? > > > I solved this problem for my purpose by writing a custom RSA method. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.vollaro at optum.com Thu Jun 14 16:39:46 2018 From: john.vollaro at optum.com (Vollaro, John) Date: Thu, 14 Jun 2018 16:39:46 +0000 Subject: [openssl-users] Windows 7 cryptbase.dll failing to load Message-ID: <14BFB9F1FC4A3B4AA76108325E1CEB76676C5F26@APSWP0838.ms.ds.uhc.com> Hi OpenSSL team, Our team has successfully built Window dlls for OpenSSL code version 1.0.2n. The dll names where libeay32.dll & ssleay32.dll. They worked on Windows 7 and Windows Server 2012 OS. Our team has built Window dlls for the OpenSSL code using version 1.1.0h. The dll names where libcrypt0-1_1-x64.dll & libssl-1_1-x64.dll These dlls worked on Windows Server 2012 OS. These dlls do *not* load on Windows 7 OS. I suspect an issue with Windows library cryptbase.dll Any suggestion on getting this to work on Windows 7? Has anyone else encountered this issue? This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Thu Jun 14 21:58:20 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 14 Jun 2018 23:58:20 +0200 Subject: [openssl-users] Windows 7 cryptbase.dll failing to load In-Reply-To: <14BFB9F1FC4A3B4AA76108325E1CEB76676C5F26@APSWP0838.ms.ds.uhc.com> References: <14BFB9F1FC4A3B4AA76108325E1CEB76676C5F26@APSWP0838.ms.ds.uhc.com> Message-ID: <412362ac-f487-d4a0-a12a-3bed20c7d0b8@wisemo.com> On 14/06/2018 18:39, Vollaro, John via openssl-users wrote: > > Hi OpenSSL team, > > Our team has successfully built Window dlls for OpenSSL code version > 1.0.2n. > > The dll names where libeay32.dll & ssleay32.dll. > > They worked on Windows 7 and Windows Server 2012 OS. > > Our team has built Window dlls for the OpenSSL code using version 1.1.0h. > > The dll names where libcrypt0-1_1-x64.dll & libssl-1_1-x64.dll > > These dlls worked on ?Windows Server 2012 OS. > > These dlls do **not** load on Windows 7 OS. > > I suspect an issue with Windows library cryptbase.dll > Note the translation table for Windows version names: DosWindows 1.01 == Windows 1.0 DosWindows 1.02 DosWindows 1.03 DosWindows 1.04 DosWindows 2.03 DosWindows 2.10 DosWindows 2.11 DosWindows 3.00 DosWindows 3.10 == Janus == Sparta == Winball DosWindows 3.11 == Snowball DosWindows 4.00.950/3.95 == Windows 95== MS-DOS 7.00 == Chicago DosWindows 4.00.1111/3.9? == Windows 95 OSR2== MS-DOS 7.01 == Detroit DosWindows 4.10.1998/3.9? == Windows 98 == Memphis DosWindows 4.10.2222/3.9? == Windows 98 SE DosWindows 4.90.3000/3.9? == Windows ME NT 3.10.528 == Razzle NT 3.50.807 == Daytona NT 3.51.1057 NT 4.00.1381 NT 4.00.1381SP3 == NT4.00 and NT4.00 Terminal Server Edition == Hydra NT 5.00.2195 == Windows 2000 NT 5.01.2600 == Windows XP (x86 and IA64) == maybe special Server 200x for IA64 == Whistler NT 5.02.37?? == Windows XP (x64) == Server 2003 == Server 2003 R2 NT 6.00.6000 == Windows Vista == Server 2008 == Longhorn NT 6.01.7600 == Windows 7 == Server 2008 R2 == Blackcomb == Vienna NT 6.02.9200 == Windows 8 == Server 2012 NT 6.03.9600 == Windows 8.1 == Server 2012 R2 == WinBlue NT 10.00.10240 (1507) == Windows 10 original== LTSB 2015 == Threshold 1 NT 10.00.10586 (1511) == Windows 10 November update == Threshold 2 NT 10.00.14393 (1607) == Windows 10 Anniversary update== LTSB 2016 == Windows Server 2016 == V2 (Redstone) NT 10.00.15063 (1703) == Windows 10 Creators update == Redstone 2 NT 10.00.16299 (1709) == Windows 10 Fall Creators update == Redstone 3 NT 10.00.17134 (1803) == Windows 10 April 2018 update == Redstone 4 Thus your 1.1.0 build runs on NT6.02 but not NT6.01, possibly due to references to NT6.02-only APIs > > Any suggestion on getting this to work on Windows 7? > > Has anyone else encountered this issue? > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 Michael.Wojcik at microfocus.com Thu Jun 14 22:39:23 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 14 Jun 2018 22:39:23 +0000 Subject: [openssl-users] Windows 7 cryptbase.dll failing to load In-Reply-To: <412362ac-f487-d4a0-a12a-3bed20c7d0b8@wisemo.com> References: <14BFB9F1FC4A3B4AA76108325E1CEB76676C5F26@APSWP0838.ms.ds.uhc.com> <412362ac-f487-d4a0-a12a-3bed20c7d0b8@wisemo.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Jakob Bohm > Sent: Thursday, June 14, 2018 15:58 > > Thus your 1.1.0 build runs on NT6.02 but not NT6.01, possibly due to > references to NT6.02-only APIs Sometimes the subsystem version information inserted by the linker is pessimistic for no reason (other than Microsoft's desire to get people to upgrade). Depends on the version of the Microsoft SDK installed, among other things. So the OP might just try linking the DLL with /VERSION:6.1. I'm not currently building a 1.1 OpenSSL, so I can't say what would need to be done with Configure to get that into the generated makefile. -- Michael Wojcik Distinguished Engineer, Micro Focus From sahil.malhotra at nxp.com Fri Jun 15 05:40:50 2018 From: sahil.malhotra at nxp.com (Sahil Malhotra) Date: Fri, 15 Jun 2018 05:40:50 +0000 Subject: [openssl-users] Openssl 1.1.0: x509: Bad format "engine"; must be pem or der Message-ID: Hi All, I am trying to create a self-signed certificate using the following commands. Working with engine_pkcs11 provided by opensc/libp11. When I was running these commands with openssl 1.0.2, these were working fine. When I tried running with openssl 1.1.0, Getting the following error. Can anyone please help to find what I am doing wrong ? root at Ubuntu:~/new# root at Ubuntu:~/new# /usr/bin/openssl req -engine pkcs11 -new -key "pkcs11:model=;manufacturer=ABC;serial=1;token=ABC_TOKEN;id=%01%00%00%00;object=Device_Key;type=private" -keyform engine -out req.pem -text -x509 -subj "/CN=NXP Semiconductor" engine "pkcs11" set. root at Ubuntu:~/new# root at Ubuntu:~/new# root at Ubuntu:~/new# root at Ubuntu:~/new# /usr/bin/openssl x509 -engine pkcs11 -keyform engine -signkey "pkcs11:model=;manufacturer=ABC;serial=1;token=ABC_TOKEN;id=%01%00%00%00;object=Device_Key;type=private " -in req.pem -out cert.pem engine "pkcs11" set. x509: Bad format "engine"; must be pem or der x509: Invalid format "engine" for -keyform x509: Use -help for summary. root at Ubuntu:~/new# root at Ubuntu:~/new# Regards, Sahil Malhotra -------------- next part -------------- An HTML attachment was scrubbed... URL: From soporteallpurpose at gmail.com Fri Jun 15 13:34:42 2018 From: soporteallpurpose at gmail.com (Fernando A) Date: Fri, 15 Jun 2018 10:34:42 -0300 Subject: [openssl-users] I need help to implement triple des algorithm with openssl Message-ID: Hi all, I am not an expert with openssl and I need replace a component in c# that run algorithm Triple DES. I tried in the command line something like this "openssl enc -des-ede3 -k 1234567890123456ABCDEFGH -in test.txt -out test.enc" but the result that I obtain is diferent of result launched by the c# component. Of course the passphrase is the same, and always file test.enc contain a phrase that start with "Salted__..." indifferent of the contain of file test.txt. some idea? thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: From stm at pdflib.com Fri Jun 15 13:45:26 2018 From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=) Date: Fri, 15 Jun 2018 15:45:26 +0200 Subject: [openssl-users] OpenSSL 1.1.0: No X509_STORE_CTX_set_cert_crl() function? Message-ID: <7956752d-984b-130e-dd5e-d320ca497d50@pdflib.com> Hi, while porting from OpenSSL 1.0.2. to OpenSSL 1.1.0 I ran into the following problem: With OpenSSL 1.0.2. I plugged into the certificate verification mechanism in order to capture the X509_CRL that was used to validate a certificate. The original function pointer stored in the cert_crl member of a X509_STORE_CTX structure was saved, and another function was assigned to the cert_crl member that called the saved original cert_crl function and then performed additional operations with the X509_CRL structure. It looks like in OpenSSL 1.1.0 I can no longer do that. There are only functions available that return various function pointers from a X509_STORE_CTX structure (like X509_STORE_CTX_get_cert_crl), but there are no corresponding counterparts to set the function pointers. Is this intentional, or is this an omission in OpenSSL 1.1.0? If this is intentional, how could I reproduce the funtionality without having to duplicate the code in the static cert_crl() function in x509_vfy.c? Thanks Stephan From matt at openssl.org Fri Jun 15 13:53:07 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 15 Jun 2018 14:53:07 +0100 Subject: [openssl-users] I need help to implement triple des algorithm with openssl In-Reply-To: References: Message-ID: <118d47a6-ab93-e2e5-f7ba-5ec7edc00ff0@openssl.org> On 15/06/18 14:34, Fernando A wrote: > Hi all, > > I am not an expert with openssl and I need replace a component in c# > that run algorithm Triple DES. > I tried in the command line something like this? > "openssl enc -des-ede3 -k 1234567890123456ABCDEFGH -in test.txt -out > test.enc" > > but the result that I obtain is diferent of result launched by the c# > component. > Of course the passphrase is the same, and always file test.enc contain a > phrase > that start with "Salted__..." indifferent of the contain of file test.txt. > some idea? > thanks in advance! Is your c# component using a passphrase or a key? If a passphrase, how does it generate the key from that passphrase? By default the OpenSSL enc command uses its own key derivation function (KDF) to generate a key from a passphrase. That KDF uses a random salt value which it prepends to the beginning of the file. If the KDF in C# is different (which it almost certainly is), and it doesn't use the same file format as OpenSSL uses (which it almost certainly doesn't) then you're going to get different results. You can alternatively pass a key rather than a passphrase to the OpenSSL command line. It seems odd that you are using the command line to replace a c# component, rather than using the OpenSSL APIs. Matt From rsalz at akamai.com Fri Jun 15 14:36:10 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 15 Jun 2018 14:36:10 +0000 Subject: [openssl-users] OpenSSL 1.1.0: No X509_STORE_CTX_set_cert_crl() function? In-Reply-To: <7956752d-984b-130e-dd5e-d320ca497d50@pdflib.com> References: <7956752d-984b-130e-dd5e-d320ca497d50@pdflib.com> Message-ID: <2006DABA-5A50-4100-845F-FC411AAC9569@akamai.com> It looks like in OpenSSL 1.1.0 I can no longer do that. There are only functions available that return various function pointers from a X509_STORE_CTX structure (like X509_STORE_CTX_get_cert_crl), but there are no corresponding counterparts to set the function pointers. This could be viewed as a bug; we had no idea people wanted to *set* various fields. WE consider missing accessors/setters in opaque datatypes a bug. From stm at pdflib.com Fri Jun 15 14:51:01 2018 From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=) Date: Fri, 15 Jun 2018 16:51:01 +0200 Subject: [openssl-users] OpenSSL 1.1.0: No X509_STORE_CTX_set_cert_crl() function? In-Reply-To: <2006DABA-5A50-4100-845F-FC411AAC9569@akamai.com> References: <7956752d-984b-130e-dd5e-d320ca497d50@pdflib.com> <2006DABA-5A50-4100-845F-FC411AAC9569@akamai.com> Message-ID: Am 15.06.18 um 16:36 schrieb Salz, Rich via openssl-users: > It looks like in OpenSSL 1.1.0 I can no longer do that. There are only > functions available that return various function pointers from a > X509_STORE_CTX structure (like X509_STORE_CTX_get_cert_crl), but there > are no corresponding counterparts to set the function pointers. > > This could be viewed as a bug; we had no idea people wanted to *set* various fields. WE consider missing accessors/setters in opaque datatypes a bug. I found the following awkward workaround: I set up a temporary X509_STORE_CTX object only for the purpose of getting the original X509_STORE_CTX_cert_crl_fn function pointer that I save somewhere. Then I call X509_STORE_set_cert_crl to assign my own cert_crl function, from which later X509_STORE_CTXs created for the X509_STORE will inherit it. This is the code (minus error checking): X509_STORE *my_store = X509_STORE_new(); X509_STORE_CTX *ctx = X509_STORE_CTX_new(); X509_STORE_CTX_init(ctx, NULL, NULL, NULL); X509_STORE_CTX_cert_crl_fn original_cert_crl = X509_STORE_CTX_get_cert_crl(ctx); X509_STORE_set_cert_crl(my_store, my_own_cert_crl); X509_STORE_CTX_free(ctx); Should I file an issue on GitHub about the missing setters? Thanks Stephan From rsalz at akamai.com Fri Jun 15 14:55:42 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 15 Jun 2018 14:55:42 +0000 Subject: [openssl-users] OpenSSL 1.1.0: No X509_STORE_CTX_set_cert_crl() function? In-Reply-To: References: <7956752d-984b-130e-dd5e-d320ca497d50@pdflib.com> <2006DABA-5A50-4100-845F-FC411AAC9569@akamai.com> Message-ID: <84F20C45-3BD1-4129-94C8-62C582205F1D@akamai.com> > Should I file an issue on GitHub about the missing setters? That would be great, thanks. Glad you got something to work. From soporteallpurpose at gmail.com Fri Jun 15 19:41:08 2018 From: soporteallpurpose at gmail.com (Fernando A) Date: Fri, 15 Jun 2018 16:41:08 -0300 Subject: [openssl-users] I need help to implement triple des algorithm with openssl In-Reply-To: <118d47a6-ab93-e2e5-f7ba-5ec7edc00ff0@openssl.org> References: <118d47a6-ab93-e2e5-f7ba-5ec7edc00ff0@openssl.org> Message-ID: Thank you Matt!, yes it odd, the component in C# is from a third an we don't know C#, we think that for a moment we could replace that using openssl command line. Could show me how pass a key to the openssl? Thank you! El vie., 15 de jun. de 2018 a la(s) 10:53, Matt Caswell (matt at openssl.org) escribi?: > > > On 15/06/18 14:34, Fernando A wrote: > > Hi all, > > > > I am not an expert with openssl and I need replace a component in c# > > that run algorithm Triple DES. > > I tried in the command line something like this > > "openssl enc -des-ede3 -k 1234567890123456ABCDEFGH -in test.txt -out > > test.enc" > > > > but the result that I obtain is diferent of result launched by the c# > > component. > > Of course the passphrase is the same, and always file test.enc contain a > > phrase > > that start with "Salted__..." indifferent of the contain of file > test.txt. > > some idea? > > thanks in advance! > > Is your c# component using a passphrase or a key? If a passphrase, how > does it generate the key from that passphrase? > > By default the OpenSSL enc command uses its own key derivation function > (KDF) to generate a key from a passphrase. That KDF uses a random salt > value which it prepends to the beginning of the file. If the KDF in C# > is different (which it almost certainly is), and it doesn't use the same > file format as OpenSSL uses (which it almost certainly doesn't) then > you're going to get different results. > > You can alternatively pass a key rather than a passphrase to the OpenSSL > command line. > > It seems odd that you are using the command line to replace a c# > component, rather than using the OpenSSL APIs. > > Matt > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Fri Jun 15 22:25:44 2018 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 15 Jun 2018 17:25:44 -0500 Subject: [openssl-users] Access clienthello in openssl1.1.0 In-Reply-To: References: Message-ID: <20180615222544.GK13834@akamai.com> On Wed, Jun 13, 2018 at 11:32:11AM -0500, Zeyuan Yu wrote: > Hi All, > > Is there still a way to access client hello in 1.1.0? > > Before 1.1.0 I can just access the internal `s->init_msg`. And starting > 1.1.1, APIs are provided for the client hello. But there doesn't seem to be > similar methods in 1.1.0. I don't believe so, and it's unclear that this qualifies as a "missing accessor" that would be eligible to get fixed in 1.1.0 as a bugfix. So I think your main option is to move to 1.1.1, at this point. -Ben From director at CforED.com Fri Jun 15 23:18:10 2018 From: director at CforED.com (Harold Huggins) Date: Fri, 15 Jun 2018 16:18:10 -0700 Subject: [openssl-users] exporting the certificate with the .pfx Message-ID: Hi, Everyone, We are having issues exporting the certificate with the .pfx Error printout log file as follows: OpenSSL> pkcs12 -export -out "cfored.pfx" -inkey "cfored_encrypted_private.key" -in "mergeredcertificate.crt" Usage: pkcs12 [options] where options are -export output PKCS12 file -chain add certificate chain -inkey file private key if not infile -certfile f add all certs in f -CApath arg - PEM format directory of CA's -CAfile arg - PEM format file of CA's -name "name" use name as friendly name -caname "nm" use nm as CA friendly name (can be used more than once). -in infile input filename -out outfile output filename -noout don't output anything, just verify. -nomacver don't verify MAC. -nocerts don't output certificates. -clcerts only output client certificates. -cacerts only output CA certificates. -nokeys don't output private keys. -info give info about PKCS#12 structure. -des encrypt private keys with DES -des3 encrypt private keys with triple DES (default) -idea encrypt private keys with idea -seed encrypt private keys with seed -aes128, -aes192, -aes256 encrypt PEM output with cbc aes -camellia128, -camellia192, -camellia256 encrypt PEM output with cbc camellia -nodes don't encrypt private keys -noiter don't use encryption iteration -nomaciter don't use MAC iteration -maciter use MAC iteration -nomac don't generate MAC -twopass separate MAC, encryption passwords -descert encrypt PKCS#12 certificates with triple DES (default RC2-40) -certpbe alg specify certificate PBE algorithm (default RC2-40) -keypbe alg specify private key PBE algorithm (default 3DES) -macalg alg digest algorithm used in MAC (default SHA1) -keyex set MS key exchange type -keysig set MS key signature type -password p set import/export password source -passin p input file pass phrase source -passout p output file pass phrase source -engine e use engine e, possibly a hardware device. -rand file;file;... load the file (or the files in the directory) into the random number generator -CSP name Microsoft CSP name -LMK Add local machine keyset attribute to private key error in pkcs12 OpenSSL> -- HAROLD HUGGINS -------------- next part -------------- An HTML attachment was scrubbed... URL: From director at CforED.com Fri Jun 15 23:25:50 2018 From: director at CforED.com (Harold Huggins) Date: Fri, 15 Jun 2018 16:25:50 -0700 Subject: [openssl-users] exporting the certificate with the .pfx In-Reply-To: References: Message-ID: <0bbc1689d2fd231d243a02f89b59f06e@CforED.com> Hi, Everyone, We are having issues exporting the certificate with the .pfx Error printout log file as follows: OpenSSL> pkcs12 -export -out "cfored.pfx" -inkey "cfored_encrypted_private.key" -in "mergeredcertificate.crt" Usage: pkcs12 [options] where options are -export output PKCS12 file -chain add certificate chain -inkey file private key if not infile -certfile f add all certs in f -CApath arg - PEM format directory of CA's -CAfile arg - PEM format file of CA's -name "name" use name as friendly name -caname "nm" use nm as CA friendly name (can be used more than once). -in infile input filename -out outfile output filename -noout don't output anything, just verify. -nomacver don't verify MAC. -nocerts don't output certificates. -clcerts only output client certificates. -cacerts only output CA certificates. -nokeys don't output private keys. -info give info about PKCS#12 structure. -des encrypt private keys with DES -des3 encrypt private keys with triple DES (default) -idea encrypt private keys with idea -seed encrypt private keys with seed -aes128, -aes192, -aes256 encrypt PEM output with cbc aes -camellia128, -camellia192, -camellia256 encrypt PEM output with cbc camellia -nodes don't encrypt private keys -noiter don't use encryption iteration -nomaciter don't use MAC iteration -maciter use MAC iteration -nomac don't generate MAC -twopass separate MAC, encryption passwords -descert encrypt PKCS#12 certificates with triple DES (default RC2-40) -certpbe alg specify certificate PBE algorithm (default RC2-40) -keypbe alg specify private key PBE algorithm (default 3DES) -macalg alg digest algorithm used in MAC (default SHA1) -keyex set MS key exchange type -keysig set MS key signature type -password p set import/export password source -passin p input file pass phrase source -passout p output file pass phrase source -engine e use engine e, possibly a hardware device. -rand file;file;... load the file (or the files in the directory) into the random number generator -CSP name Microsoft CSP name -LMK Add local machine keyset attribute to private key error in pkcs12 OpenSSL> -- HAROLD HUGGINS -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sat Jun 16 00:08:53 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 15 Jun 2018 20:08:53 -0400 Subject: [openssl-users] exporting the certificate with the .pfx In-Reply-To: <0bbc1689d2fd231d243a02f89b59f06e@CforED.com> References: <0bbc1689d2fd231d243a02f89b59f06e@CforED.com> Message-ID: <7B71EE85-B1E2-4A3E-885C-06045CB3F6E6@dukhovni.org> > On Jun 15, 2018, at 7:25 PM, Harold Huggins wrote: > > We are having issues exporting the certificate with the .pfx Works here. $ openssl req -new -x509 -newkey rsa:1024 -nodes -keyout key.pem -out cert.pem -days 30 -subj "/CN=$(uname -n)" Generating a 1024 bit RSA private key ............................++++++ .................................................++++++ writing new private key to 'key.pem' ----- $ openssl pkcs12 -export -out chain.p12 -inkey key.pem -in cert.pem \ -passout pass:foobar -certpbe aes-128-cbc -keypbe aes-128-cbc $ openssl pkcs12 -info -in chain.p12 -passin pass:foobar -passout pass:foobar MAC Iteration 2048 MAC verified OK PKCS7 Encrypted data: PBES2, PBKDF2, AES-128-CBC, Iteration 2048, PRF hmacWithSHA1 Certificate bag Bag Attributes localKeyID: F7 AC 6C BE 62 B1 CC 80 C7 AC DC B4 9F 85 C6 19 C6 F7 4B 0F subject=/CN=amnesiac.example issuer=/CN=amnesiac.example -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- PKCS7 Data Shrouded Keybag: PBES2, PBKDF2, AES-128-CBC, Iteration 2048, PRF hmacWithSHA1 Bag Attributes localKeyID: F7 AC 6C BE 62 B1 CC 80 C7 AC DC B4 9F 85 C6 19 C6 F7 4B 0F Key Attributes: -----BEGIN ENCRYPTED PRIVATE KEY----- ... -----END ENCRYPTED PRIVATE KEY----- -- Viktor. From dcoombs at carillon.ca Sat Jun 16 12:45:58 2018 From: dcoombs at carillon.ca (Dave Coombs) Date: Sat, 16 Jun 2018 08:45:58 -0400 Subject: [openssl-users] I need help to implement triple des algorithm with openssl In-Reply-To: References: <118d47a6-ab93-e2e5-f7ba-5ec7edc00ff0@openssl.org> Message-ID: <9D70C3C9-4DC4-4B9B-A58A-777E0EACBED6@carillon.ca> > Thank you Matt!, > yes it odd, the component in C# is from a third an we don't know C#, we think that for a moment we could replace that using openssl command line. > > Could show me how pass a key to the openssl? To use a specific key instead of deriving it from a passphrase, use -K instead of -k, with the key in hex. Simple example: $ echo asdf | openssl enc -des-ede3 -K 0123456789abcdef0123456789abcdef | xxd 00000000: 216e eaf3 964d 11bf !n...M.. If ever you're using CBC mode you would also need to specify an IV (with -iv) but you said des-ede3 which is two-key 3DES in ECB, so no need. -Dave > Thank you! > > > > El vie., 15 de jun. de 2018 a la(s) 10:53, Matt Caswell (matt at openssl.org ) escribi?: > > > On 15/06/18 14:34, Fernando A wrote: > > Hi all, > > > > I am not an expert with openssl and I need replace a component in c# > > that run algorithm Triple DES. > > I tried in the command line something like this > > "openssl enc -des-ede3 -k 1234567890123456ABCDEFGH -in test.txt -out > > test.enc" > > > > but the result that I obtain is diferent of result launched by the c# > > component. > > Of course the passphrase is the same, and always file test.enc contain a > > phrase > > that start with "Salted__..." indifferent of the contain of file test.txt. > > some idea? > > thanks in advance! > > Is your c# component using a passphrase or a key? If a passphrase, how > does it generate the key from that passphrase? > > By default the OpenSSL enc command uses its own key derivation function > (KDF) to generate a key from a passphrase. That KDF uses a random salt > value which it prepends to the beginning of the file. If the KDF in C# > is different (which it almost certainly is), and it doesn't use the same > file format as OpenSSL uses (which it almost certainly doesn't) then > you're going to get different results. > > You can alternatively pass a key rather than a passphrase to the OpenSSL > command line. > > It seems odd that you are using the command line to replace a c# > component, rather than using the OpenSSL APIs. > > Matt > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From stm at pdflib.com Mon Jun 18 06:56:24 2018 From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=) Date: Mon, 18 Jun 2018 08:56:24 +0200 Subject: [openssl-users] OpenSSL 1.1.0: No X509_STORE_CTX_set_cert_crl() function? In-Reply-To: <84F20C45-3BD1-4129-94C8-62C582205F1D@akamai.com> References: <7956752d-984b-130e-dd5e-d320ca497d50@pdflib.com> <2006DABA-5A50-4100-845F-FC411AAC9569@akamai.com> <84F20C45-3BD1-4129-94C8-62C582205F1D@akamai.com> Message-ID: Am 15.06.18 um 16:55 schrieb Salz, Rich via openssl-users: >> Should I file an issue on GitHub about the missing setters? > > That would be great, thanks. Glad you got something to work. > Submitte new OpenSSL issue #6505: https://github.com/openssl/openssl/issues/6505 -- Stephan From hkario at redhat.com Mon Jun 18 20:23:11 2018 From: hkario at redhat.com (Hubert Kario) Date: Mon, 18 Jun 2018 22:23:11 +0200 Subject: [openssl-users] Call for testing TLS 1.3 In-Reply-To: <149c2dc6-d1ed-edc8-43cc-4fe8d33ae5cb@openssl.org> References: <20180429104326.GA21314@roeckx.be> <149c2dc6-d1ed-edc8-43cc-4fe8d33ae5cb@openssl.org> Message-ID: <1626025.MiUQL6QOuo@pintsize.usersys.redhat.com> On Friday, 8 June 2018 10:26:07 CEST Matt Caswell wrote: > On 08/06/18 02:48, John Jiang wrote: > > Is it possible to check Key/IV update feature via these tools? > > Thanks! > > Yes. See the "CONNECTED COMMANDS" sections of these pages: > https://www.openssl.org/docs/manmaster/man1/s_server.html > https://www.openssl.org/docs/manmaster/man1/s_client.html > > Basically typing "k" or "K" from an s_server/s_client session will issue > a KeyUpdate message. Using the capitalised form ("K"), additionally > requests a KeyUpdate from the peer. Are there similar commands to perform or control post-handshake client authentication? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From hkario at redhat.com Mon Jun 18 20:40:11 2018 From: hkario at redhat.com (Hubert Kario) Date: Mon, 18 Jun 2018 22:40:11 +0200 Subject: [openssl-users] Call for testing TLS 1.3 In-Reply-To: <20180429104326.GA21314@roeckx.be> References: <20180429104326.GA21314@roeckx.be> Message-ID: <1849113.sVd5ymLn7f@pintsize.usersys.redhat.com> On Sunday, 29 April 2018 12:43:26 CEST Kurt Roeckx wrote: > The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS > 1.3 brings a lot of changes that might cause incompatibility. For > an overview see https://wiki.openssl.org/index.php/TLS1.3 > > We are considering if we should enable TLS 1.3 by default or not, > or when it should be enabled. For that, we would like to know how > applications behave with the latest beta release. > > When testing this, it's important that both sides of the > connection support the same TLS 1.3 draft version. OpenSSL > currently implements draft 26. We would like to see tests > for OpenSSL acting as client and server. > > https://github.com/tlswg/tls13-spec/wiki/Implementations lists > other TLS 1.3 implementations and the draft they currently > support. Note that the versions listed there might not be for the > latest release. It also lists some https test servers. > > We would really like to see a diverse set of applictions being > tested. Please report any results you have to us. We are moving forward with the TLS 1.3 support in tlsfuzzer and early results with OpenSSL look good. We do have a lot more sketched out than actually done though: https:// github.com/tomato42/tlsfuzzer/projects/1 (in total about 170 different scenarios are planned with just 12 implemented). -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From matt at openssl.org Mon Jun 18 22:21:19 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 18 Jun 2018 23:21:19 +0100 Subject: [openssl-users] Call for testing TLS 1.3 In-Reply-To: <1626025.MiUQL6QOuo@pintsize.usersys.redhat.com> References: <20180429104326.GA21314@roeckx.be> <149c2dc6-d1ed-edc8-43cc-4fe8d33ae5cb@openssl.org> <1626025.MiUQL6QOuo@pintsize.usersys.redhat.com> Message-ID: <6d6e727c-48df-7c31-63cd-ab13cc1c536e@openssl.org> On 18/06/18 21:23, Hubert Kario wrote: > On Friday, 8 June 2018 10:26:07 CEST Matt Caswell wrote: >> On 08/06/18 02:48, John Jiang wrote: >>> Is it possible to check Key/IV update feature via these tools? >>> Thanks! >> >> Yes. See the "CONNECTED COMMANDS" sections of these pages: >> https://www.openssl.org/docs/manmaster/man1/s_server.html >> https://www.openssl.org/docs/manmaster/man1/s_client.html >> >> Basically typing "k" or "K" from an s_server/s_client session will issue >> a KeyUpdate message. Using the capitalised form ("K"), additionally >> requests a KeyUpdate from the peer. > > Are there similar commands to perform or control post-handshake client > authentication? Yes. As mentioned on the above s_server link, type "c" from an s_server session to send a certificate request to the client. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From devang.kubavat at in.abb.com Tue Jun 19 06:16:07 2018 From: devang.kubavat at in.abb.com (Devang Kubavat) Date: Tue, 19 Jun 2018 06:16:07 +0000 Subject: [openssl-users] Regarding to disable some signature algorithm in client hello message Message-ID: Hi, I want to disable the SHA1 hash algorithm in Extension: signature algorithm client hello message. [cid:image003.jpg at 01D407C3.1A227530] I have used /* the signature algorithms list */ const char signAlgo[] = "RSA+SHA256"; (void)SSL_CTX_set1_client_sigalgs_list(ctx, signAlgo); But, still client is setting all algorithms. Is there any other way to set signature algorithm to SSL_CTX or SSL ? Best Regards, Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 34117 bytes Desc: image003.jpg URL: From murugesh.pitchaiah at gmail.com Tue Jun 19 09:36:15 2018 From: murugesh.pitchaiah at gmail.com (murugesh pitchaiah) Date: Tue, 19 Jun 2018 15:06:15 +0530 Subject: [openssl-users] Regarding to disable some signature algorithm in client hello message In-Reply-To: References: Message-ID: Hi, SSL_CTX_set1_client_sigalgs_list - is the correct method for this purpose. Just try for checking return value of this function. On failure it returns 0. Also try SSL_CTX_set1_client_sigalgs_list (ctx, "RSA+SHA256"); Thanks, Murugesh P. On 6/19/18, Devang Kubavat wrote: > Hi, > > I want to disable the SHA1 hash algorithm in Extension: signature algorithm > client hello message. > > [cid:image003.jpg at 01D407C3.1A227530] > > I have used > /* the signature algorithms list */ > const char signAlgo[] = "RSA+SHA256"; > (void)SSL_CTX_set1_client_sigalgs_list(ctx, signAlgo); > > But, still client is setting all algorithms. Is there any other way to set > signature algorithm to SSL_CTX or SSL ? > > > Best Regards, > Devang > > From matt at openssl.org Tue Jun 19 09:41:37 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 19 Jun 2018 10:41:37 +0100 Subject: [openssl-users] Regarding to disable some signature algorithm in client hello message In-Reply-To: References: Message-ID: On 19/06/18 07:16, Devang Kubavat wrote: > Hi, > > ? > > I want to disable the SHA1 hash algorithm in Extension: signature > algorithm client hello message. > > ? > > I have used > > ??????/* the signature algorithms list */ > > ????? constcharsignAlgo[] = "RSA+SHA256"; > > ????? (void)SSL_CTX_set1_client_sigalgs_list(ctx, signAlgo); > > ? > > But, still client is setting all algorithms. Is there any other way to > set signature algorithm to SSL_CTX or SSL ? The function "SSL_CTX_set1_client_sigalgs_list()" is for setting signature algorithms related to *client authentication*. This is not the same as the sig algs sent in the ClientHello. For that you need to use SSL_CTX_set1_sigalgs_list(). Matt From john.sha.jiang at gmail.com Tue Jun 19 13:40:19 2018 From: john.sha.jiang at gmail.com (John Jiang) Date: Tue, 19 Jun 2018 21:40:19 +0800 Subject: [openssl-users] rsa_pss_pss_*/rsa_pss_rsae_* and TLS_RSA_*/TLS_ECDHE_RSA_* Message-ID: Using OpenSSL 1.1.1-pre7 Please consider the following cases and handshaking results: 1. rsa_pss_pss_256 certificate + TLS_RSA_WITH_AES_256_GCM_SHA384 cipher suite Handshaking failed with no suitable cipher 2. rsa_pss_pss_256 certificate + TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 cipher suite Handshaking succeeded. 3. rsa_pss_rsae_256 certificate + TLS_RSA_WITH_AES_256_GCM_SHA384 cipher suite Handshaking succeeded. 4. rsa_pss_rsae_256 certificate + TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 cipher suite Handshaking succeeded. Why did case 1 fail? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Jun 19 15:11:23 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 19 Jun 2018 17:11:23 +0200 Subject: [openssl-users] rsa_pss_pss_*/rsa_pss_rsae_* and TLS_RSA_*/TLS_ECDHE_RSA_* In-Reply-To: References: Message-ID: On 19/06/2018 15:40, John Jiang wrote: > Using OpenSSL 1.1.1-pre7 > > Please consider the following cases and handshaking results: > 1. rsa_pss_pss_256 certificate + TLS_RSA_WITH_AES_256_GCM_SHA384 > cipher suite > Handshaking failed with no suitable cipher > > 2. rsa_pss_pss_256 certificate + TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > cipher suite > Handshaking succeeded. > > 3. rsa_pss_rsae_256 certificate + TLS_RSA_WITH_AES_256_GCM_SHA384 > cipher suite > Handshaking succeeded. > > 4. rsa_pss_rsae_256 certificate + > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 cipher suite > Handshaking succeeded. > > Why did case 1 fail? The TLS_RSA_ cipher suites require that the premaster secret is encrypted with the RSA key in the servers certificate. But an rsa_pss_pss_256 certificate (have not seen that notation before) is probably a signing-only certificate, that says not to encrypt anything with its RSA key. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 vc.chakrapani at gmail.com Tue Jun 19 15:18:18 2018 From: vc.chakrapani at gmail.com (Chakrapani Reddy) Date: Tue, 19 Jun 2018 20:48:18 +0530 Subject: [openssl-users] help : tls1.3 : tls1.2 test case failing after integration of openssl-1.1.1-pre7 Message-ID: Hello , Started using openssl-1.1.1-pre7 (pre-release 7) in my lab. Compiled the code in Linux successfully. When I run the tls1.2 test case observed that it's failing with openssl-1.1.1-pre7 but the same test case is passing with the openssl-1.1.0g. Sample code : SSL_CTX *ctx = SSL_CTX_new(TLSv1_2_method()); if (ctx==0) { return(false); } if ((ssl_session = SSL_new(ctx))==0) { return(false); } if (ssl_get_new_session(ssl_session, 1)==0) { return(false); } if(ssl_session->session == NULL) { printf("++++++++++ SSL_new : ssl_session->session is NULL +++++++++"); } if(ssl_session->s3 == NULL) { printf("+++++++++ SSL_new : ssl_session->s3 is NULL +++++++++"); } Below are the observations: * SSL_new() returned the valid pointer but s3 member as NULL. * ssl_get_new_session() is giving the session member as NULL. Configured the below flags during the compilation process. ./Configure --prefix=/opt/build/openssl-1.1.1-pre7 no-tls1_3 no-shared enable-rc5 enable-md2 enable-ssl2 enable-weak-ssl-ciphers enable-zlib --with-zlib-lib=/opt/build/zlib-1.2.8/lib/ --with-zlib-include=/opt/build/zlib-1.2.8/include/ linux-x86_64 Behavior is same with the configuration flag " enable-tls1_3" too. Can you please help to explain here if I am missing anything in integration part or known issue in openssl-1.1.1-pre7 ? Regards, Chakrapani -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Jun 19 15:23:33 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 19 Jun 2018 16:23:33 +0100 Subject: [openssl-users] help : tls1.3 : tls1.2 test case failing after integration of openssl-1.1.1-pre7 In-Reply-To: References: Message-ID: On 19/06/18 16:18, Chakrapani Reddy wrote: > Hello??, > > Started using openssl-1.1.1-pre7 (pre-release 7) in my lab. Compiled the > code in Linux successfully. When I run the tls1.2 test case observed > that it's failing with openssl-1.1.1-pre7 but the same test case is > passing with the openssl-1.1.0g. > > Sample code : > ??? SSL_CTX *ctx = SSL_CTX_new(TLSv1_2_method()); > ??? if (ctx==0) { > ??????? return(false); > ??? } > ??? if ((ssl_session = SSL_new(ctx))==0) { > ??????? return(false); > ??? } > ??? if (ssl_get_new_session(ssl_session, 1)==0)? { > ??????? return(false); > ??? } > ??? if(ssl_session->session == NULL) > ??? { > ??????? printf("++++++++++ SSL_new : ssl_session->session is NULL > +++++++++"); > ??? } > ??? if(ssl_session->s3 == NULL) > ??? { > ??????? printf("+++++++++ SSL_new : ssl_session->s3 is NULL +++++++++"); > ??? } > > Below are the observations: > * SSL_new() returned the valid pointer but s3 member? as NULL. > * ssl_get_new_session() is giving the session member as NULL. The SSL object is an opaque type, so you are not supposed to access those members. Given that the structure definition is not in the public header files, have you included an internal OpenSSL header file in your project? If so, that is likely to be your problem. Matt From srikuppa at cisco.com Tue Jun 19 17:54:10 2018 From: srikuppa at cisco.com (Srivalli Kuppa (srikuppa)) Date: Tue, 19 Jun 2018 17:54:10 +0000 Subject: [openssl-users] Regarding to disable some signature algorithm in client hello message In-Reply-To: References: Message-ID: <92F927E2-0D99-4E57-B4EC-9D17C1794CD1@cisco.com> I tried to modify " tls12_sigalgs" list under t1_lib.c in OpenSSL 1.0.2x version to restrict a bunch of signature algorithms from being proposed during Client hello message. That did work. Thanks. Srivalli ?On 6/19/18, 5:36 AM, "openssl-users on behalf of murugesh pitchaiah" wrote: Hi, SSL_CTX_set1_client_sigalgs_list - is the correct method for this purpose. Just try for checking return value of this function. On failure it returns 0. Also try SSL_CTX_set1_client_sigalgs_list (ctx, "RSA+SHA256"); Thanks, Murugesh P. On 6/19/18, Devang Kubavat wrote: > Hi, > > I want to disable the SHA1 hash algorithm in Extension: signature algorithm > client hello message. > > [cid:image003.jpg at 01D407C3.1A227530] > > I have used > /* the signature algorithms list */ > const char signAlgo[] = "RSA+SHA256"; > (void)SSL_CTX_set1_client_sigalgs_list(ctx, signAlgo); > > But, still client is setting all algorithms. Is there any other way to set > signature algorithm to SSL_CTX or SSL ? > > > Best Regards, > Devang > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From john.sha.jiang at gmail.com Wed Jun 20 05:51:11 2018 From: john.sha.jiang at gmail.com (John Jiang) Date: Wed, 20 Jun 2018 13:51:11 +0800 Subject: [openssl-users] rsa_pss_pss_*/rsa_pss_rsae_* and TLS_RSA_*/TLS_ECDHE_RSA_* In-Reply-To: References: Message-ID: 2018-06-19 23:11 GMT+08:00 Jakob Bohm : > On 19/06/2018 15:40, John Jiang wrote: > >> Using OpenSSL 1.1.1-pre7 >> >> Please consider the following cases and handshaking results: >> 1. rsa_pss_pss_256 certificate + TLS_RSA_WITH_AES_256_GCM_SHA384 cipher >> suite >> Handshaking failed with no suitable cipher >> >> 2. rsa_pss_pss_256 certificate + TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 >> cipher suite >> Handshaking succeeded. >> >> 3. rsa_pss_rsae_256 certificate + TLS_RSA_WITH_AES_256_GCM_SHA384 cipher >> suite >> Handshaking succeeded. >> >> 4. rsa_pss_rsae_256 certificate + TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 >> cipher suite >> Handshaking succeeded. >> >> Why did case 1 fail? >> > The TLS_RSA_ cipher suites require that the premaster secret > is encrypted with the RSA key in the servers certificate. > But an rsa_pss_pss_256 certificate (have not seen that notation > before) is probably a signing-only certificate, that says not > to encrypt anything with its RSA key. > Why does rsa_pss_rsae_256 + TLS_RSA_* work? It sounds that rsa_pss_pss_256 and rsa_pss_rsae_256 are the same signature scheme. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.sha.jiang at gmail.com Wed Jun 20 06:11:49 2018 From: john.sha.jiang at gmail.com (John Jiang) Date: Wed, 20 Jun 2018 14:11:49 +0800 Subject: [openssl-users] Call for testing TLS 1.3 In-Reply-To: <6d6e727c-48df-7c31-63cd-ab13cc1c536e@openssl.org> References: <20180429104326.GA21314@roeckx.be> <149c2dc6-d1ed-edc8-43cc-4fe8d33ae5cb@openssl.org> <1626025.MiUQL6QOuo@pintsize.usersys.redhat.com> <6d6e727c-48df-7c31-63cd-ab13cc1c536e@openssl.org> Message-ID: 2018-06-19 6:21 GMT+08:00 Matt Caswell : > > > On 18/06/18 21:23, Hubert Kario wrote: > > On Friday, 8 June 2018 10:26:07 CEST Matt Caswell wrote: > >> On 08/06/18 02:48, John Jiang wrote: > >>> Is it possible to check Key/IV update feature via these tools? > >>> Thanks! > >> > >> Yes. See the "CONNECTED COMMANDS" sections of these pages: > >> https://www.openssl.org/docs/manmaster/man1/s_server.html > >> https://www.openssl.org/docs/manmaster/man1/s_client.html > >> > >> Basically typing "k" or "K" from an s_server/s_client session will issue > >> a KeyUpdate message. Using the capitalised form ("K"), additionally > >> requests a KeyUpdate from the peer. > > > > Are there similar commands to perform or control post-handshake client > > authentication? > > Yes. As mentioned on the above s_server link, type "c" from an s_server > session to send a certificate request to the client. > With the mentioned pages, I don't get how to test 0-RTT. But it sounds that OpenSSL already supports this feature. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From OlegP at actelis.com Wed Jun 20 07:00:53 2018 From: OlegP at actelis.com (Oleg Paikin) Date: Wed, 20 Jun 2018 07:00:53 +0000 Subject: [openssl-users] FIPS 140-2 certification Message-ID: Hi We would like to add to our product OpenSSL with FIPS 140-2 module. The problem is that our OS and CPUs are not FIPS certified. We use vxWorks 5.5.1 with 3 types of CPUs in different products. How can we get certification for these environments? OSF answered that they do not do FIPS consulting work anymore. Can somebody explain what is the process and cost to get such certification? Regards, Oleg -------------- next part -------------- An HTML attachment was scrubbed... URL: From devang.kubavat at in.abb.com Wed Jun 20 08:44:03 2018 From: devang.kubavat at in.abb.com (Devang Kubavat) Date: Wed, 20 Jun 2018 08:44:03 +0000 Subject: [openssl-users] Unexpected behaviors in TLS handshake Message-ID: Hi all, I set the signature algorithm using in client, /* signature algorithm list */ (void)SSL_CTX_set1_client_sigalgs_list(ctx, "RSA+SHA512"); Expected behavior: client only accepts server certificate which has signature algorithm SHA512withRSAencryption during TLS handshake. But, here even I set "RSA+SHA512" signature algorithm, still client is accepting the server certificate which has signature algorithm SHA256withRSAencryption. Why? Best Regards, Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Jun 20 08:55:56 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 20 Jun 2018 09:55:56 +0100 Subject: [openssl-users] Unexpected behaviors in TLS handshake In-Reply-To: References: Message-ID: On 20/06/18 09:44, Devang Kubavat wrote: > Hi all, > > I set the signature algorithm using in client, > > /* signature algorithm list */ > > (void)SSL_CTX_set1_client_sigalgs_list(ctx, ?RSA+SHA512?); > > ? > > Expected behavior: client only accepts server certificate which has > signature algorithm SHA512withRSAencryption during TLS handshake. > > ? > > But, here even I set ?RSA+SHA512? signature algorithm, still client is > accepting the server certificate which has signature algorithm > SHA256withRSAencryption. Why? As I said in reply to your other post: "The function "SSL_CTX_set1_client_sigalgs_list()" is for setting signature algorithms related to *client authentication*. This is not the same as the sig algs sent in the ClientHello. For that you need to use SSL_CTX_set1_sigalgs_list()." Matt From matt at openssl.org Wed Jun 20 09:01:56 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 20 Jun 2018 10:01:56 +0100 Subject: [openssl-users] Call for testing TLS 1.3 In-Reply-To: References: <20180429104326.GA21314@roeckx.be> <149c2dc6-d1ed-edc8-43cc-4fe8d33ae5cb@openssl.org> <1626025.MiUQL6QOuo@pintsize.usersys.redhat.com> <6d6e727c-48df-7c31-63cd-ab13cc1c536e@openssl.org> Message-ID: <8a0eeabc-5172-c342-58c0-6af12cc162a8@openssl.org> On 20/06/18 07:11, John Jiang wrote: > 2018-06-19 6:21 GMT+08:00 Matt Caswell >: > > > > On 18/06/18 21:23, Hubert Kario wrote: > > On Friday, 8 June 2018 10:26:07 CEST Matt Caswell wrote: > >> On 08/06/18 02:48, John Jiang wrote: > >>> Is it possible to check Key/IV update feature via these tools? > >>> Thanks! > >> > >> Yes. See the "CONNECTED COMMANDS" sections of these pages: > >> https://www.openssl.org/docs/manmaster/man1/s_server.html > > >> https://www.openssl.org/docs/manmaster/man1/s_client.html > > >> > >> Basically typing "k" or "K" from an s_server/s_client session will issue > >> a KeyUpdate message. Using the capitalised form ("K"), additionally > >> requests a KeyUpdate from the peer. > > > > Are there similar commands to perform or control post-handshake client > > authentication? > > Yes. As mentioned on the above s_server link, type "c" from an s_server > session to send a certificate request to the client. > > With the mentioned pages, I don't get how to test 0-RTT. > But it sounds that OpenSSL already supports this feature. It is on those pages - just not in the "CONNECTED COMMANDS" section. To test 0-RTT early data start s_server with the "-early_data" flag: $ openssl s_server -early_data Obtain a session that can later be used for sending early data: $ openssl s_client -sess_out session.pem Type "Q" in the s_client window to close the connection. Now you can do a 0-RTT handshake and send early data (assuming the existence of a file "myearlydata.dat" containing the early data you want to send): $ openssl s_client -sess_in session.pem -early_data myearlydata.dat Matt From vc.chakrapani at gmail.com Wed Jun 20 09:53:31 2018 From: vc.chakrapani at gmail.com (Chakrapani Reddy) Date: Wed, 20 Jun 2018 15:23:31 +0530 Subject: [openssl-users] help : tls1.3 : tls1.2 test case failing after integration of openssl-1.1.1-pre7 In-Reply-To: References: Message-ID: Hi Matt, Thanks Matt for your reply. As per my understanding internal OpenSSL header file is not included. Shall we know the way how to access SSL object members with openssl-1.1.1-pre ? Regards, Chakrapani On 19/06/18 16:18, Chakrapani Reddy wrote: > Hello , > > Started using openssl-1.1.1-pre7 (pre-release 7) in my lab. Compiled the > code in Linux successfully. When I run the tls1.2 test case observed > that it's failing with openssl-1.1.1-pre7 but the same test case is > passing with the openssl-1.1.0g. > > Sample code : > SSL_CTX *ctx = SSL_CTX_new(TLSv1_2_method()); > if (ctx==0) { > return(false); > } > if ((ssl_session = SSL_new(ctx))==0) { > return(false); > } > if (ssl_get_new_session(ssl_session, 1)==0) { > return(false); > } > if(ssl_session->session == NULL) > { > printf("++++++++++ SSL_new : ssl_session->session is NULL > +++++++++"); > } > if(ssl_session->s3 == NULL) > { > printf("+++++++++ SSL_new : ssl_session->s3 is NULL +++++++++"); > } > > Below are the observations: > * SSL_new() returned the valid pointer but s3 member as NULL. > * ssl_get_new_session() is giving the session member as NULL. The SSL object is an opaque type, so you are not supposed to access those members. Given that the structure definition is not in the public header files, have you included an internal OpenSSL header file in your project? If so, that is likely to be your problem. Matt On Tue, Jun 19, 2018 at 8:48 PM, Chakrapani Reddy wrote: > Hello , > > Started using openssl-1.1.1-pre7 (pre-release 7) in my lab. Compiled the > code in Linux successfully. When I run the tls1.2 test case observed that > it's failing with openssl-1.1.1-pre7 but the same test case is passing with > the openssl-1.1.0g. > > Sample code : > SSL_CTX *ctx = SSL_CTX_new(TLSv1_2_method()); > if (ctx==0) { > return(false); > } > if ((ssl_session = SSL_new(ctx))==0) { > return(false); > } > if (ssl_get_new_session(ssl_session, 1)==0) { > return(false); > } > if(ssl_session->session == NULL) > { > printf("++++++++++ SSL_new : ssl_session->session is NULL > +++++++++"); > } > if(ssl_session->s3 == NULL) > { > printf("+++++++++ SSL_new : ssl_session->s3 is NULL +++++++++"); > } > > Below are the observations: > * SSL_new() returned the valid pointer but s3 member as NULL. > * ssl_get_new_session() is giving the session member as NULL. > > Configured the below flags during the compilation process. > ./Configure --prefix=/opt/build/openssl-1.1.1-pre7 no-tls1_3 no-shared > enable-rc5 enable-md2 enable-ssl2 enable-weak-ssl-ciphers enable-zlib > --with-zlib-lib=/opt/build/zlib-1.2.8/lib/ --with-zlib-include=/opt/build/zlib-1.2.8/include/ > linux-x86_64 > > Behavior is same with the configuration flag " enable-tls1_3" too. > > Can you please help to explain here if I am missing anything in > integration part or known issue in openssl-1.1.1-pre7 ? > > > Regards, > Chakrapani > -------------- next part -------------- An HTML attachment was scrubbed... URL: From digant.kubavat at gmail.com Wed Jun 20 13:51:54 2018 From: digant.kubavat at gmail.com (Devang Kubavat) Date: Wed, 20 Jun 2018 19:21:54 +0530 Subject: [openssl-users] Unexpected behaviors in TLS handshake In-Reply-To: References: Message-ID: <9BEBC762-48A0-4D32-ABC7-0AC6BA36C101@gmail.com> Hi Matt, Thanks for reply. I also used both functions SSL_CTX_set1_sigalgs_list() SSL_CTX_set1_client_sigalgs_list() but same thing happens. I set client side ?RSA+SHA512? using SSL_CTX_set1_sigalgs_list() but still it is accepting sever certificate which has signature algorithm SHA256withRSAencryption. Best Regards, Devang Sent from my iPhone > On 20-Jun-2018, at 2:25 PM, Matt Caswell wrote: > > > >> On 20/06/18 09:44, Devang Kubavat wrote: >> Hi all, >> >> I set the signature algorithm using in client, >> >> /* signature algorithm list */ >> >> (void)SSL_CTX_set1_client_sigalgs_list(ctx, ?RSA+SHA512?); >> >> >> >> Expected behavior: client only accepts server certificate which has >> signature algorithm SHA512withRSAencryption during TLS handshake. >> >> >> >> But, here even I set ?RSA+SHA512? signature algorithm, still client is >> accepting the server certificate which has signature algorithm >> SHA256withRSAencryption. Why? > > As I said in reply to your other post: > > "The function "SSL_CTX_set1_client_sigalgs_list()" is for setting > signature algorithms related to *client authentication*. This is not the > same as the sig algs sent in the ClientHello. For that you need to use > SSL_CTX_set1_sigalgs_list()." > > Matt > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From openssl at openssl.org Wed Jun 20 15:06:20 2018 From: openssl at openssl.org (OpenSSL) Date: Wed, 20 Jun 2018 15:06:20 +0000 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 8 published Message-ID: <20180620150620.GA32273@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.1.1 pre release 8 (beta) =========================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 8 has now been made available. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. The beta release is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1-pre8.tar.gz Size: 8334954 SHA1 checksum: 6bca29b8b9b6cf399ad9ee585ff72c314406a757 SHA256 checksum: 1205cd763dd92c910cc590658a5b0774599e8587d89d6debd948f242b949321e The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1-pre8.tar.gz openssl sha256 openssl-1.1.1-pre8.tar.gz Please download and check this beta release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlsqaTYACgkQ2cTSbQ5g RJEDPgf+MNjzRojgEzlu1IQmBthLgE2u9FL1IzTqeDGLBHolCws136AP0C8meHMi kJUS616C5Xe8P4NYJKHQhrRoJoB8iY92aJRJTjWLEic/KWR/SmTfLLuUCQ35iArP sT95NOhtHiYhc5iHAk0cDt42kf8ukgpLi1DcobNwzoFUma9M5y973V6fMg7OpIWu gdSFFRjajmGJnWWmlW6+25XPBW+2otu07yRTIM+O08CEl2EcYf0TxDmncCoHS1Zu vHt8HmRVTTzZ27hFndeD2HLeiVUe/teUfHAWe5VyqRhLcNoa20zGX2F/cvzZH8Zb 7qmwRpfVFJX0llNccuhCQVKnah1kjw== =6mX8 -----END PGP SIGNATURE----- From mark at keypair.us Wed Jun 20 15:57:21 2018 From: mark at keypair.us (Mark Minnoch) Date: Wed, 20 Jun 2018 08:57:21 -0700 Subject: [openssl-users] FIPS 140-2 certification Message-ID: Oleg wrote: > We would like to add to our product OpenSSL with FIPS 140-2 module. The problem is that our OS > and CPUs are not FIPS certified. We use vxWorks 5.5.1 with 3 types of CPUs in different products. > > How can we get certification for these environments? OSF answered that they do not do FIPS > consulting work anymore. Can somebody explain what is the process and cost to get such > certification? My company, KeyPair Consulting, helps our Clients with FIPS 140-2 testing for the OpenSSL FIPS Object Module. I sent Oleg a direct message with additional details. Our service is described here: https://keypair.us/private-labels/ Mark J. Minnoch Co-Founder, CISSP, CISA KeyPair Consulting +1 (805) 550-3231 <(805)%20550-3231> mobile https://KeyPair.us https://www.linkedin.com/in/minnoch *We expertly guide technology companies in achieving their FIPS 140 goals* *New blog post: You Have Your FIPS Certificate. Now What? * -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Wed Jun 20 16:15:10 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 20 Jun 2018 16:15:10 +0000 Subject: [openssl-users] FIPS 140-2 certification In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Oleg Paikin > Sent: Wednesday, June 20, 2018 01:01 > We would like to add to our product OpenSSL with FIPS 140-2 module. The problem is that our OS and CPUs > are not FIPS certified. We use vxWorks 5.5.1 with 3 types of CPUs in different products. Disclaimer: I've never had to shepherd anything through the FIPS validation process. The following is just my understanding from reading about it. Nothing is "FIPS certified". FIPS 140-2 does not define a "certification". There is FIPS validation, which if successful results in a "validation certificate". There's also FIPS 140 "user affirmation", which basically involves you saying "hey, any crypto we have is FIPS 140-2 validated in some other context, just not here, cross our hearts". Some customers may accept that, and others may not. There's also a "FIPS Inside" claim, where you say that even if the entire system is not FIPS-validated, all the actual crypto is. (I'm actually not sure that's officially endorsed by the NIST procurement procedures doc; I've heard people who should know claim that it is, but I haven't looked for chapter & verse myself.) Also, note that what's validated is a combination of the cryptographic implementation itself; cryptographic things that are done (e.g. the self-tests) and not done (e.g. no forbidden algorithms are used); and the runtime platform (the "Operational Environment"). So what you'd be getting validated is not the OS and CPUs themselves, but the combination of OpenSSL (and any other crypto software or hardware you might have), OS, and CPU. From your description, it sounds like you need four validations, unless your customers will accept user affirmation. That's assuming your customers aren't also requesting FIPS 140-2 hardware tamper-resistance or some other additional assurance. > How can we get certification for these environments? OSF answered that they do not do FIPS consulting > work anymore. Can somebody explain what is the process and cost to get such certification? The process is you find a lab that will do FIPS 104-2 validation, pay them a lot of money, and wait a long time (months) while they do the testing and go back and forth with the CMVP. History shows that the CMVP can be rather arbitrary. The cost is generally considerable - I think tens of thousands of dollars is typical. Now, all that said, you can use OpenSSL with the FIPS container and enable FIPS mode without claiming you're FIPS-validated. That doesn't fulfill NIST procurement rules, but you may have a customer who isn't subject to those rules but wants to tick some "FIPS" checkbox anyway. (There's no technical advantage to doing so, but cryptography is an esoteric subject and sometimes people come up with pointless requirements.) I've known people who don't need FIPS validation to ask for some FIPS claim anyway, even when that claim is essentially meaningless. If that's the case, just make it possible for the customer to enable FIPS mode and let them go their merry way. -- Michael Wojcik Distinguished Engineer, Micro Focus From mark at keypair.us Wed Jun 20 16:33:04 2018 From: mark at keypair.us (Mark Minnoch) Date: Wed, 20 Jun 2018 09:33:04 -0700 Subject: [openssl-users] OpenSSL FIPS Object Module 2.0 on CD Message-ID: If you are looking for a copy of the OpenSSL FIPS Object Module (versions 2.0 to 2.0.16) delivered to you on CD, then please send an email to cd at keypair.us with your shipping address. We will send you a copy of the original OpenSSL FOM CD. For details, see: https://keypair.us/2018/05/cd/ Mark J. Minnoch Co-Founder, CISSP, CISA KeyPair Consulting +1 (805) 550-3231 <(805)%20550-3231> mobile https://KeyPair.us https://www.linkedin.com/in/minnoch *We expertly guide technology companies in achieving their FIPS 140 goals* *New blog post: You Have Your FIPS Certificate. Now What? * -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Jun 20 16:47:25 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 20 Jun 2018 17:47:25 +0100 Subject: [openssl-users] Unexpected behaviors in TLS handshake In-Reply-To: <9BEBC762-48A0-4D32-ABC7-0AC6BA36C101@gmail.com> References: <9BEBC762-48A0-4D32-ABC7-0AC6BA36C101@gmail.com> Message-ID: <861d741a-a507-05ba-e02d-fbf198017e1e@openssl.org> On 20/06/18 14:51, Devang Kubavat wrote: > Hi Matt, > Thanks for reply. > > I also used both functions SSL_CTX_set1_sigalgs_list() > SSL_CTX_set1_client_sigalgs_list() > but same thing happens. > I set client side ?RSA+SHA512? using SSL_CTX_set1_sigalgs_list() but still it is accepting sever certificate which has signature algorithm SHA256withRSAencryption. RFC5246 (TLSv1.2) says this about sigalgs: The client uses the "signature_algorithms" extension to indicate to the server which signature/hash algorithm pairs may be used in digital signatures. The "extension_data" field of this extension contains a "supported_signature_algorithms" value. There are actually 2 places in TLS where the server sends digital signatures to the client: in the ServerKeyExchange message, and in the server's Certificate. An OpenSSL server will use the client's sigalgs to guide which of its certificates are appropriate to use for the client - so if it has an ECDSA cert but the client hasn't offered any ECDSA sig algs then it won't use that cert. The server will also sign the ServerKeyExchange with one of the sig algs offered by the client. Note though that an OpenSSL server does *not* (by default) check the signature in its certs for compliance with the sig algs. So, for example, if it has an ECDSA cert signed by the CA using RSA+SHA256, but the client only offers ECDSA sig algs then it will still use that certificate. You can configure the server to operate in "strict" mode (e.g. using the "-strict" command line arg to s_server). In that mode it will also check its certificate chain for compliance with the client's sig algs. An OpenSSL client will enforce that the ServerKeyExchange signature is consistent with the sig algs that it sent. It does *not* enforce that the server's certificate signatures are consistent with those sig algs. I don't think there is any equivalent of the server's "-strict" to switch this checking on. Note that in TLSv1.3 there are actually *two* sig algs extensions, i.e. "signature_algorithms" and "signature_algorithms_cert". The latter enables you to specify acceptable signature algorithms in a certificate chain separately from signatures algorithms in the TLSv1.3 CertificateVerify message. Hope that helps, Matt > > Best Regards, > Devang > > Sent from my iPhone > >> On 20-Jun-2018, at 2:25 PM, Matt Caswell wrote: >> >> >> >>> On 20/06/18 09:44, Devang Kubavat wrote: >>> Hi all, >>> >>> I set the signature algorithm using in client, >>> >>> /* signature algorithm list */ >>> >>> (void)SSL_CTX_set1_client_sigalgs_list(ctx, ?RSA+SHA512?); >>> >>> >>> >>> Expected behavior: client only accepts server certificate which has >>> signature algorithm SHA512withRSAencryption during TLS handshake. >>> >>> >>> >>> But, here even I set ?RSA+SHA512? signature algorithm, still client is >>> accepting the server certificate which has signature algorithm >>> SHA256withRSAencryption. Why? >> >> As I said in reply to your other post: >> >> "The function "SSL_CTX_set1_client_sigalgs_list()" is for setting >> signature algorithms related to *client authentication*. This is not the >> same as the sig algs sent in the ClientHello. For that you need to use >> SSL_CTX_set1_sigalgs_list()." >> >> Matt >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From hkario at redhat.com Wed Jun 20 17:20:41 2018 From: hkario at redhat.com (Hubert Kario) Date: Wed, 20 Jun 2018 19:20:41 +0200 Subject: [openssl-users] rsa_pss_pss_*/rsa_pss_rsae_* and TLS_RSA_*/TLS_ECDHE_RSA_* In-Reply-To: References: Message-ID: <3191979.IQF0b6dFqg@pintsize.usersys.redhat.com> On Wednesday, 20 June 2018 07:51:11 CEST John Jiang wrote: > 2018-06-19 23:11 GMT+08:00 Jakob Bohm : > > On 19/06/2018 15:40, John Jiang wrote: > >> Using OpenSSL 1.1.1-pre7 > >> > >> Please consider the following cases and handshaking results: > >> 1. rsa_pss_pss_256 certificate + TLS_RSA_WITH_AES_256_GCM_SHA384 cipher > >> suite > >> Handshaking failed with no suitable cipher > >> > >> 2. rsa_pss_pss_256 certificate + TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > >> cipher suite > >> Handshaking succeeded. > >> > >> 3. rsa_pss_rsae_256 certificate + TLS_RSA_WITH_AES_256_GCM_SHA384 cipher > >> suite > >> Handshaking succeeded. > >> > >> 4. rsa_pss_rsae_256 certificate + TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > >> cipher suite > >> Handshaking succeeded. > >> > >> Why did case 1 fail? > > > > The TLS_RSA_ cipher suites require that the premaster secret > > is encrypted with the RSA key in the servers certificate. > > But an rsa_pss_pss_256 certificate (have not seen that notation > > before) is probably a signing-only certificate, that says not > > to encrypt anything with its RSA key. > > Why does rsa_pss_rsae_256 + TLS_RSA_* work? > It sounds that rsa_pss_pss_256 and rsa_pss_rsae_256 are the same signature > scheme. because certificate that is usable for rsa_pss_rsae_sha256 signatures has a rsaEncryption Subject Public Key Info, that means it is generally usable both for encrypting the premaster key (TLS_RSA_* ciphers) and making signatures of its own (TLS_ECDHE_RSA_* ciphers), unless the KeyUsage X509v3 extension doesn't say otherwise... certificate that has a rsassa-pss Subject Public Key Info key is usable *only* for making rsassa-pss signatures (or rsa_pss_pss_* signatures) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From openssl-users at dukhovni.org Wed Jun 20 17:31:15 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 20 Jun 2018 13:31:15 -0400 Subject: [openssl-users] Unexpected behaviors in TLS handshake In-Reply-To: <861d741a-a507-05ba-e02d-fbf198017e1e@openssl.org> References: <9BEBC762-48A0-4D32-ABC7-0AC6BA36C101@gmail.com> <861d741a-a507-05ba-e02d-fbf198017e1e@openssl.org> Message-ID: <04A60B9E-5CED-407A-A777-0F4BF79031D7@dukhovni.org> > On Jun 20, 2018, at 12:47 PM, Matt Caswell wrote: > > An OpenSSL client will enforce that the ServerKeyExchange signature is > consistent with the sig algs that it sent. It does *not* enforce that > the server's certificate signatures are consistent with those sig algs. > I don't think there is any equivalent of the server's "-strict" to > switch this checking on. > > Note that in TLSv1.3 there are actually *two* sig algs extensions, i.e. > "signature_algorithms" and "signature_algorithms_cert". The latter > enables you to specify acceptable signature algorithms in a certificate > chain separately from signatures algorithms in the TLSv1.3 > CertificateVerify message. Right, certificate chain verification is the business of the X.509 code in libcrypto and lies entirely outside the SSL library. The SSL library sets the "security level" establishing a baseline acceptable cryptographic strength, but otherwise, if your trusted CAs use particular signature algorithms (per CA/B Forum practices, ...) then you'll accept the algorithms they use. If some root CAs, or intermediate CAs to which they delegate authority, employ weak algorithms, your best bet is to not trust those CAs, they should not be using weak algorithms. TLS is not the best place to regulate (Web) PKI. At present libcrypto does not provide a fine-grained way to restrict which signature algorithms are acceptable for a particular invocation of X509_verify_cert(3). The "best" you can do is enable only the EVP algorithms you want when when initializing the OpenSSL library. I don't recall whether leaving some EVP algorithms uninitialized is still possible now that OpenSSL 1.1.x is doing automatic self-initialization. -- Viktor. From ylavic.dev at gmail.com Wed Jun 20 18:55:35 2018 From: ylavic.dev at gmail.com (Yann Ylavic) Date: Wed, 20 Jun 2018 20:55:35 +0200 Subject: [openssl-users] Double TLS 1.3 session ticket? Message-ID: Hi, connecting s_client to s_server with TLS 1.3 seems to cause two successive session tickets to be sent by the server (see below). Is this expected? $ openssl s_server -accept 127.0.0.1:4443 -cert ... -key ... -state Using default temp DH parameters ACCEPT SSL_accept:before SSL initialization SSL_accept:before SSL initialization SSL_accept:SSLv3/TLS read client hello SSL_accept:SSLv3/TLS write server hello SSL_accept:SSLv3/TLS write change cipher spec SSL_accept:TLSv1.3 write encrypted extensions SSL_accept:SSLv3/TLS write certificate SSL_accept:TLSv1.3 write server certificate verify SSL_accept:SSLv3/TLS write finished SSL_accept:TLSv1.3 early data SSL_accept:TLSv1.3 early data SSL_accept:SSLv3/TLS read finished SSL_accept:SSLv3/TLS write session ticket SSL_accept:SSLv3/TLS write session ticket ... $ openssl s_client -connect 127.0.0.1:4443 -state CONNECTED(00000003) SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS read server hello SSL_connect:TLSv1.3 read encrypted extensions [] SSL_connect:SSLv3/TLS read server certificate SSL_connect:TLSv1.3 read server certificate verify SSL_connect:SSLv3/TLS read finished SSL_connect:SSLv3/TLS write change cipher spec SSL_connect:SSLv3/TLS write finished [] --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 1344 bytes and written 395 bytes Verification error: unable to verify the first certificate --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 1024 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: Session-ID-ctx: Master-Key: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 PSK identity: None PSK identity hint: None SRP username: None Start Time: 1529519509 Timeout : 7200 (sec) Verify return code: 21 (unable to verify the first certificate) Extended master secret: no --- SSL_connect:SSL negotiation finished successfully SSL_connect:SSL negotiation finished successfully SSL_connect:SSLv3/TLS read server session ticket read R BLOCK SSL_connect:SSL negotiation finished successfully SSL_connect:SSL negotiation finished successfully SSL_connect:SSLv3/TLS read server session ticket read R BLOCK ... Regards, Yann. From openssl-users at dukhovni.org Wed Jun 20 18:59:54 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 20 Jun 2018 14:59:54 -0400 Subject: [openssl-users] Double TLS 1.3 session ticket? In-Reply-To: References: Message-ID: <416BCF31-0DB7-4ACA-B6D0-C826F82A0509@dukhovni.org> > On Jun 20, 2018, at 2:55 PM, Yann Ylavic wrote: > > Hi, > > connecting s_client to s_server with TLS 1.3 seems to cause two > successive session tickets to be sent by the server (see below). > > Is this expected? Yes. -- Viktor. From rsalz at akamai.com Wed Jun 20 18:59:04 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 20 Jun 2018 18:59:04 +0000 Subject: [openssl-users] Double TLS 1.3 session ticket? In-Reply-To: References: Message-ID: <240E297E-D487-4F51-BF03-554A644B1499@akamai.com> > connecting s_client to s_server with TLS 1.3 seems to cause two successive session tickets to be sent by the server (see below). > Is this expected? Yes. From ylavic.dev at gmail.com Wed Jun 20 19:20:25 2018 From: ylavic.dev at gmail.com (Yann Ylavic) Date: Wed, 20 Jun 2018 21:20:25 +0200 Subject: [openssl-users] Double TLS 1.3 session ticket? In-Reply-To: <416BCF31-0DB7-4ACA-B6D0-C826F82A0509@dukhovni.org> References: <416BCF31-0DB7-4ACA-B6D0-C826F82A0509@dukhovni.org> Message-ID: On Wed, Jun 20, 2018 at 8:59 PM, Viktor Dukhovni wrote: > > >> On Jun 20, 2018, at 2:55 PM, Yann Ylavic wrote: >> >> Hi, >> >> connecting s_client to s_server with TLS 1.3 seems to cause two >> successive session tickets to be sent by the server (see below). >> >> Is this expected? > > Yes. Thanks, it does not happen with mozzilla implementation (tls13.crypto.mozilla.org), is this openssl specific or part of the specification? Also, since there does not seem to be a round trip in between, any reason to flush the BIO/socket? From jb-openssl at wisemo.com Wed Jun 20 19:44:15 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 20 Jun 2018 21:44:15 +0200 Subject: [openssl-users] Unexpected behaviors in TLS handshake In-Reply-To: <04A60B9E-5CED-407A-A777-0F4BF79031D7@dukhovni.org> References: <9BEBC762-48A0-4D32-ABC7-0AC6BA36C101@gmail.com> <861d741a-a507-05ba-e02d-fbf198017e1e@openssl.org> <04A60B9E-5CED-407A-A777-0F4BF79031D7@dukhovni.org> Message-ID: On 20/06/2018 19:31, Viktor Dukhovni wrote: > > If some root CAs, or intermediate CAs to which they delegate authority, > employ weak algorithms, your best bet is to not trust those > CAs, they should not be using weak algorithms. > > TLS is not the best place to regulate (Web) PKI. I believe there is a fundamental concern, impossible to handle sanely at the CA policy level, that a CA may reasonably have certificate hierarchies targeting people with different maximum security strength and/or living at different times within a root certificate lifespan (decades). Thus it is reasonable for a particular TLS participant to dynamically reject/ignore certificates weaker than it's own policies even if issued by a root CA that has both strong and weak subtrees. For example CA1 may, over time, have the following chains: longtermCAroot -> ? OldIntermediary(signed-with-RSA2048-SHA1, expired or revoked) -> ? ? OldEECerts(all expired or revoked) longtermCAroot -> ? crossSignedNewCAroot(signed-with-RSA2048-SHA256) -> ? NewIntermediary(signed-with-RSA4096-SHA256) -> ? ? ? CurrentEEcerts (all signed with RSA4096-SHA256) newCAroot-> NewIntermediary(signed-with-RSA4096-SHA256) -> ? ? CurrentEEcerts (all signed with RSA4096-SHA256) longtermCAroot -> ? NeverIssuedIntermediary(falsified via SHA1 weakness) -> ??? FakeCert (signed with RSA4096-SHA256). By making a TLS library able to reject certificate chains involving RSA-MD5 (or whatever else the run time configuration chooses to distrust), it can protect its user against trusting the NeverIssuedIntermediary and thus the FakeCert. CA policy and the browser forum can only choose to accept or refuse longtermCAroot entirely.? Trusting only the self-signed variant of crossSignedNewCAroot won't work until that has been distributed via secure channels and all needs to trust longtermCAroot for other uses of the unified openSSL CA directory have disappeared. The scenario becomes even more complicated in cases when (due to refusals to backport algorithms to older libraries), there are real systems that cannot accept the latest state of the art minimum algorithms, thus in turn requiring the ongoing issuance of certificates with old algorithm chaining to CA roots trusted by such older systems. The above pattern of algorithm distrust can be expected to reccur every few decades as new attacks are found or otherwise become viable. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 Jun 20 19:46:46 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 20 Jun 2018 19:46:46 +0000 Subject: [openssl-users] Double TLS 1.3 session ticket? In-Reply-To: References: <416BCF31-0DB7-4ACA-B6D0-C826F82A0509@dukhovni.org> Message-ID: > Thanks, it does not happen with mozzilla implementation (tls13.crypto.mozilla.org), is this openssl specific or part of the specification? The specification allows a server to send one or more tickets, at its discretion. From jetson23 at hotmail.com Wed Jun 20 19:55:10 2018 From: jetson23 at hotmail.com (Jason Schultz) Date: Wed, 20 Jun 2018 19:55:10 +0000 Subject: [openssl-users] OpenSSL FIPS Object Module 2.0 on CD In-Reply-To: References: Message-ID: Just curious, but does this satisfy Section 6.6 of the User Guide, since the CD does not come directly from the OpenSSL Foundation? I don't have a huge need to know, just curious since as with a lot of issues regarding FIPS, no answer would surprise me. ________________________________ From: openssl-users on behalf of Mark Minnoch Sent: Wednesday, June 20, 2018 4:33 PM To: openssl-users at openssl.org Subject: [openssl-users] OpenSSL FIPS Object Module 2.0 on CD If you are looking for a copy of the OpenSSL FIPS Object Module (versions 2.0 to 2.0.16) delivered to you on CD, then please send an email to cd at keypair.us with your shipping address. We will send you a copy of the original OpenSSL FOM CD. For details, see: https://keypair.us/2018/05/cd/ Mark J. Minnoch Co-Founder, CISSP, CISA KeyPair Consulting +1 (805) 550-3231 mobile https://KeyPair.us https://www.linkedin.com/in/minnoch We expertly guide technology companies in achieving their FIPS 140 goals New blog post: You Have Your FIPS Certificate. Now What? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Jun 20 21:07:56 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 20 Jun 2018 17:07:56 -0400 Subject: [openssl-users] Unexpected behaviors in TLS handshake In-Reply-To: References: <9BEBC762-48A0-4D32-ABC7-0AC6BA36C101@gmail.com> <861d741a-a507-05ba-e02d-fbf198017e1e@openssl.org> <04A60B9E-5CED-407A-A777-0F4BF79031D7@dukhovni.org> Message-ID: <5CF39874-4241-4FF4-B0B8-DB0A91CA17CD@dukhovni.org> > On Jun 20, 2018, at 3:44 PM, Jakob Bohm wrote: > > I believe there is a fundamental concern, impossible to handle sanely > at the CA policy level, that a CA may reasonably have certificate > hierarchies targeting people with different maximum security strength > and/or living at different times within a root certificate lifespan > (decades). > > Thus it is reasonable for a particular TLS participant to dynamically > reject/ignore certificates weaker than it's own policies even if > issued by a root CA that has both strong and weak subtrees. For that we have a coarse filter in the form of the security level. Thus MD5 is no longer accepted outside root CA self signatures at the default security level 1 or higher. One thing I forgot to mention is: https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_security_callback.html The callback interface is not yet documented, but it does allow the application to bless or reject each algorithm for a particular purpose: void SSL_CTX_set0_security_ex_data(SSL_CTX *ctx, void *ex); void SSL_CTX_set_security_callback(SSL_CTX *ctx, int (*cb)(SSL *s, SSL_CTX *ctx, int op, int bits, int nid, void *other, void *ex)); When this is documented, users who really want low level control would be able to accept or reject specific algorithms for specific operations. The "op" values of interest are: SSL_SECOP_EE_KEY /* accept/reject an EE public key */ SSL_SECOP_CA_KEY /* accept/reject a CA public key */ SSL_SECOP_CA_MD /* accept/reject a CA hash algorithm */ If there is enough demand and contributor energy, this interface could get documented, code examples provided, ... -- -- Viktor. From ylavic.dev at gmail.com Wed Jun 20 21:31:24 2018 From: ylavic.dev at gmail.com (Yann Ylavic) Date: Wed, 20 Jun 2018 23:31:24 +0200 Subject: [openssl-users] Double TLS 1.3 session ticket? In-Reply-To: References: <416BCF31-0DB7-4ACA-B6D0-C826F82A0509@dukhovni.org> Message-ID: >> Thanks, it does not happen with mozzilla implementation > (tls13.crypto.mozilla.org), is this openssl specific or part of the > specification? > > The specification allows a server to send one or more tickets, at its discretion. OK thanks, I could find the relevant PR and rationale after more googling. One caveat though, the info_callback()s can now be called multiple times with SSL_CB_HANDSHAKE_START/DONE (for each ticket), same possibly for others callbacks (if any) where the state could be tracked. The s_client output from the original message is misleading in this regard. For instance in Apache httpd info_callback() is used to check for and forbid client initiated renegotiations, not a big deal since they shouldn't exist anymore with TLS 1.3 (so this check has been disabled since it's enforced by openssl in the first place), but I wonder if announcing the start then end of the same handshake multiple times could/should be avoided (i.e. handshake ends after last ticket only)? From jb-openssl at wisemo.com Wed Jun 20 21:46:03 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 20 Jun 2018 23:46:03 +0200 Subject: [openssl-users] Unexpected behaviors in TLS handshake In-Reply-To: <5CF39874-4241-4FF4-B0B8-DB0A91CA17CD@dukhovni.org> References: <9BEBC762-48A0-4D32-ABC7-0AC6BA36C101@gmail.com> <861d741a-a507-05ba-e02d-fbf198017e1e@openssl.org> <04A60B9E-5CED-407A-A777-0F4BF79031D7@dukhovni.org> <5CF39874-4241-4FF4-B0B8-DB0A91CA17CD@dukhovni.org> Message-ID: <007eeedf-a528-52b8-d963-800b5feff2d5@wisemo.com> On 20/06/2018 23:07, Viktor Dukhovni wrote: > >> On Jun 20, 2018, at 3:44 PM, Jakob Bohm wrote: >> >> I believe there is a fundamental concern, impossible to handle sanely >> at the CA policy level, that a CA may reasonably have certificate >> hierarchies targeting people with different maximum security strength >> and/or living at different times within a root certificate lifespan >> (decades). >> >> Thus it is reasonable for a particular TLS participant to dynamically >> reject/ignore certificates weaker than it's own policies even if >> issued by a root CA that has both strong and weak subtrees. > For that we have a coarse filter in the form of the security > level. Thus MD5 is no longer accepted outside root CA self > signatures at the default security level 1 or higher. > > One thing I forgot to mention is: > > https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_security_callback.html > > The callback interface is not yet documented, but it does allow > the application to bless or reject each algorithm for a particular > purpose: > > void SSL_CTX_set0_security_ex_data(SSL_CTX *ctx, void *ex); > void SSL_CTX_set_security_callback(SSL_CTX *ctx, > int (*cb)(SSL *s, SSL_CTX *ctx, int op, > int bits, int nid, > void *other, void *ex)); > > When this is documented, users who really want low level > control would be able to accept or reject specific algorithms > for specific operations. > > The "op" values of interest are: > > SSL_SECOP_EE_KEY /* accept/reject an EE public key */ > SSL_SECOP_CA_KEY /* accept/reject a CA public key */ > SSL_SECOP_CA_MD /* accept/reject a CA hash algorithm */ > > If there is enough demand and contributor energy, this > interface could get documented, code examples provided, ... > What would be much more useful would be a way to put the simpler forms in the cipher list or config options list that OpenSSL encourages generic clients and servers to make available to end users, thus allowing such end users (not software developers like me) to disable broken algorithms as soon as practical to their situation.? Also end users wanting higher security levels might want to disable the weaker of the "currently secure" algorithms, along with disabling the corresponding TLS ciphers suites.? So currently, these would be approximately the users who might manually disable 128 bit symmetric cipher suites. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 matt at openssl.org Wed Jun 20 21:49:17 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 20 Jun 2018 22:49:17 +0100 Subject: [openssl-users] Double TLS 1.3 session ticket? In-Reply-To: References: <416BCF31-0DB7-4ACA-B6D0-C826F82A0509@dukhovni.org> Message-ID: On 20/06/18 22:31, Yann Ylavic wrote: >>> Thanks, it does not happen with mozzilla implementation >> (tls13.crypto.mozilla.org), is this openssl specific or part of the >> specification? >> >> The specification allows a server to send one or more tickets, at its discretion. > > OK thanks, I could find the relevant PR and rationale after more googling. > > One caveat though, the info_callback()s can now be called multiple > times with SSL_CB_HANDSHAKE_START/DONE (for each ticket), same > possibly for others callbacks (if any) where the state could be > tracked. The s_client output from the original message is misleading > in this regard. > > For instance in Apache httpd info_callback() is used to check for and > forbid client initiated renegotiations, not a big deal since they > shouldn't exist anymore with TLS 1.3 (so this check has been disabled > since it's enforced by openssl in the first place), but I wonder if > announcing the start then end of the same handshake multiple times > could/should be avoided (i.e. handshake ends after last ticket only)? They really are individual transactions, so it makes much more sense to me to signal each one as a separate handshake. On the client side we have little choice because we don't know how many tickets the server will send. It seems odd to do it differently on the server. Matt From ylavic.dev at gmail.com Wed Jun 20 22:17:26 2018 From: ylavic.dev at gmail.com (Yann Ylavic) Date: Thu, 21 Jun 2018 00:17:26 +0200 Subject: [openssl-users] Double TLS 1.3 session ticket? In-Reply-To: References: <416BCF31-0DB7-4ACA-B6D0-C826F82A0509@dukhovni.org> Message-ID: On Wed, Jun 20, 2018 at 11:49 PM, Matt Caswell wrote: > > On 20/06/18 22:31, Yann Ylavic wrote: >> >> but I wonder if >> announcing the start then end of the same handshake multiple times >> could/should be avoided (i.e. handshake ends after last ticket only)? > > They really are individual transactions, so it makes much more sense to > me to signal each one as a separate handshake. On the client side we > have little choice because we don't know how many tickets the server > will send. It seems odd to do it differently on the server. Right but if s_server had handled SSL_CB_HANDSHAKE_START/DONE in its info callback (like s_client), you'd see "SSL negotiation finished successfully" after each ticket, even if the server knows (or could). They are not really transactions since the client isn't supposed to send anything in between, it's still part of the initial handshake IMHO, and the flush seems not really needed either until the last ticket. Looks like it's missing some state in the machine. Regards, Yann. From ylavic.dev at gmail.com Wed Jun 20 23:16:27 2018 From: ylavic.dev at gmail.com (Yann Ylavic) Date: Thu, 21 Jun 2018 01:16:27 +0200 Subject: [openssl-users] Double TLS 1.3 session ticket? In-Reply-To: References: <416BCF31-0DB7-4ACA-B6D0-C826F82A0509@dukhovni.org> Message-ID: On Thu, Jun 21, 2018 at 12:17 AM, Yann Ylavic wrote: > > Right but if s_server had handled SSL_CB_HANDSHAKE_START/DONE in its > info callback (like s_client), you'd see "SSL negotiation finished > successfully" after each ticket, even if the server knows (or could). Hm, actually I tried that and the real end on the server seems to be SSL_CB_HANDSHAKE_DONE && SSL_get_state(s) == TLS_ST_OK, while SSL_CB_HANDSHAKE_* are only transactions markers (not really limited to tickets). Sorry for the noise. From mark at keypair.us Wed Jun 20 23:35:40 2018 From: mark at keypair.us (Mark Minnoch) Date: Wed, 20 Jun 2018 16:35:40 -0700 Subject: [openssl-users] OpenSSL FIPS Object Module 2.0 on CD Message-ID: I'm responding to a previous post about obtaining a CD of the OpenSSL FIPS Object Module from KeyPair Consulting rather than directly from OpenSSL. The question is: > Just curious, but does this satisfy Section 6.6 of the User Guide, > since the CD does not come directly from the OpenSSL Foundation? That's a great question. KeyPair Consulting will send a copy of the OpenSSL FOM on CD to people that choose not to use the following options: The best way to get the OpenSSL FIPS Object Module distribution is directly from OpenSSL at https://www.openssl.org/source/ The second best way is to get the OpenSSL FIPS Object Module CD directly from OpenSSL (as described in the OpenSSL FOM Security Policy and User Guide). Mark J. Minnoch Co-Founder, CISSP, CISA KeyPair Consulting +1 (805) 550-3231 <(805)%20550-3231> mobile https://KeyPair.us https://www.linkedin.com/in/minnoch *We expertly guide technology companies in achieving their FIPS 140 goals* *New blog post: You Have Your FIPS Certificate. Now What? * -------------- next part -------------- An HTML attachment was scrubbed... URL: From dclarke at blastwave.org Thu Jun 21 03:11:16 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Thu, 21 Jun 2018 04:11:16 +0100 Subject: [openssl-users] Double TLS 1.3 session ticket? In-Reply-To: References: <416BCF31-0DB7-4ACA-B6D0-C826F82A0509@dukhovni.org> Message-ID: On 06/20/2018 08:46 PM, Salz, Rich via openssl-users wrote: >> Thanks, it does not happen with mozzilla implementation > (tls13.crypto.mozilla.org), is this openssl specific or part of the > specification? > > The specification allows a server to send one or more tickets, at its discretion. > That being the case I can close this as "not a bug" : https://bz.apache.org/bugzilla/show_bug.cgi?id=62413 Dennis From best.sakthi3 at gmail.com Thu Jun 21 07:31:16 2018 From: best.sakthi3 at gmail.com (sakdev) Date: Thu, 21 Jun 2018 00:31:16 -0700 (MST) Subject: [openssl-users] Openssl working with hostname(localhost) but not with IP Message-ID: <1529566276168-0.post@n7.nabble.com> Hi, I am migrating my application from visualstudio6.0 to VS2015. My application using is using openssl-1.0.2j. For this migration i built openssl in VS2015, libraries generated successfully. I am using MiniWeb server as virtual server for SSL connections. The problem is libraries(ssleay32.dll & libeay32,dll) built in VS2015 is not working as expected. *"https://localhost" is working but "https://my ip" is not working*. If i replace these dynamic libraries with older one which is built in visualstudio6.0 is working fine with IP. Pls help me to solve this problem. Thanks in advance. While using IP page is showing like this -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From matt at openssl.org Thu Jun 21 08:56:38 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 21 Jun 2018 09:56:38 +0100 Subject: [openssl-users] Double TLS 1.3 session ticket? In-Reply-To: References: <416BCF31-0DB7-4ACA-B6D0-C826F82A0509@dukhovni.org> Message-ID: <5e2a7433-ccd3-a29c-303c-04a8b8549e23@openssl.org> On 20/06/18 23:17, Yann Ylavic wrote: > They are not really transactions since the client isn't supposed to > send anything in between, This is not the case. The client can be sending data before, during/in between, and after the period that the server is issuing tickets. Matt From john.sha.jiang at gmail.com Thu Jun 21 09:44:22 2018 From: john.sha.jiang at gmail.com (John Jiang) Date: Thu, 21 Jun 2018 17:44:22 +0800 Subject: [openssl-users] Call for testing TLS 1.3 In-Reply-To: <8a0eeabc-5172-c342-58c0-6af12cc162a8@openssl.org> References: <20180429104326.GA21314@roeckx.be> <149c2dc6-d1ed-edc8-43cc-4fe8d33ae5cb@openssl.org> <1626025.MiUQL6QOuo@pintsize.usersys.redhat.com> <6d6e727c-48df-7c31-63cd-ab13cc1c536e@openssl.org> <8a0eeabc-5172-c342-58c0-6af12cc162a8@openssl.org> Message-ID: 2018-06-20 17:01 GMT+08:00 Matt Caswell : > > > On 20/06/18 07:11, John Jiang wrote: > > 2018-06-19 6:21 GMT+08:00 Matt Caswell > >: > > > > > > > > On 18/06/18 21:23, Hubert Kario wrote: > > > On Friday, 8 June 2018 10:26:07 CEST Matt Caswell wrote: > > >> On 08/06/18 02:48, John Jiang wrote: > > >>> Is it possible to check Key/IV update feature via these tools? > > >>> Thanks! > > >> > > >> Yes. See the "CONNECTED COMMANDS" sections of these pages: > > >> https://www.openssl.org/docs/manmaster/man1/s_server.html > > > > >> https://www.openssl.org/docs/manmaster/man1/s_client.html > > > > >> > > >> Basically typing "k" or "K" from an s_server/s_client session > will issue > > >> a KeyUpdate message. Using the capitalised form ("K"), > additionally > > >> requests a KeyUpdate from the peer. > > > > > > Are there similar commands to perform or control post-handshake > client > > > authentication? > > > > Yes. As mentioned on the above s_server link, type "c" from an > s_server > > session to send a certificate request to the client. > > > > With the mentioned pages, I don't get how to test 0-RTT. > > But it sounds that OpenSSL already supports this feature. > > It is on those pages - just not in the "CONNECTED COMMANDS" section. > > To test 0-RTT early data start s_server with the "-early_data" flag: > > $ openssl s_server -early_data > > Obtain a session that can later be used for sending early data: > > $ openssl s_client -sess_out session.pem > > Type "Q" in the s_client window to close the connection. Now you can do > a 0-RTT handshake and send early data (assuming the existence of a file > "myearlydata.dat" containing the early data you want to send): > > $ openssl s_client -sess_in session.pem -early_data myearlydata.dat > > If s_server doesn't use option -early_data, the NewSessionTicket won't contain early_data extension, and then in the second connection, s_client won't send early data even option -early_data is used. Right? Is it possible to take s_client to send early data, even though the server don't support 0-RTT. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Jun 21 09:50:41 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 21 Jun 2018 10:50:41 +0100 Subject: [openssl-users] Call for testing TLS 1.3 In-Reply-To: References: <20180429104326.GA21314@roeckx.be> <149c2dc6-d1ed-edc8-43cc-4fe8d33ae5cb@openssl.org> <1626025.MiUQL6QOuo@pintsize.usersys.redhat.com> <6d6e727c-48df-7c31-63cd-ab13cc1c536e@openssl.org> <8a0eeabc-5172-c342-58c0-6af12cc162a8@openssl.org> Message-ID: <738e647b-948b-0761-344a-addea3b50015@openssl.org> On 21/06/18 10:44, John Jiang wrote: > If s_server doesn't use option -early_data, the NewSessionTicket won't > contain early_data extension, > and then in the second connection, s_client won't send early data even > option -early_data is used. > Right? Correct. > Is it possible to take s_client to send early data, even though the > server don't support 0-RTT. You can start s_server with the -early_data option and connect to it via s_client to get the session with the early_data extension in it. Then stop and restart s_server without the early_data extension. Start s_client and attempt to send early_data. The early_data will get rejected and a full handshake will occur instead. Or, another possibility is to do things as I originally suggested (so that s_client sends early data that the server accepts), but then use s_client *again* reusing the same session to send early data. The replay protection will kick in, and s_server will refuse the early data. Matt From jisoza at gmail.com Fri Jun 22 15:03:41 2018 From: jisoza at gmail.com (Juan Isoza) Date: Fri, 22 Jun 2018 17:03:41 +0200 Subject: [openssl-users] Open SSL 1.1.1 release Message-ID: Hello, I'll soon release a software which contain openssl (static linked). I must choose between using 1.1.0, 1.1.1 pre 8, or wait some week .I think TLS 1.3 support is great. Can we suppose 1.1.1 final will be released soon ? regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Jun 22 15:07:04 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 22 Jun 2018 16:07:04 +0100 Subject: [openssl-users] Open SSL 1.1.1 release In-Reply-To: References: Message-ID: On 22/06/18 16:03, Juan Isoza wrote: > > Hello, > I'll soon release a software which contain openssl (static linked). > > I must choose between using 1.1.0, 1.1.1 pre 8, or wait some week .I > think TLS 1.3 support is great. > > Can we suppose 1.1.1 final will be released soon ? There is no definitive release date at the moment. It cannot be released until the TLSv1.3 RFC is published which it hasn't been yet (it's been approved, and is currently in the RFC Editor's queue awaiting publication). We have said that there will be at least one beta release cycle after the RFC publication. Matt From matt at openssl.org Fri Jun 22 15:11:23 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 22 Jun 2018 16:11:23 +0100 Subject: [openssl-users] Open SSL 1.1.1 release In-Reply-To: References: Message-ID: On 22/06/18 16:07, Matt Caswell wrote: > > > On 22/06/18 16:03, Juan Isoza wrote: >> >> Hello, >> I'll soon release a software which contain openssl (static linked). >> >> I must choose between using 1.1.0, 1.1.1 pre 8, or wait some week .I >> think TLS 1.3 support is great. >> >> Can we suppose 1.1.1 final will be released soon ? > > There is no definitive release date at the moment. It cannot be released > until the TLSv1.3 RFC is published which it hasn't been yet (it's been > approved, and is currently in the RFC Editor's queue awaiting > publication). We have said that there will be at least one beta release > cycle after the RFC publication. Oh, one other important point. 1.1.1 pre 8 implements TLSv1.3 draft 28 (the latest available draft). We know that this will *not* be interoperable with the final TLSv1.3 because it uses a special draft version number inside the protocol - the final RFC will use the "real" version number. Matt From Michal.Trojnara at stunnel.org Sat Jun 23 06:10:21 2018 From: Michal.Trojnara at stunnel.org (Michal Trojnara) Date: Sat, 23 Jun 2018 08:10:21 +0200 Subject: [openssl-users] stunnel 5.47 released Message-ID: Dear Users, I have released version 5.47 of stunnel. Version 5.47, 2018.06.23, urgency: HIGH * New features - Fast add_lock_callback for OpenSSL < 1.1.0. This largely improves performance on heavy load. - Automatic detection of Homebrew OpenSSL. - Clarified port binding error logs. - Various "make test" improvements. * Bugfixes - Fixed a crash on switching to SNI slave sections. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: c4e675db996eb92beef885f72a3ed8af3c7603fea6b99d2873198dd6c0021d0b stunnel-5.47.tar.gz 985e1d65a3f4a7599cc78630960e1b2c97981f91ce6bc41f2eefcd371b4067a3 stunnel-5.47-win32-installer.exe 309cfb79329448f0c134aece0d10d0737e3728b25c288e9a76650837cd6f839c stunnel-5.47-android.zip Best regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From naliaka at protonmail.com Mon Jun 25 13:44:51 2018 From: naliaka at protonmail.com (Cyrus Naliaka) Date: Mon, 25 Jun 2018 09:44:51 -0400 Subject: [openssl-users] License change still scheduled for 1.1.1 ? Message-ID: Hi, I see that the latest pre release for 1.1.1 is still under the legacy OpenSSL/SSLeay license. Do you still plan to switch to Apache license for the final 1.1.1 release? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Jun 25 15:20:44 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 25 Jun 2018 15:20:44 +0000 Subject: [openssl-users] License change still scheduled for 1.1.1 ? In-Reply-To: References: Message-ID: <45129FC9-48AC-4A50-A2D4-1C7FFEA7743F@akamai.com> * Do you still plan to switch to Apache license for the final 1.1.1 release? That is still our goal, as stated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.vollaro at optum.com Tue Jun 26 15:12:07 2018 From: john.vollaro at optum.com (Vollaro, John) Date: Tue, 26 Jun 2018 15:12:07 +0000 Subject: [openssl-users] How can we change the names of the libraries from standard names Message-ID: <14BFB9F1FC4A3B4AA76108325E1CEB76676D0DFA@APSWP0838.ms.ds.uhc.com> In the standard make files published for 1.0.2o How can we change the name of these files to reflect the architecture(bitness) of the OS. We would like the 32 bit and 64 bit names to be different. libeay32.dll libeay32.lib ssleay32.dll ssleay32.lib This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe at felipegasper.com Wed Jun 27 11:41:50 2018 From: felipe at felipegasper.com (Felipe Gasper) Date: Wed, 27 Jun 2018 07:41:50 -0400 Subject: [openssl-users] How to send alert in handshake? Message-ID: RFC 3546, in describing the SNI extension, recommends that servers send a warning to clients that request an unknown server name. (Page 9) I?d like to implement that warning .. could someone please point me to which API functions expose this ability? Thank you! -Felipe Gasper Mississauga, ON From rsalz at akamai.com Wed Jun 27 12:59:55 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 27 Jun 2018 12:59:55 +0000 Subject: [openssl-users] How to send alert in handshake? In-Reply-To: References: Message-ID: <241A0428-C225-47E5-9670-4D74B33171E6@akamai.com> As in sending a non-fatal alert? There's no API to do that. And it probably wouldn't work anyway, as most runtimes treat any alert as fatal. Your best bet is to implement the right callback (depends on which version of openssl you are using) and return an error if the SNI isn't one of your allowed values. ?On 6/27/18, 8:45 AM, "Felipe Gasper" wrote: RFC 3546, in describing the SNI extension, recommends that servers send a warning to clients that request an unknown server name. (Page 9) I?d like to implement that warning .. could someone please point me to which API functions expose this ability? Thank you! -Felipe Gasper Mississauga, ON -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From matt at openssl.org Wed Jun 27 13:12:35 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 27 Jun 2018 14:12:35 +0100 Subject: [openssl-users] How to send alert in handshake? In-Reply-To: References: Message-ID: <70c3ab18-10c1-782c-2219-b8582ba02dae@openssl.org> On 27/06/18 12:41, Felipe Gasper wrote: > RFC 3546, in describing the SNI extension, recommends that servers send a warning to clients that request an unknown server name. (Page 9) > > I?d like to implement that warning .. could someone please point me to which API functions expose this ability? In order to implement SNI you need an SNI callback which can be set with this function: long SSL_CTX_set_tlsext_servername_callback(SSL_CTX *ctx, int (*cb)(SSL *, int *, void *)); It is (briefly) documented in 1.1.1 (but not earlier versions - although it exists in those versions): https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_tlsext_servername_callback.html The documentation seems to be missing some vital information though - like what the arguments to the callback mean and what the return value does! The callback should return: SSL_TLSEXT_ERR_OK, if it successfully processed the SNI SSL_TLSEXT_ERR_ALERT_WARNING, to send a warning alert back SSL_TLSEXT_ERR_ALERT_FATAL, to send a fatal alert back SSL_TLSEXT_ERR_NOACK, to continue without acknowledging the SNI at all The alert, if sent, will default to SSL_AD_UNRECOGNIZED_NAME but you can fill in the second "int *" argument to the callback with some other alert value if you wish. >From the callback you can determine what the requested servername was by calling SSL_get_servername(). Note though that RFC 3546 that you reference is obsolete. It was obsoleted by RFC 4366, which itself was obsoleted by RFC 6066. That last RFC has this to say about fatal vs warning alerts: If the server understood the ClientHello extension but does not recognize the server name, the server SHOULD take one of two actions: either abort the handshake by sending a fatal-level unrecognized_name(112) alert or continue the handshake. It is NOT RECOMMENDED to send a warning-level unrecognized_name(112) alert, because the client's behavior in response to warning-level alerts is unpredictable. If there is a mismatch between the server name used by the client application and the server name of the credential chosen by the server, this mismatch will become apparent when the client application performs the server endpoint identification, at which point the client application will have to decide whether to proceed with the communication. TLS implementations are encouraged to make information available to application callers about warning- level alerts that were received or sent during a TLS handshake. Such information can be useful for diagnostic purposes. Matt From openssl-users at dukhovni.org Wed Jun 27 15:57:01 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 27 Jun 2018 11:57:01 -0400 Subject: [openssl-users] How to send alert in handshake? In-Reply-To: <70c3ab18-10c1-782c-2219-b8582ba02dae@openssl.org> References: <70c3ab18-10c1-782c-2219-b8582ba02dae@openssl.org> Message-ID: <82C50DE2-FE07-4344-9B9E-1E2841017883@dukhovni.org> > On Jun 27, 2018, at 9:12 AM, Matt Caswell wrote: > > Note though that RFC 3546 that you reference is obsolete. It was > obsoleted by RFC 4366, which itself was obsoleted by RFC 6066. That last > RFC has this to say about fatal vs warning alerts: > > If the server understood the ClientHello extension but > does not recognize the server name, the server SHOULD take one of two > actions: either abort the handshake by sending a fatal-level > unrecognized_name(112) alert or continue the handshake. It is NOT > RECOMMENDED to send a warning-level unrecognized_name(112) alert, > because the client's behavior in response to warning-level alerts is > unpredictable. If there is a mismatch between the server name used > by the client application and the server name of the credential > chosen by the server, this mismatch will become apparent when the > client application performs the server endpoint identification, at > which point the client application will have to decide whether to > proceed with the communication. What this means is that you really should NOT send alerts, and either select a matching certificate chain, or else let the server proceed with the default certificate chain. Don't abort the connection just because the SNI did not match. Some clients accept more than one server name, but can only send one name in the SNI. The default chain may also be acceptable. -- Viktor. From angus at magsys.co.uk Wed Jun 27 16:55:00 2018 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Wed, 27 Jun 2018 17:55 +0100 (BST) Subject: [openssl-users] How to send alert in handshake? In-Reply-To: <70c3ab18-10c1-782c-2219-b8582ba02dae@openssl.org> Message-ID: > In order to implement SNI you need an SNI callback > The callback should return: > > SSL_TLSEXT_ERR_OK, if it successfully processed the SNI > SSL_TLSEXT_ERR_ALERT_WARNING, to send a warning alert back > SSL_TLSEXT_ERR_ALERT_FATAL, to send a fatal alert back > SSL_TLSEXT_ERR_NOACK, to continue without acknowledging the SNI > at all Our SSL library used to return SSL_TLSEXT_ERR_ALERT_WARNING if no name match was found, until we discovered that Java SSL treats this as a fatal error when we changed to OK. But it did not seem to cause a problem with any browsers or OpenSSL clients, which I assume ignore it. What would SSL_alert_type_string return in the client? Angus From flash at vicsmba.com Thu Jun 28 03:12:02 2018 From: flash at vicsmba.com (Eric S Eberhard) Date: Wed, 27 Jun 2018 20:12:02 -0700 Subject: [openssl-users] [stunnel-users] stunnel 5.47 released In-Reply-To: <30034261.8111.1529733930802.JavaMail.root@m05> References: <30034261.8111.1529733930802.JavaMail.root@m05> Message-ID: <000901d40e8d$cea75f40$6bf61dc0$@vicsmba.com> Query -- how does this relate to TLSv1.3 and the alpha version (which is not going to work with the final version -- and does not exist I think) -- and what version of openssl do you recommend? Thanks, Eric Eric S Eberhard VICS (Vertical Integrated Computer Systems) Voice: 928 567 3529 Cell : 928 301 7537 (not reliable except for text or if not home) 2933 W Middle Verde Rd Camp Verde, AZ 86322 -----Original Message----- From: stunnel-users [mailto:stunnel-users-bounces at stunnel.org] On Behalf Of Michal Trojnara Sent: Friday, June 22, 2018 11:10 PM To: stunnel-users at stunnel.org; stunnel-announce at stunnel.org; openssl-users at openssl.org Subject: [stunnel-users] stunnel 5.47 released Dear Users, I have released version 5.47 of stunnel. Version 5.47, 2018.06.23, urgency: HIGH * New features - Fast add_lock_callback for OpenSSL < 1.1.0. This largely improves performance on heavy load. - Automatic detection of Homebrew OpenSSL. - Clarified port binding error logs. - Various "make test" improvements. * Bugfixes - Fixed a crash on switching to SNI slave sections. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: c4e675db996eb92beef885f72a3ed8af3c7603fea6b99d2873198dd6c0021d0b stunnel-5.47.tar.gz 985e1d65a3f4a7599cc78630960e1b2c97981f91ce6bc41f2eefcd371b4067a3 stunnel-5.47-win32-installer.exe 309cfb79329448f0c134aece0d10d0737e3728b25c288e9a76650837cd6f839c stunnel-5.47-android.zip Best regards, Mike From pratyush.parimal at gmail.com Thu Jun 28 15:41:24 2018 From: pratyush.parimal at gmail.com (pratyush parimal) Date: Thu, 28 Jun 2018 11:41:24 -0400 Subject: [openssl-users] When to call ERR_clear_error() ? Message-ID: Hi all, I have a multi-threaded SSL server application which uses SSL_write()/SSL_read() calls. In my write-loop, whenever SSL_write() returns <= 0, I call SSL_get_error() to see what happened, and then proceed based on what I find. After that, I call ERR_clear_error() because I think I need to clear the error queue for the current thread. Is calling ERR_clear_error() the right thing to do? The manpage for SSL_get_error() says: " ... SSL_get_error() inspects the current thread's OpenSSL error queue. Thus, SSL_get_error() must be used in the same thread that performed the TLS/SSL I/O operation, and no other OpenSSL function calls should appear in between. The current thread's error queue must be empty before the TLS/SSL I/O operation is attempted, or SSL_get_error() will not work reliably." My reason for calling ERR_clear_error() is to make sure that " ... current thread's error queue must be empty before the TLS/SSL I/O operation is attempted ...". My application is multi-threaded and I don't want SSL errors from one thread to cause with other threads. What can happen if I don't call ERR_clear_error() ? Could someone explain the correct/reasonable places I should be using that function? Thanks, Pratyush