From Keonho.Lee at telit.com Wed Jun 1 09:47:47 2016 From: Keonho.Lee at telit.com (Keonho Lee) Date: Wed, 1 Jun 2016 09:47:47 +0000 Subject: [openssl-users] [Question] How to know that all supported SSL version? Message-ID: Hi all, I'd like to know a way or OpenSSL command for what kind of SSL version are supported on current OpenSSL package. ex) SSL3.0/ TLS1.0/ TLS1.2/ DTLS1.0..etc.. BR, KH.Lee. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Image_01.jpg Type: image/jpg Size: 25136 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: autosig_Image_01.jpg Type: image/jpg Size: 2771 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: autosig_Image_07.gif Type: image/gif Size: 1089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: autosig_Image_04.gif Type: image/gif Size: 1059 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: autosig_Image_05.gif Type: image/gif Size: 643 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: autosig_Image_02.JPG Type: image/jpg Size: 8465 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: autosig_Image_06.gif Type: image/gif Size: 1091 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: autosig_Image_03.gif Type: image/gif Size: 1111 bytes Desc: not available URL: From tudor-dan.ambarus at nxp.com Thu Jun 2 13:28:36 2016 From: tudor-dan.ambarus at nxp.com (Tudor-Dan Ambarus) Date: Thu, 2 Jun 2016 13:28:36 +0000 Subject: [openssl-users] dtls record layer throughput test Message-ID: Hi, Is there a throughput test for dtls record layer in openssl? I want to measure the performance of dtls record layer in openssl. I've used s_server and s_client to talk over dtls, but seems that they are only meant for functional testing. Thanks, ta From matt at openssl.org Thu Jun 2 14:30:53 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 2 Jun 2016 15:30:53 +0100 Subject: [openssl-users] dtls record layer throughput test In-Reply-To: References: Message-ID: <5750431D.5030706@openssl.org> On 02/06/16 14:28, Tudor-Dan Ambarus wrote: > Hi, > > Is there a throughput test for dtls record layer in openssl? > I want to measure the performance of dtls record layer in openssl. > > I've used s_server and s_client to talk over dtls, but seems > that they are only meant for functional testing. Not really. s_time exists for TLS testing but unfortunately doesn't support DTLS. There is also ssltest which isn't part of the installed files but is contained in the test directory. That does have some DTLS support and could *possibly* be used for this purpose - but both client and server are in the same process and communication is in memory, not via the network. Matt From loki at zapto.roth.ca Thu Jun 2 16:06:45 2016 From: loki at zapto.roth.ca (Oliver Briscbois) Date: Thu, 02 Jun 2016 23:06:45 +0700 Subject: [openssl-users] ECDSA Certificate does not work References: <20160428063106.GH3300@mournblade.imrryr.org> Message-ID: On 2016-04-28, Viktor Dukhovni wrote: > On Thu, Apr 28, 2016 at 07:44:53AM +0200, Danny wrote: > >> I've been trying to get an ECDSA certificate to work with a Postfix >> installation lately. > > See also http://www.postfix.org/postfix-tls.1.html, which does all > the magic to create RSA and/or ECDSA keys for Postfix 3.1 or later. Thanks for your replies Viktor. I was having the same problem and your solution worked for me also. Oliver From jbtalley98 at gmail.com Fri Jun 3 20:30:46 2016 From: jbtalley98 at gmail.com (Jason Talley) Date: Fri, 3 Jun 2016 15:30:46 -0500 Subject: [openssl-users] FIPS & FIPS_SIgnature Message-ID: Hello all, I have successfully compiled/linked w/ fipsld and FIPS_mode_set(1) returns true. I'm trying to understand what the FIPS_signature variable represents. Can it be used to verify/match against the FIPS library somehow? Is it supposed to match the sha/mac from the fips build? Or should this value simply be unique per release - especially in a static build. (So, if I were to dynamically link, this would stay the same, and in theory, if someone tried to preload a different library, then the fingerprints would likely mismatch and result in a failure to enable). If I dump out the value to truly convince myself that FIPS is enabled, I see: FIPS version part of OpenSSL 1.0.2h-fips 3 May 2016. Signature: dd:4a:38:e6:5d:db:d3:80:c2:aa:8d:20:c2:01:31:26:83:44:fd:1e: If I run OPENSSL_FIPS=1 openssl md5 - then I also get denied b/c FIPS mode is enabled. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danchik at rebelbase.com Thu Jun 9 00:29:26 2016 From: danchik at rebelbase.com (Dan S) Date: Wed, 8 Jun 2016 17:29:26 -0700 Subject: [openssl-users] Symbol(s) not found _TLSv1_2_method _BIO_test_flags Message-ID: Hello, I've compiled openssl.1.0.2h on osx (32bit) and linked staticly my project with libcrypto.a and libssl/a, but I get 2 linking errors with "Symbol(s) not found": _TLSv1_2_method, referenced from ... and _BIO_test_flags, referenced from ... Why would this be happening? ps: (same code works on pc as well but it is linked there with previous verision libs - 1.0.2g) Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From b_duvvuri at yahoo.com Thu Jun 9 05:38:44 2016 From: b_duvvuri at yahoo.com (Bala Duvvuri) Date: Thu, 9 Jun 2016 05:38:44 +0000 (UTC) Subject: [openssl-users] OpenSSL and RFC 5280 References: <2086335050.173386.1465450724106.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <2086335050.173386.1465450724106.JavaMail.yahoo@mail.yahoo.com> Hi All, For our solution to be compliant to RFC 5280: a> What are options to be specified to OpenSSL "req" command during the creation of CSR? b> What are options to be specified to OpenSSL "verify" command to validate a certificate? Does OpenSSL claim to be compliant to RFC 5280? thanks, Bala From danchik at rebelbase.com Sat Jun 11 02:56:52 2016 From: danchik at rebelbase.com (Dan S) Date: Fri, 10 Jun 2016 19:56:52 -0700 Subject: [openssl-users] Symbol(s) not found _TLSv1_2_method _BIO_test_flags In-Reply-To: References: Message-ID: I've also tried 1.0.2g and same problem on osx. Little more details: on pc the expected symbol (_TLSv1_2_method) is in the ssleay32.lib as expected on mac (and this is specifically on 10.5 and 10.6 Darwin i386) it builds two libs: libcrypto.a and libssl.a (the undefined symbol is showing up in libssl.a but as undefined in lib itself) using `nm libssl.a`: libssl.a(s23_meth.o): ....... U _TLSv1_2_enc_data U _TLSv1_2_method ...... and later libssl.a(t1_meth.o): ....... U _TLSv1_2_enc_data 00000000 T _TLSv1_2_method 000001c0 s _TLSv1_2_method_data.16176 ...... it seems there is an object maybe missing from when it was linked. Any help or suggestion would be greatly appreciated Thank you in advance On Wed, Jun 8, 2016 at 5:29 PM, Dan S wrote: > Hello, I've compiled openssl.1.0.2h on osx (32bit) and linked staticly my > project with libcrypto.a and libssl/a, but I get 2 linking errors with > "Symbol(s) not found": > > _TLSv1_2_method, referenced from ... > and > _BIO_test_flags, referenced from ... > > Why would this be happening? > > > ps: (same code works on pc as well but it is linked there with previous > verision libs - 1.0.2g) > > > Thank you > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Suman.Patro-TRN at lntebg.com Sun Jun 12 06:45:10 2016 From: Suman.Patro-TRN at lntebg.com (R-D intern) Date: Sat, 11 Jun 2016 23:45:10 -0700 (MST) Subject: [openssl-users] regarding automating certificate management process Message-ID: <1465713910333-66636.post@n7.nabble.com> Hello, I have implemented ssl for tcp ad HTTP as well i.e ssl security for tcp ad http servers. I have created self- signed certificate for CA and server and client certificates using the self- signed CA certificate.But I would like to know the process of automating certificate management . For example: 1. My certificates and private keys are stored on my local machine in .pem format .I need to make the files unreadable so as to avoid mischief .Hence I create a .pfx file and install that on my windows certificate store, But I would require the cert and key paths in the server program. How do I open windows store and extract certs and keys only to retrieve those for my server program and not store the certs and keys on my local machine or file ? Is this the procedure how keys and certs are secured on server machines ? if not , what is the procedure, please elaborate. 2. One more concern is , if I export the .pfx file for my server program, I need to also give a password with which the .pfx file import had been done on the windows cert store and at some point in time , if the certificate renewal is to be done and the system admin is a new one, a new password will be assigned and on next export of .pfx file to server program, how do I assign new password? Is this the process that needs to be followed? -- View this message in context: http://openssl.6102.n7.nabble.com/regarding-automating-certificate-management-process-tp66636.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From axel.luttgens at skynet.be Sun Jun 12 09:24:51 2016 From: axel.luttgens at skynet.be (Axel Luttgens) Date: Sun, 12 Jun 2016 11:24:51 +0200 Subject: [openssl-users] Symbol(s) not found _TLSv1_2_method _BIO_test_flags In-Reply-To: References: Message-ID: <185D4A0E-FCEC-476F-A12F-33156F9B88B6@skynet.be> > Le 9 juin 2016 ? 02:29, Dan S a ?crit : > > Hello, I've compiled openssl.1.0.2h on osx (32bit) and linked staticly my project with libcrypto.a and libssl/a, but I get 2 linking errors with "Symbol(s) not found": > > _TLSv1_2_method, referenced from ... > and > _BIO_test_flags, referenced from ... > > Why would this be happening? Hello Dan, Difficult to tell from here. ;-) What (and how) are you trying to compile? > Le 11 juin 2016 ? 04:56, Dan S a ?crit : > > I've also tried 1.0.2g and same problem on osx. Little more details: on pc the expected symbol (_TLSv1_2_method) is in the ssleay32.lib as expected > > on mac (and this is specifically on 10.5 and 10.6 Darwin i386) it builds two libs: > > libcrypto.a and libssl.a (the undefined symbol is showing up in libssl.a but as undefined in lib itself) using `nm libssl.a`: > > [?] > > it seems there is an object maybe missing from when it was linked. This may also mean that they are expected to be defined somewhere else. As a minimal test case, could you try to compile this one: #include int main() { SSL_CTX * ctx; ctx = SSL_CTX_new(TLSv1_2_method()); } so as to check the consistency of the -I, -L and -l options passed to gcc? Axel From Suman.Patro-TRN at lntebg.com Sun Jun 12 13:52:44 2016 From: Suman.Patro-TRN at lntebg.com (R-D intern) Date: Sun, 12 Jun 2016 06:52:44 -0700 (MST) Subject: [openssl-users] regarding automating certificate management process Message-ID: <1465739564983-66646.post@n7.nabble.com> Hello, I have implemented ssl for tcp ad HTTP as well i.e ssl security for tcp ad http servers. I have created self- signed certificate for CA and server and client certificates using the self- signed CA certificate.But I would like to know the process of automating certificate management . For example: 1. My certificates and private keys are stored on my local machine in .pem format .I need to make the files unreadable so as to avoid mischief .Hence I create a .pfx file and install that on my windows certificate store, But I would require the cert and key paths in the server program. How do I open windows store and extract certs and keys only to retrieve those for my server program and not store the certs and keys on my local machine or file ? Is this the procedure how keys and certs are secured on server machines ? if not , what is the procedure, please elaborate. 2. One more concern is , if I export the .pfx file for my server program, I need to also give a password with which the .pfx file import had been done on the windows cert store and at some point in time , if the certificate renewal is to be done and the system admin is a new one, a new password will be assigned and on next export of .pfx file to server program, how do I assign new password? Is this the process that needs to be followed? Please reply, Best, R-DIntern -- View this message in context: http://openssl.6102.n7.nabble.com/regarding-automating-certificate-management-process-tp66646.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From jb-openssl at wisemo.com Sun Jun 12 20:49:24 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Sun, 12 Jun 2016 22:49:24 +0200 Subject: [openssl-users] regarding automating certificate management process In-Reply-To: <1465739564983-66646.post@n7.nabble.com> References: <1465739564983-66646.post@n7.nabble.com> Message-ID: <74653a31-a169-bebd-8995-699504c72077@wisemo.com> On 12/06/2016 15:52, R-D intern wrote: > Hello, > I have implemented ssl for tcp ad HTTP as well i.e ssl security for > tcp ad http servers. I have created self- signed certificate for CA and > server and client certificates using the self- signed CA certificate.But I > would like to know the process of automating certificate management . For > example: > 1. My certificates and private keys are stored on my local machine in .pem > format .I need to make the files unreadable so as to avoid mischief .Hence I > create a .pfx file and install that on my windows certificate store, But I > would require the cert and key paths in the server program. How do I open > windows store and extract certs and keys only to retrieve those for my > server program and not store the certs and keys on my local machine or file > ? Is this the procedure how keys and certs are secured on server machines ? > if not , what is the procedure, please elaborate. Although you can (insecurely) set the Windows key stores to allow reading back out the private key, this should never be done except when temporarily storing a key that is not intended to stay there (like when using Microsoft tools to create a PFX file for somewhere else). The standard way is to make your server (or non-server) program call the Windows CryptoAPI functions to perform the operation using the key, without actually revealing the key itself. Microsoft programs such as IIS, IE and the AD LDAP server typically do this by default (to the point of requiring keys to be imported into the Windows store to be used at all). OpenSSL based programs can use a key stored in the Windows key store by using the "CryptoAPI Engine" and instructing it as to which key in the Windows key store it should use. > 2. One more concern is , if I export the .pfx file for my server program, I > need to also give a password with which the .pfx file import had been done > on the windows cert store and at some point in time , if the certificate > renewal is to be done and the system admin is a new one, a new password will > be assigned and on next export of .pfx file to server program, how do I > assign new password? Is this the process that needs to be followed? > Please reply, > Best, > R-DIntern PFX files are generally a bad way to store keys, the format is essentially a botched design originally intended as a means to transport personal keys from one Browser installation to another. While a PFX file conveniently stores a private key along with its public key and a certificate chain, the encryption done is not exactly impressive, often defaulting to outdated NSA-friendly 40-bit encryption as permitted in crypto products exported from the US to the rest of the world in the 1990s. Encrypting a private key PEM file with the options available in modern programs such as OpenSSL tends to be a lot better, though I do know of even stronger protections even for file based private key storage. However ultimately, unless you have access to some super-protected storage locations where the server can store/retrieve a "password" but not a full size private key, giving the server limited access to an unencrypted private key PEM file is not significantly worse than giving the same server access to an encrypted private key and a non-encrypted decryption password for that key. A common way to restrict the servers access to the private key file on non- Windows computers is to have the server process start under a privileged account (such as UNIX root), load the private key and open a few other privileged resources (such as the ability to listen on TCP port 443), then irreversibly drop those privileges before processing any data coming from outside or other dubious places. To access the secret or privileged stuff again, a privileged sysadmin would have to stop the server program and start it again, causing it to load the stuff into memory and dropping privileges again as before (Same thing happens on reboot). On Windows the "irreversibly dropping privileges" feature is missing in the OS design, so another option when designing or modifying a server application is to have a privileged process (such as a service launched under LocalService or LocalSystem account), retrieve the password from an ACL protected registry key, then pass it securely to the actual service process launched under a less privileged account using a call such as CreateProcessAsUserW() or CreateProcessWithLogonW(). Note that neither the command line nor the environment variables are secure because they are exposed to lesser administrators via the WMI service, as used by e.g. the Task Manager UI. As for letting new administrators access secret passwords known to the previous administrators, this issue is in no way limited to certificates and should have a consistent solution in any well-run organizations. One way would be to keep these passwords in a heavily protected (and encrypted) file such as one from a quality off-line password manager program, while having the master decryption password for that file written down in an envelope in a locked physical safe (its kind of hard to hack a piece of paper in a locked non-electronic safe over the Internet...). 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 Prabhat.Puroshottam at outlook.com Mon Jun 13 14:29:54 2016 From: Prabhat.Puroshottam at outlook.com (Prabhat Puroshottam) Date: Mon, 13 Jun 2016 14:29:54 +0000 Subject: [openssl-users] Openssl connecting with TLS 1.0 no matter what Message-ID: Hi, We have client and server software both using openssl. I am using the following on the server side, c = SSL_CTX_new (TLSv1_2_server_method ()); SSL_CTX_set_options(INTERNAL(bi)->context, SSL_OP_ALL|SSL_OP_NO_SSLv2|SSL_OP_NO_TICKET); >From the client side I am using this: c = SSL_CTX_new (TLSv1_2_client_method ()); I have tried SSLv23_client_method and TLSv1_1_client_method and also TLSv1_2_client_method (as above) . Further I have tried setting options SSL_OP_NO_TLSv1|SSL_OP_NO_TLSv1_1. But no matter what I try client always seems to want to communicate in TLS 1.0, which I verified from wireshark output. Openssl version is OpenSSL 1.0.2f-fips 28 Jan 2016. The error reported by SSL_accept on the server side is as follows: s3_srvr.c:960 error:1408A10B:SSL routines:ssl3_get_client_hello:wrong version number Can somebody please help me understand what I am doing wrong? The following is wireshark output for client hello message (where TLS 1.0 can be seen): TLSv1 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 228 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 224 Version: TLS 1.0 (0x0301) Random GMT Unix Time: May 8, 2085 18:48:29.000000000 India Standard Time Random Bytes: 1320449c55b3169ee836d18c6f6493b76f9766c9fd9cd62a... Session ID Length: 32 Session ID: 94734c3d52dc3215bb47ccd71709c9e75312efe8c9bfd088... Cipher Suites Length: 106 Cipher Suites (53 suites) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DH_RSA_WITH_AES_256_CBC_SHA (0x0037) Cipher Suite: TLS_DH_DSS_WITH_AES_256_CBC_SHA (0x0036) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0086) Cipher Suite: TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0085) Cipher Suite: TLS_ECDH_anon_WITH_AES_256_CBC_SHA (0xc019) Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f) Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DH_RSA_WITH_AES_128_CBC_SHA (0x0031) Cipher Suite: TLS_DH_DSS_WITH_AES_128_CBC_SHA (0x0030) Cipher Suite: TLS_DHE_RSA_WITH_SEED_CBC_SHA (0x009a) Cipher Suite: TLS_DHE_DSS_WITH_SEED_CBC_SHA (0x0099) Cipher Suite: TLS_DH_RSA_WITH_SEED_CBC_SHA (0x0098) Cipher Suite: TLS_DH_DSS_WITH_SEED_CBC_SHA (0x0097) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0043) Cipher Suite: TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0042) Cipher Suite: TLS_ECDH_anon_WITH_AES_128_CBC_SHA (0xc018) Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e) Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_SEED_CBC_SHA (0x0096) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_IDEA_CBC_SHA (0x0007) Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007) Cipher Suite: TLS_ECDH_anon_WITH_RC4_128_SHA (0xc016) Cipher Suite: TLS_ECDH_RSA_WITH_RC4_128_SHA (0xc00c) Cipher Suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA (0xc002) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) Cipher Suite: TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA (0x0010) Cipher Suite: TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA (0x000d) Cipher Suite: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA (0xc017) Cipher Suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d) Cipher Suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Thanks, Prabhat. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danchik at rebelbase.com Mon Jun 13 20:14:08 2016 From: danchik at rebelbase.com (Dan S) Date: Mon, 13 Jun 2016 13:14:08 -0700 Subject: [openssl-users] Symbol(s) not found _TLSv1_2_method _BIO_test_flags In-Reply-To: <185D4A0E-FCEC-476F-A12F-33156F9B88B6@skynet.be> References: <185D4A0E-FCEC-476F-A12F-33156F9B88B6@skynet.be> Message-ID: I did this step at a time to see what happens and here are the results: With no paths modified, just bare code produces compile error ('TLSv1_2_method' was not declared at this scope) as expected because openssl that comes osx 10.6 is older without such method - ok so far Adding header paths to the 1.0.2h now compiles but then produces linking Symbols(s) not found: _TLS1_2_method referenced from _main in main.o and _SSL_CTX_new referenced - also means wrong path since it doesn't even see the SSL_CTX_new, ok so far adding new lib paths: and the libs to include m annually via -Lpath and -llib flags : /Developer/usr/bin/g++-4.2 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -L/Volumes/MacintoshHD/w/testss3/build/Debug -L/Volumes/MacintoshHD/w/native_3rdparty/openssl.1.0.2h -F/Volumes/MacintoshHD/w/testss3/build/Debug -filelist /Volumes/MacintoshHD/w/testss3/build/testss3.build/Debug/testss3.build/Objects-normal/x86_64/testss3.LinkFileList -mmacosx-version-min=10.6 -lcrypto -lssl -o /Volumes/MacintoshHD/w/testss3/build/Debug/testss3 (ps, the -filelist ...../testss3.LinkFileList contains single path to the main.o) So to me this looks like 1.0.2h did not compile with TLSv1_2_method (and I can not find the object that implements it either, only see that it is referenced from s23_meth.o) I am thinking there is an .o missing from linking of libssl.a but can't find what object has the implementation of TLSv1_2_method (I've even got rid of all the spaces in all the paths before compiling openssl, make had issues installing across paths with spaces) On Sun, Jun 12, 2016 at 2:24 AM, Axel Luttgens wrote: > > Le 9 juin 2016 ? 02:29, Dan S a ?crit : > > > > Hello, I've compiled openssl.1.0.2h on osx (32bit) and linked staticly > my project with libcrypto.a and libssl/a, but I get 2 linking errors with > "Symbol(s) not found": > > > > _TLSv1_2_method, referenced from ... > > and > > _BIO_test_flags, referenced from ... > > > > Why would this be happening? > > Hello Dan, > > Difficult to tell from here. ;-) > > What (and how) are you trying to compile? > > > > Le 11 juin 2016 ? 04:56, Dan S a ?crit : > > > > I've also tried 1.0.2g and same problem on osx. Little more details: on > pc the expected symbol (_TLSv1_2_method) is in the ssleay32.lib as expected > > > > on mac (and this is specifically on 10.5 and 10.6 Darwin i386) it builds > two libs: > > > > libcrypto.a and libssl.a (the undefined symbol is showing up in libssl.a > but as undefined in lib itself) using `nm libssl.a`: > > > > [?] > > > > it seems there is an object maybe missing from when it was linked. > > This may also mean that they are expected to be defined somewhere else. > > As a minimal test case, could you try to compile this one: > > #include > > int main() > { > SSL_CTX * ctx; > ctx = SSL_CTX_new(TLSv1_2_method()); > } > > so as to check the consistency of the -I, -L and -l options passed to gcc? > > Axel > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danchik at rebelbase.com Mon Jun 13 20:16:24 2016 From: danchik at rebelbase.com (Dan S) Date: Mon, 13 Jun 2016 13:16:24 -0700 Subject: [openssl-users] Symbol(s) not found _TLSv1_2_method _BIO_test_flags In-Reply-To: References: <185D4A0E-FCEC-476F-A12F-33156F9B88B6@skynet.be> Message-ID: sorry forgot to mantion that after linking with all the paths set it produces the single error (one from before: Symbol(s) not found _TLS1_2_method referenced from _main in main.o On Mon, Jun 13, 2016 at 1:14 PM, Dan S wrote: > I did this step at a time to see what happens and here are the results: > > With no paths modified, just bare code produces compile error > ('TLSv1_2_method' was not declared at this scope) as expected because > openssl that comes osx 10.6 is older without such method - ok so far > > Adding header paths to the 1.0.2h now compiles but then produces linking > Symbols(s) not found: _TLS1_2_method referenced from _main in main.o and > _SSL_CTX_new referenced - also means wrong path since it doesn't even see > the SSL_CTX_new, ok so far > > adding new lib paths: and the libs to include m annually via -Lpath and > -llib flags : > > /Developer/usr/bin/g++-4.2 -arch x86_64 -isysroot > /Developer/SDKs/MacOSX10.6.sdk > -L/Volumes/MacintoshHD/w/testss3/build/Debug > -L/Volumes/MacintoshHD/w/native_3rdparty/openssl.1.0.2h > -F/Volumes/MacintoshHD/w/testss3/build/Debug > -filelist > /Volumes/MacintoshHD/w/testss3/build/testss3.build/Debug/testss3.build/Objects-normal/x86_64/testss3.LinkFileList > > -mmacosx-version-min=10.6 > -lcrypto > -lssl > -o /Volumes/MacintoshHD/w/testss3/build/Debug/testss3 > > (ps, the -filelist ...../testss3.LinkFileList contains single path to the > main.o) > > So to me this looks like 1.0.2h did not compile with TLSv1_2_method (and I > can not find the object that implements it either, only see that it is > referenced from s23_meth.o) > > I am thinking there is an .o missing from linking of libssl.a but can't > find what object has the implementation of TLSv1_2_method > > (I've even got rid of all the spaces in all the paths before compiling > openssl, make had issues installing across paths with spaces) > > > On Sun, Jun 12, 2016 at 2:24 AM, Axel Luttgens > wrote: > >> > Le 9 juin 2016 ? 02:29, Dan S a ?crit : >> > >> > Hello, I've compiled openssl.1.0.2h on osx (32bit) and linked staticly >> my project with libcrypto.a and libssl/a, but I get 2 linking errors with >> "Symbol(s) not found": >> > >> > _TLSv1_2_method, referenced from ... >> > and >> > _BIO_test_flags, referenced from ... >> > >> > Why would this be happening? >> >> Hello Dan, >> >> Difficult to tell from here. ;-) >> >> What (and how) are you trying to compile? >> >> >> > Le 11 juin 2016 ? 04:56, Dan S a ?crit : >> > >> > I've also tried 1.0.2g and same problem on osx. Little more details: >> on pc the expected symbol (_TLSv1_2_method) is in the ssleay32.lib as >> expected >> > >> > on mac (and this is specifically on 10.5 and 10.6 Darwin i386) it >> builds two libs: >> > >> > libcrypto.a and libssl.a (the undefined symbol is showing up in >> libssl.a but as undefined in lib itself) using `nm libssl.a`: >> > >> > [?] >> > >> > it seems there is an object maybe missing from when it was linked. >> >> This may also mean that they are expected to be defined somewhere else. >> >> As a minimal test case, could you try to compile this one: >> >> #include >> >> int main() >> { >> SSL_CTX * ctx; >> ctx = SSL_CTX_new(TLSv1_2_method()); >> } >> >> so as to check the consistency of the -I, -L and -l options passed to gcc? >> >> Axel >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danchik at rebelbase.com Mon Jun 13 22:32:35 2016 From: danchik at rebelbase.com (Dan S) Date: Mon, 13 Jun 2016 15:32:35 -0700 Subject: [openssl-users] Symbol(s) not found _TLSv1_2_method _BIO_test_flags In-Reply-To: References: <185D4A0E-FCEC-476F-A12F-33156F9B88B6@skynet.be> Message-ID: So I had a suggestion to verify the correct linking by renaming the libssl and libcrypto built locally to something else, and linking to them- turns out that was the problem, apparently adding the search path in xcode does not take priority :( and it was still linking with the distributed old open ssl that came with 10.6 :( So I may just use the renamed files if I can't figure out how to tell the xcode to ignore the system libraries Thank you for helping look into this for me On Mon, Jun 13, 2016 at 1:16 PM, Dan S wrote: > sorry forgot to mantion that after linking with all the paths set it > produces the single error (one from before: Symbol(s) not found > _TLS1_2_method referenced from _main in main.o > > On Mon, Jun 13, 2016 at 1:14 PM, Dan S wrote: > >> I did this step at a time to see what happens and here are the results: >> >> With no paths modified, just bare code produces compile error >> ('TLSv1_2_method' was not declared at this scope) as expected because >> openssl that comes osx 10.6 is older without such method - ok so far >> >> Adding header paths to the 1.0.2h now compiles but then produces linking >> Symbols(s) not found: _TLS1_2_method referenced from _main in main.o and >> _SSL_CTX_new referenced - also means wrong path since it doesn't even see >> the SSL_CTX_new, ok so far >> >> adding new lib paths: and the libs to include m annually via -Lpath and >> -llib flags : >> >> /Developer/usr/bin/g++-4.2 -arch x86_64 -isysroot >> /Developer/SDKs/MacOSX10.6.sdk >> -L/Volumes/MacintoshHD/w/testss3/build/Debug >> -L/Volumes/MacintoshHD/w/native_3rdparty/openssl.1.0.2h >> -F/Volumes/MacintoshHD/w/testss3/build/Debug >> -filelist >> /Volumes/MacintoshHD/w/testss3/build/testss3.build/Debug/testss3.build/Objects-normal/x86_64/testss3.LinkFileList >> >> -mmacosx-version-min=10.6 >> -lcrypto >> -lssl >> -o /Volumes/MacintoshHD/w/testss3/build/Debug/testss3 >> >> (ps, the -filelist ...../testss3.LinkFileList contains single path to the >> main.o) >> >> So to me this looks like 1.0.2h did not compile with TLSv1_2_method (and >> I can not find the object that implements it either, only see that it is >> referenced from s23_meth.o) >> >> I am thinking there is an .o missing from linking of libssl.a but can't >> find what object has the implementation of TLSv1_2_method >> >> (I've even got rid of all the spaces in all the paths before compiling >> openssl, make had issues installing across paths with spaces) >> >> >> On Sun, Jun 12, 2016 at 2:24 AM, Axel Luttgens >> wrote: >> >>> > Le 9 juin 2016 ? 02:29, Dan S a ?crit : >>> > >>> > Hello, I've compiled openssl.1.0.2h on osx (32bit) and linked staticly >>> my project with libcrypto.a and libssl/a, but I get 2 linking errors with >>> "Symbol(s) not found": >>> > >>> > _TLSv1_2_method, referenced from ... >>> > and >>> > _BIO_test_flags, referenced from ... >>> > >>> > Why would this be happening? >>> >>> Hello Dan, >>> >>> Difficult to tell from here. ;-) >>> >>> What (and how) are you trying to compile? >>> >>> >>> > Le 11 juin 2016 ? 04:56, Dan S a ?crit : >>> > >>> > I've also tried 1.0.2g and same problem on osx. Little more details: >>> on pc the expected symbol (_TLSv1_2_method) is in the ssleay32.lib as >>> expected >>> > >>> > on mac (and this is specifically on 10.5 and 10.6 Darwin i386) it >>> builds two libs: >>> > >>> > libcrypto.a and libssl.a (the undefined symbol is showing up in >>> libssl.a but as undefined in lib itself) using `nm libssl.a`: >>> > >>> > [?] >>> > >>> > it seems there is an object maybe missing from when it was linked. >>> >>> This may also mean that they are expected to be defined somewhere else. >>> >>> As a minimal test case, could you try to compile this one: >>> >>> #include >>> >>> int main() >>> { >>> SSL_CTX * ctx; >>> ctx = SSL_CTX_new(TLSv1_2_method()); >>> } >>> >>> so as to check the consistency of the -I, -L and -l options passed to >>> gcc? >>> >>> Axel >>> >>> -- >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Mon Jun 13 23:00:10 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 13 Jun 2016 19:00:10 -0400 Subject: [openssl-users] Symbol(s) not found _TLSv1_2_method _BIO_test_flags In-Reply-To: References: <185D4A0E-FCEC-476F-A12F-33156F9B88B6@skynet.be> Message-ID: On Mon, Jun 13, 2016 at 6:32 PM, Dan S wrote: > So I had a suggestion to verify the correct linking by renaming the libssl > and libcrypto built locally to something else, and linking to them- turns > out that was the problem, apparently adding the search path in xcode does > not take priority :( and it was still linking with the distributed old open > ssl that came with 10.6 :( > > So I may just use the renamed files if I can't figure out how to tell the > xcode to ignore the system libraries > Usually you do one of three things. First, you build your shared object with a name. You will see something like this in the Makefile: -install_name "$@" -current_version "$(LIB_MAJOR).$(LIB_MINOR).$(LIB_PATCH)"... Or, you use install_name_tool after you build the shared object to add the name later. This is often used to reset the name after an install. Second, you build as normal but you link against the static library using the fully qualified pathname. You have to use the fully qualified name because the IS X linker always uses the dynamic lib, if available. it becomes an accute problem on iOS, where only the system can supply dynlibs. You will see something like this when linking: clang ... foo.o bar.o /usr/local/ssl/lib/libcrypto.a /usr/local/ssl/lib/libssl.a -o foo.exe This, you run your executable with DYLD_LIBRARY_PATH set (http://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/dyld.1.html): DYLD_LIBRARY_PATH="/usr/local/ssl/lib:$DYLD_LIBRARY_PATH"; ./foo.exe I personally use the second method. After years of fidlling with these issues on multiple platforms, I try to avoid dynamic libraries as much as possible. I want something that "just works" everywhere, and linking against the static archive is the only thing I've found to achieve it. Jeff From Prabhat.Puroshottam at outlook.com Tue Jun 14 07:34:04 2016 From: Prabhat.Puroshottam at outlook.com (Prabhat Puroshottam) Date: Tue, 14 Jun 2016 07:34:04 +0000 Subject: [openssl-users] Openssl connecting with TLS 1.0 no matter what In-Reply-To: References: Message-ID: Please ignore this message. This was happening because client was using saved session information to connect. ________________________________ From: openssl-users on behalf of Prabhat Puroshottam Sent: Monday, June 13, 2016 7:59:54 PM To: openssl-users at openssl.org Subject: [openssl-users] Openssl connecting with TLS 1.0 no matter what Hi, We have client and server software both using openssl. I am using the following on the server side, c = SSL_CTX_new (TLSv1_2_server_method ()); SSL_CTX_set_options(INTERNAL(bi)->context, SSL_OP_ALL|SSL_OP_NO_SSLv2|SSL_OP_NO_TICKET); >From the client side I am using this: c = SSL_CTX_new (TLSv1_2_client_method ()); I have tried SSLv23_client_method and TLSv1_1_client_method and also TLSv1_2_client_method (as above) . Further I have tried setting options SSL_OP_NO_TLSv1|SSL_OP_NO_TLSv1_1. But no matter what I try client always seems to want to communicate in TLS 1.0, which I verified from wireshark output. Openssl version is OpenSSL 1.0.2f-fips 28 Jan 2016. The error reported by SSL_accept on the server side is as follows: s3_srvr.c:960 error:1408A10B:SSL routines:ssl3_get_client_hello:wrong version number Can somebody please help me understand what I am doing wrong? The following is wireshark output for client hello message (where TLS 1.0 can be seen): TLSv1 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 228 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 224 Version: TLS 1.0 (0x0301) Random GMT Unix Time: May 8, 2085 18:48:29.000000000 India Standard Time Random Bytes: 1320449c55b3169ee836d18c6f6493b76f9766c9fd9cd62a... Session ID Length: 32 Session ID: 94734c3d52dc3215bb47ccd71709c9e75312efe8c9bfd088... Cipher Suites Length: 106 Cipher Suites (53 suites) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DH_RSA_WITH_AES_256_CBC_SHA (0x0037) Cipher Suite: TLS_DH_DSS_WITH_AES_256_CBC_SHA (0x0036) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0086) Cipher Suite: TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0085) Cipher Suite: TLS_ECDH_anon_WITH_AES_256_CBC_SHA (0xc019) Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f) Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DH_RSA_WITH_AES_128_CBC_SHA (0x0031) Cipher Suite: TLS_DH_DSS_WITH_AES_128_CBC_SHA (0x0030) Cipher Suite: TLS_DHE_RSA_WITH_SEED_CBC_SHA (0x009a) Cipher Suite: TLS_DHE_DSS_WITH_SEED_CBC_SHA (0x0099) Cipher Suite: TLS_DH_RSA_WITH_SEED_CBC_SHA (0x0098) Cipher Suite: TLS_DH_DSS_WITH_SEED_CBC_SHA (0x0097) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0043) Cipher Suite: TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0042) Cipher Suite: TLS_ECDH_anon_WITH_AES_128_CBC_SHA (0xc018) Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e) Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_SEED_CBC_SHA (0x0096) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_IDEA_CBC_SHA (0x0007) Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007) Cipher Suite: TLS_ECDH_anon_WITH_RC4_128_SHA (0xc016) Cipher Suite: TLS_ECDH_RSA_WITH_RC4_128_SHA (0xc00c) Cipher Suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA (0xc002) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) Cipher Suite: TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA (0x0010) Cipher Suite: TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA (0x000d) Cipher Suite: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA (0xc017) Cipher Suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d) Cipher Suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Thanks, Prabhat. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tudor-dan.ambarus at nxp.com Tue Jun 14 08:12:41 2016 From: tudor-dan.ambarus at nxp.com (Tudor-Dan Ambarus) Date: Tue, 14 Jun 2016 08:12:41 +0000 Subject: [openssl-users] dtls record layer throughput test In-Reply-To: <5750431D.5030706@openssl.org> References: <5750431D.5030706@openssl.org> Message-ID: Hi, Matt, all, > > Is there a throughput test for dtls record layer in openssl? > > I want to measure the performance of dtls record layer in openssl. > > > > I've used s_server and s_client to talk over dtls, but seems > > that they are only meant for functional testing. > > Not really. s_time exists for TLS testing but unfortunately doesn't > support DTLS. There is also ssltest which isn't part of the installed > files but is contained in the test directory. That does have some DTLS > support and could *possibly* be used for this purpose - but both client > and server are in the same process and communication is in memory, not > via the network. Thank you for the useful information. Are you aware of any attempt of adding an openssl speed test for tls/dtls record layer protection? I'm thinking of a method of measuring how many tls/dtls record layer encapsulation/decapsulation operations openssl can perform in a given time. I don't need a communication channel, I only want to test the performance of the authenc operations in tls/dtls context. Thanks, ta From matt at openssl.org Tue Jun 14 10:03:51 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 14 Jun 2016 11:03:51 +0100 Subject: [openssl-users] dtls record layer throughput test In-Reply-To: References: <5750431D.5030706@openssl.org> Message-ID: <575FD687.2010607@openssl.org> On 14/06/16 09:12, Tudor-Dan Ambarus wrote: > Hi, Matt, all, > > >>> Is there a throughput test for dtls record layer in openssl? >>> I want to measure the performance of dtls record layer in openssl. >>> >>> I've used s_server and s_client to talk over dtls, but seems >>> that they are only meant for functional testing. >> >> Not really. s_time exists for TLS testing but unfortunately doesn't >> support DTLS. There is also ssltest which isn't part of the installed >> files but is contained in the test directory. That does have some DTLS >> support and could *possibly* be used for this purpose - but both client >> and server are in the same process and communication is in memory, not >> via the network. > > Thank you for the useful information. > > Are you aware of any attempt of adding an openssl speed test for > tls/dtls record layer protection? I'm thinking of a method of measuring > how many tls/dtls record layer encapsulation/decapsulation operations > openssl can perform in a given time. I don't need a communication channel, > I only want to test the performance of the authenc operations in > tls/dtls context. I know of organisations that do this kind of thing internally (at least for TLS). I'm not aware of any public effort. Matt From c.holper at ades.at Tue Jun 14 22:02:00 2016 From: c.holper at ades.at (c.holper at ades.at) Date: Wed, 15 Jun 2016 00:02:00 +0200 Subject: [openssl-users] RSA-OAEP (without MGF1P) Message-ID: <2040366c-7005-f482-6159-7c521d76e555@ades.at> Hi! Dealing with XML Security and enncryption/decryption I am looking for support of padding RSA-OAEP. As far I can see PKCS 1.5 and RSA-OAEP-MGF1P is supported within OpenSSL. Can anyone tell me what about RSA-OAEP and the support for it? Thanks! Chris From Murali.Kamal at ca.com Wed Jun 15 12:44:43 2016 From: Murali.Kamal at ca.com (Kamal, Murali) Date: Wed, 15 Jun 2016 12:44:43 +0000 Subject: [openssl-users] Need Information on validation for OpenSSL FIPS Message-ID: Hi Team, I read through the content on "OpenSSL" page regarding the 'hostage', 'ransom' and 'aftermath' details. As I understand it, the currently active 'SE version' or #2398 (2.0.12) has been validated/certified only on 23 new platforms (as per its 'Security Policy' pdf on NIST site) and the other 100+ platforms of cert-number #1747 & #2743 (TAR ball 2.0.10) will be considered as "vendor-affirmed" or "user-affirmed" (as per section 'G5' of NIST Implementation Guide pdf) for this "SE or 2.0.12" version; because this 2.0.12 version "functionally supports all previous platforms" (but not listed/stated explicitly by NIST for 2.0.12 or 2.0.13 or 2.0.N version of the module). Is my understanding correct? If No, request you to provide inputs to correct my understanding. If Yes, then considering, we get a "Premium Level" support contract with OpenSSL Software services (commercial consulting entity); can we again raise a NEW 'Validation/certification request' against an old platform that is already part of #1747 or #2743? The purpose of my above question is that, we don't want to build 2 versions of our product, one that is built with 2.0.10 and another with 2.0.12 or higher for the same OS with different version (say FreeBSD 9.x and 10.x) to claim FIPS-validated status. This way, we may be able to pay for re-asserting/revalidating by a CMVP for a dozen old platforms that are already part of #1747 or #2743 again in #2398 (2.0.12) or 2.0.N; thereby we can build our product using #2398 or some NEW certificate number #xxxx and claim "FIPS-validated" status with just one TAR ball (say 2.0.12 or some 2.0.N). So that my product documentation would be clear with just ONE certificate number (either #2398 or #2473 or a #Brand_new_num) for all platforms of my interest. Because, there will be some skeptical customers who would go to the NIST site for the certificate number we quote (#xxxx) and look for a list of "NIST-CMVP-Validated" platforms against a given #xxxx as they may not agree to "user-affirmed" or "vendor-affirmed" platforms as "FIPS-Validated". Regards, Murali Kamal Senior Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From sarat12us at gmail.com Wed Jun 15 20:07:43 2016 From: sarat12us at gmail.com (sarat) Date: Wed, 15 Jun 2016 13:07:43 -0700 (MST) Subject: [openssl-users] created OpenSSL TSL1.2 server (TCP server) and trying to connect thru JAVA client Message-ID: <1466021263996-66773.post@n7.nabble.com> Hi I am new to OpenSSL or SSL for that matter.I created OpenSSL TSL1.2 server (TCP server) and trying to connect thru JAVA client ( JAVA8 TCP client ).I am not able to make handshake properly. I am messing up with certificates. What the certificates I need to create server side which is running on Linux to connect from java client which is running on windows?Which certificate I need to start the client with and how?Do I need to have CA certificate, Can I use self-signed certificate.Do I need to create cert, key and p12 files?Which one to use where? I am confused. Can someone help me please? -- View this message in context: http://openssl.6102.n7.nabble.com/created-OpenSSL-TSL1-2-server-TCP-server-and-trying-to-connect-thru-JAVA-client-tp66773.html Sent from the OpenSSL - User mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From googleersatz at oliverniebuhr.de Thu Jun 16 10:31:36 2016 From: googleersatz at oliverniebuhr.de (Oliver Niebuhr) Date: Thu, 16 Jun 2016 12:31:36 +0200 Subject: [openssl-users] 1.0.2h no-tls1 Build Error unknown option no-tls1 Message-ID: <1186246c-25e9-176b-150d-cf83c183fb51@oliverniebuhr.de> Hello. Not sure if this is a Bug or not: Steps: 1.) perl Configure no-ssl3 no-tls1 no-idea no-mdc2 no-rc5 VC-WIN32 --prefix=C:\opensslx86 2.) ms\do_nasm.bat or ms\do_ms.bat 3.) Message Output with ms\do_ms.bat usage: perl util\mkfiles.pl 1>MINFO perl util\mk1mf.pl no-asm VC-WIN32 1>ms\nt.mak unknown option - no-heartbeats unknown option - no-tls1 perl util\mk1mf.pl dll no-asm VC-WIN32 1>ms\ntdll.mak unknown option - no-heartbeats unknown option - no-tls1 if x == x goto skipce perl util\mkdef.pl 32 libeay 1>ms\libeay32.def perl util\mkdef.pl 32 ssleay 1>ms\ssleay32.def ++ No Problems with no-ssl3 (which is disabled by default now anyway). Is this a Bug? If yes: Already known or should I file a BR? Or do I miss anything else. I would love to disable TLS1.0 I cant use 1.1.0 yet: A.) Not released :) B.) Not supported by the Qt Framework anyway. Thanks Oliver -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From rakesht at cdac.in Fri Jun 17 05:02:20 2016 From: rakesht at cdac.in (Rakesh T) Date: Fri, 17 Jun 2016 10:32:20 +0530 Subject: [openssl-users] How to choose ECDH and ECDHE with curve more than 192 Message-ID: <01b601d1c855$6ea641e0$4bf2c5a0$@cdac.in> Hi, I am using tomcat server, where I came across a situation where TestSSLServer(http://www.bolet.org/TestSSLServer/) tool reports the below, Highly appreciate your expertise in recommending a solution to the finding where I can choose ECDH curve size greater than 192. In the server the suites are just ECDH or ECDHE. I wonder how to restrict the curve value for the EC. How can i resolve this at the server end. Minimum EC size (no extension): 256 Minimum EC size (with extension): 160 Supported curves (size and name) ('*' = selected by server): 162 sect163k1 (K-163) 162 sect163r1 162 sect163r2 (B-163) 192 sect193r1 192 sect193r2 231 sect233k1 (K-233) 232 sect233r1 (B-233) 237 sect239k1 281 sect283k1 (K-283) 282 sect283r1 (B-283) 407 sect409k1 (K-409) 408 sect409r1 (B-409) 569 sect571k1 (K-571) 570 sect571r1 (B-571) 160 secp160k1 160 secp160r1 160 secp160r2 192 secp192k1 192 secp192r1 (P-192) 224 secp224k1 224 secp224r1 (P-224) 256 secp256k1 * 256 secp256r1 (P-256) 384 secp384r1 (P-384) 521 secp521r1 (P-521) ========================================= WARN[SK004]: Server supports ECDH parameters smaller than 192 bits Thanks and highly appreciate your advice. Thanks & Regards Raakesh. T ------------------------------------------------------------------------------------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From danm at prime.gushi.org Fri Jun 17 06:38:00 2016 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Thu, 16 Jun 2016 23:38:00 -0700 (PDT) Subject: [openssl-users] OpenSSL responder as a CGI Message-ID: Hey there all, I'm using SSL as part of puppet, which has its own sort of CA. Puppet has no idea about OCSP, but on the master, it leaves most of its configuration to the apache backend. Since apache won't re-read a CRL unless restarted, OCSP seemed like a good answer to this. Puppet's CA doesn't generate a standard index.txt. What it *does* do is generate a standard CRL (which I suppose I can parse with the openssl crl command) as well as an inventory file that contains cert start and end dates, as well as serials and subjects. I *think* this is enough information to effectively regenerate the OCSP index file, and thus answer CRL requests. Rather than letting the openssl code manage sockets and tcp ports, I figured I'd write some basic perl code as glue, and let apache run an OCSP responder in a vhost, which would simply generate a signed response. The CGI would basically be a wrapper, as well as a tool to regenerate an index.txt if either the inventory or the CRL had changed. This way, threading and the like aren't issues, and error-handling is more easily catchable. Does any of this sound like a particularly awful idea? -Dan -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From testossl2016 at gmail.com Fri Jun 17 11:04:59 2016 From: testossl2016 at gmail.com (Test ssl) Date: Fri, 17 Jun 2016 16:34:59 +0530 Subject: [openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q In-Reply-To: References: Message-ID: Hi Openssl Team, We are facing an issue with DTLS failure during the Openssl upgrade from 1.0.1m to 1.0.1q. We have attached the network trace file in attachment with good (1.0.1m) and fail (1.0.1q) case. The test scenario is that we are trying to connect a cisco based Endpoint device to a Video conference server, where our code resides. Please help us with this DTLS failure scenario which we are not able to understand that what wrong we did in our application code in using Openssl APIs. Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Successtrace.pcap Type: application/octet-stream Size: 11478 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Failure_SSL.pcap Type: application/octet-stream Size: 15726 bytes Desc: not available URL: From matt at openssl.org Fri Jun 17 12:25:59 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 17 Jun 2016 13:25:59 +0100 Subject: [openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q In-Reply-To: References: Message-ID: <5763EC57.3010300@openssl.org> Hello On 17/06/16 12:04, Test ssl wrote: > We are facing an issue with DTLS failure during the Openssl upgrade from > 1.0.1m to 1.0.1q. We have attached the network trace file in attachment > with good (1.0.1m) and fail (1.0.1q) case. > > The test scenario is that we are trying to connect a cisco based > Endpoint device to a Video conference server, where our code resides. > > Please help us with this DTLS failure scenario which we are not able to > understand that what wrong we did in our application code in using > Openssl APIs. This looks like quite a strange trace in both the success and failure cases. The traces are slightly confusing because it looks like you are making multiple connections from different ports. To simplify things in the success case I filtered wireshark to only show me the port 22602 <-> port 49164 communication. This showed me the following interaction Client Server ====== ====== ClientHello ServerHello Certificate ServerHelloDone ClientKeyExchange ChangeCipherSpec EncryptedHandshakeMessage ChangeCipherSpec EncryptedHandshakeMessage So far so good. This looks like a normal successful handshake. The EncryptedHandshakeMessages at the end of these exchanges are the Finished messages indicating that the handshake was successful. I would then expect to see Application Data being exchanged. Instead I see this: Client Server ====== ====== ClientHello ServerHello Certificate ServerKeyExchange CertificateRequest ServerHelloDone Certificate ClientKeyExchange CertificateVerify ChangeCipherSpec EncryptedHandshakeMessage ChangeCipherSpec EncryptedHandshakeMessage So AFAICT the client and server appear to have swapped roles!!! The server is sending Client message and the client is sending server messages. Not only that but the connection previously established seems to have been thrown away and they are starting from scratch (i.e. unencrypted) without having first shutdown the previous connection or having sent any application data. The failure case is similar. The client and server apparently successfully complete a handshake. They then seem to swap roles (starting from scratch again, without any app data being sent), except this time we see: Client Server ====== ====== ClientHello ServerHello Certificate ServerKeyExchange CertificateRequest ServerHelloDone Alert (Handshake Failure) ClientHello ServerHello Certificate ServerKeyExchange CertificateRequest ServerHelloDone Alert (Decrypt Error) So here we see the "server", that seems to have forgotten it is the server and is now acting as the client attempt to initiate a handshake (forgetting all about the previous connection). It then fails with a Handshake Failure (I'm not surprised), and apparently decides to have another go. This time we see a DecryptError which suggests the "server" (acting as a client) is expecting to receive encrypted data, but the client (acting as a server) is still sending unencrypted data. You need to try and figure out why the two ends of the communication are so confused about what role they are playing (or is there something you haven't told me about the way your application works?). Matt From rsalz at akamai.com Fri Jun 17 13:18:48 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 17 Jun 2016 13:18:48 +0000 Subject: [openssl-users] OpenSSL responder as a CGI In-Reply-To: References: Message-ID: > Does any of this sound like a particularly awful idea? On the contrary, it sounds like a good idea. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From testossl2016 at gmail.com Fri Jun 17 16:29:10 2016 From: testossl2016 at gmail.com (Test ssl) Date: Fri, 17 Jun 2016 21:59:10 +0530 Subject: [openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q In-Reply-To: <5763EC57.3010300@openssl.org> References: <5763EC57.3010300@openssl.org> Message-ID: Hi Matt, With same application code and openssl1.0.1m we are not facing "Alert (Handshake Failure)" but in case of 1.0.1q we are facing it. That is what we are not able to understand that what is the reason for this "Alert (Handshake Failure)". Please help us on this, which part of functionality we can modify in the application code to overcome this DTLS handshake failure. Regards, On Fri, Jun 17, 2016 at 5:55 PM, Matt Caswell wrote: > Hello > > On 17/06/16 12:04, Test ssl wrote: > > We are facing an issue with DTLS failure during the Openssl upgrade from > > 1.0.1m to 1.0.1q. We have attached the network trace file in attachment > > with good (1.0.1m) and fail (1.0.1q) case. > > > > The test scenario is that we are trying to connect a cisco based > > Endpoint device to a Video conference server, where our code resides. > > > > Please help us with this DTLS failure scenario which we are not able to > > understand that what wrong we did in our application code in using > > Openssl APIs. > > This looks like quite a strange trace in both the success and failure > cases. > > The traces are slightly confusing because it looks like you are making > multiple connections from different ports. To simplify things in the > success case I filtered wireshark to only show me the port 22602 <-> > port 49164 communication. > > This showed me the following interaction > > > Client Server > ====== ====== > > ClientHello > ServerHello > Certificate > ServerHelloDone > ClientKeyExchange > ChangeCipherSpec > EncryptedHandshakeMessage > ChangeCipherSpec > EncryptedHandshakeMessage > > So far so good. This looks like a normal successful handshake. The > EncryptedHandshakeMessages at the end of these exchanges are the > Finished messages indicating that the handshake was successful. I would > then expect to see Application Data being exchanged. Instead I see this: > > Client Server > ====== ====== > > ClientHello > ServerHello > Certificate > ServerKeyExchange > CertificateRequest > ServerHelloDone > Certificate > ClientKeyExchange > CertificateVerify > ChangeCipherSpec > EncryptedHandshakeMessage > ChangeCipherSpec > EncryptedHandshakeMessage > > So AFAICT the client and server appear to have swapped roles!!! The > server is sending Client message and the client is sending server > messages. Not only that but the connection previously established seems > to have been thrown away and they are starting from scratch (i.e. > unencrypted) without having first shutdown the previous connection or > having sent any application data. > > The failure case is similar. The client and server apparently > successfully complete a handshake. They then seem to swap roles > (starting from scratch again, without any app data being sent), except > this time we see: > > Client Server > ====== ====== > > ClientHello > > ServerHello > Certificate > ServerKeyExchange > CertificateRequest > ServerHelloDone > Alert (Handshake Failure) > ClientHello > ServerHello > Certificate > ServerKeyExchange > CertificateRequest > ServerHelloDone > Alert (Decrypt Error) > > > So here we see the "server", that seems to have forgotten it is the > server and is now acting as the client attempt to initiate a handshake > (forgetting all about the previous connection). It then fails with a > Handshake Failure (I'm not surprised), and apparently decides to have > another go. This time we see a DecryptError which suggests the "server" > (acting as a client) is expecting to receive encrypted data, but the > client (acting as a server) is still sending unencrypted data. > > You need to try and figure out why the two ends of the communication are > so confused about what role they are playing (or is there something you > haven't told me about the way your application works?). > > Matt > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Jun 17 16:35:38 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 17 Jun 2016 17:35:38 +0100 Subject: [openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q In-Reply-To: References: <5763EC57.3010300@openssl.org> Message-ID: <576426DA.5020108@openssl.org> On 17/06/16 17:29, Test ssl wrote: > Hi Matt, > > With same application code and openssl1.0.1m we are not facing "Alert > (Handshake Failure)" but in case of 1.0.1q we are facing it. > > That is what we are not able to understand that what is the reason for > this "Alert (Handshake Failure)". > > Please help us on this, which part of functionality we can modify in the > application code to overcome this DTLS handshake failure. Well to have a chance of answering that I need to understand why your application is behaving in the way I described below. If your application is doing something weird and unexpected it may well be that it just happened to work by accident in 1.0.1m, but something under the hood changed, and it doesn't any more. Why do we see this strange double handshake in your application where the client/server apparently switch roles? Is there something about your application design that could explain it? Is it intentional? Matt > > Regards, > > On Fri, Jun 17, 2016 at 5:55 PM, Matt Caswell > wrote: > > Hello > > On 17/06/16 12:04, Test ssl wrote: > > We are facing an issue with DTLS failure during the Openssl upgrade from > > 1.0.1m to 1.0.1q. We have attached the network trace file in attachment > > with good (1.0.1m) and fail (1.0.1q) case. > > > > The test scenario is that we are trying to connect a cisco based > > Endpoint device to a Video conference server, where our code resides. > > > > Please help us with this DTLS failure scenario which we are not able to > > understand that what wrong we did in our application code in using > > Openssl APIs. > > This looks like quite a strange trace in both the success and > failure cases. > > The traces are slightly confusing because it looks like you are making > multiple connections from different ports. To simplify things in the > success case I filtered wireshark to only show me the port 22602 <-> > port 49164 communication. > > This showed me the following interaction > > > Client Server > ====== ====== > > ClientHello > ServerHello > Certificate > ServerHelloDone > ClientKeyExchange > ChangeCipherSpec > EncryptedHandshakeMessage > ChangeCipherSpec > EncryptedHandshakeMessage > > So far so good. This looks like a normal successful handshake. The > EncryptedHandshakeMessages at the end of these exchanges are the > Finished messages indicating that the handshake was successful. I would > then expect to see Application Data being exchanged. Instead I see this: > > Client Server > ====== ====== > > ClientHello > ServerHello > Certificate > ServerKeyExchange > CertificateRequest > ServerHelloDone > Certificate > ClientKeyExchange > CertificateVerify > ChangeCipherSpec > EncryptedHandshakeMessage > ChangeCipherSpec > EncryptedHandshakeMessage > > So AFAICT the client and server appear to have swapped roles!!! The > server is sending Client message and the client is sending server > messages. Not only that but the connection previously established seems > to have been thrown away and they are starting from scratch (i.e. > unencrypted) without having first shutdown the previous connection or > having sent any application data. > > The failure case is similar. The client and server apparently > successfully complete a handshake. They then seem to swap roles > (starting from scratch again, without any app data being sent), except > this time we see: > > Client Server > ====== ====== > > ClientHello > > ServerHello > Certificate > ServerKeyExchange > CertificateRequest > ServerHelloDone > Alert (Handshake Failure) > ClientHello > ServerHello > Certificate > ServerKeyExchange > CertificateRequest > ServerHelloDone > Alert (Decrypt Error) > > > So here we see the "server", that seems to have forgotten it is the > server and is now acting as the client attempt to initiate a handshake > (forgetting all about the previous connection). It then fails with a > Handshake Failure (I'm not surprised), and apparently decides to have > another go. This time we see a DecryptError which suggests the "server" > (acting as a client) is expecting to receive encrypted data, but the > client (acting as a server) is still sending unencrypted data. > > You need to try and figure out why the two ends of the communication are > so confused about what role they are playing (or is there something you > haven't told me about the way your application works?). > > Matt > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > From felixbliedung at web.de Fri Jun 17 15:54:30 2016 From: felixbliedung at web.de (fterm) Date: Fri, 17 Jun 2016 08:54:30 -0700 (MST) Subject: [openssl-users] encrypt a file using openSSL in C Message-ID: <1466178870420-66824.post@n7.nabble.com> Hi, i've got a question for my study stuff: I have to decrypt a file using C. I have a corrupt key corrupt-src-key.bin (an initial vector is at the end of the file - dont know if i should usw them - maybe dont have to). decrypted file is *.pdf and it was encrypted with Camellia-192-OFB (openssl EVP_camellia_192_ofb() ). Byte number 23(start counting from 0) was set to 0. Now i have to write a small C app which decrypts this file. At least ive got 2 more files(src-cipher.bin and dest-key.bin)). Thanks very much for help. If someone is interested, i can send the files. Thx -- View this message in context: http://openssl.6102.n7.nabble.com/encrypt-a-file-using-openSSL-in-C-tp66824.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From googleersatz at oliverniebuhr.de Fri Jun 17 17:41:25 2016 From: googleersatz at oliverniebuhr.de (Google Ersatz) Date: Fri, 17 Jun 2016 19:41:25 +0200 Subject: [openssl-users] 1.0.2h no-tls1 Build Error unknown option no-tls1 In-Reply-To: <1186246c-25e9-176b-150d-cf83c183fb51@oliverniebuhr.de> References: <1186246c-25e9-176b-150d-cf83c183fb51@oliverniebuhr.de> Message-ID: <20160617174125.6459475.57295.8194@oliverniebuhr.de> ?No one? Well guess I have to wait and see if another 1.0.2 Version will have a fix for it. Have a nice weekend anyway. Oliver? Send?from?a?Mobile?Device.?Encoding?Problems can?happen. ? Originalnachricht ? Von: Oliver Niebuhr Gesendet: Donnerstag, 16. Juni 2016 12:31 An: openssl-users at openssl.org Betreff: 1.0.2h no-tls1 Build Error unknown option no-tls1 Hello. Not sure if this is a Bug or not: Steps: 1.) perl Configure no-ssl3 no-tls1 no-idea no-mdc2 no-rc5 VC-WIN32 --prefix=C:\opensslx86 2.) ms\do_nasm.bat or ms\do_ms.bat 3.) Message Output with ms\do_ms.bat usage: perl util\mkfiles.pl 1>MINFO perl util\mk1mf.pl no-asm VC-WIN32 1>ms\nt.mak unknown option - no-heartbeats unknown option - no-tls1 perl util\mk1mf.pl dll no-asm VC-WIN32 1>ms\ntdll.mak unknown option - no-heartbeats unknown option - no-tls1 if x == x goto skipce perl util\mkdef.pl 32 libeay 1>ms\libeay32.def perl util\mkdef.pl 32 ssleay 1>ms\ssleay32.def ++ No Problems with no-ssl3 (which is disabled by default now anyway). Is this a Bug? If yes: Already known or should I file a BR? Or do I miss anything else. I would love to disable TLS1.0 I cant use 1.1.0 yet: A.) Not released :) B.) Not supported by the Qt Framework anyway. Thanks Oliver From rakesht at cdac.in Sat Jun 18 11:47:14 2016 From: rakesht at cdac.in (Rakesh T) Date: Sat, 18 Jun 2016 17:17:14 +0530 Subject: [openssl-users] What is the minimum and default curve size for ECDH implementation Message-ID: <020901d1c957$291f9b50$7b5ed1f0$@cdac.in> HI, Which is the default and minimum Curve size for ECDH and ECDHE in openssl. Is it 256 by default? Thanks & Regards Raakesh. T ------------------------------------------------------------------------------------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mh at mh-sec.de Sat Jun 18 16:02:07 2016 From: mh at mh-sec.de (Marc Heuse) Date: Sat, 18 Jun 2016 18:02:07 +0200 Subject: [openssl-users] Trouble porting code to OpenSSL 1.1 Message-ID: Hi, I have a problem with porting OpenSSL code from 1.0 to 1.1. Please do not complain that it does not look like it make sense what this code does here - complain to Microsoft who implements certs with RDP non-standard ... The goal of the following code is to change the ASN.1 value of the signature algorithm in a certificate. // OpenSSL 1.0 code, well, really written already when 0.9 was there nid = OBJ_obj2nid(cert->cert_info->key->algor->algorithm); if ((nid == NID_md5WithRSAEncryption) || (nid == NID_shaWithRSAEncryption)) { ASN1_OBJECT_free(cert->cert_info->key->algor->algorithm); cert->cert_info->key->algor->algorithm = OBJ_nid2obj(NID_rsaEncryption); } // OpenSSL 1.1 code nid = X509_get_signature_nid(cert); if ((nid == NID_md5WithRSAEncryption) || (nid == NID_shaWithRSAEncryption)) { ... how to set the algorithm in the cert to NID_rsaEncryption in OpenSSL v1.1.x? Any help how to implement this with the new 1.1 functions is highly appreciated :) Greets, Marc -- Marc Heuse www.mh-sec.de PGP: AF3D 1D4C D810 F0BB 977D 3807 C7EE D0A0 6BE9 F573 From dev+openssl at seantek.com Sat Jun 18 17:43:51 2016 From: dev+openssl at seantek.com (Sean Leonard) Date: Sat, 18 Jun 2016 10:43:51 -0700 Subject: [openssl-users] Creating multi-valued RDN with config (still not working) Message-ID: <9361abf9-ad39-9576-bd28-32e1088d5b1d@seantek.com> I am trying to create a multi-valued RDN with OpenSSL using a config file and the openssl req -x509 command, without success. According to the 2006 thread "Multi-value RDNs and openssl.cnf format" , one is supposed to do this by prefixing the keys in the distinguished_name section with "+" on subsequent entries to add to a multi-valued RDN, such as: [distinguished_name] ST = California +L = Los Angeles +postalCode=90013 Unfortunately, that (still) does not work. The error from openssl req -x509 (etc.) is: problems making Certificate Request 30008:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too large:.\crypto\asn1\a_object.c:109: 30008:error:0B083077:x509 certificate routines:X509_NAME_ENTRY_create_by_txt:invalid field name:.\crypto\x509\x509name.c:285:name=+L I was successful at making a multi-valued RDN with the -multivalue-rdn and -subj options, but that is not as versatile/scriptable. Any ideas? Sean PS It looks like it may be related to the behavior in auto_info (req.c) X509_NAME_add_entry_by_txt (x509name.c), in particular, the relationship between the variables mval, type, and p in auto_info (req.c). Could be a bug. From testossl2016 at gmail.com Sun Jun 19 13:47:48 2016 From: testossl2016 at gmail.com (Test ssl) Date: Sun, 19 Jun 2016 19:17:48 +0530 Subject: [openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q In-Reply-To: <576426DA.5020108@openssl.org> References: <5763EC57.3010300@openssl.org> <576426DA.5020108@openssl.org> Message-ID: Hi Matt, This is a DTLSv1.0 connection, so the hosts on both sides will connect to each other acting as both TLS client and TLS server. We think the dtls failure is due to cipher suites. But we are not able to understand why it works for 1.0.1m with same certificate. Please help us. Regards, On Fri, Jun 17, 2016 at 10:05 PM, Matt Caswell wrote: > > > On 17/06/16 17:29, Test ssl wrote: > > Hi Matt, > > > > With same application code and openssl1.0.1m we are not facing "Alert > > (Handshake Failure)" but in case of 1.0.1q we are facing it. > > > > That is what we are not able to understand that what is the reason for > > this "Alert (Handshake Failure)". > > > > Please help us on this, which part of functionality we can modify in the > > application code to overcome this DTLS handshake failure. > > Well to have a chance of answering that I need to understand why your > application is behaving in the way I described below. If your > application is doing something weird and unexpected it may well be that > it just happened to work by accident in 1.0.1m, but something under the > hood changed, and it doesn't any more. > > Why do we see this strange double handshake in your application where > the client/server apparently switch roles? Is there something about your > application design that could explain it? Is it intentional? > > Matt > > > > > > Regards, > > > > On Fri, Jun 17, 2016 at 5:55 PM, Matt Caswell > > wrote: > > > > Hello > > > > On 17/06/16 12:04, Test ssl wrote: > > > We are facing an issue with DTLS failure during the Openssl > upgrade from > > > 1.0.1m to 1.0.1q. We have attached the network trace file in > attachment > > > with good (1.0.1m) and fail (1.0.1q) case. > > > > > > The test scenario is that we are trying to connect a cisco based > > > Endpoint device to a Video conference server, where our code > resides. > > > > > > Please help us with this DTLS failure scenario which we are not > able to > > > understand that what wrong we did in our application code in using > > > Openssl APIs. > > > > This looks like quite a strange trace in both the success and > > failure cases. > > > > The traces are slightly confusing because it looks like you are > making > > multiple connections from different ports. To simplify things in the > > success case I filtered wireshark to only show me the port 22602 <-> > > port 49164 communication. > > > > This showed me the following interaction > > > > > > Client Server > > ====== ====== > > > > ClientHello > > ServerHello > > Certificate > > ServerHelloDone > > ClientKeyExchange > > ChangeCipherSpec > > EncryptedHandshakeMessage > > ChangeCipherSpec > > EncryptedHandshakeMessage > > > > So far so good. This looks like a normal successful handshake. The > > EncryptedHandshakeMessages at the end of these exchanges are the > > Finished messages indicating that the handshake was successful. I > would > > then expect to see Application Data being exchanged. Instead I see > this: > > > > Client Server > > ====== ====== > > > > ClientHello > > ServerHello > > Certificate > > ServerKeyExchange > > CertificateRequest > > ServerHelloDone > > Certificate > > ClientKeyExchange > > CertificateVerify > > ChangeCipherSpec > > EncryptedHandshakeMessage > > ChangeCipherSpec > > EncryptedHandshakeMessage > > > > So AFAICT the client and server appear to have swapped roles!!! The > > server is sending Client message and the client is sending server > > messages. Not only that but the connection previously established > seems > > to have been thrown away and they are starting from scratch (i.e. > > unencrypted) without having first shutdown the previous connection or > > having sent any application data. > > > > The failure case is similar. The client and server apparently > > successfully complete a handshake. They then seem to swap roles > > (starting from scratch again, without any app data being sent), > except > > this time we see: > > > > Client Server > > ====== ====== > > > > ClientHello > > > > ServerHello > > Certificate > > ServerKeyExchange > > CertificateRequest > > ServerHelloDone > > Alert (Handshake Failure) > > ClientHello > > ServerHello > > Certificate > > ServerKeyExchange > > CertificateRequest > > ServerHelloDone > > Alert (Decrypt Error) > > > > > > So here we see the "server", that seems to have forgotten it is the > > server and is now acting as the client attempt to initiate a > handshake > > (forgetting all about the previous connection). It then fails with a > > Handshake Failure (I'm not surprised), and apparently decides to have > > another go. This time we see a DecryptError which suggests the > "server" > > (acting as a client) is expecting to receive encrypted data, but the > > client (acting as a server) is still sending unencrypted data. > > > > You need to try and figure out why the two ends of the communication > are > > so confused about what role they are playing (or is there something > you > > haven't told me about the way your application works?). > > > > 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 noloader at gmail.com Sun Jun 19 13:58:44 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 19 Jun 2016 09:58:44 -0400 Subject: [openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q In-Reply-To: References: <5763EC57.3010300@openssl.org> <576426DA.5020108@openssl.org> Message-ID: On Sun, Jun 19, 2016 at 9:47 AM, Test ssl wrote: > Hi Matt, > > This is a DTLSv1.0 connection, so the hosts on both sides will connect to > each other acting as both TLS client and TLS server. > > We think the dtls failure is due to cipher suites. But we are not able to > understand why it works for 1.0.1m with same certificate. > > Please help us. I don't mean to speak out of turn, but you are not giving Matt too much to work with. Perhaps you could put together a minimum sample program which demonstrates the problem? Or maybe give him s_server and s_client commands to duplicate it? Jeff From matt at openssl.org Sun Jun 19 14:12:38 2016 From: matt at openssl.org (Matt Caswell) Date: Sun, 19 Jun 2016 15:12:38 +0100 Subject: [openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q In-Reply-To: References: <5763EC57.3010300@openssl.org> <576426DA.5020108@openssl.org> Message-ID: <5766A856.9070203@openssl.org> On 19/06/16 14:47, Test ssl wrote: > Hi Matt, > > This is a DTLSv1.0 connection, so the hosts on both sides will connect > to each other acting as both TLS client and TLS server. That makes no sense at all - it isn't the way DTLS works. DTLS has a single client role and a single server role in all DTLS versions (including DTLSv1.0). In that respect it is the same as TLS. > > We think the dtls failure is due to cipher suites. But we are not able > to understand why it works for 1.0.1m with same certificate. Possibly it is. However the confused roles above are highly suspect and that could also be the cause. The traces you sent suggest that you are mixing messages from two different DTLS connections across a single UDP connection. If that's really what is happening then I'm not surprised it fails. Matt > > Please help us. > > Regards, > > On Fri, Jun 17, 2016 at 10:05 PM, Matt Caswell > wrote: > > > > On 17/06/16 17:29, Test ssl wrote: > > Hi Matt, > > > > With same application code and openssl1.0.1m we are not facing "Alert > > (Handshake Failure)" but in case of 1.0.1q we are facing it. > > > > That is what we are not able to understand that what is the reason for > > this "Alert (Handshake Failure)". > > > > Please help us on this, which part of functionality we can modify in the > > application code to overcome this DTLS handshake failure. > > Well to have a chance of answering that I need to understand why your > application is behaving in the way I described below. If your > application is doing something weird and unexpected it may well be that > it just happened to work by accident in 1.0.1m, but something under the > hood changed, and it doesn't any more. > > Why do we see this strange double handshake in your application where > the client/server apparently switch roles? Is there something about your > application design that could explain it? Is it intentional? > > Matt > > > > > > Regards, > > > > On Fri, Jun 17, 2016 at 5:55 PM, Matt Caswell > > >> wrote: > > > > Hello > > > > On 17/06/16 12:04, Test ssl wrote: > > > We are facing an issue with DTLS failure during the Openssl > upgrade from > > > 1.0.1m to 1.0.1q. We have attached the network trace file in > attachment > > > with good (1.0.1m) and fail (1.0.1q) case. > > > > > > The test scenario is that we are trying to connect a cisco based > > > Endpoint device to a Video conference server, where our code > resides. > > > > > > Please help us with this DTLS failure scenario which we are > not able to > > > understand that what wrong we did in our application code in > using > > > Openssl APIs. > > > > This looks like quite a strange trace in both the success and > > failure cases. > > > > The traces are slightly confusing because it looks like you > are making > > multiple connections from different ports. To simplify things > in the > > success case I filtered wireshark to only show me the port > 22602 <-> > > port 49164 communication. > > > > This showed me the following interaction > > > > > > Client Server > > ====== ====== > > > > ClientHello > > ServerHello > > Certificate > > ServerHelloDone > > ClientKeyExchange > > ChangeCipherSpec > > EncryptedHandshakeMessage > > ChangeCipherSpec > > EncryptedHandshakeMessage > > > > So far so good. This looks like a normal successful handshake. The > > EncryptedHandshakeMessages at the end of these exchanges are the > > Finished messages indicating that the handshake was > successful. I would > > then expect to see Application Data being exchanged. Instead I > see this: > > > > Client Server > > ====== ====== > > > > ClientHello > > ServerHello > > Certificate > > ServerKeyExchange > > CertificateRequest > > ServerHelloDone > > Certificate > > ClientKeyExchange > > CertificateVerify > > ChangeCipherSpec > > EncryptedHandshakeMessage > > ChangeCipherSpec > > EncryptedHandshakeMessage > > > > So AFAICT the client and server appear to have swapped > roles!!! The > > server is sending Client message and the client is sending server > > messages. Not only that but the connection previously > established seems > > to have been thrown away and they are starting from scratch (i.e. > > unencrypted) without having first shutdown the previous > connection or > > having sent any application data. > > > > The failure case is similar. The client and server apparently > > successfully complete a handshake. They then seem to swap roles > > (starting from scratch again, without any app data being > sent), except > > this time we see: > > > > Client Server > > ====== ====== > > > > ClientHello > > > > ServerHello > > Certificate > > ServerKeyExchange > > CertificateRequest > > ServerHelloDone > > Alert (Handshake Failure) > > ClientHello > > ServerHello > > Certificate > > ServerKeyExchange > > CertificateRequest > > ServerHelloDone > > Alert (Decrypt Error) > > > > > > So here we see the "server", that seems to have forgotten it > is the > > server and is now acting as the client attempt to initiate a > handshake > > (forgetting all about the previous connection). It then fails > with a > > Handshake Failure (I'm not surprised), and apparently decides > to have > > another go. This time we see a DecryptError which suggests the > "server" > > (acting as a client) is expecting to receive encrypted data, > but the > > client (acting as a server) is still sending unencrypted data. > > > > You need to try and figure out why the two ends of the > communication are > > so confused about what role they are playing (or is there > something you > > haven't told me about the way your application works?). > > > > 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 > > > > From uri at ll.mit.edu Sun Jun 19 14:10:25 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Sun, 19 Jun 2016 14:10:25 +0000 Subject: [openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q Message-ID: <20160619141033.18296913.62758.75006@ll.mit.edu> I'm also speaking out of turn, but having both ends trying to be both server and client *on the same connection* just does not make sense, TLS or DTLS. Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Jeffrey Walton Sent: Sunday, June 19, 2016 09:59 To: OpenSSL Users Reply To: noloader at gmail.com Subject: Re: [openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q On Sun, Jun 19, 2016 at 9:47 AM, Test ssl wrote: > Hi Matt, > > This is a DTLSv1.0 connection, so the hosts on both sides will connect to > each other acting as both TLS client and TLS server. > > We think the dtls failure is due to cipher suites. But we are not able to > understand why it works for 1.0.1m with same certificate. > > Please help us. I don't mean to speak out of turn, but you are not giving Matt too much to work with. Perhaps you could put together a minimum sample program which demonstrates the problem? Or maybe give him s_server and s_client commands to duplicate it? Jeff -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From noloader at gmail.com Sun Jun 19 14:20:16 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 19 Jun 2016 10:20:16 -0400 Subject: [openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q In-Reply-To: <20160619141033.18296913.62758.75006@ll.mit.edu> References: <20160619141033.18296913.62758.75006@ll.mit.edu> Message-ID: On Sun, Jun 19, 2016 at 10:10 AM, Blumenthal, Uri - 0553 - MITLL wrote: > I'm also speaking out of turn, but having both ends trying to be both server and client *on the same connection* just does not make sense, TLS or DTLS. > Yeah, I was having trouble envisioning the use case. But I did not want to dismiss it until I understood the requirements. Jeff From rakesht at cdac.in Sun Jun 19 14:56:40 2016 From: rakesht at cdac.in (Rakesh T) Date: Sun, 19 Jun 2016 20:26:40 +0530 Subject: [openssl-users] How to choose ECDH and ECDHE with curve more than 192 In-Reply-To: <01b601d1c855$6ea641e0$4bf2c5a0$@cdac.in> References: <01b601d1c855$6ea641e0$4bf2c5a0$@cdac.in> Message-ID: <024501d1ca3a$caa61150$5ff233f0$@cdac.in> Got this solved, while updating. as the latest openssl version has a minimum curve value of P-256. Thanks & Regards Raakesh. T From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Rakesh T Sent: 17 June 2016 10:32 To: openssl-users at openssl.org Cc: wiki at openssl.org Subject: [openssl-users] How to choose ECDH and ECDHE with curve more than 192 Hi, I am using tomcat server, where I came across a situation where TestSSLServer(http://www.bolet.org/TestSSLServer/) tool reports the below, Highly appreciate your expertise in recommending a solution to the finding where I can choose ECDH curve size greater than 192. In the server the suites are just ECDH or ECDHE. I wonder how to restrict the curve value for the EC. How can i resolve this at the server end. Minimum EC size (no extension): 256 Minimum EC size (with extension): 160 Supported curves (size and name) ('*' = selected by server): 162 sect163k1 (K-163) 162 sect163r1 162 sect163r2 (B-163) 192 sect193r1 192 sect193r2 231 sect233k1 (K-233) 232 sect233r1 (B-233) 237 sect239k1 281 sect283k1 (K-283) 282 sect283r1 (B-283) 407 sect409k1 (K-409) 408 sect409r1 (B-409) 569 sect571k1 (K-571) 570 sect571r1 (B-571) 160 secp160k1 160 secp160r1 160 secp160r2 192 secp192k1 192 secp192r1 (P-192) 224 secp224k1 224 secp224r1 (P-224) 256 secp256k1 * 256 secp256r1 (P-256) 384 secp384r1 (P-384) 521 secp521r1 (P-521) ========================================= WARN[SK004]: Server supports ECDH parameters smaller than 192 bits Thanks and highly appreciate your advice. Thanks & Regards Raakesh. T ---------------------------------------------------------------------------- --------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ---------------------------------------------------------------------------- --------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hawk at kmpc.net Sun Jun 19 19:01:01 2016 From: hawk at kmpc.net (Paul Hawkins) Date: Sun, 19 Jun 2016 14:01:01 -0500 Subject: [openssl-users] Signing a CSR with x509 that is in DER format gives PEM read error Message-ID: <5766EBED.8060101@kmpc.net> Real new to openssl as my product has just added a feature to upload certs for https access which I need to test. I have been using the tools to create the different types of certs that I want to test our feature with and have had good success after a few mis-steps. One of the invalid tests I want to try is upload a signed cert in DER format. So going full bore I tried this: * generate rsa key in PEM format with genrsa * convert key to DER with rsa * create the CSR in DER format with req All of these I checked are in DER format as they can only be parsed if I use the '-inform DER' option for their respective cmds. But trying to sign the CSR I get an error like x509 is trying to read a PEM CSR: 139782416189088:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: CERTIFICATE REQUEST I am using the option to tell x509 the CSR and the signing key is in DER format but it seems to not have any affect for the CSR. If I change the cmds so the CSR is in PEM format the x509 signing works with the DER key. On the other hand, as expected, if I just create a self-signed PEM format cert I can use x509 to convert it to DER format. But I wanted to understand if I am seeing a bug or if my understanding is incorrect. Here are the req and x509 cmds from my bash script that I am using: openssl req -config $CONF -new -keyform DER -key $MISC/der_format_der.key -outform DER -out $MISC/der_format.csr openssl x509 -req -in $MISC/der_format.csr -out $MISC/der_format.crt -inform DER -outform DER \ -signkey $MISC/der_format_der.key -keyform DER -days 365 -set_serial 14 Thanks, Paul Hawkins -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Mon Jun 20 14:07:46 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 20 Jun 2016 16:07:46 +0200 Subject: [openssl-users] encrypt a file using openSSL in C In-Reply-To: <1466178870420-66824.post@n7.nabble.com> References: <1466178870420-66824.post@n7.nabble.com> Message-ID: On 17/06/2016 17:54, fterm wrote: > Hi, > i've got a question for my study stuff: I have to decrypt a file using C. I > have a corrupt key corrupt-src-key.bin (an initial vector is at the end of > the file - dont know if i should usw them - maybe dont have to). decrypted > file is *.pdf and it was encrypted with Camellia-192-OFB (openssl > EVP_camellia_192_ofb() ). Byte number 23(start counting from 0) was set to > 0. Now i have to write a small C app which decrypts this file. At least ive > got 2 more files(src-cipher.bin and dest-key.bin)). Thanks very much for > help. If someone is interested, i can send the files. Thx OFB modes use the key and IV to generate a data independent key stream which is then xored with the raw data to encrypt or decrypt. Thus you definitely need the IV value to do the decryption, and corrupting a byte in the encrypted file (other than the IV) will simply corrupt the same byte in the decrypted file with no other side effect (that is why real crypto designs also incorporate a MAC or signature of the data, because decryption itself would not detect deliberate tampering). 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 mirko.fit at onespin.com Mon Jun 20 15:05:53 2016 From: mirko.fit at onespin.com (Mirko Fit) Date: Mon, 20 Jun 2016 17:05:53 +0200 Subject: [openssl-users] openssl shared libs Message-ID: <76c18d1d-f3b4-3f38-f98d-1242e59cf7fc@onespin.com> Hi, I've got some questions on the shared build of openssl. Is it safe to use the shared libraries libssl.so and libcrypto.so? Couldn't the shared libs be replaced by manipulated ones that intercept my calls and steal the passwords? I was wondering why every linux distrubutions comes with these shared libs if the scenario I described was possible. Thanks, Mirko From kgoldman at us.ibm.com Mon Jun 20 15:25:20 2016 From: kgoldman at us.ibm.com (Ken Goldman) Date: Mon, 20 Jun 2016 11:25:20 -0400 Subject: [openssl-users] openssl shared libs In-Reply-To: <76c18d1d-f3b4-3f38-f98d-1242e59cf7fc@onespin.com> References: <76c18d1d-f3b4-3f38-f98d-1242e59cf7fc@onespin.com> Message-ID: Just one opinion: If your attacker can replace the libraries, they have root access. They can hook into the keyboard, replace your application, etc. If they have root access, you've already lost. OTOH, static link means that your application won't automatically get security updates. On 6/20/2016 11:05 AM, Mirko Fit wrote: > > I've got some questions on the shared build of openssl. > Is it safe to use the shared libraries libssl.so and libcrypto.so? > Couldn't the shared libs be replaced by manipulated ones that intercept > my calls and steal the passwords? > I was wondering why every linux distrubutions comes with these shared > libs if the scenario I described was possible. > > Thanks, > Mirko > From mirko.fit at onespin.com Mon Jun 20 15:36:03 2016 From: mirko.fit at onespin.com (Mirko Fit) Date: Mon, 20 Jun 2016 17:36:03 +0200 Subject: [openssl-users] openssl shared libs In-Reply-To: References: <76c18d1d-f3b4-3f38-f98d-1242e59cf7fc@onespin.com> Message-ID: <3c466f68-c331-079f-0abc-ecdaabdc83d7@onespin.com> I meant the easy way of replacing a shared lib (no need to be root): > LD_LIBRARY_PATH=/path/to/modified/shared/lib:$LD_LIBRARY_PATH > my_tool Am 20.06.2016 um 17:25 schrieb Ken Goldman: > Just one opinion: If your attacker can replace the libraries, they > have root access. They can hook into the keyboard, replace your > application, etc. If they have root access, you've already lost. > > OTOH, static link means that your application won't automatically get > security updates. > > On 6/20/2016 11:05 AM, Mirko Fit wrote: >> >> I've got some questions on the shared build of openssl. >> Is it safe to use the shared libraries libssl.so and libcrypto.so? >> Couldn't the shared libs be replaced by manipulated ones that intercept >> my calls and steal the passwords? >> I was wondering why every linux distrubutions comes with these shared >> libs if the scenario I described was possible. >> >> Thanks, >> Mirko >> > > From Michael.Wojcik at microfocus.com Mon Jun 20 16:04:26 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 20 Jun 2016 16:04:26 +0000 Subject: [openssl-users] openssl shared libs In-Reply-To: <3c466f68-c331-079f-0abc-ecdaabdc83d7@onespin.com> References: <76c18d1d-f3b4-3f38-f98d-1242e59cf7fc@onespin.com> <3c466f68-c331-079f-0abc-ecdaabdc83d7@onespin.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Mirko Fit > Sent: Monday, June 20, 2016 09:36 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] openssl shared libs > > I meant the easy way of replacing a shared lib (no need to be root): > > LD_LIBRARY_PATH=/path/to/modified/shared/lib:$LD_LIBRARY_PATH > > my_tool What's the attack tree look like for this case, under your threat model? Here you're talking about users running "my_tool" and subverting their own security. They already could run my_tool under a debugger and intercept keys and so on. And what "passwords" (per your initial email) are being handled by my_tool that the user doesn't know about? Are they hard-coded in the my_tool binary? That said, there *are* possible attacks here. For example, an attacker might use social engineering to get a user to run my_tool with subverted shared libraries; essentially that's a side-loading attack. But it needn't be the OpenSSL libraries, because once the application is running malicious code, all bets are off. (Subverting OpenSSL would be convenient for stealing TLS credentials, but it's not necessary.) Or an attacker might gain access to a user account and set LD_LIBRARY_PATH, LD_PRELOAD, etc in the user's environment and wait for the user to run my_tool. But these considerations don't suffice to create a coherent security policy. You need a threat model so that you can evaluate the economics. What are the vulnerabilities under your model created by dynamic loading, and what do they cost? What are the vulnerabilities created by static linking (Ken Goldman rightly mentions the difficulty of picking up security updates, for example), and what do they cost? If you don't have the resources to create a proper threat model and produce usable cost estimates, then you have to use heuristics. And the heuristic most widely followed in this case is "link the OpenSSL shared objects". -- Michael Wojcik Technology Specialist, Micro Focus From yoom at misoccer.us Mon Jun 20 20:25:10 2016 From: yoom at misoccer.us (Yoom Nguyen) Date: Mon, 20 Jun 2016 16:25:10 -0400 (EDT) Subject: [openssl-users] library result doesn't look right In-Reply-To: Message-ID: <12658746.502358.1466454310354.JavaMail.root@misoccer.us> Greetings Everyone, I recent download and compiled a new version openssl-1.0.2h.tar than what came with RedHat distribution. successfully compile and test. Using the following options export CFLAGS="-fPIC" ./config shared enable-ec_nistp_64_gcc_128 no-ssl2 no-ssl3 --openssldir=/usr/local/openssl -DOPENSSL_USE_IPV6=0 I am concern whether I have used and compiled correct information or Not. I am not seeing any library that would indicate version .2h They all show libcrypto.so.1.0.0 and libssl.so.1.0.0 Are they the correct results? >From this directory /usr/local/openssl/lib I do not see any libcrypto.... libarary that would refer to version 1.0.2????? all of them is 1.0.0.... Are these correct results. [root at web1 lib]# ls -l total 8544 drwxr-xr-x. 2 root root 4096 Jun 20 15:16 engines -rw-r--r--. 1 root root 4658450 Jun 20 15:16 libcrypto.a lrwxrwxrwx. 1 root root 18 Jun 20 15:16 libcrypto.so -> libcrypto.so.1.0.0 -r-xr-xr-x. 1 root root 2817780 Jun 20 15:16 libcrypto.so.1.0.0 -rw-r--r--. 1 root root 753560 Jun 20 15:16 libssl.a lrwxrwxrwx. 1 root root 15 Jun 20 15:16 libssl.so -> libssl.so.1.0.0 -r-xr-xr-x. 1 root root 509261 Jun 20 15:16 libssl.so.1.0.0 drwxr-xr-x. 2 root root 58 Apr 12 2015 pkgconfig My server is running redhat 7 and I see these different version. [root at web1 lib]# ls -alt /lib64/libcrypto* lrwxrwxrwx. 1 root root 19 Apr 9 2015 /lib64/libcrypto.so.6 -> libcrypto.so.0.9.8e lrwxrwxrwx. 1 root root 19 Apr 9 2015 /lib64/libcrypto.so.10 -> libcrypto.so.1.0.1e -rwxr-xr-x. 1 root root 2013048 Jan 15 2015 /lib64/libcrypto.so.1.0.1e -rwxr-xr-x. 1 root root 1440048 Jun 3 2014 /lib64/libcrypto.so.0.9.8e Is there a document for compiling and integrating a new OPENSSL release for and existing Redhat 7 EN OS some where? Thanks, Y From jb-openssl at wisemo.com Tue Jun 21 10:06:26 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 21 Jun 2016 12:06:26 +0200 Subject: [openssl-users] library result doesn't look right In-Reply-To: <12658746.502358.1466454310354.JavaMail.root@misoccer.us> References: <12658746.502358.1466454310354.JavaMail.root@misoccer.us> Message-ID: <9d035061-9ebb-b84b-f2f3-2a20ed476fb3@wisemo.com> On 20/06/2016 22:25, Yoom Nguyen wrote: > Greetings Everyone, > > > I recent download and compiled a new version openssl-1.0.2h.tar than what came with RedHat distribution. > > successfully compile and test. Using the following options > export CFLAGS="-fPIC" > ./config shared enable-ec_nistp_64_gcc_128 no-ssl2 no-ssl3 --openssldir=/usr/local/openssl -DOPENSSL_USE_IPV6=0 > > > I am concern whether I have used and compiled correct information or Not. I am not seeing any library that would indicate version .2h > They all show libcrypto.so.1.0.0 and libssl.so.1.0.0 > > > Are they the correct results? > > > > From this directory /usr/local/openssl/lib > I do not see any libcrypto.... libarary that would refer to version 1.0.2????? > all of them is 1.0.0.... > > Are these correct results. > > [root at web1 lib]# ls -l > total 8544 > drwxr-xr-x. 2 root root 4096 Jun 20 15:16 engines > -rw-r--r--. 1 root root 4658450 Jun 20 15:16 libcrypto.a > lrwxrwxrwx. 1 root root 18 Jun 20 15:16 libcrypto.so -> libcrypto.so.1.0.0 > -r-xr-xr-x. 1 root root 2817780 Jun 20 15:16 libcrypto.so.1.0.0 > -rw-r--r--. 1 root root 753560 Jun 20 15:16 libssl.a > lrwxrwxrwx. 1 root root 15 Jun 20 15:16 libssl.so -> libssl.so.1.0.0 > -r-xr-xr-x. 1 root root 509261 Jun 20 15:16 libssl.so.1.0.0 > drwxr-xr-x. 2 root root 58 Apr 12 2015 pkgconfig > > > > My server is running redhat 7 and I see these different version. > [root at web1 lib]# ls -alt /lib64/libcrypto* > lrwxrwxrwx. 1 root root 19 Apr 9 2015 /lib64/libcrypto.so.6 -> libcrypto.so.0.9.8e > lrwxrwxrwx. 1 root root 19 Apr 9 2015 /lib64/libcrypto.so.10 -> libcrypto.so.1.0.1e > -rwxr-xr-x. 1 root root 2013048 Jan 15 2015 /lib64/libcrypto.so.1.0.1e > -rwxr-xr-x. 1 root root 1440048 Jun 3 2014 /lib64/libcrypto.so.0.9.8e > > > Is there a document for compiling and integrating a new OPENSSL release for and existing Redhat 7 EN OS some where? > > > Thanks, > Y Yes, the OpenSSL team pretends that all the 1.0.Xx versions are binary compatible and should be installed as libcrypto.so.1.0.0 . In reality, this is not entirely true, since at least one flag bits passed as a top level parameter have changed between the various 1.0.x patch versions. You can override their policy by changing one or two settings in the top level Makefile. 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 eurus at openmailbox.org Tue Jun 21 10:16:32 2016 From: eurus at openmailbox.org (eurus at openmailbox.org) Date: Tue, 21 Jun 2016 18:16:32 +0800 Subject: [openssl-users] How to encode text request of 'req -text -noout''s output? Message-ID: <2016062118162683254281@openmailbox.org> Hi, If I get a text version of a request(e.g. use the command "openssl req -noout -text -in ca.csr"), how can I encode it with openssl command(thus transform it to the format that is able to be recognized by applications)? Thanks, Eurus -------------- next part -------------- An HTML attachment was scrubbed... URL: From volder at volumeintegration.com Tue Jun 21 17:19:39 2016 From: volder at volumeintegration.com (Virginia Older) Date: Tue, 21 Jun 2016 13:19:39 -0400 Subject: [openssl-users] Problem revoking a Cert Message-ID: I am trying to revoke a cert but I am getting the following error: openssl ca -revoke test.crt Using configuration from /etc/pki/tls/openssl.cnf Enter pass phrase for /etc/pki/tls/vaCA1/signing-ca.key: unable to load certificate 139933357430600:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: TRUSTED CERTIFICATE I was having trouble getting the cert to work in the browser, I created another to test it and it worked but some of our applications need the CN to match the person's username so I need to revoke the cert I was having problems with to create another. Thanks for any help you can provide. I don't do a lot of certificate management so please let me know if there is more information I can provide. -- You learn that you don?t have any real freedom without real discipline. -Alan Rickman -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Tue Jun 21 19:58:17 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 21 Jun 2016 19:58:17 +0000 Subject: [openssl-users] Trouble porting code to OpenSSL 1.1 In-Reply-To: References: Message-ID: <20160621195817.GA24034@openssl.org> On Sat, Jun 18, 2016, Marc Heuse wrote: > Hi, > > I have a problem with porting OpenSSL code from 1.0 to 1.1. > Please do not complain that it does not look like it make sense what > this code does here - complain to Microsoft who implements certs with > RDP non-standard ... > I am curious though as to why you need to do this... > > // OpenSSL 1.0 code, well, really written already when 0.9 was there > > nid = OBJ_obj2nid(cert->cert_info->key->algor->algorithm); > if ((nid == NID_md5WithRSAEncryption) || (nid == > NID_shaWithRSAEncryption)) { > ASN1_OBJECT_free(cert->cert_info->key->algor->algorithm); > cert->cert_info->key->algor->algorithm = OBJ_nid2obj(NID_rsaEncryption); > } > > > // OpenSSL 1.1 code > > nid = X509_get_signature_nid(cert); > if ((nid == NID_md5WithRSAEncryption) || (nid == > NID_shaWithRSAEncryption)) { > ... how to set the algorithm in the cert to NID_rsaEncryption in > OpenSSL v1.1.x? > > Well the start of that isn't equivalent. Anyway here goes. First you need to get the X509_PUBKEY structure from the certificate (cert->cert_info->key). You can do this with X509_get_X509_PUBKEY(). Once you have that you can get the algorithm OID and algorithm identifier (you only need the latter) using X509_PUBKEY_get0_param(). Then you can use X509_ALGOR_get0() to retrieve the ASN1_OBJECT and X509_ALGOR_set0 to set it if you need to. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From jb-openssl at wisemo.com Tue Jun 21 21:41:11 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 21 Jun 2016 23:41:11 +0200 Subject: [openssl-users] Trouble porting code to OpenSSL 1.1 In-Reply-To: References: Message-ID: <1ad77dba-76f0-3b70-49ad-5d9f6ad8fd21@wisemo.com> On 18/06/2016 18:02, Marc Heuse wrote: > Hi, > > I have a problem with porting OpenSSL code from 1.0 to 1.1. > Please do not complain that it does not look like it make sense what > this code does here - complain to Microsoft who implements certs with > RDP non-standard ... > > The goal of the following code is to change the ASN.1 value of the > signature algorithm in a certificate. > > // OpenSSL 1.0 code, well, really written already when 0.9 was there > > nid = OBJ_obj2nid(cert->cert_info->key->algor->algorithm); > if ((nid == NID_md5WithRSAEncryption) || (nid == > NID_shaWithRSAEncryption)) { > ASN1_OBJECT_free(cert->cert_info->key->algor->algorithm); > cert->cert_info->key->algor->algorithm = OBJ_nid2obj(NID_rsaEncryption); > } > > > // OpenSSL 1.1 code > > nid = X509_get_signature_nid(cert); > if ((nid == NID_md5WithRSAEncryption) || (nid == > NID_shaWithRSAEncryption)) { > ... how to set the algorithm in the cert to NID_rsaEncryption in > OpenSSL v1.1.x? > > > Any help how to implement this with the new 1.1 functions is highly > appreciated :) > Strangely, when I look at certificates generated by the "openssl ca" utility, they already say "Public Key Algorithm: rsaEncryption", where did you get certificates that specified "md5WithRSAEncryption" or "shaWithRsaEncryption" as the subject public key algorithm? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From raji.kotamraju at gmail.com Wed Jun 22 05:41:08 2016 From: raji.kotamraju at gmail.com (Rajeswari K) Date: Wed, 22 Jun 2016 11:11:08 +0530 Subject: [openssl-users] Record aggregation with TLS Client Message-ID: Hello Openssl users, Having a query on when our device acitng as TLS Client, we observed that both client certificate and client key exchange messages are going in a single packet. Is there any way to separate this? That means is there any option to avoid multiple records in a single packet? Thanks, Rajeswari. -------------- next part -------------- An HTML attachment was scrubbed... URL: From raji.kotamraju at gmail.com Wed Jun 22 08:31:28 2016 From: raji.kotamraju at gmail.com (Rajeswari K) Date: Wed, 22 Jun 2016 14:01:28 +0530 Subject: [openssl-users] ECDSA vs RSA certificates Message-ID: Hello Openssl users, Need pointers on how to use ECDSA vs RSA certificates. When our device acting as TLS server, we have support for both ECDSA and RSA based certificates. At first, we need to feed a certificate for the TLS server to accept the connections. >From the code, having a feel that, if we feed ECDSA based certificates, ECDSA based ciphers only get selected by server. But, what if client doesn't have a cipher matched with ECDSA? Does server choose RSA based cipher or because the certificate we fed is holding ECDSA signature, will it respond with "no shared cipher"? Is there a way we can feed multiple certificates i.e. one with ECDSA and other with RSA to TLS server during SSL_CTX initialization? Or Once Client hello is received, after examining client supported ciphers, do we need to feed respective (i.e. ECDSA/RSA) certificate? Thanks, Rajeswari. -------------- next part -------------- An HTML attachment was scrubbed... URL: From swall at redcom.com Wed Jun 22 12:55:56 2016 From: swall at redcom.com (Wall, Stephen) Date: Wed, 22 Jun 2016 08:55:56 -0400 Subject: [openssl-users] ECDSA vs RSA certificates In-Reply-To: References: Message-ID: <401084E5E73F4241A44F3C9E6FD79428037C27B6B6@exch-01> > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Rajeswari K > Is there a way we can feed multiple certificates i.e. one with ECDSA and other with RSA > to TLS server during SSL_CTX initialization?? Yes, you can set a certificate of each known type (DSA, RSA, EC), see the Notes section at https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_use_certificate.html -spw From Michael.Wojcik at microfocus.com Wed Jun 22 14:54:13 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 22 Jun 2016 14:54:13 +0000 Subject: [openssl-users] Record aggregation with TLS Client In-Reply-To: References: Message-ID: By "a single packet", do you mean a single TCP segment? No, there's no way to ensure they're sent in separate TCP segments. TCP segmentation is a function of the TCP/IP stack. And your application knows nothing about it anyway; TCP is a byte-stream protocol. Why do you think you want to do this? (When people ask this question, for TLS or any other protocol, it almost always indicates that they don't understand TCP and have a broken design. TCP is not a record-based protocol.) Michael Wojcik Technology Specialist, Micro Focus From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Rajeswari K Sent: Tuesday, June 21, 2016 23:41 To: openssl-users at openssl.org Subject: [openssl-users] Record aggregation with TLS Client Hello Openssl users, Having a query on when our device acitng as TLS Client, we observed that both client certificate and client key exchange messages are going in a single packet. Is there any way to separate this? That means is there any option to avoid multiple records in a single packet? Thanks, Rajeswari. -------------- next part -------------- An HTML attachment was scrubbed... URL: From c.holper at ades.at Wed Jun 22 15:09:18 2016 From: c.holper at ades.at (c.holper at ades.at) Date: Wed, 22 Jun 2016 17:09:18 +0200 Subject: [openssl-users] CMS: Encrypt with binary encoding Message-ID: Hi! Is there a way to get binary (not base64) encoding out of CMS-encrypt?? openssl cms -encrypt -in plain.txt mycer.cer gives me a MIME-part with Content-Transfer-Encoding: base64 But I'd like to have binary. Thanks for help! Chris From jb-openssl at wisemo.com Wed Jun 22 15:19:58 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 22 Jun 2016 17:19:58 +0200 Subject: [openssl-users] CMS: Encrypt with binary encoding In-Reply-To: References: Message-ID: <55f216c9-183a-f986-eb75-02c72804d595@wisemo.com> On 22/06/2016 17:09, c.holper at ades.at wrote: > Hi! > > Is there a way to get binary (not base64) encoding out of CMS-encrypt?? > > openssl cms -encrypt -in plain.txt mycer.cer > > gives me a MIME-part with > Content-Transfer-Encoding: base64 > > But I'd like to have binary. > Thanks for help! > > Chris -outform DER 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 c.holper at ades.at Wed Jun 22 15:40:28 2016 From: c.holper at ades.at (c.holper at ades.at) Date: Wed, 22 Jun 2016 17:40:28 +0200 Subject: [openssl-users] CMS: Encrypt with binary encoding Message-ID: <6c73729c-24b3-ae0b-43fe-49c909e3c6fb@ades.at> Yes, but then there is no MIME-Header. Can I have MIME with binary encoding?? From thomas.francis.jr at pobox.com Wed Jun 22 18:07:56 2016 From: thomas.francis.jr at pobox.com (Thomas Francis, Jr.) Date: Wed, 22 Jun 2016 14:07:56 -0400 Subject: [openssl-users] CMS: Encrypt with binary encoding In-Reply-To: <6c73729c-24b3-ae0b-43fe-49c909e3c6fb@ades.at> References: <6c73729c-24b3-ae0b-43fe-49c909e3c6fb@ades.at> Message-ID: <1E9B2633-252E-4DC2-979A-B8ED8771461A@pobox.com> > On Jun 22, 2016, at 11:40 AM, c.holper at ades.at wrote: > > Yes, but then there is no MIME-Header. > Can I have MIME with binary encoding?? Not really. If you?re using raw binary output, the output wouldn?t be a MIME body (or body-part), so a MIME header would be inappropriate. MIME requires output to be 7-bit clean (i.e., the high bit of every byte is 0), with some special exceptions. Base64 is usually the preferred encoding, although many other encodings (e.g. uuencode) are allowed. Raw binary output would not be allowed (unless you could guarantee it meets the exceptional cases, which you can?t for something like this). You could always prepend a MIME header, but that wouldn?t make your output a MIME body. TOM -- +-----------------------------+----------------------------+ | Thomas Francis, Jr. | Preserve wildlife -- | | thomas.francis.jr at pobox.com | Pickle a squirrel! | | http://www.bbsclient.net/ | | +-----------------------------+----------------------------+ From mirko.fit at onespin.com Thu Jun 23 07:59:42 2016 From: mirko.fit at onespin.com (Mirko Fit) Date: Thu, 23 Jun 2016 09:59:42 +0200 Subject: [openssl-users] openssl shared libs In-Reply-To: References: <76c18d1d-f3b4-3f38-f98d-1242e59cf7fc@onespin.com> <3c466f68-c331-079f-0abc-ecdaabdc83d7@onespin.com> Message-ID: Here's my scenario in detail: We have 3 parties: (V) Vendor of intellectual property (U) User of intellectual property (may not see the IP, but use it with some tools and see the output) (T) Tool provider (may decipher the IP and use it, but not show it to (U)) According to IEEE-1735 we do the following: The (V) creates a session key and encrypts it's intellectual property using AES-256. Then he encrypts the session key using RSA-4096 and the public key of (T). So (T) should be able to decipher the session key and thus the IP. Now (T) burns his private key into his tool to his customer (U) to use all IP that some vendor (V) encrypted for the use with (T)'s tools. The critical scenario is the following: Assume (U) is the bad guy, who is interested in the intellectual property. He could replace the openssl shared libs to intercept the call to |AES_set_encrypt_key(..)| and steal the session key. With this key he and everyone he shares the key with can decipher the IP of (V). Now my company is (T) and we don't want to leak (V)'s session key. You may assume that our binary is protected state of the art agains debugger attacks and stuff. So the only question is if the shared openssl library makes the tool more vulnerable? Thanks in advance, Mirko Am 20.06.2016 um 18:04 schrieb Michael Wojcik: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Mirko Fit >> Sent: Monday, June 20, 2016 09:36 >> To: openssl-users at openssl.org >> Subject: Re: [openssl-users] openssl shared libs >> >> I meant the easy way of replacing a shared lib (no need to be root): >> > LD_LIBRARY_PATH=/path/to/modified/shared/lib:$LD_LIBRARY_PATH >> > my_tool > What's the attack tree look like for this case, under your threat model? > > Here you're talking about users running "my_tool" and subverting their own security. They already could run my_tool under a debugger and intercept keys and so on. And what "passwords" (per your initial email) are being handled by my_tool that the user doesn't know about? Are they hard-coded in the my_tool binary? > > That said, there *are* possible attacks here. For example, an attacker might use social engineering to get a user to run my_tool with subverted shared libraries; essentially that's a side-loading attack. But it needn't be the OpenSSL libraries, because once the application is running malicious code, all bets are off. (Subverting OpenSSL would be convenient for stealing TLS credentials, but it's not necessary.) Or an attacker might gain access to a user account and set LD_LIBRARY_PATH, LD_PRELOAD, etc in the user's environment and wait for the user to run my_tool. > > But these considerations don't suffice to create a coherent security policy. You need a threat model so that you can evaluate the economics. What are the vulnerabilities under your model created by dynamic loading, and what do they cost? What are the vulnerabilities created by static linking (Ken Goldman rightly mentions the difficulty of picking up security updates, for example), and what do they cost? > > If you don't have the resources to create a proper threat model and produce usable cost estimates, then you have to use heuristics. And the heuristic most widely followed in this case is "link the OpenSSL shared objects". > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Jun 23 12:14:09 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 23 Jun 2016 12:14:09 +0000 Subject: [openssl-users] openssl shared libs In-Reply-To: References: <76c18d1d-f3b4-3f38-f98d-1242e59cf7fc@onespin.com> <3c466f68-c331-079f-0abc-ecdaabdc83d7@onespin.com> Message-ID: > Now my company is (T) and we don't want to leak (V)'s session key. > You may assume that our binary is protected state of the art agains debugger attacks and stuff. > So the only question is if the shared openssl library makes the tool more vulnerable? You cannot prevent someone from changing what the software that runs on their computer. You can only make it harder. Shared libraries are easier for a user to replace; static libraries are harder. From uri at ll.mit.edu Thu Jun 23 13:11:53 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 23 Jun 2016 13:11:53 +0000 Subject: [openssl-users] openssl shared libs Message-ID: <20160623131202.18296913.74631.75722@ll.mit.edu> Look at Intel SGX, available since Skylake CPU. Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Salz, Rich Sent: Thursday, June 23, 2016 08:17 To: openssl-users at openssl.org Reply To: openssl-users at openssl.org Cc: Dominik Stra?er Subject: Re: [openssl-users] openssl shared libs > Now my company is (T) and we don't want to leak (V)'s session key. > You may assume that our binary is protected state of the art agains debugger attacks and stuff. > So the only question is if the shared openssl library makes the tool more vulnerable? You cannot prevent someone from changing what the software that runs on their computer. You can only make it harder. Shared libraries are easier for a user to replace; static libraries are harder. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From Michael.Wojcik at microfocus.com Thu Jun 23 13:58:32 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 23 Jun 2016 13:58:32 +0000 Subject: [openssl-users] openssl shared libs In-Reply-To: References: <76c18d1d-f3b4-3f38-f98d-1242e59cf7fc@onespin.com> <3c466f68-c331-079f-0abc-ecdaabdc83d7@onespin.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Salz, Rich > Sent: Thursday, June 23, 2016 06:14 > To: openssl-users at openssl.org > Cc: Dominik Stra?er > Subject: Re: [openssl-users] openssl shared libs > Mirko Fit (mirko.fit at onespin.com) wrote: > > Now my company is (T) and we don't want to leak (V)'s session key. > > You may assume that our binary is protected state of the art against debugger attacks and stuff. I may assume that, but I'm pretty dubious about it. Still, let's leave that aside for these purposes. > > So the only question is if the shared openssl library makes the tool more vulnerable? That's an imprecise question. A better formulation is, "under my threat model, does static linking significantly increase the cost to an attacker, and significantly more than it increases the cost to me, and is the increase in my cost worth it, considering the value of the assets being protected?". Static and dynamic linking both make your tool "more vulnerable", for different reasons. Using OpenSSL makes your tool "more vulnerable"; not using OpenSSL makes it "more vulnerable". Anything you do makes it "more vulnerable" under some branch of the attack tree. Rich responded: > You cannot prevent someone from changing what the software that runs on > their computer. You can only make it harder. Yes, but that's axiomatically true. *All* security measures are about raising costs asymmetrically; if they're successful, they increase the cost for the attacker more than they do the cost for the defender. That's what defines a security measure. Per my previous note in this stream, "cost" has to be measured and evaluated (relative to the value of the protected assets) under a threat model to be meaningful. But the point you make here is particularly relevant in a case like this, because there's a limit to how high you can raise the attacker's cost, when you're looking at attacks against software running on equipment under the attacker's control - particularly when that equipment is a general-purpose computer (and quite possibly a VM), and not on, say, tamper-resistant hardware. (Let's just run in a VM with a hacked hypervisor that heuristically detects AES decryption and steals the decrypted data. Or better, detects RSA and steals the private key.) > Shared libraries are easier for a user to replace; static libraries are harder. Yes. So in Mirko's particular case, his threat model *does* include attackers who are hostile users, which is not the most common case for OpenSSL. Here dynamically llinking libcrypto does provide an attack branch that's relatively low-cost for the attacker. Also, if he's using libcrypto only for AES encryption (not clear from his description), many critical OpenSSL updates won't apply to him, which means some of the costs associated with static linking won't apply to him. So for this relatively uncommon case, there appears to be an economic advantage in static linking. And this gets back to the question in Mirko's original email. Most applications dynamically link OpenSSL because they have a rather different use case and thus a rather different threat model. It's not very useful to ask "why does everyone else do X?" when X doesn't apply to your situation. Except, of course, that you may learn why X doesn't apply to your situation. -- Michael Wojcik Technology Specialist, Micro Focus From sharan8989 at gmail.com Thu Jun 23 15:09:17 2016 From: sharan8989 at gmail.com (Shivasharan D N) Date: Thu, 23 Jun 2016 20:39:17 +0530 Subject: [openssl-users] [openssl.org #4582] BUG - Application crashing in OpenSSL code while creating x509 certificate object Message-ID: Hi OpenSSL users, I have come across an issue which is reported in the below ticket: http://rt.openssl.org/Ticket/Display.html?id=4582 (Please log in as guest with password guest if prompted) 0.9.8 is no longer supported by OpenSSL. So I am posting in this forum. Can you guys help me out if you can recall coming across similar issue anytime? Thanks, Sharan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjl at mnmicro.net Thu Jun 23 16:25:53 2016 From: rjl at mnmicro.net (Russ Loucks) Date: Thu, 23 Jun 2016 11:25:53 -0500 Subject: [openssl-users] Unable to run application after Windows updates Message-ID: <81046AB7-D60E-4F99-84FC-F58E1D537E40@mnmicro.net> We have an application running on Windows 8.1 (HP) tablets that is mostly statically linked except for a few libraries, including the SSLEAY32 and LIBEAY32 libraries. We're using version 1.0.2 of the OpenSSL libraries. We ship our executable and these two libraries and then set a PATH entry in the registry that points to our 'lib' directory so the system/library loader can find the libraries at load/run time. There are two other packages on these tablets we ship that include older versions of the OpenSSL libraries - Intel TXE Components/TCS (OpenSSL version 1.0.0g) and HP Registration service (1.0.0d). Works well. Until the user runs Windows updates.... Then, when our application starts we get a 'The ordinal 3905 could not be located in the dynamic link library 'C:\program Files\\lib\SSALEAY32.dll'. I've tried the following - all to no avail: removing the HP and Intel OpenSSL libraries (but safe-keeping them for later re-installation) Re-installing our application and OpenSSL libraries Interestingly, the OpenSSL libraries in the HP and Intel installations do not change after the Windows update - they're the same versions as before the update.... I'm stumped. Any clues? I'm guessing the best course of action is to statically link the OpenSSL libs into our app. Is that a good plan? Thanks for the help. Russ Loucks ---- Russ Loucks mailto: rjl at mnmicro.net Winter is coming -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Thu Jun 23 18:44:47 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 23 Jun 2016 20:44:47 +0200 Subject: [openssl-users] Unable to run application after Windows updates In-Reply-To: <81046AB7-D60E-4F99-84FC-F58E1D537E40@mnmicro.net> References: <81046AB7-D60E-4F99-84FC-F58E1D537E40@mnmicro.net> Message-ID: On 23/06/2016 18:25, Russ Loucks wrote: > We have an application running on Windows 8.1 (HP) tablets that is > mostly statically linked except for a few libraries, including the > SSLEAY32 and LIBEAY32 libraries. > > We're using version 1.0.2 of the OpenSSL libraries. > > We ship our executable and these two libraries and then set a PATH > entry in the registry that points to our 'lib' directory so the > system/library loader can find the libraries at load/run time. > > There are two other packages on these tablets we ship that include > older versions of the OpenSSL libraries - Intel TXE Components/TCS > (OpenSSL version 1.0.0g) and HP Registration service (1.0.0d). > > Works well. > > Until the user runs Windows updates.... > > Then, when our application starts we get a 'The ordinal 3905 could not > be located in the dynamic link library 'C:\program Files\ installdir>\lib\SSALEAY32.dll'. > > I've tried the following - all to no avail: > > * removing the HP and Intel OpenSSL libraries (but safe-keeping them > for later re-installation) > * Re-installing our application and OpenSSL libraries > > Interestingly, the OpenSSL libraries in the HP and Intel installations > do not change after the Windows update - they're the same versions as > before the update.... > > I'm stumped. Any clues? > > I'm guessing the best course of action is to statically link the > OpenSSL libs into our app. Is that a good plan? > > Thanks for the help. > > Over the past few years, Microsoft has been phasing in a security improvement (and it is an improvement) to protect against remote attackers dropping trojanized replacement DLLs in an unsecured (document) directory which they have reason to believe will be the current directory when the attacked program is loaded. This change consists of a change in the default search order for DLLs where no explicit directory is passed to LoadLibrary/ LoadLibraryEx, and a very similar change to the search order for DLLs that are named (with no path obviously) in the import tables in programs and other DLLs. The recommended best practice for DLLs loaded by linking to an import library (which contains the needed entries for the import table) is to leave OS owned standard DLLs in System32 (SysWoW64 for 32 bit programs on Win64), use explicit manifest version references in the calling EXE/DLLs linked in manifest (don't trust the manifest generator in Visual Studio, it tends to get details wrong), and put application specific DLLs (including private copies of stuff such as SSLEAY32.DLL) in the same directory as the referencing EXE/DLL file. Playing around with the PATH environment variable when installing programs is generally considered worst practice due to the risk of affecting other programs by inflicting your own DLLs etc. on them. As a side effect of all this, having a dedicated lib/dll subdir in your install dir will generally not work unless you load all those DLLs via your own calls to LoadLibrary/LoadLibraryEx with explicitly computed full pathnames, thus such a dir is now only good for plugins and other on-demand loaded components. With a little tweaking it could also be useful for OpenSSL engine plugin DLLs. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjl at mnmicro.net Thu Jun 23 19:50:43 2016 From: rjl at mnmicro.net (Russ Loucks) Date: Thu, 23 Jun 2016 14:50:43 -0500 Subject: [openssl-users] Unable to run application after Windows updates In-Reply-To: References: <81046AB7-D60E-4F99-84FC-F58E1D537E40@mnmicro.net> Message-ID: <972F29FB-DCD3-43CA-94EE-695FDF1E43C8@mnmicro.net> On Jun 23, 2016, at 1:44 PM, Jakob Bohm wrote: > On 23/06/2016 18:25, Russ Loucks wrote: >> We have an application running on Windows 8.1 (HP) tablets that is mostly statically linked except for a few libraries, including the SSLEAY32 and LIBEAY32 libraries. >> >> We're using version 1.0.2 of the OpenSSL libraries. >> >> We ship our executable and these two libraries and then set a PATH entry in the registry that points to our 'lib' directory so the system/library loader can find the libraries at load/run time. >> >> There are two other packages on these tablets we ship that include older versions of the OpenSSL libraries - Intel TXE Components/TCS (OpenSSL version 1.0.0g) and HP Registration service (1.0.0d). >> >> Works well. >> >> Until the user runs Windows updates.... >> >> Then, when our application starts we get a 'The ordinal 3905 could not be located in the dynamic link library 'C:\program Files\\lib\SSALEAY32.dll'. >> >> I've tried the following - all to no avail: >> removing the HP and Intel OpenSSL libraries (but safe-keeping them for later re-installation) >> Re-installing our application and OpenSSL libraries >> Interestingly, the OpenSSL libraries in the HP and Intel installations do not change after the Windows update - they're the same versions as before the update.... >> >> I'm stumped. Any clues? >> >> I'm guessing the best course of action is to statically link the OpenSSL libs into our app. Is that a good plan? >> >> Thanks for the help. >> >> > Over the past few years, Microsoft has been phasing in a security > improvement (and it is an improvement) to protect against remote > attackers dropping trojanized replacement DLLs in an unsecured > (document) directory which they have reason to believe will be > the current directory when the attacked program is loaded. > This change consists of a change in the default search order > for DLLs where no explicit directory is passed to LoadLibrary/ > LoadLibraryEx, and a very similar change to the search order for > DLLs that are named (with no path obviously) in the import tables > in programs and other DLLs. > > The recommended best practice for DLLs loaded by linking to an > import library (which contains the needed entries for the import > table) is to leave OS owned standard DLLs in System32 (SysWoW64 > for 32 bit programs on Win64), use explicit manifest version > references in the calling EXE/DLLs linked in manifest (don't trust > the manifest generator in Visual Studio, it tends to get details > wrong), and put application specific DLLs (including private > copies of stuff such as SSLEAY32.DLL) in the same directory as the > referencing EXE/DLL file. > > Playing around with the PATH environment variable when installing > programs is generally considered worst practice due to the risk of > affecting other programs by inflicting your own DLLs etc. on them. > > As a side effect of all this, having a dedicated lib/dll subdir in > your install dir will generally not work unless you load all those > DLLs via your own calls to LoadLibrary/LoadLibraryEx with > explicitly computed full pathnames, thus such a dir is now only > good for plugins and other on-demand loaded components. With a > little tweaking it could also be useful for OpenSSL engine plugin > DLLs. Thanks much for the info. I?ll work on two options - statically linking the libs and, if that doesn?t work, augmenting our existing app manifest to bind the app to the DLLs. I?ll let you know what I find. ---- Russ Loucks mailto: rjl at mnmicro.net Winter is coming -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michal.Trojnara at stunnel.org Thu Jun 23 20:38:06 2016 From: Michal.Trojnara at stunnel.org (=?UTF-8?Q?Micha=c5=82_Trojnara?=) Date: Thu, 23 Jun 2016 22:38:06 +0200 Subject: [openssl-users] stunnel 5.33 released Message-ID: <576C48AE.1080806@stunnel.org> Dear Users, I have released version 5.33 of stunnel. This release fixes a memory leak. Upgrade is highly recommended. The ChangeLog entry: Version 5.33, 2016.06.23, urgency: HIGH * New features - Improved memory leak detection performance and accuracy. - Improved compatibility with the current OpenSSL 1.1.0-dev tree. - SNI support also enabled on OpenSSL 0.9.8f and later (thx to Guillermo Rodriguez Garcia). - Added support for PKCS #12 (.p12/.pfx) certificates (thx to Dmitry Bakshaev). * Bugfixes - Fixed a TLS session caching memory leak (thx to Richard Kraemer). Before stunnel 5.27 this leak only emerged with sessiond enabled. - Yet another WinCE socket fix (thx to Richard Kraemer). - Fixed passphrase/pin dialogs in tstunnel.exe. - Fixed a FORK threading build regression bug. - OPENSSL_NO_DH compilation fix (thx to Brian Lin). Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 7f54636d1e00864fd4d6bdda0bef60b8aaf24350cf02f89dfd2ac7967c052c73 stunnel-5.33.tar.gz facd42d19b78e3b4c3a8fb207577c5ba142a5d98ccbc7c0fd3c44b49f65b2235 stunnel-5.33-installer.exe 82fa7e723d7e226a797626dd43d5eb08ee2298b11ae9c1a7589ee9e121e6edfa stunnel-5.33-android.zip Best regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 884 bytes Desc: OpenPGP digital signature URL: From sahilgandhi87 at gmail.com Fri Jun 24 05:59:39 2016 From: sahilgandhi87 at gmail.com (Sahil Gandhi) Date: Fri, 24 Jun 2016 11:29:39 +0530 Subject: [openssl-users] Regarding FIPS capable openssl (I want to combine libcrypto.a and libssl.a) Message-ID: Hi All, I have built Openssl-fips-2.0.10.tar on* RHEL Linux* (*Same happens with Solaris 10*). Then I built Openssl-1.0.1p using respective fips object module (i.e. Openssl-fips-2.0.10.tar). Once I have built Openssl-1.0.1p, libcrypto.a and libssl.a has been created. I need to join these 2 libraries and make it one. I am doing it using "ar" command as follows: ar -x libssl.a ar -x libcrypto.a Then combine all .o files to make third library: ar -r libnew.a *.o But when i use this libnew.a in my sample(contain FIPS_mode_set(1)), it compiles successfully but when execute the executable it throws error* finger print does not match:fips.c:232* Plz help. I need to combine both libaries and make it one. Any help/suggestion? -- Sahil Gandhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Fri Jun 24 06:27:27 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 24 Jun 2016 08:27:27 +0200 Subject: [openssl-users] Regarding FIPS capable openssl (I want to combine libcrypto.a and libssl.a) In-Reply-To: References: Message-ID: <4a324a98-f1c1-286b-747b-d5dd2724d034@wisemo.com> On 24/06/2016 07:59, Sahil Gandhi wrote: > Hi All, > > I have built Openssl-fips-2.0.10.tar on* RHEL Linux* (/_*Same happens > with Solaris 10*_/). Then I built Openssl-1.0.1p using respective fips > object module (i.e. Openssl-fips-2.0.10.tar). > > Once I have built Openssl-1.0.1p, libcrypto.a and libssl.a has been > created. > I need to join these 2 libraries and make it one. > > I am doing it using "ar" command as follows: > > ar -x libssl.a > ar -x libcrypto.a > > Then combine all .o files to make third library: > ar -r libnew.a *.o > > But when i use this libnew.a in my sample(contain FIPS_mode_set(1)), > it compiles successfully but when execute the executable it throws > error* finger print does not match:fips.c:232* > > Plz help. > I need to combine both libaries and make it one. > > Any help/suggestion? > You forgot the special link step for FIPS enabled applications, perhaps also some of the other required steps from the FIPS module users guide. 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 sahilgandhi87 at gmail.com Fri Jun 24 07:10:12 2016 From: sahilgandhi87 at gmail.com (Sahil Gandhi) Date: Fri, 24 Jun 2016 12:40:12 +0530 Subject: [openssl-users] Regarding FIPS capable openssl (I want to combine libcrypto.a and libssl.a) In-Reply-To: <4a324a98-f1c1-286b-747b-d5dd2724d034@wisemo.com> References: <4a324a98-f1c1-286b-747b-d5dd2724d034@wisemo.com> Message-ID: Hi Jakob, Could you please elaborate it? I am not getting it. I might missing something but I did not get it. Many Thanks Jakob for replying. -Sahil On Fri, Jun 24, 2016 at 11:57 AM, Jakob Bohm wrote: > On 24/06/2016 07:59, Sahil Gandhi wrote: > >> Hi All, >> >> I have built Openssl-fips-2.0.10.tar on* RHEL Linux* (/_*Same happens >> with Solaris 10*_/). Then I built Openssl-1.0.1p using respective fips >> object module (i.e. Openssl-fips-2.0.10.tar). >> >> Once I have built Openssl-1.0.1p, libcrypto.a and libssl.a has been >> created. >> I need to join these 2 libraries and make it one. >> >> I am doing it using "ar" command as follows: >> >> ar -x libssl.a >> ar -x libcrypto.a >> >> Then combine all .o files to make third library: >> ar -r libnew.a *.o >> >> But when i use this libnew.a in my sample(contain FIPS_mode_set(1)), it >> compiles successfully but when execute the executable it throws error* >> finger print does not match:fips.c:232* >> >> Plz help. >> I need to combine both libaries and make it one. >> >> Any help/suggestion? >> >> > You forgot the special link step for FIPS enabled applications, > perhaps also some of the other required steps from the FIPS > module users guide. > > > > 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 > -- Sahil Gandhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Fri Jun 24 10:44:57 2016 From: marquess at openssl.com (Steve Marquess) Date: Fri, 24 Jun 2016 06:44:57 -0400 Subject: [openssl-users] Regarding FIPS capable openssl (I want to combine libcrypto.a and libssl.a) In-Reply-To: References: <4a324a98-f1c1-286b-747b-d5dd2724d034@wisemo.com> Message-ID: <576D0F29.5050701@openssl.com> On 06/24/2016 03:10 AM, Sahil Gandhi wrote: > Hi Jakob, > > Could you please elaborate it? I am not getting it. > I might missing something but I did not get it. > > Many Thanks Jakob for replying. > > -Sahil > > On Fri, Jun 24, 2016 at 11:57 AM, Jakob Bohm > wrote: > > On 24/06/2016 07:59, Sahil Gandhi wrote: > > Hi All, > > I have built Openssl-fips-2.0.10.tar on* RHEL Linux* (/_*Same > happens with Solaris 10*_/). Then I built Openssl-1.0.1p using > respective fips object module (i.e. Openssl-fips-2.0.10.tar). > > Once I have built Openssl-1.0.1p, libcrypto.a and libssl.a has > been created. > I need to join these 2 libraries and make it one. > > I am doing it using "ar" command as follows: > > ar -x libssl.a > ar -x libcrypto.a > > Then combine all .o files to make third library: > ar -r libnew.a *.o > > But when i use this libnew.a in my sample(contain > FIPS_mode_set(1)), it compiles successfully but when execute the > executable it throws error* finger print does not match:fips.c:232* > > Plz help. > I need to combine both libaries and make it one. > > Any help/suggestion? > > > You forgot the special link step for FIPS enabled applications, > perhaps also some of the other required steps from the FIPS > module users guide. > See https://openssl.org/docs/fips/UserGuide-2.0.pdf. The FIPS module requires special build-time voodoo to satisfy the peculiar requirements of the FIPS 140-2 validation. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From sahilgandhi87 at gmail.com Fri Jun 24 13:24:18 2016 From: sahilgandhi87 at gmail.com (Sahil Gandhi) Date: Fri, 24 Jun 2016 18:54:18 +0530 Subject: [openssl-users] Regarding FIPS capable openssl (I want to combine libcrypto.a and libssl.a) In-Reply-To: <576D0F29.5050701@openssl.com> References: <4a324a98-f1c1-286b-747b-d5dd2724d034@wisemo.com> <576D0F29.5050701@openssl.com> Message-ID: Hi Steve, Could you please help me out? I tried to re-read that part of user-guide but no success. I know how to generate fingerprint but once i create new static library out of libcrypto.a and libssl.a. And I do generate the finger print of that new library but don't know how to proceed further with that. because if i use that new library(to create executable) as it is, it throws fingerprint mismatch error. My sample source file has FIPS_mode_set(1) call only. Thanks Sahil On Fri, Jun 24, 2016 at 4:14 PM, Steve Marquess wrote: > On 06/24/2016 03:10 AM, Sahil Gandhi wrote: > > Hi Jakob, > > > > Could you please elaborate it? I am not getting it. > > I might missing something but I did not get it. > > > > Many Thanks Jakob for replying. > > > > -Sahil > > > > On Fri, Jun 24, 2016 at 11:57 AM, Jakob Bohm > > wrote: > > > > On 24/06/2016 07:59, Sahil Gandhi wrote: > > > > Hi All, > > > > I have built Openssl-fips-2.0.10.tar on* RHEL Linux* (/_*Same > > happens with Solaris 10*_/). Then I built Openssl-1.0.1p using > > respective fips object module (i.e. Openssl-fips-2.0.10.tar). > > > > Once I have built Openssl-1.0.1p, libcrypto.a and libssl.a has > > been created. > > I need to join these 2 libraries and make it one. > > > > I am doing it using "ar" command as follows: > > > > ar -x libssl.a > > ar -x libcrypto.a > > > > Then combine all .o files to make third library: > > ar -r libnew.a *.o > > > > But when i use this libnew.a in my sample(contain > > FIPS_mode_set(1)), it compiles successfully but when execute the > > executable it throws error* finger print does not > match:fips.c:232* > > > > Plz help. > > I need to combine both libaries and make it one. > > > > Any help/suggestion? > > > > > > You forgot the special link step for FIPS enabled applications, > > perhaps also some of the other required steps from the FIPS > > module users guide. > > > > See https://openssl.org/docs/fips/UserGuide-2.0.pdf. > > The FIPS module requires special build-time voodoo to satisfy the > peculiar requirements of the FIPS 140-2 validation. > > -Steve M. > > -- > Steve Marquess > OpenSSL Validation Services, Inc. > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marquess at openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Sahil Gandhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Fri Jun 24 13:43:15 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 24 Jun 2016 15:43:15 +0200 Subject: [openssl-users] Regarding FIPS capable openssl (I want to combine libcrypto.a and libssl.a) In-Reply-To: References: <4a324a98-f1c1-286b-747b-d5dd2724d034@wisemo.com> <576D0F29.5050701@openssl.com> Message-ID: On 24/06/2016 15:24, Sahil Gandhi wrote: > Hi Steve, > > Could you please help me out? > I tried to re-read that part of user-guide but no success. > I know how to generate fingerprint but once i create new static > library out of libcrypto.a and libssl.a. > And I do generate the finger print of that new library but don't know > how to proceed further with that. > > because if i use that new library(to create executable) as it is, it > throws fingerprint mismatch error. > My sample source file has FIPS_mode_set(1) call only. > Because fipscannister.o is not compiled as 100% position independent code (and cannot legally be done so due to the bureaucratic rules of the FIPS validation), every new program linked to the FIPS enabled libcrypto.a will end up with a different fingerprint for the fipscannister. And if load address randomization is enabled in the operating system, each new run of the program will end up with a different fingerprint and thus not work. The situation is slightly better for the libcrypto.so DLL, because if load address randomization is turned off and it is ensured that libcrypto.so will load at a particular address every time, there will only be one fingerprint for each compiled libcrypto.so DLL. > On Fri, Jun 24, 2016 at 4:14 PM, Steve Marquess > wrote: > > On 06/24/2016 03:10 AM, Sahil Gandhi wrote: > > Hi Jakob, > > > > Could you please elaborate it? I am not getting it. > > I might missing something but I did not get it. > > > > Many Thanks Jakob for replying. > > > > -Sahil > > > > On Fri, Jun 24, 2016 at 11:57 AM, Jakob Bohm > > > >> wrote: > > > > On 24/06/2016 07:59, Sahil Gandhi wrote: > > > > Hi All, > > > > I have built Openssl-fips-2.0.10.tar on* RHEL Linux* > (/_*Same > > happens with Solaris 10*_/). Then I built Openssl-1.0.1p > using > > respective fips object module (i.e. > Openssl-fips-2.0.10.tar). > > > > Once I have built Openssl-1.0.1p, libcrypto.a and > libssl.a has > > been created. > > I need to join these 2 libraries and make it one. > > > > I am doing it using "ar" command as follows: > > > > ar -x libssl.a > > ar -x libcrypto.a > > > > Then combine all .o files to make third library: > > ar -r libnew.a *.o > > > > But when i use this libnew.a in my sample(contain > > FIPS_mode_set(1)), it compiles successfully but when > execute the > > executable it throws error* finger print does not > match:fips.c:232* > > > > Plz help. > > I need to combine both libaries and make it one. > > > > Any help/suggestion? > > > > > > You forgot the special link step for FIPS enabled applications, > > perhaps also some of the other required steps from the FIPS > > module users guide. > > > > See https://openssl.org/docs/fips/UserGuide-2.0.pdf. > > The FIPS module requires special build-time voodoo to satisfy the > peculiar requirements of the FIPS 140-2 validation. > 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 danchik at rebelbase.com Fri Jun 24 20:35:30 2016 From: danchik at rebelbase.com (Dan S) Date: Fri, 24 Jun 2016 13:35:30 -0700 Subject: [openssl-users] Unable to run application after Windows updates In-Reply-To: <972F29FB-DCD3-43CA-94EE-695FDF1E43C8@mnmicro.net> References: <81046AB7-D60E-4F99-84FC-F58E1D537E40@mnmicro.net> <972F29FB-DCD3-43CA-94EE-695FDF1E43C8@mnmicro.net> Message-ID: less headache static linking to SSLEAY32 and LIBEAY32 :), depending on how many windows versions you want to support, static linking to WS2_32 and CRYP32 may also be useful (though linking all 4 nearly tripled the binary for what we needed to have included), but don't have to worry about what version or SP is on the target machine and not bother with redistributables that may otherwise be needed on some installations... Also, lib dependencies in manifests may be treated differently between platforms and I am not sure if dependencies can be separated by the platform (for example 7 will accept abs paths, vista will expect paths to be relative to the location of the manifest file (embedded or near the .exe) and XP wants them relative to the exe (placing the dlls, the manifest and the exe in the same could avoid that, however lunching from different user accounts may again be a headache (ex. SUBSTed or hard linked paths on current user may differ from those of the run as user as in launching an app from SUBSTed (at login) path, for example, will fail to find the DLLs in current folder on vista and xp if you run as administrator that never had the startup script SUBST any drives) On Thu, Jun 23, 2016 at 12:50 PM, Russ Loucks wrote: > > On Jun 23, 2016, at 1:44 PM, Jakob Bohm wrote: > > On 23/06/2016 18:25, Russ Loucks wrote: > > We have an application running on Windows 8.1 (HP) tablets that is mostly > statically linked except for a few libraries, including the SSLEAY32 and > LIBEAY32 libraries. > > We're using version 1.0.2 of the OpenSSL libraries. > > We ship our executable and these two libraries and then set a PATH entry > in the registry that points to our 'lib' directory so the system/library > loader can find the libraries at load/run time. > > There are two other packages on these tablets we ship that include older > versions of the OpenSSL libraries - Intel TXE Components/TCS (OpenSSL > version 1.0.0g) and HP Registration service (1.0.0d). > > Works well. > > Until the user runs Windows updates.... > > Then, when our application starts we get a 'The ordinal 3905 could not be > located in the dynamic link library 'C:\program Files\ installdir>\lib\SSALEAY32.dll'. > > I've tried the following - all to no avail: > > - removing the HP and Intel OpenSSL libraries (but safe-keeping them > for later re-installation) > - Re-installing our application and OpenSSL libraries > > Interestingly, the OpenSSL libraries in the HP and Intel installations do > not change after the Windows update - they're the same versions as before > the update.... > > I'm stumped. Any clues? > > I'm guessing the best course of action is to statically link the OpenSSL > libs into our app. Is that a good plan? > > Thanks for the help. > > > Over the past few years, Microsoft has been phasing in a security > improvement (and it is an improvement) to protect against remote > attackers dropping trojanized replacement DLLs in an unsecured > (document) directory which they have reason to believe will be > the current directory when the attacked program is loaded. > This change consists of a change in the default search order > for DLLs where no explicit directory is passed to LoadLibrary/ > LoadLibraryEx, and a very similar change to the search order for > DLLs that are named (with no path obviously) in the import tables > in programs and other DLLs. > > The recommended best practice for DLLs loaded by linking to an > import library (which contains the needed entries for the import > table) is to leave OS owned standard DLLs in System32 (SysWoW64 > for 32 bit programs on Win64), use explicit manifest version > references in the calling EXE/DLLs linked in manifest (don't trust > the manifest generator in Visual Studio, it tends to get details > wrong), and put application specific DLLs (including private > copies of stuff such as SSLEAY32.DLL) in the same directory as the > referencing EXE/DLL file. > > Playing around with the PATH environment variable when installing > programs is generally considered worst practice due to the risk of > affecting other programs by inflicting your own DLLs etc. on them. > > As a side effect of all this, having a dedicated lib/dll subdir in > your install dir will generally not work unless you load all those > DLLs via your own calls to LoadLibrary/LoadLibraryEx with > explicitly computed full pathnames, thus such a dir is now only > good for plugins and other on-demand loaded components. With a > little tweaking it could also be useful for OpenSSL engine plugin > DLLs. > > > Thanks much for the info. I?ll work on two options - statically linking > the libs and, if that doesn?t work, augmenting our existing app manifest to > bind the app to the DLLs. > > I?ll let you know what I find. > > ---- > Russ Loucks > mailto: rjl at mnmicro.net > Winter is coming > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danchik at rebelbase.com Fri Jun 24 21:45:21 2016 From: danchik at rebelbase.com (Dan S) Date: Fri, 24 Jun 2016 14:45:21 -0700 Subject: [openssl-users] Record aggregation with TLS Client In-Reply-To: References: Message-ID: You can look into modifying the window size for transmission (likely devastating your throughput, considering it will have to drop from around usual 64K to about a tenth of the size - mostly notably with the increase of ACKs and header repetition with each packet ... falls too far and it will start resending same packets again .. this is notable especially when there is other traffic on the network). Also can try providing the TCP_NODELAY option, but that also will not guarantee the packets separation because there are many other things that control it (for example if the receiver is far behind responding with ACKs so the sender will keep buffering if it ends too far ahead and blocks) On Wed, Jun 22, 2016 at 7:54 AM, Michael Wojcik < Michael.Wojcik at microfocus.com> wrote: > By "a single packet", do you mean a single TCP segment? > > > > No, there's no way to ensure they're sent in separate TCP segments. TCP > segmentation is a function of the TCP/IP stack. And your application knows > nothing about it anyway; TCP is a byte-stream protocol. > > > > Why do you think you want to do this? (When people ask this question, for > TLS or any other protocol, it almost always indicates that they don't > understand TCP and have a broken design. TCP is not a record-based > protocol.) > > > > Michael Wojcik > Technology Specialist, Micro Focus > > > > > > *From:* openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *Rajeswari K > *Sent:* Tuesday, June 21, 2016 23:41 > *To:* openssl-users at openssl.org > *Subject:* [openssl-users] Record aggregation with TLS Client > > > > Hello Openssl users, > > > > Having a query on when our device acitng as TLS Client, we observed that > both client certificate and client key exchange messages are going in a > single packet. > > > > Is there any way to separate this? That means is there any option to avoid > multiple records in a single packet? > > > > > > Thanks, > > Rajeswari. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl at five-ten-sg.com Sun Jun 26 18:24:46 2016 From: carl at five-ten-sg.com (Carl Byington) Date: Sun, 26 Jun 2016 11:24:46 -0700 Subject: [openssl-users] openssl 1.1 and sendmail Message-ID: <1466965486.24302.19.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I am trying to modify the sendmail 8.16 snapshot to use openssl 1.1, but ran into a few issues. SSL_CTX_set_tmp_rsa_callback() was used to setup a temporary rsa key. It seems we never need to generate temp rsa keys since all the ephemeral rsa exchanges were removed. Is that correct? x509_vfy.h has: # define X509_STORE_set_verify_cb_func(ctx,func) ((ctx)->verify_cb=(func)) which causes a compile error since the X509_STORE structure is opaque. Is there a workaround for this? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAldwHbYACgkQL6j7milTFsHWhACeLM8DgD/4W06c9SCxvaW8kdS7 +CkAn38LMd1J9KGRjJpxpLzIjOQ8P5LQ =vL8B -----END PGP SIGNATURE----- From carl at five-ten-sg.com Sun Jun 26 23:00:00 2016 From: carl at five-ten-sg.com (Carl Byington) Date: Sun, 26 Jun 2016 16:00:00 -0700 Subject: [openssl-users] openssl 1.1.0-pre5 errors with --api=1.0.0 Message-ID: <1466982000.24302.28.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Compiling openssl 1.1.0-pre5 with: ./Configure --api=1.0.0 --prefix=/usr/local - --openssldir=/usr/etc/pki/tls enable-ec_nistp_64_gcc_128 zlib sctp enable-camellia enable-seed enable-rfc3779 enable-cms enable-md2 no-mdc2 no-rc5 no-ec2m no-gost no-srp enable-deprecated shared linux-x86_64 produces errors, including crypto/evp/e_idea.c: In function 'idea_ecb_cipher': crypto/evp/e_idea.c:85: warning: implicit declaration of function 'idea_ecb_encrypt' That seems to be caused by 0x00101000L rather than 0x10100000L testing the api level. grep -rl COMPAT.*0x00101000L openssl-1.1.0-pre5 openssl-1.1.0-pre5/include/openssl/x509v3.h openssl-1.1.0-pre5/include/openssl/idea.h openssl-1.1.0-pre5/include/openssl/bn.h The current master on github also has an instance of that in crypto/rand/rand_win.c Do you want comments like this on this -users list, or the -dev list? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAldwXmQACgkQL6j7milTFsGZfACfaF8qd4RHMtkIdYVbDRPdLu6O pTwAoIZXLkw/WkzGsQVMFRofI/NUSCZN =LxJp -----END PGP SIGNATURE----- From sahilgandhi87 at gmail.com Mon Jun 27 07:19:21 2016 From: sahilgandhi87 at gmail.com (Sahil Gandhi) Date: Mon, 27 Jun 2016 12:49:21 +0530 Subject: [openssl-users] Regarding FIPS capable openssl (I want to combine libcrypto.a and libssl.a) In-Reply-To: References: <4a324a98-f1c1-286b-747b-d5dd2724d034@wisemo.com> <576D0F29.5050701@openssl.com> Message-ID: Hi Jakob, Thanks a lot for your time and detailed explanation. Regards, Sahil On Fri, Jun 24, 2016 at 7:13 PM, Jakob Bohm wrote: > On 24/06/2016 15:24, Sahil Gandhi wrote: > >> Hi Steve, >> >> Could you please help me out? >> I tried to re-read that part of user-guide but no success. >> I know how to generate fingerprint but once i create new static library >> out of libcrypto.a and libssl.a. >> And I do generate the finger print of that new library but don't know how >> to proceed further with that. >> >> because if i use that new library(to create executable) as it is, it >> throws fingerprint mismatch error. >> My sample source file has FIPS_mode_set(1) call only. >> >> Because fipscannister.o is not compiled as 100% position independent > code (and cannot legally be done so due to the bureaucratic rules of > the FIPS validation), every new program linked to the FIPS enabled > libcrypto.a will end up with a different fingerprint for the > fipscannister. > > And if load address randomization is enabled in the operating system, > each new run of the program will end up with a different fingerprint > and thus not work. > > The situation is slightly better for the libcrypto.so DLL, because > if load address randomization is turned off and it is ensured that > libcrypto.so will load at a particular address every time, there > will only be one fingerprint for each compiled libcrypto.so DLL. > > On Fri, Jun 24, 2016 at 4:14 PM, Steve Marquess > > wrote: >> >> On 06/24/2016 03:10 AM, Sahil Gandhi wrote: >> > Hi Jakob, >> > >> > Could you please elaborate it? I am not getting it. >> > I might missing something but I did not get it. >> > >> > Many Thanks Jakob for replying. >> > >> > -Sahil >> > >> > On Fri, Jun 24, 2016 at 11:57 AM, Jakob Bohm >> >> > >> >> wrote: >> > >> > On 24/06/2016 07:59, Sahil Gandhi wrote: >> > >> > Hi All, >> > >> > I have built Openssl-fips-2.0.10.tar on* RHEL Linux* >> (/_*Same >> > happens with Solaris 10*_/). Then I built Openssl-1.0.1p >> using >> > respective fips object module (i.e. >> Openssl-fips-2.0.10.tar). >> > >> > Once I have built Openssl-1.0.1p, libcrypto.a and >> libssl.a has >> > been created. >> > I need to join these 2 libraries and make it one. >> > >> > I am doing it using "ar" command as follows: >> > >> > ar -x libssl.a >> > ar -x libcrypto.a >> > >> > Then combine all .o files to make third library: >> > ar -r libnew.a *.o >> > >> > But when i use this libnew.a in my sample(contain >> > FIPS_mode_set(1)), it compiles successfully but when >> execute the >> > executable it throws error* finger print does not >> match:fips.c:232* >> > >> > Plz help. >> > I need to combine both libaries and make it one. >> > >> > Any help/suggestion? >> > >> > >> > You forgot the special link step for FIPS enabled applications, >> > perhaps also some of the other required steps from the FIPS >> > module users guide. >> > >> >> See https://openssl.org/docs/fips/UserGuide-2.0.pdf. >> >> The FIPS module requires special build-time voodoo to satisfy the >> peculiar requirements of the FIPS 140-2 validation. >> >> > 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 > -- Sahil -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Jun 27 08:21:55 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 27 Jun 2016 09:21:55 +0100 Subject: [openssl-users] openssl 1.1.0-pre5 errors with --api=1.0.0 In-Reply-To: <1466982000.24302.28.camel@ns.five-ten-sg.com> References: <1466982000.24302.28.camel@ns.five-ten-sg.com> Message-ID: <5770E223.3050601@openssl.org> On 27/06/16 00:00, Carl Byington wrote: > > Do you want comments like this on this -users list, or the -dev list? Bug reports should either be raised as an issue in github (https://github.com/openssl/openssl/issues) or sent to rt at openssl.org. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From sahilgandhi87 at gmail.com Mon Jun 27 08:37:27 2016 From: sahilgandhi87 at gmail.com (Sahil Gandhi) Date: Mon, 27 Jun 2016 14:07:27 +0530 Subject: [openssl-users] Regarding FIPS capable openssl (I want to combine libcrypto.a and libssl.a) In-Reply-To: References: <4a324a98-f1c1-286b-747b-d5dd2724d034@wisemo.com> <576D0F29.5050701@openssl.com> Message-ID: Hi Steve, Could you please elaborate in detail? Many Thanks, Sahil On Mon, Jun 27, 2016 at 12:49 PM, Sahil Gandhi wrote: > Hi Jakob, > > Thanks a lot for your time and detailed explanation. > > Regards, > Sahil > > On Fri, Jun 24, 2016 at 7:13 PM, Jakob Bohm wrote: > >> On 24/06/2016 15:24, Sahil Gandhi wrote: >> >>> Hi Steve, >>> >>> Could you please help me out? >>> I tried to re-read that part of user-guide but no success. >>> I know how to generate fingerprint but once i create new static library >>> out of libcrypto.a and libssl.a. >>> And I do generate the finger print of that new library but don't know >>> how to proceed further with that. >>> >>> because if i use that new library(to create executable) as it is, it >>> throws fingerprint mismatch error. >>> My sample source file has FIPS_mode_set(1) call only. >>> >>> Because fipscannister.o is not compiled as 100% position independent >> code (and cannot legally be done so due to the bureaucratic rules of >> the FIPS validation), every new program linked to the FIPS enabled >> libcrypto.a will end up with a different fingerprint for the >> fipscannister. >> >> And if load address randomization is enabled in the operating system, >> each new run of the program will end up with a different fingerprint >> and thus not work. >> >> The situation is slightly better for the libcrypto.so DLL, because >> if load address randomization is turned off and it is ensured that >> libcrypto.so will load at a particular address every time, there >> will only be one fingerprint for each compiled libcrypto.so DLL. >> >> On Fri, Jun 24, 2016 at 4:14 PM, Steve Marquess >> > wrote: >>> >>> On 06/24/2016 03:10 AM, Sahil Gandhi wrote: >>> > Hi Jakob, >>> > >>> > Could you please elaborate it? I am not getting it. >>> > I might missing something but I did not get it. >>> > >>> > Many Thanks Jakob for replying. >>> > >>> > -Sahil >>> > >>> > On Fri, Jun 24, 2016 at 11:57 AM, Jakob Bohm >>> >>> > >> >>> wrote: >>> > >>> > On 24/06/2016 07:59, Sahil Gandhi wrote: >>> > >>> > Hi All, >>> > >>> > I have built Openssl-fips-2.0.10.tar on* RHEL Linux* >>> (/_*Same >>> > happens with Solaris 10*_/). Then I built Openssl-1.0.1p >>> using >>> > respective fips object module (i.e. >>> Openssl-fips-2.0.10.tar). >>> > >>> > Once I have built Openssl-1.0.1p, libcrypto.a and >>> libssl.a has >>> > been created. >>> > I need to join these 2 libraries and make it one. >>> > >>> > I am doing it using "ar" command as follows: >>> > >>> > ar -x libssl.a >>> > ar -x libcrypto.a >>> > >>> > Then combine all .o files to make third library: >>> > ar -r libnew.a *.o >>> > >>> > But when i use this libnew.a in my sample(contain >>> > FIPS_mode_set(1)), it compiles successfully but when >>> execute the >>> > executable it throws error* finger print does not >>> match:fips.c:232* >>> > >>> > Plz help. >>> > I need to combine both libaries and make it one. >>> > >>> > Any help/suggestion? >>> > >>> > >>> > You forgot the special link step for FIPS enabled applications, >>> > perhaps also some of the other required steps from the FIPS >>> > module users guide. >>> > >>> >>> See https://openssl.org/docs/fips/UserGuide-2.0.pdf. >>> >>> The FIPS module requires special build-time voodoo to satisfy the >>> peculiar requirements of the FIPS 140-2 validation. >>> >>> >> 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 >> > > > > -- > Sahil > > -- Sahil Gandhi Project Engineer R&D CDAC, Pune -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenchow.cn at gmail.com Mon Jun 27 09:13:23 2016 From: kenchow.cn at gmail.com (Ken Chow) Date: Mon, 27 Jun 2016 17:13:23 +0800 Subject: [openssl-users] Regarding FIPS capable openssl (I want to combine libcrypto.a and libssl.a) In-Reply-To: References: <4a324a98-f1c1-286b-747b-d5dd2724d034@wisemo.com> <576D0F29.5050701@openssl.com> Message-ID: I think you should refer the way of building Android application https://wiki.openssl.org/index.php/Android . Trying to warp libcryto.so to your dynamic library by the specified FIPS compiler, once you successfully generated your dynamic library, then no need to specify FIPS compiler for compiling your execute program any more, and it worked for me, whatever under linux(gcc) or android(NDK). Ken Chow about.me/kenchowcn [image: Ken Chow on about.me] 2016-06-27 16:37 GMT+08:00 Sahil Gandhi : > Hi Steve, > > Could you please elaborate in detail? > > Many Thanks, > Sahil > > On Mon, Jun 27, 2016 at 12:49 PM, Sahil Gandhi > wrote: > >> Hi Jakob, >> >> Thanks a lot for your time and detailed explanation. >> >> Regards, >> Sahil >> >> On Fri, Jun 24, 2016 at 7:13 PM, Jakob Bohm >> wrote: >> >>> On 24/06/2016 15:24, Sahil Gandhi wrote: >>> >>>> Hi Steve, >>>> >>>> Could you please help me out? >>>> I tried to re-read that part of user-guide but no success. >>>> I know how to generate fingerprint but once i create new static library >>>> out of libcrypto.a and libssl.a. >>>> And I do generate the finger print of that new library but don't know >>>> how to proceed further with that. >>>> >>>> because if i use that new library(to create executable) as it is, it >>>> throws fingerprint mismatch error. >>>> My sample source file has FIPS_mode_set(1) call only. >>>> >>>> Because fipscannister.o is not compiled as 100% position independent >>> code (and cannot legally be done so due to the bureaucratic rules of >>> the FIPS validation), every new program linked to the FIPS enabled >>> libcrypto.a will end up with a different fingerprint for the >>> fipscannister. >>> >>> And if load address randomization is enabled in the operating system, >>> each new run of the program will end up with a different fingerprint >>> and thus not work. >>> >>> The situation is slightly better for the libcrypto.so DLL, because >>> if load address randomization is turned off and it is ensured that >>> libcrypto.so will load at a particular address every time, there >>> will only be one fingerprint for each compiled libcrypto.so DLL. >>> >>> On Fri, Jun 24, 2016 at 4:14 PM, Steve Marquess >>> > wrote: >>>> >>>> On 06/24/2016 03:10 AM, Sahil Gandhi wrote: >>>> > Hi Jakob, >>>> > >>>> > Could you please elaborate it? I am not getting it. >>>> > I might missing something but I did not get it. >>>> > >>>> > Many Thanks Jakob for replying. >>>> > >>>> > -Sahil >>>> > >>>> > On Fri, Jun 24, 2016 at 11:57 AM, Jakob Bohm >>>> >>>> > >> >>>> wrote: >>>> > >>>> > On 24/06/2016 07:59, Sahil Gandhi wrote: >>>> > >>>> > Hi All, >>>> > >>>> > I have built Openssl-fips-2.0.10.tar on* RHEL Linux* >>>> (/_*Same >>>> > happens with Solaris 10*_/). Then I built Openssl-1.0.1p >>>> using >>>> > respective fips object module (i.e. >>>> Openssl-fips-2.0.10.tar). >>>> > >>>> > Once I have built Openssl-1.0.1p, libcrypto.a and >>>> libssl.a has >>>> > been created. >>>> > I need to join these 2 libraries and make it one. >>>> > >>>> > I am doing it using "ar" command as follows: >>>> > >>>> > ar -x libssl.a >>>> > ar -x libcrypto.a >>>> > >>>> > Then combine all .o files to make third library: >>>> > ar -r libnew.a *.o >>>> > >>>> > But when i use this libnew.a in my sample(contain >>>> > FIPS_mode_set(1)), it compiles successfully but when >>>> execute the >>>> > executable it throws error* finger print does not >>>> match:fips.c:232* >>>> > >>>> > Plz help. >>>> > I need to combine both libaries and make it one. >>>> > >>>> > Any help/suggestion? >>>> > >>>> > >>>> > You forgot the special link step for FIPS enabled >>>> applications, >>>> > perhaps also some of the other required steps from the FIPS >>>> > module users guide. >>>> > >>>> >>>> See https://openssl.org/docs/fips/UserGuide-2.0.pdf. >>>> >>>> The FIPS module requires special build-time voodoo to satisfy the >>>> peculiar requirements of the FIPS 140-2 validation. >>>> >>>> >>> 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 >>> >> >> >> >> -- >> Sahil >> >> > > > -- > Sahil Gandhi > Project Engineer > R&D CDAC, Pune > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Jun 27 10:56:35 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 27 Jun 2016 11:56:35 +0100 Subject: [openssl-users] openssl 1.1.0-pre5 errors with --api=1.0.0 In-Reply-To: <1466982000.24302.28.camel@ns.five-ten-sg.com> References: <1466982000.24302.28.camel@ns.five-ten-sg.com> Message-ID: <57710663.8060405@openssl.org> On 27/06/16 00:00, Carl Byington wrote: > Compiling openssl 1.1.0-pre5 with: > > ./Configure --api=1.0.0 --prefix=/usr/local > --openssldir=/usr/etc/pki/tls enable-ec_nistp_64_gcc_128 zlib sctp > enable-camellia enable-seed enable-rfc3779 enable-cms enable-md2 no-mdc2 > no-rc5 no-ec2m no-gost no-srp enable-deprecated shared linux-x86_64 > > produces errors, including > > crypto/evp/e_idea.c: In function 'idea_ecb_cipher': > crypto/evp/e_idea.c:85: warning: implicit declaration of function > 'idea_ecb_encrypt' > > That seems to be caused by 0x00101000L rather than 0x10100000L testing > the api level. > > > grep -rl COMPAT.*0x00101000L openssl-1.1.0-pre5 > > openssl-1.1.0-pre5/include/openssl/x509v3.h > openssl-1.1.0-pre5/include/openssl/idea.h > openssl-1.1.0-pre5/include/openssl/bn.h > > The current master on github also has an instance of that in > crypto/rand/rand_win.c This should now be fixed in the latest master. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From matt at openssl.org Mon Jun 27 11:42:45 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 27 Jun 2016 12:42:45 +0100 Subject: [openssl-users] openssl 1.1 and sendmail In-Reply-To: <1466965486.24302.19.camel@ns.five-ten-sg.com> References: <1466965486.24302.19.camel@ns.five-ten-sg.com> Message-ID: <57711135.8090004@openssl.org> On 26/06/16 19:24, Carl Byington wrote: > I am trying to modify the sendmail 8.16 snapshot to use openssl 1.1, but > ran into a few issues. > > > SSL_CTX_set_tmp_rsa_callback() was used to setup a temporary rsa key. It > seems we never need to generate temp rsa keys since all the ephemeral > rsa exchanges were removed. Is that correct? > Yes - these were export grade ciphersuites so they were removed and so were the associated functions. We should probably add some no-op compat macros for these. > > x509_vfy.h has: > > # define X509_STORE_set_verify_cb_func(ctx,func) > ((ctx)->verify_cb=(func)) > > which causes a compile error since the X509_STORE structure is opaque. > Is there a workaround for this? This was fixed some while ago in commit 7cafbb4bd and is available in the latest master. Matt From matthew.b.donald at gmail.com Mon Jun 27 14:04:08 2016 From: matthew.b.donald at gmail.com (Matthew Donald) Date: Tue, 28 Jun 2016 00:04:08 +1000 Subject: [openssl-users] How to encode text request of 'req -text -noout''s output? In-Reply-To: <2016062118162683254281@openmailbox.org> References: <2016062118162683254281@openmailbox.org> Message-ID: The file ca.csr is already readable by an application. It is a PEM-encoded ASN.1 formatted file. You can use the openssl library calls to decode the CSR and extract individual fields. The printed output of the -text option is generated by X509_REQ_print_ex() (which you can find in openssl/crypto/asn1/t_req.c). The code of this routine will demonstrate how to extract the fields you need. Matthew On 21 June 2016 at 20:16, eurus at openmailbox.org wrote: > Hi, > > If I get a text version of a request(e.g. use the command "openssl req > -noout -text -in ca.csr"), how can I encode it with openssl command(thus > transform it to the format that is able to be recognized by applications)? > > Thanks, > Eurus > ------------------------------ > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at lakesideos.com Mon Jun 27 19:08:38 2016 From: tony at lakesideos.com (Tony Girgenti) Date: Mon, 27 Jun 2016 15:08:38 -0400 Subject: [openssl-users] Getting error 'SSLv2_client_method': identifier not found Message-ID: <001001d1d0a7$4ff558d0$efe00a70$@lakesideos.com> Hello, I migrated a Visual Studio 6.0 C++ program to Visual Studio 2015 C++. The program uses OpenSSL. I have downloaded and installed OpenSSL-Win32 version 1.0.2g. I'm trying to figure what I need to do to fix the error I am getting on this line: m_pSSLctx = SSL_CTX_new(SSLv2_client_method()); The statement is part of this method: I see that there are conditional compilation statements in "ssl.h" that look like this: # if (defined(OPENSSL_NO_RSA) || defined(OPENSSL_NO_MD5)) && !defined(OPENSSL_NO_SSL2) # define OPENSSL_NO_SSL2 # endif And this: # ifndef OPENSSL_NO_SSL2 const SSL_METHOD *SSLv2_method(void); /* SSLv2 */ const SSL_METHOD *SSLv2_server_method(void); /* SSLv2 */ const SSL_METHOD *SSLv2_client_method(void); /* SSLv2 */ # endif With my limited knowledge of C++, I think I understand that "SSLv2_client_method" is created if "OPENSSL_NO_SSL2" is not defined in the program. In my case, I think it is defining "OPENSSL_NO_SSL2" and that is why my program can't find the identifier "SSLv2_client_method". I need help in trying to figure out if I need to add something to my program that will get rid of this error. The VS 6.0 version of this program works fine. I have both the executable part of it and the source code. Any help that anyone can provide to make this work would be gratefully appreciated. Thanks, Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 30660 bytes Desc: not available URL: From rsalz at akamai.com Mon Jun 27 19:19:42 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 27 Jun 2016 19:19:42 +0000 Subject: [openssl-users] Getting error 'SSLv2_client_method': identifier not found In-Reply-To: <001001d1d0a7$4ff558d0$efe00a70$@lakesideos.com> References: <001001d1d0a7$4ff558d0$efe00a70$@lakesideos.com> Message-ID: Do not use SSLv2. From Michael.Wojcik at microfocus.com Mon Jun 27 19:49:51 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 27 Jun 2016 19:49:51 +0000 Subject: [openssl-users] Getting error 'SSLv2_client_method': identifier not found In-Reply-To: <001001d1d0a7$4ff558d0$efe00a70$@lakesideos.com> References: <001001d1d0a7$4ff558d0$efe00a70$@lakesideos.com> Message-ID: SSLv2 is no longer supported, and neither are the SSLv2_*_method calls. (And yes, this causes build problems when updating to newer OpenSSL builds; and while that causes some pain, it was the Right Thing to do.) As Rich said, don't use SSLv2. Don't use SSLv3. If you can help it, don't use anything older than TLSv1.2. The simplest fix is to change "SSLv2_client_method" to "SSLv23_client_method". (Inserting a single character; can't get much simpler than that.) But since you really don't want to talk to a server that only supports SSLv3, you might as well use TLSv1_client_method instead, or even better TLSv1_2_client_method. Since we have no idea what your program does, or what it has to interoperate with, we can't offer any more-specific advice. SSLv23_client_method will use the old SSL-format ClientHello, but will (barring more-restrictive options set using SSL_CTX_set_options or similar) use later protocol versions for the actual conversation if the server supports them. All that said, by far the best approach is to learn how TLS and OpenSSL work, so you can make an informed decision. TLS is agonizingly complicated and a minefield of security holes, and TLS applications maintained by people who don't have the necessary specialized knowledge are very likely to be severely insecure. For example, they may try to use SSLv2, which has been broken for a couple of decades. (That is, it's been broken for as long as it existed, but it's been widely known to be broken since the mid-1990s.) Feistyduck.com has a free "OpenSSL cookbook" ebook which is a decent introduction. Michael Wojcik Technology Specialist, Micro Focus From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Tony Girgenti Sent: Monday, June 27, 2016 13:09 To: openssl-users at openssl.org Subject: [openssl-users] Getting error 'SSLv2_client_method': identifier not found Hello, I migrated a Visual Studio 6.0 C++ program to Visual Studio 2015 C++. The program uses OpenSSL. I have downloaded and installed OpenSSL-Win32 version 1.0.2g. I?m trying to figure what I need to do to fix the error I am getting on this line: m_pSSLctx = SSL_CTX_new(SSLv2_client_method()); -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at lakesideos.com Mon Jun 27 20:08:16 2016 From: tony at lakesideos.com (Tony Girgenti) Date: Mon, 27 Jun 2016 16:08:16 -0400 Subject: [openssl-users] Getting error 'SSLv2_client_method': identifier not found In-Reply-To: References: <001001d1d0a7$4ff558d0$efe00a70$@lakesideos.com> Message-ID: <002101d1d0af$a4d71bb0$ee855310$@lakesideos.com> Michael, Thank you for your explanation of where my program is and what I should do to continue using some kind of SSL. I first need to figure out how this program uses SSL. Then I can go ahead and try to use TLSv1.2. I did try to use "SSLv23_client_method" and got the same compile error "LNK2026 module unsafe for SAFESEH image.". Thanks, Tony From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Michael Wojcik Sent: Monday, June 27, 2016 3:50 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Getting error 'SSLv2_client_method': identifier not found SSLv2 is no longer supported, and neither are the SSLv2_*_method calls. (And yes, this causes build problems when updating to newer OpenSSL builds; and while that causes some pain, it was the Right Thing to do.) As Rich said, don't use SSLv2. Don't use SSLv3. If you can help it, don't use anything older than TLSv1.2. The simplest fix is to change "SSLv2_client_method" to "SSLv23_client_method". (Inserting a single character; can't get much simpler than that.) But since you really don't want to talk to a server that only supports SSLv3, you might as well use TLSv1_client_method instead, or even better TLSv1_2_client_method. Since we have no idea what your program does, or what it has to interoperate with, we can't offer any more-specific advice. SSLv23_client_method will use the old SSL-format ClientHello, but will (barring more-restrictive options set using SSL_CTX_set_options or similar) use later protocol versions for the actual conversation if the server supports them. All that said, by far the best approach is to learn how TLS and OpenSSL work, so you can make an informed decision. TLS is agonizingly complicated and a minefield of security holes, and TLS applications maintained by people who don't have the necessary specialized knowledge are very likely to be severely insecure. For example, they may try to use SSLv2, which has been broken for a couple of decades. (That is, it's been broken for as long as it existed, but it's been widely known to be broken since the mid-1990s.) Feistyduck.com has a free "OpenSSL cookbook" ebook which is a decent introduction. Michael Wojcik Technology Specialist, Micro Focus From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Tony Girgenti Sent: Monday, June 27, 2016 13:09 To: openssl-users at openssl.org Subject: [openssl-users] Getting error 'SSLv2_client_method': identifier not found Hello, I migrated a Visual Studio 6.0 C++ program to Visual Studio 2015 C++. The program uses OpenSSL. I have downloaded and installed OpenSSL-Win32 version 1.0.2g. I'm trying to figure what I need to do to fix the error I am getting on this line: m_pSSLctx = SSL_CTX_new(SSLv2_client_method()); -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Mon Jun 27 20:39:50 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 27 Jun 2016 22:39:50 +0200 Subject: [openssl-users] Getting error 'SSLv2_client_method': identifier not found In-Reply-To: <002101d1d0af$a4d71bb0$ee855310$@lakesideos.com> References: <001001d1d0a7$4ff558d0$efe00a70$@lakesideos.com> <002101d1d0af$a4d71bb0$ee855310$@lakesideos.com> Message-ID: "Unsafe for SAFESEH" is a completely different error: It means that at least one file or library in your program was either not compiled with the /SAFESEH switch or is an assembler module without the magic incantation to tell the linker it contains no Structured Exeption Handlers.In either case, it only occurs if you try to link with the /SAFESEH linker switch despite the inclusion of such object file(s). On 27/06/2016 22:08, Tony Girgenti wrote: > > Michael, > > Thank you for your explanation of where my program is and what I > should do to continue using some kind of SSL. > > I first need to figure out how this program uses SSL. Then I can go > ahead and try to use TLSv1.2. > > I did try to use "SSLv23_client_method" and got the same compile error > ?LNK2026 module unsafe for SAFESEH image.?. > > *From:* openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *Michael Wojcik > *Sent:* Monday, June 27, 2016 3:50 PM > *To:* openssl-users at openssl.org > *Subject:* Re: [openssl-users] Getting error 'SSLv2_client_method': > identifier not found > > SSLv2 is no longer supported, and neither are the SSLv2_*_method > calls. (And yes, this causes build problems when updating to newer > OpenSSL builds; and while that causes some pain, it was the Right > Thing to do.) > > As Rich said, don't use SSLv2. Don't use SSLv3. If you can help it, > don't use anything older than TLSv1.2. > > The simplest fix is to change "SSLv2_client_method" to > "SSLv23_client_method". (Inserting a single character; can't get much > simpler than that.) But since you really don't want to talk to a > server that only supports SSLv3, you might as well use > TLSv1_client_method instead, or even better TLSv1_2_client_method. > Since we have no idea what your program does, or what it has to > interoperate with, we can't offer any more-specific advice. > > SSLv23_client_method will use the old SSL-format ClientHello, but will > (barring more-restrictive options set using SSL_CTX_set_options or > similar) use later protocol versions for the actual conversation if > the server supports them. > > All that said, by far the best approach is to learn how TLS and > OpenSSL work, so you can make an informed decision. TLS is agonizingly > complicated and a minefield of security holes, and TLS applications > maintained by people who don't have the necessary specialized > knowledge are very likely to be severely insecure. For example, they > may try to use SSLv2, which has been broken for a couple of decades. > (That is, it's been broken for as long as it existed, but it's been > widely known to be broken since the mid-1990s.) > > Feistyduck.com has a free "OpenSSL cookbook" ebook which is a decent > introduction. > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *Tony Girgenti > *Sent:* Monday, June 27, 2016 13:09 > *To:* openssl-users at openssl.org > *Subject:* [openssl-users] Getting error 'SSLv2_client_method': > identifier not found > > Hello, > > I migrated a Visual Studio 6.0 C++ program to Visual Studio 2015 C++. > The program uses OpenSSL. I have downloaded and installed > OpenSSL-Win32 version 1.0.2g. > > I?m trying to figure what I need to do to fix the error I am getting > on this line: m_pSSLctx = SSL_CTX_new(SSLv2_client_method()); > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at lakesideos.com Mon Jun 27 19:45:15 2016 From: tony at lakesideos.com (Tony Girgenti) Date: Mon, 27 Jun 2016 15:45:15 -0400 Subject: [openssl-users] [SPAM] Re: Getting error 'SSLv2_client_method': identifier not found In-Reply-To: References: <001001d1d0a7$4ff558d0$efe00a70$@lakesideos.com> Message-ID: <001b01d1d0ac$6dbd7460$49385d20$@lakesideos.com> Hello, Thanks for your help. If I change the statement to m_pSSLctx = SSL_CTX_new(SSLv3_client_method()); The compiler gives the error: "LNK2026 module unsafe for SAFESEH image." Can you give more information about how to not use SSLv2? Thanks, Tony -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich Sent: Monday, June 27, 2016 3:20 PM To: openssl-users at openssl.org Subject: [SPAM] Re: [openssl-users] Getting error 'SSLv2_client_method': identifier not found Do not use SSLv2. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From matt at openssl.org Mon Jun 27 21:52:42 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 27 Jun 2016 22:52:42 +0100 Subject: [openssl-users] Getting error 'SSLv2_client_method': identifier not found In-Reply-To: References: <001001d1d0a7$4ff558d0$efe00a70$@lakesideos.com> Message-ID: <5771A02A.4030704@openssl.org> On 27/06/16 20:49, Michael Wojcik wrote: > The simplest fix is to change "SSLv2_client_method" to > "SSLv23_client_method". (Inserting a single character; can't get much > simpler than that.) But since you really don't want to talk to a server > that only supports SSLv3, you might as well use TLSv1_client_method > instead, or even better TLSv1_2_client_method. Since we have no idea > what your program does, or what it has to interoperate with, we can't > offer any more-specific advice. I would always recommend using the version flexible SSLv23_client_method() over the version fixed TLSv1_client_method() and TLSv1_2_client_method(). If you use TLSv1_client_method() then you can only ever talk TLSv1.0, even if both client and server are actually capable of negotiating something better. Using TLSv1_2_client_method() is kind of ok (except of course you deny yourself the possibility of talking to servers that don't support TLSv1.2 yet) - but if you ever upgrade OpenSSL to some future version that supports TLS1.3 (or later!) then, if you forget to upgrade your app at the same time, you are stuck with a less than optimal TLS version. Therefore use SSLv23_client_method() and disable any versions that you do not want to use with SSL_CTX_set_options()/SSL_set_options(): https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_options.html Of course I echo what everyone else has said about not using SSLv2_client_method() at all!! Matt From Michael.Wojcik at microfocus.com Mon Jun 27 22:15:29 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 27 Jun 2016 22:15:29 +0000 Subject: [openssl-users] Getting error 'SSLv2_client_method': identifier not found In-Reply-To: <5771A02A.4030704@openssl.org> References: <001001d1d0a7$4ff558d0$efe00a70$@lakesideos.com> <5771A02A.4030704@openssl.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Matt Caswell > Sent: Monday, June 27, 2016 15:53 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Getting error 'SSLv2_client_method': identifier > not found > > I would always recommend using the version flexible > SSLv23_client_method() over the version fixed TLSv1_client_method() and > TLSv1_2_client_method(). Thanks. I had misremembered - I thought the TLSv* methods would allow later TLS versions as well. (The code I support either always uses SSLv23_*_method and sets options to restrict versions, or lets the administrator configure it to use a different method but uses SSLv23 by default, depending on product.) Should have checked the docs before posting. -- Michael Wojcik Technology Specialist, Micro Focus From tony at lakesideos.com Mon Jun 27 22:48:09 2016 From: tony at lakesideos.com (Tony Girgenti) Date: Mon, 27 Jun 2016 18:48:09 -0400 Subject: [openssl-users] Getting error 'SSLv2_client_method': identifier not found In-Reply-To: References: <001001d1d0a7$4ff558d0$efe00a70$@lakesideos.com> <5771A02A.4030704@openssl.org> Message-ID: <002b01d1d0c5$fb523ae0$f1f6b0a0$@lakesideos.com> Hello, Is OpenSSL compatible with SAFESEH(safe exception handling feature)? https://msdn.microsoft.com/en-us/library/100ezk17.aspx Thanks, Tony -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Michael Wojcik Sent: Monday, June 27, 2016 6:15 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Getting error 'SSLv2_client_method': identifier not found > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of Matt Caswell > Sent: Monday, June 27, 2016 15:53 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Getting error 'SSLv2_client_method': > identifier not found > > I would always recommend using the version flexible > SSLv23_client_method() over the version fixed TLSv1_client_method() > and TLSv1_2_client_method(). Thanks. I had misremembered - I thought the TLSv* methods would allow later TLS versions as well. (The code I support either always uses SSLv23_*_method and sets options to restrict versions, or lets the administrator configure it to use a different method but uses SSLv23 by default, depending on product.) Should have checked the docs before posting. -- Michael Wojcik Technology Specialist, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From Michael.Wojcik at microfocus.com Tue Jun 28 13:58:50 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 28 Jun 2016 13:58:50 +0000 Subject: [openssl-users] Getting error 'SSLv2_client_method': identifier not found In-Reply-To: <002b01d1d0c5$fb523ae0$f1f6b0a0$@lakesideos.com> References: <001001d1d0a7$4ff558d0$efe00a70$@lakesideos.com> <5771A02A.4030704@openssl.org> <002b01d1d0c5$fb523ae0$f1f6b0a0$@lakesideos.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Tony Girgenti > Sent: Monday, June 27, 2016 16:48 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Getting error 'SSLv2_client_method': identifier > not found > > Is OpenSSL compatible with SAFESEH(safe exception handling feature)? It should be, if you're using a current OpenSSL release and you're building it properly. For some time now, OpenSSL's assembly modules have had SAFESEH gubbins wedged into them as necessary. See e.g. the ::safeseh subroutine in crypto/perlasm/x86nasm.pl in the OpenSSL sources. I just linked a little test program against a library built with OpenSSL 1.0.2g with SAFESEH enabled. No warnings, and dumpbin /loadconfig shows that it has a SafeSEH table. In your original note you said that you "downloaded and installed OpenSSL 1.0.2g". It's not clear what that means. Are you building using libraries created by someone else? -- Michael Wojcik Technology Specialist, Micro Focus From tony at lakesideos.com Tue Jun 28 14:25:49 2016 From: tony at lakesideos.com (Tony Girgenti) Date: Tue, 28 Jun 2016 10:25:49 -0400 Subject: [openssl-users] Getting error 'SSLv2_client_method': identifier not found In-Reply-To: References: <001001d1d0a7$4ff558d0$efe00a70$@lakesideos.com> <5771A02A.4030704@openssl.org> <002b01d1d0c5$fb523ae0$f1f6b0a0$@lakesideos.com> Message-ID: <000601d1d148$f8224120$e866c360$@lakesideos.com> Michael, Thanks for your help. I forget where I downloaded OpenSSL from, but all I did was download a zip file and unzipped all the file to a folder called: OpenSSL-Win32. >From there, I simply pointed my Visual Studio project properties directory search for includes and lib files to that folder. I did not compile or change anything in that folder. Thanks, Tony -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Michael Wojcik Sent: Tuesday, June 28, 2016 9:59 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] Getting error 'SSLv2_client_method': identifier not found > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of Tony Girgenti > Sent: Monday, June 27, 2016 16:48 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Getting error 'SSLv2_client_method': > identifier not found > > Is OpenSSL compatible with SAFESEH(safe exception handling feature)? It should be, if you're using a current OpenSSL release and you're building it properly. For some time now, OpenSSL's assembly modules have had SAFESEH gubbins wedged into them as necessary. See e.g. the ::safeseh subroutine in crypto/perlasm/x86nasm.pl in the OpenSSL sources. I just linked a little test program against a library built with OpenSSL 1.0.2g with SAFESEH enabled. No warnings, and dumpbin /loadconfig shows that it has a SafeSEH table. In your original note you said that you "downloaded and installed OpenSSL 1.0.2g". It's not clear what that means. Are you building using libraries created by someone else? -- Michael Wojcik Technology Specialist, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From rjl at mnmicro.net Tue Jun 28 16:07:24 2016 From: rjl at mnmicro.net (Russ Loucks) Date: Tue, 28 Jun 2016 11:07:24 -0500 Subject: [openssl-users] Unable to run application after Windows updates In-Reply-To: References: <81046AB7-D60E-4F99-84FC-F58E1D537E40@mnmicro.net> <972F29FB-DCD3-43CA-94EE-695FDF1E43C8@mnmicro.net> Message-ID: <99EEC7DF-4C59-4657-9134-6F8955D4EA8A@mnmicro.net> On Jun 24, 2016, at 3:35 PM, Dan S wrote: > less headache static linking to SSLEAY32 and LIBEAY32 :), depending on how many windows versions you want to support, static linking to WS2_32 and CRYP32 may also be useful (though linking all 4 nearly tripled the binary for what we needed to have included), but don't have to worry about what version or SP is on the target machine and not bother with redistributables that may otherwise be needed on some installations... Also, lib dependencies in manifests may be treated differently between platforms and I am not sure if dependencies can be separated by the platform (for example 7 will accept abs paths, vista will expect paths to be relative to the location of the manifest file (embedded or near the .exe) and XP wants them relative to the exe (placing the dlls, the manifest and the exe in the same could avoid that, however lunching from different user accounts may again be a headache (ex. SUBSTed or hard linked paths on current user may differ from those of the run as user as in launching an app from SUBSTed (at login) path, for example, will fail to find the DLLs in current folder on vista and xp if you run as administrator that never had the startup script SUBST any drives) > > > On Thu, Jun 23, 2016 at 12:50 PM, Russ Loucks wrote: > > On Jun 23, 2016, at 1:44 PM, Jakob Bohm wrote: > >> On 23/06/2016 18:25, Russ Loucks wrote: >>> We have an application running on Windows 8.1 (HP) tablets that is mostly statically linked except for a few libraries, including the SSLEAY32 and LIBEAY32 libraries. >>> >>> We're using version 1.0.2 of the OpenSSL libraries. >>> >>> We ship our executable and these two libraries and then set a PATH entry in the registry that points to our 'lib' directory so the system/library loader can find the libraries at load/run time. >>> >>> There are two other packages on these tablets we ship that include older versions of the OpenSSL libraries - Intel TXE Components/TCS (OpenSSL version 1.0.0g) and HP Registration service (1.0.0d). >>> >>> Works well. >>> >>> Until the user runs Windows updates.... >>> >>> Then, when our application starts we get a 'The ordinal 3905 could not be located in the dynamic link library 'C:\program Files\\lib\SSALEAY32.dll'. >>> >>> I've tried the following - all to no avail: >>> removing the HP and Intel OpenSSL libraries (but safe-keeping them for later re-installation) >>> Re-installing our application and OpenSSL libraries >>> Interestingly, the OpenSSL libraries in the HP and Intel installations do not change after the Windows update - they're the same versions as before the update.... >>> >>> I'm stumped. Any clues? >>> >>> I'm guessing the best course of action is to statically link the OpenSSL libs into our app. Is that a good plan? >>> >>> Thanks for the help. >>> >>> >> Over the past few years, Microsoft has been phasing in a security >> improvement (and it is an improvement) to protect against remote >> attackers dropping trojanized replacement DLLs in an unsecured >> (document) directory which they have reason to believe will be >> the current directory when the attacked program is loaded. >> This change consists of a change in the default search order >> for DLLs where no explicit directory is passed to LoadLibrary/ >> LoadLibraryEx, and a very similar change to the search order for >> DLLs that are named (with no path obviously) in the import tables >> in programs and other DLLs. >> >> The recommended best practice for DLLs loaded by linking to an >> import library (which contains the needed entries for the import >> table) is to leave OS owned standard DLLs in System32 (SysWoW64 >> for 32 bit programs on Win64), use explicit manifest version >> references in the calling EXE/DLLs linked in manifest (don't trust >> the manifest generator in Visual Studio, it tends to get details >> wrong), and put application specific DLLs (including private >> copies of stuff such as SSLEAY32.DLL) in the same directory as the >> referencing EXE/DLL file. >> >> Playing around with the PATH environment variable when installing >> programs is generally considered worst practice due to the risk of >> affecting other programs by inflicting your own DLLs etc. on them. >> >> As a side effect of all this, having a dedicated lib/dll subdir in >> your install dir will generally not work unless you load all those >> DLLs via your own calls to LoadLibrary/LoadLibraryEx with >> explicitly computed full pathnames, thus such a dir is now only >> good for plugins and other on-demand loaded components. With a >> little tweaking it could also be useful for OpenSSL engine plugin >> DLLs. > > Thanks much for the info. I?ll work on two options - statically linking the libs and, if that doesn?t work, augmenting our existing app manifest to bind the app to the DLLs. > > I?ll let you know what I find. > > ----Russ Loucks > mailto: rjl at mnmicro.net > Winter is coming > > -- > 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 Got this to work on the HP tablets by statically linking the OpenSSL libraries into our app. Interestingly I have a Toshiba Encore tablet running Windows 8.1 and applied all the upgrades and our app didn?t break like it did on the HP. Oh, well, I like the solution. ---- Russ Loucks mailto: rjl at mnmicro.net ?Until you teach someone calculus, they can?t even walk finite distances. But they can get reallllllly close.? - Saturday Morning Breakfast Cereal -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgnet.dev at gmail.com Tue Jun 28 17:24:41 2016 From: pgnet.dev at gmail.com (PGNet Dev) Date: Tue, 28 Jun 2016 10:24:41 -0700 Subject: [openssl-users] openssl 1.0.2h pkcs12 export fails @ "digital envelope routines:EVP_PBE_CipherInit:unknown cipher" Message-ID: <7d08ff23-1c24-e1c2-30c0-04770836dbb6@gmail.com> I'm setting up a new, local CA. The local openssl instance is openssl version OpenSSL 1.0.2h 3 May 2016 config'd/built with ... no-comp no-zlib no-zlib-dynamic \ enable-ec_nistp_64_gcc_128 \ enable-rfc3779 \ enable-ecdsa \ no-idea \ no-mdc2 \ no-rc2 \ no-rc5 \ no-ssl2 \ no-ssl3 \ no-weak-ssl-ciphers pkcs12 export, which worked a (long) while ago, now fails, openssl genrsa -des3 -aes256 -out test_CA.key 4096 openssl req -new -x509 -sha512 -days 365 -set_serial 01 -config ./openssl.cnf -subj "/C=US/ST=ST/L=CITY/O=example.com/OU=test_CA/emailAddress=ssl at example.com/CN=test_CA" \ -key test_CA.key \ -out test_CA.crt openssl pkcs12 -export \ -in test_CA.crt \ -inkey test_CA.key \ -out test_CA.p12 140199860266640:error:060740A0:digital envelope routines:EVP_PBE_CipherInit:unknown cipher:evp_pbe.c:181: 140199860266640:error:23077073:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 algor cipherinit error:p12_decr.c:87: 140199860266640:error:2306C067:PKCS12 routines:PKCS12_item_i2d_encrypt:encrypt error:p12_decr.c:188: 140199860266640:error:23073067:PKCS12 routines:PKCS12_pack_p7encdata:encrypt error:p12_add.c:213: Looks like the config above removed a required cipher? Perhaps too stringent ... What's the fix/workaround to get pkcs12 export working again? From pgnet.dev at gmail.com Tue Jun 28 18:03:27 2016 From: pgnet.dev at gmail.com (PGNet Dev) Date: Tue, 28 Jun 2016 11:03:27 -0700 Subject: [openssl-users] [SOLVED?] Re: openssl 1.0.2h pkcs12 export fails @ "digital envelope routines:EVP_PBE_CipherInit:unknown cipher" In-Reply-To: <7d08ff23-1c24-e1c2-30c0-04770836dbb6@gmail.com> References: <7d08ff23-1c24-e1c2-30c0-04770836dbb6@gmail.com> Message-ID: <5de61e8f-feff-0181-b05f-511a1bf9ea01@gmail.com> Reading @ https://www.openssl.org/docs/manmaster/apps/pkcs12.html "By default the private key is encrypted using triple DES and the certificate using 40 bit RC2." which clearly implies, with RC2 disabled (it is), that'll cause a problem in default config. Adding the options openssl pkcs12 -export \ >>> -descert fixes the problem, insofar as no error's caused on export. Would code to enable/use "-descert" as default cert, in the case of RC2 disabled, be called for? Or, perhaps with RC2 considered 'weak' these days, worhtwhile to make "-descert" the default? From Michael.Wojcik at microfocus.com Tue Jun 28 18:51:32 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 28 Jun 2016 18:51:32 +0000 Subject: [openssl-users] Getting error 'SSLv2_client_method': identifier not found In-Reply-To: <000601d1d148$f8224120$e866c360$@lakesideos.com> References: <001001d1d0a7$4ff558d0$efe00a70$@lakesideos.com> <5771A02A.4030704@openssl.org> <002b01d1d0c5$fb523ae0$f1f6b0a0$@lakesideos.com> <000601d1d148$f8224120$e866c360$@lakesideos.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Tony Girgenti > Sent: Tuesday, June 28, 2016 08:26 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Getting error 'SSLv2_client_method': identifier > not found > > I forget where I downloaded OpenSSL from, but all I did was download a zip > file and unzipped all the file to a folder called: OpenSSL-Win32. > > From there, I simply pointed my Visual Studio project properties directory > search for includes and lib files to that folder. I did not compile or > change anything in that folder. Linking against a security component of unknown provenance? Let's just say that would not be my preferred approach. Of course this points to one of the (many) problems with TLS: It's not easy to get it into your application. Open-source implementations (OpenSSL, GnuTLS, LibreSSL, NSS, CyaSSL, ...) are not trivial to work with. Many OSes come with some TLS implementation installed by default or as an add-on package, but then you have to work with their API, build, configuration, etc, which often raises issues with portability; and if, say, you're trying to use an application (or other component) that's built to use OpenSSL, then Microsoft's SChannel isn't going to do you much good. That said, it's not that hard to read the instructions, download the OpenSSL tarball, verify its signature, and build it. Then all you have to worry about are the myriad difficulties of using the OpenSSL API, dealing with the wide array of SSL and TLS protocol and ciphersuite pitfalls, navigating the nightmarish bog of X.509-certificate PKIs, diagnosing obscure failures, educating users, ... TLS is a solution that asymptotically approaches being worse than the problem. (Now I want that on a t-shirt.) But at the moment there are no viable alternatives for most use cases. -- Michael Wojcik Technology Specialist, Micro Focus From noloader at gmail.com Wed Jun 29 00:03:50 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 28 Jun 2016 20:03:50 -0400 Subject: [openssl-users] Getting error 'SSLv2_client_method': identifier not found In-Reply-To: References: <001001d1d0a7$4ff558d0$efe00a70$@lakesideos.com> Message-ID: On Mon, Jun 27, 2016 at 3:49 PM, Michael Wojcik wrote: > SSLv2 is no longer supported, and neither are the SSLv2_*_method calls. (And > yes, this causes build problems when updating to newer OpenSSL builds; and > while that causes some pain, it was the Right Thing to do.) > > As Rich said, don't use SSLv2. Don't use SSLv3. If you can help it, don't > use anything older than TLSv1.2. The library should have unconditionally set OPENSSL_NO_SSL2 when it yanked SSLv2 support. Iit was warned about use cases like this. When SSLv2 was re-added to return NULL because, it still omitted OPENSSL_NO_SSL2. There was no need to break existing client code in this case. From dni.grosu at gmail.com Wed Jun 29 04:57:14 2016 From: dni.grosu at gmail.com (danigrosu) Date: Tue, 28 Jun 2016 21:57:14 -0700 (MST) Subject: [openssl-users] OpenSSL s_time output meaning Message-ID: <1467176234459-67092.post@n7.nabble.com> Using the `$ openssl s_time -connect localhost:443 -new -time 30` command gives this output: No CIPHER specified Collecting connection statistics for 30 seconds ********** etc. 8102 connections in 12.65s; 640.47 connections/user sec, bytes read 0 8102 connections in 31 real seconds, 0 bytes read per connection What is the difference between 8102 connections in 12.65s and 8102 connections in 31 real seconds ? -- View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-s-time-output-meaning-tp67092.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From matt at openssl.org Wed Jun 29 07:43:09 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 29 Jun 2016 08:43:09 +0100 Subject: [openssl-users] Getting error 'SSLv2_client_method': identifier not found In-Reply-To: References: <001001d1d0a7$4ff558d0$efe00a70$@lakesideos.com> Message-ID: <57737C0D.4090108@openssl.org> On 29/06/16 01:03, Jeffrey Walton wrote: > On Mon, Jun 27, 2016 at 3:49 PM, Michael Wojcik > wrote: >> SSLv2 is no longer supported, and neither are the SSLv2_*_method calls. (And >> yes, this causes build problems when updating to newer OpenSSL builds; and >> while that causes some pain, it was the Right Thing to do.) >> >> As Rich said, don't use SSLv2. Don't use SSLv3. If you can help it, don't >> use anything older than TLSv1.2. > > The library should have unconditionally set OPENSSL_NO_SSL2 when it > yanked SSLv2 support. Iit was warned about use cases like this. > > When SSLv2 was re-added to return NULL because, it still omitted > OPENSSL_NO_SSL2. Huh? We do define it? >From my 1.0.2 opensslconf.h: #ifndef OPENSSL_NO_SSL2 # define OPENSSL_NO_SSL2 #endif Matt From ozkron at gmail.com Wed Jun 29 08:46:06 2016 From: ozkron at gmail.com (Oz) Date: Wed, 29 Jun 2016 08:46:06 +0000 (UTC) Subject: [openssl-users] Using SSL with wokring sockets and events Message-ID: I have a running program, the program is written in C I want to convert it from connecting to an HTTP to HTTPS (SSL) I have an event for write/read/timeout/error and such How do I continue and use the current sockets FD I have, but using openSSL over it? the most easy and simple way? I have created a CTX object, and an SSL object over it (SSL_new(..)) I thought about using BIO_new_socket, but having problems with the connection/ hand shake and reading/writing data (I am the client code only) From jb-openssl at wisemo.com Wed Jun 29 09:48:12 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 29 Jun 2016 11:48:12 +0200 Subject: [openssl-users] Using SSL with wokring sockets and events In-Reply-To: References: Message-ID: <6f9eb547-9772-a6c9-5330-f0c59ea09d71@wisemo.com> On 29/06/2016 10:46, Oz wrote: > I have a running program, the program is written in C > I want to convert it from connecting to an HTTP to HTTPS (SSL) > > I have an event for write/read/timeout/error and such > > How do I continue and use the current sockets FD I have, but using openSSL > over it? the most easy and simple way? > > I have created a CTX object, and an SSL object over it (SSL_new(..)) > > I thought about using BIO_new_socket, but having problems with the > connection/ hand shake and reading/writing data (I am the client code only) Try BIO_new_socket + BIO_set_fd Then do the standard OpenSSL socket loop that repeatedly checks if OpenSSL wants you to wait for socket send ready, socket receive ready, data from application ready or data to application ready, then proceeds accordingly (There is an example in apps/s_client.c, but it is difficult to read and contains optional stuff you won't need in your app). I think there is a better example somewhere. 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 sahilgandhi87 at gmail.com Wed Jun 29 11:09:38 2016 From: sahilgandhi87 at gmail.com (Sahil Gandhi) Date: Wed, 29 Jun 2016 16:39:38 +0530 Subject: [openssl-users] Regarding FIPS capable openssl (I want to combine libcrypto.a and libssl.a) In-Reply-To: References: <4a324a98-f1c1-286b-747b-d5dd2724d034@wisemo.com> <576D0F29.5050701@openssl.com> Message-ID: Hi Ken, Sorry for the late reply. I really appreciate your suggestion but I some how need to have static library not the dynamic one. Thanks & Regards, -Sahil On Mon, Jun 27, 2016 at 2:43 PM, Ken Chow wrote: > I think you should refer the way of building Android application > https://wiki.openssl.org/index.php/Android . > > Trying to warp libcryto.so to your dynamic library by the specified FIPS > compiler, once you successfully generated your dynamic library, then no > need to specify FIPS compiler for compiling your execute program any more, > and it worked for me, whatever under linux(gcc) or android(NDK). > > > > > > Ken Chow > about.me/kenchowcn > [image: Ken Chow on about.me] > > > 2016-06-27 16:37 GMT+08:00 Sahil Gandhi : > >> Hi Steve, >> >> Could you please elaborate in detail? >> >> Many Thanks, >> Sahil >> >> On Mon, Jun 27, 2016 at 12:49 PM, Sahil Gandhi >> wrote: >> >>> Hi Jakob, >>> >>> Thanks a lot for your time and detailed explanation. >>> >>> Regards, >>> Sahil >>> >>> On Fri, Jun 24, 2016 at 7:13 PM, Jakob Bohm >>> wrote: >>> >>>> On 24/06/2016 15:24, Sahil Gandhi wrote: >>>> >>>>> Hi Steve, >>>>> >>>>> Could you please help me out? >>>>> I tried to re-read that part of user-guide but no success. >>>>> I know how to generate fingerprint but once i create new static >>>>> library out of libcrypto.a and libssl.a. >>>>> And I do generate the finger print of that new library but don't know >>>>> how to proceed further with that. >>>>> >>>>> because if i use that new library(to create executable) as it is, it >>>>> throws fingerprint mismatch error. >>>>> My sample source file has FIPS_mode_set(1) call only. >>>>> >>>>> Because fipscannister.o is not compiled as 100% position independent >>>> code (and cannot legally be done so due to the bureaucratic rules of >>>> the FIPS validation), every new program linked to the FIPS enabled >>>> libcrypto.a will end up with a different fingerprint for the >>>> fipscannister. >>>> >>>> And if load address randomization is enabled in the operating system, >>>> each new run of the program will end up with a different fingerprint >>>> and thus not work. >>>> >>>> The situation is slightly better for the libcrypto.so DLL, because >>>> if load address randomization is turned off and it is ensured that >>>> libcrypto.so will load at a particular address every time, there >>>> will only be one fingerprint for each compiled libcrypto.so DLL. >>>> >>>> On Fri, Jun 24, 2016 at 4:14 PM, Steve Marquess >>>> > wrote: >>>>> >>>>> On 06/24/2016 03:10 AM, Sahil Gandhi wrote: >>>>> > Hi Jakob, >>>>> > >>>>> > Could you please elaborate it? I am not getting it. >>>>> > I might missing something but I did not get it. >>>>> > >>>>> > Many Thanks Jakob for replying. >>>>> > >>>>> > -Sahil >>>>> > >>>>> > On Fri, Jun 24, 2016 at 11:57 AM, Jakob Bohm >>>>> >>>>> > >> >>>>> wrote: >>>>> > >>>>> > On 24/06/2016 07:59, Sahil Gandhi wrote: >>>>> > >>>>> > Hi All, >>>>> > >>>>> > I have built Openssl-fips-2.0.10.tar on* RHEL Linux* >>>>> (/_*Same >>>>> > happens with Solaris 10*_/). Then I built Openssl-1.0.1p >>>>> using >>>>> > respective fips object module (i.e. >>>>> Openssl-fips-2.0.10.tar). >>>>> > >>>>> > Once I have built Openssl-1.0.1p, libcrypto.a and >>>>> libssl.a has >>>>> > been created. >>>>> > I need to join these 2 libraries and make it one. >>>>> > >>>>> > I am doing it using "ar" command as follows: >>>>> > >>>>> > ar -x libssl.a >>>>> > ar -x libcrypto.a >>>>> > >>>>> > Then combine all .o files to make third library: >>>>> > ar -r libnew.a *.o >>>>> > >>>>> > But when i use this libnew.a in my sample(contain >>>>> > FIPS_mode_set(1)), it compiles successfully but when >>>>> execute the >>>>> > executable it throws error* finger print does not >>>>> match:fips.c:232* >>>>> > >>>>> > Plz help. >>>>> > I need to combine both libaries and make it one. >>>>> > >>>>> > Any help/suggestion? >>>>> > >>>>> > >>>>> > You forgot the special link step for FIPS enabled >>>>> applications, >>>>> > perhaps also some of the other required steps from the FIPS >>>>> > module users guide. >>>>> > >>>>> >>>>> See https://openssl.org/docs/fips/UserGuide-2.0.pdf. >>>>> >>>>> The FIPS module requires special build-time voodoo to satisfy the >>>>> peculiar requirements of the FIPS 140-2 validation. >>>>> >>>>> >>>> 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 >>>> >>> >>> >>> >>> -- >>> Sahil >>> >>> >> >> >> -- >> Sahil Gandhi >> Project Engineer >> R&D CDAC, Pune >> >> -- >> 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 > > -- Sahil Gandhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Wed Jun 29 12:13:04 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 29 Jun 2016 12:13:04 +0000 Subject: [openssl-users] Getting error 'SSLv2_client_method': identifier not found In-Reply-To: References: <001001d1d0a7$4ff558d0$efe00a70$@lakesideos.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Jeffrey Walton > Sent: Tuesday, June 28, 2016 18:04 > To: OpenSSL Users > Subject: Re: [openssl-users] Getting error 'SSLv2_client_method': identifier > not found > > On Mon, Jun 27, 2016 at 3:49 PM, Michael Wojcik > wrote: > > SSLv2 is no longer supported, and neither are the SSLv2_*_method calls. > (And > > yes, this causes build problems when updating to newer OpenSSL builds; > and > > while that causes some pain, it was the Right Thing to do.) > > The library should have unconditionally set OPENSSL_NO_SSL2 when it > yanked SSLv2 support. Iit was warned about use cases like this. > > When SSLv2 was re-added to return NULL because, it still omitted > OPENSSL_NO_SSL2. > > There was no need to break existing client code in this case. That's a valid argument. There was a time, not so long ago, when I made a similar argument on this very list (and was pretty cranky about proposed changes to the OpenSSL API). At the moment, I'm inclined to prefer a compile-time error to a run-time one in this case. I suspect there's a fair bit of code out there which doesn't check for a null return from the *_method calls, leading to some puzzlement on the part of developers. (I'll agree re OPENSSL_NO_SSL2; that ought to be defined.) But perhaps tomorrow I'll feel differently. There's an argument to be made either way. -- Michael Wojcik Technology Specialist, Micro Focus From dlmeetei at gmail.com Wed Jun 29 12:18:17 2016 From: dlmeetei at gmail.com (Devchandra L Meetei) Date: Wed, 29 Jun 2016 17:48:17 +0530 Subject: [openssl-users] Using SSL with wokring sockets and events In-Reply-To: References: Message-ID: If you are intending to use asynchronous event based NIO library libuv, then you might like to use BIO pair. I have done some abstraction on top of openSSL so that it becomes easy for callback based async lib. May be you can have a look at it On Wed, Jun 29, 2016 at 2:16 PM, Oz wrote: > I have a running program, the program is written in C > I want to convert it from connecting to an HTTP to HTTPS (SSL) > > I have an event for write/read/timeout/error and such > > How do I continue and use the current sockets FD I have, but using openSSL > over it? the most easy and simple way? > > I have created a CTX object, and an SSL object over it (SSL_new(..)) > > I thought about using BIO_new_socket, but having problems with the > connection/ hand shake and reading/writing data (I am the client code only) > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Warm Regards --Dev OpenPegasus Developer "I'm one of those people that think Thomas Edison and the light bulb changed the world more than Karl Marx ever did,? Steve Jobs -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Wed Jun 29 12:55:29 2016 From: marquess at openssl.com (Steve Marquess) Date: Wed, 29 Jun 2016 08:55:29 -0400 Subject: [openssl-users] Regarding FIPS capable openssl (I want to combine libcrypto.a and libssl.a) In-Reply-To: References: <4a324a98-f1c1-286b-747b-d5dd2724d034@wisemo.com> <576D0F29.5050701@openssl.com> Message-ID: <5773C541.60704@openssl.com> On 06/29/2016 07:09 AM, Sahil Gandhi wrote: > Hi Ken, > > Sorry for the late reply. I really appreciate your suggestion but I some > how need to have static library not the dynamic one. You can statically link an application with the FIPS module, using the special "fipsld" link process, but you cannot put the FIPS module in a conventional static library (as managed with "ar"). Unfortunately the requirements of FIPS 140-2 conflict in several ways with standard software engineering practice; it is the tail that wags the dog. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From mike.scott at miracl.com Wed Jun 29 14:46:13 2016 From: mike.scott at miracl.com (Michael Scott) Date: Wed, 29 Jun 2016 15:46:13 +0100 Subject: [openssl-users] Creating an X25519-based Certificate Message-ID: Hello, How do I do this? Using the OpenSSL command line tool, a certificate request must be self-signed, but the X25519 elliptic curve (newly supported in version 1.1.0), doesn't do signature, it can only be used for key exchange. (Of course the X25519 Montgomery curve is birationally equivalent to an Edwards curve which can do signature. And indeed it is our intention to use the Edwards curve. But first I need a CA-signed X25519 cert. But because of the above catch-22 problem, I cannot create one.) Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Jun 29 14:53:14 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 29 Jun 2016 14:53:14 +0000 Subject: [openssl-users] Creating an X25519-based Certificate In-Reply-To: References: Message-ID: <5a4e1b46971f4532b85e4ac4cd71882e@usma1ex-dag1mb1.msg.corp.akamai.com> > How do I do this? Using the OpenSSL command line tool, a certificate request must be self-signed, but the X25519 elliptic curve (newly supported in version 1.1.0), doesn't do signature, it can only be used for key exchange. You cannot do it. You should look at the CFRG documents on Ed25519. From jb-openssl at wisemo.com Wed Jun 29 15:10:45 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 29 Jun 2016 17:10:45 +0200 Subject: [openssl-users] Creating an X25519-based Certificate In-Reply-To: <5a4e1b46971f4532b85e4ac4cd71882e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5a4e1b46971f4532b85e4ac4cd71882e@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <533a8427-ae00-76e4-264b-9dc68f1128aa@wisemo.com> On 29/06/2016 16:53, Salz, Rich wrote: >> How do I do this? Using the OpenSSL command line tool, a certificate request must be self-signed, but the X25519 elliptic curve (newly supported in version 1.1.0), doesn't do signature, it can only be used for key exchange. > You cannot do it. > > You should look at the CFRG documents on Ed25519. > This raises two general questions: 1. What is CFRG, I don't remember that acronym. 2. What is the general procedure for generating a CSR for an encryption-only algorithm, such as DH, ECDH etc.? 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 mike.scott at miracl.com Wed Jun 29 15:16:42 2016 From: mike.scott at miracl.com (Michael Scott) Date: Wed, 29 Jun 2016 16:16:42 +0100 Subject: [openssl-users] Creating an X25519-based Certificate In-Reply-To: <533a8427-ae00-76e4-264b-9dc68f1128aa@wisemo.com> References: <5a4e1b46971f4532b85e4ac4cd71882e@usma1ex-dag1mb1.msg.corp.akamai.com> <533a8427-ae00-76e4-264b-9dc68f1128aa@wisemo.com> Message-ID: WellI can help with CFRG - its Crypto Forum Research Group. Mike On Wed, Jun 29, 2016 at 4:10 PM, Jakob Bohm wrote: > On 29/06/2016 16:53, Salz, Rich wrote: > >> How do I do this? Using the OpenSSL command line tool, a certificate >>> request must be self-signed, but the X25519 elliptic curve (newly supported >>> in version 1.1.0), doesn't do signature, it can only be used for key >>> exchange. >>> >> You cannot do it. >> >> You should look at the CFRG documents on Ed25519. >> >> This raises two general questions: > > 1. What is CFRG, I don't remember that acronym. > > 2. What is the general procedure for generating a CSR for > an encryption-only algorithm, such as DH, ECDH etc.? > > 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 rsalz at akamai.com Wed Jun 29 15:27:18 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 29 Jun 2016 15:27:18 +0000 Subject: [openssl-users] Creating an X25519-based Certificate In-Reply-To: <533a8427-ae00-76e4-264b-9dc68f1128aa@wisemo.com> References: <5a4e1b46971f4532b85e4ac4cd71882e@usma1ex-dag1mb1.msg.corp.akamai.com> <533a8427-ae00-76e4-264b-9dc68f1128aa@wisemo.com> Message-ID: <06ce8836688b40669ea394749e129822@usma1ex-dag1mb1.msg.corp.akamai.com> > 1. What is CFRG, I don't remember that acronym. Crypto Forum Research Group, part of the IETF's affiliated research group. Co-chair is Kenny Paterson of lucky-13 (etc). Useful documents here as well as pointers to the mailing list https://datatracker.ietf.org/rg/cfrg/documents/ > 2. What is the general procedure for generating a CSR for > an encryption-only algorithm, such as DH, ECDH etc.? I don't know of one. From Erwann.Abalea at docusign.com Wed Jun 29 15:27:32 2016 From: Erwann.Abalea at docusign.com (Erwann Abalea) Date: Wed, 29 Jun 2016 15:27:32 +0000 Subject: [openssl-users] Creating an X25519-based Certificate In-Reply-To: References: Message-ID: <3B854BA7-2662-4FA9-BA24-B062D75CBD3E@docusign.com> Bonjour, You may have a classic certificate containing your {X,Ed}{25519,448,whatever} public key once: * an OID is allocated to identify this type of public key (it will go into tbs.subjectPublicKeyInfo.algorithm.algorithm) * a set of associated optional parameters are defined for this OID (to go into tbs.subjectPublicKeyInfo.algorithm.parameters) * a canonical encoding for this type of public key is defined, so the key material can be enclosed into tbs.subjectPublicKeyInfo.subjectPublicKey This certificate may be RSA-signed or ECDSA-signed (or whatever-signed, in fact). For a CA to be able to Ed{25519,448,whatever}-sign something, the previous steps must have been done, plus: * an OID is allocated to identify the signature algorithm to apply (it will not be ECDSA) -> cert.signatureAlgorithm.algorithm * a set of associated optional parameters are defined for this OID -> cert.signatureAlgorithm.parameters * a canonical encoding for the signature value is defined, so it can be enclosed into cert.signatureValue All this is being discussed at CFRG. Cordialement, Erwann Abalea Le 29 juin 2016 ? 16:46, Michael Scott > a ?crit : Hello, How do I do this? Using the OpenSSL command line tool, a certificate request must be self-signed, but the X25519 elliptic curve (newly supported in version 1.1.0), doesn't do signature, it can only be used for key exchange. (Of course the X25519 Montgomery curve is birationally equivalent to an Edwards curve which can do signature. And indeed it is our intention to use the Edwards curve. But first I need a CA-signed X25519 cert. But because of the above catch-22 problem, I cannot create one.) Mike -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.scott at miracl.com Wed Jun 29 17:17:06 2016 From: mike.scott at miracl.com (Michael Scott) Date: Wed, 29 Jun 2016 18:17:06 +0100 Subject: [openssl-users] Creating an X25519-based Certificate In-Reply-To: <3B854BA7-2662-4FA9-BA24-B062D75CBD3E@docusign.com> References: <3B854BA7-2662-4FA9-BA24-B062D75CBD3E@docusign.com> Message-ID: Thanks Erwann, but that's not an answer to my question. To get the CA to sign (using RSA or anything) a certificate that contains an X25519 public key, that certificate must first submit to the CA something called a "Certificate request". This takes the form of the supplicant certificate, which is self-signed. However you cannot self-sign with an X25519 key (using the openssl command line tool), as it objects that X25519 does not support signature. So the issue arises around the "certificate request" process. There is I agree no problem in creating the certificate itself. Mike On Wed, Jun 29, 2016 at 4:27 PM, Erwann Abalea wrote: > Bonjour, > > You may have a classic certificate containing your > {X,Ed}{25519,448,whatever} public key once: > > - an OID is allocated to identify this type of public key (it will go > into tbs.subjectPublicKeyInfo.algorithm.algorithm) > - a set of associated optional parameters are defined for this OID (to > go into tbs.subjectPublicKeyInfo.algorithm.parameters) > - a canonical encoding for this type of public key is defined, so the > key material can be enclosed into tbs.subjectPublicKeyInfo.subjectPublicKey > > > This certificate may be RSA-signed or ECDSA-signed (or whatever-signed, in > fact). > > For a CA to be able to Ed{25519,448,whatever}-sign something, the previous > steps must have been done, plus: > > - an OID is allocated to identify the signature algorithm to apply (it > will not be ECDSA) -> cert.signatureAlgorithm.algorithm > - a set of associated optional parameters are defined for this OID -> > cert.signatureAlgorithm.parameters > - a canonical encoding for the signature value is defined, so it can > be enclosed into cert.signatureValue > > > All this is being discussed at CFRG. > > Cordialement, > Erwann Abalea > > Le 29 juin 2016 ? 16:46, Michael Scott a ?crit : > > Hello, > > > How do I do this? Using the OpenSSL command line tool, a certificate > request must be self-signed, but the X25519 elliptic curve (newly supported > in version 1.1.0), doesn't do signature, it can only be used for key > exchange. > > (Of course the X25519 Montgomery curve is birationally equivalent to an > Edwards curve which can do signature. And indeed it is our intention to use > the Edwards curve. But first I need a CA-signed X25519 cert. But because of > the above catch-22 problem, I cannot create one.) > > > Mike > > > -- > 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 rsalz at akamai.com Wed Jun 29 17:18:42 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 29 Jun 2016 17:18:42 +0000 Subject: [openssl-users] Creating an X25519-based Certificate In-Reply-To: References: <3B854BA7-2662-4FA9-BA24-B062D75CBD3E@docusign.com> Message-ID: <46de17a101a54957a86e4cd29ce29424@usma1ex-dag1mb1.msg.corp.akamai.com> >as it objects that X25519 does not support signature. ? To repeat: X25519 only supports key exchange. The 25519 signing mechanism is not yet defined. From rsalz at akamai.com Wed Jun 29 17:21:29 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 29 Jun 2016 17:21:29 +0000 Subject: [openssl-users] Creating an X25519-based Certificate In-Reply-To: <46de17a101a54957a86e4cd29ce29424@usma1ex-dag1mb1.msg.corp.akamai.com> References: <3B854BA7-2662-4FA9-BA24-B062D75CBD3E@docusign.com> <46de17a101a54957a86e4cd29ce29424@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > To repeat: X25519 only supports key exchange. The 25519 signing > mechanism is not yet defined. And see also: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ From mike.scott at miracl.com Wed Jun 29 17:26:36 2016 From: mike.scott at miracl.com (Michael Scott) Date: Wed, 29 Jun 2016 18:26:36 +0100 Subject: [openssl-users] Creating an X25519-based Certificate In-Reply-To: References: <3B854BA7-2662-4FA9-BA24-B062D75CBD3E@docusign.com> <46de17a101a54957a86e4cd29ce29424@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: On Wed, Jun 29, 2016 at 6:21 PM, Salz, Rich wrote: > > > To repeat: X25519 only supports key exchange. The 25519 signing > > mechanism is not yet defined. > Which I don't have a problem with. But surely the openssl command line tool should provide a mechanism for allowing an X25519-based certificate to be signed by a CA. Its seems that the "certificate request" protocol, which requires self-signing, prevents this in this case. Mike > > And see also: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ > > -- > 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 Wed Jun 29 17:28:36 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 29 Jun 2016 17:28:36 +0000 Subject: [openssl-users] Creating an X25519-based Certificate In-Reply-To: References: <3B854BA7-2662-4FA9-BA24-B062D75CBD3E@docusign.com> <46de17a101a54957a86e4cd29ce29424@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <52bcd392c867485590da45468b04cc4c@usma1ex-dag1mb1.msg.corp.akamai.com> > But surely the openssl command line tool should provide a mechanism for allowing an X25519-based certificate to be signed by a CA.? > Its seems that the "certificate request" protocol, which requires self-signing, prevents this in this case. Yes, that is exactly the point. From abe.racioppo at gmail.com Wed Jun 29 17:52:24 2016 From: abe.racioppo at gmail.com (Abe Racioppo) Date: Wed, 29 Jun 2016 13:52:24 -0400 Subject: [openssl-users] Creating an X25519-based Certificate In-Reply-To: <52bcd392c867485590da45468b04cc4c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <3B854BA7-2662-4FA9-BA24-B062D75CBD3E@docusign.com> <46de17a101a54957a86e4cd29ce29424@usma1ex-dag1mb1.msg.corp.akamai.com> <52bcd392c867485590da45468b04cc4c@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: 290620161352 On 6/29/16, Salz, Rich wrote: > >> But surely the openssl command line tool should provide a mechanism for >> allowing an X25519-based certificate to be signed by a CA. > >> Its seems that the "certificate request" protocol, which requires >> self-signing, prevents this in this case. > > Yes, that is exactly the point. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- signature From abe.racioppo at gmail.com Wed Jun 29 17:52:55 2016 From: abe.racioppo at gmail.com (Abe Racioppo) Date: Wed, 29 Jun 2016 13:52:55 -0400 Subject: [openssl-users] Creating an X25519-based Certificate In-Reply-To: References: <3B854BA7-2662-4FA9-BA24-B062D75CBD3E@docusign.com> <46de17a101a54957a86e4cd29ce29424@usma1ex-dag1mb1.msg.corp.akamai.com> <52bcd392c867485590da45468b04cc4c@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: tsets On 6/29/16, Abe Racioppo wrote: > 290620161352 > > On 6/29/16, Salz, Rich wrote: >> >>> But surely the openssl command line tool should provide a mechanism for >>> allowing an X25519-based certificate to be signed by a CA. >> >>> Its seems that the "certificate request" protocol, which requires >>> self-signing, prevents this in this case. >> >> Yes, that is exactly the point. >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > > -- > signature > -- signature From dev+openssl at seantek.com Wed Jun 29 18:10:50 2016 From: dev+openssl at seantek.com (Sean Leonard) Date: Wed, 29 Jun 2016 11:10:50 -0700 Subject: [openssl-users] Creating multi-valued RDN with config (still not working) In-Reply-To: <9361abf9-ad39-9576-bd28-32e1088d5b1d@seantek.com> References: <9361abf9-ad39-9576-bd28-32e1088d5b1d@seantek.com> Message-ID: <9cb59753-95df-b2b5-c1c7-8003ae2adbb3@seantek.com> Just following up... Sean On 6/18/2016 10:43 AM, Sean Leonard wrote: > I am trying to create a multi-valued RDN with OpenSSL using a config > file and the openssl req -x509 command, without success. > > According to the 2006 thread "Multi-value RDNs and openssl.cnf format" > , > one is supposed to do this by prefixing the keys in the > distinguished_name section with "+" on subsequent entries to add to a > multi-valued RDN, such as: > > [distinguished_name] > ST = California > +L = Los Angeles > +postalCode=90013 > > Unfortunately, that (still) does not work. The error from openssl req > -x509 (etc.) is: > > problems making Certificate Request > 30008:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num > too large:.\crypto\asn1\a_object.c:109: > 30008:error:0B083077:x509 certificate > routines:X509_NAME_ENTRY_create_by_txt:invalid field > name:.\crypto\x509\x509name.c:285:name=+L > > > I was successful at making a multi-valued RDN with the -multivalue-rdn > and -subj options, but that is not as versatile/scriptable. Any ideas? > > Sean > > PS It looks like it may be related to the behavior in auto_info > (req.c) X509_NAME_add_entry_by_txt (x509name.c), in particular, the > relationship between the variables mval, type, and p in auto_info > (req.c). Could be a bug. > > From sahilgandhi87 at gmail.com Thu Jun 30 03:58:28 2016 From: sahilgandhi87 at gmail.com (Sahil Gandhi) Date: Thu, 30 Jun 2016 09:28:28 +0530 Subject: [openssl-users] Regarding FIPS capable openssl (I want to combine libcrypto.a and libssl.a) In-Reply-To: <5773C541.60704@openssl.com> References: <4a324a98-f1c1-286b-747b-d5dd2724d034@wisemo.com> <576D0F29.5050701@openssl.com> <5773C541.60704@openssl.com> Message-ID: Hi Steve, Thanks for the reply. Regards, Sahil On Wed, Jun 29, 2016 at 6:25 PM, Steve Marquess wrote: > On 06/29/2016 07:09 AM, Sahil Gandhi wrote: > > Hi Ken, > > > > Sorry for the late reply. I really appreciate your suggestion but I some > > how need to have static library not the dynamic one. > > You can statically link an application with the FIPS module, using the > special "fipsld" link process, but you cannot put the FIPS module in a > conventional static library (as managed with "ar"). > > Unfortunately the requirements of FIPS 140-2 conflict in several ways > with standard software engineering practice; it is the tail that wags > the dog. > > -Steve M. > > -- > Steve Marquess > OpenSSL Validation Services, Inc. > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marquess at openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Sahil Gandhi Project Engineer R&D CDAC, Pune -------------- next part -------------- An HTML attachment was scrubbed... URL: From Erwann.Abalea at docusign.com Thu Jun 30 08:37:26 2016 From: Erwann.Abalea at docusign.com (Erwann Abalea) Date: Thu, 30 Jun 2016 08:37:26 +0000 Subject: [openssl-users] Creating an X25519-based Certificate In-Reply-To: References: <3B854BA7-2662-4FA9-BA24-B062D75CBD3E@docusign.com> Message-ID: <1E082092-B0C9-4B6B-96CC-E4481039FD6F@docusign.com> Ok, you?re talking about OpenSSL command line tool only, I missed that part. The solution should then be to modify apps/ca.c:certify() function to add an arg, and avoid the call to X509_REQ_verify when desired. Cordialement, Erwann Abalea Le 29 juin 2016 ? 19:17, Michael Scott > a ?crit : Thanks Erwann, but that's not an answer to my question. To get the CA to sign (using RSA or anything) a certificate that contains an X25519 public key, that certificate must first submit to the CA something called a "Certificate request". This takes the form of the supplicant certificate, which is self-signed. However you cannot self-sign with an X25519 key (using the openssl command line tool), as it objects that X25519 does not support signature. So the issue arises around the "certificate request" process. There is I agree no problem in creating the certificate itself. Mike On Wed, Jun 29, 2016 at 4:27 PM, Erwann Abalea > wrote: Bonjour, You may have a classic certificate containing your {X,Ed}{25519,448,whatever} public key once: * an OID is allocated to identify this type of public key (it will go into tbs.subjectPublicKeyInfo.algorithm.algorithm) * a set of associated optional parameters are defined for this OID (to go into tbs.subjectPublicKeyInfo.algorithm.parameters) * a canonical encoding for this type of public key is defined, so the key material can be enclosed into tbs.subjectPublicKeyInfo.subjectPublicKey This certificate may be RSA-signed or ECDSA-signed (or whatever-signed, in fact). For a CA to be able to Ed{25519,448,whatever}-sign something, the previous steps must have been done, plus: * an OID is allocated to identify the signature algorithm to apply (it will not be ECDSA) -> cert.signatureAlgorithm.algorithm * a set of associated optional parameters are defined for this OID -> cert.signatureAlgorithm.parameters * a canonical encoding for the signature value is defined, so it can be enclosed into cert.signatureValue All this is being discussed at CFRG. Cordialement, Erwann Abalea Le 29 juin 2016 ? 16:46, Michael Scott > a ?crit : Hello, How do I do this? Using the OpenSSL command line tool, a certificate request must be self-signed, but the X25519 elliptic curve (newly supported in version 1.1.0), doesn't do signature, it can only be used for key exchange. (Of course the X25519 Montgomery curve is birationally equivalent to an Edwards curve which can do signature. And indeed it is our intention to use the Edwards curve. But first I need a CA-signed X25519 cert. But because of the above catch-22 problem, I cannot create one.) Mike -- 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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.scott at miracl.com Thu Jun 30 08:41:15 2016 From: mike.scott at miracl.com (Michael Scott) Date: Thu, 30 Jun 2016 09:41:15 +0100 Subject: [openssl-users] Creating an X25519-based Certificate In-Reply-To: <1E082092-B0C9-4B6B-96CC-E4481039FD6F@docusign.com> References: <3B854BA7-2662-4FA9-BA24-B062D75CBD3E@docusign.com> <1E082092-B0C9-4B6B-96CC-E4481039FD6F@docusign.com> Message-ID: Yes, I can certainly program my way out of the problem, but it would be nice if the command line tool allowed me a way to do it. Thanks! Mike On Thu, Jun 30, 2016 at 9:37 AM, Erwann Abalea wrote: > Ok, you?re talking about OpenSSL command line tool only, I missed that > part. > > The solution should then be to modify apps/ca.c:certify() function to add > an arg, and avoid the call to X509_REQ_verify when desired. > > Cordialement, > Erwann Abalea > > Le 29 juin 2016 ? 19:17, Michael Scott a ?crit : > > Thanks Erwann, but that's not an answer to my question. > > To get the CA to sign (using RSA or anything) a certificate that contains > an X25519 public key, that certificate must first submit to the CA > something called a "Certificate request". This takes the form of the > supplicant certificate, which is self-signed. However you cannot self-sign > with an X25519 key (using the openssl command line tool), as it objects > that X25519 does not support signature. > > So the issue arises around the "certificate request" process. There is I > agree no problem in creating the certificate itself. > > > Mike > > > > On Wed, Jun 29, 2016 at 4:27 PM, Erwann Abalea > wrote: > >> Bonjour, >> >> You may have a classic certificate containing your >> {X,Ed}{25519,448,whatever} public key once: >> >> - an OID is allocated to identify this type of public key (it will go >> into tbs.subjectPublicKeyInfo.algorithm.algorithm) >> - a set of associated optional parameters are defined for this OID >> (to go into tbs.subjectPublicKeyInfo.algorithm.parameters) >> - a canonical encoding for this type of public key is defined, so the >> key material can be enclosed into tbs.subjectPublicKeyInfo.subjectPublicKey >> >> >> This certificate may be RSA-signed or ECDSA-signed (or whatever-signed, >> in fact). >> >> For a CA to be able to Ed{25519,448,whatever}-sign something, the >> previous steps must have been done, plus: >> >> - an OID is allocated to identify the signature algorithm to apply >> (it will not be ECDSA) -> cert.signatureAlgorithm.algorithm >> - a set of associated optional parameters are defined for this OID -> >> cert.signatureAlgorithm.parameters >> - a canonical encoding for the signature value is defined, so it can >> be enclosed into cert.signatureValue >> >> >> All this is being discussed at CFRG. >> >> Cordialement, >> Erwann Abalea >> >> Le 29 juin 2016 ? 16:46, Michael Scott a ?crit : >> >> Hello, >> >> >> How do I do this? Using the OpenSSL command line tool, a certificate >> request must be self-signed, but the X25519 elliptic curve (newly supported >> in version 1.1.0), doesn't do signature, it can only be used for key >> exchange. >> >> (Of course the X25519 Montgomery curve is birationally equivalent to an >> Edwards curve which can do signature. And indeed it is our intention to use >> the Edwards curve. But first I need a CA-signed X25519 cert. But because of >> the above catch-22 problem, I cannot create one.) >> >> >> Mike >> >> >> -- >> 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 >> >> > -- > 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 jb-openssl at wisemo.com Thu Jun 30 14:58:02 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 30 Jun 2016 16:58:02 +0200 Subject: [openssl-users] Creating an X25519-based Certificate In-Reply-To: <1E082092-B0C9-4B6B-96CC-E4481039FD6F@docusign.com> References: <3B854BA7-2662-4FA9-BA24-B062D75CBD3E@docusign.com> <1E082092-B0C9-4B6B-96CC-E4481039FD6F@docusign.com> Message-ID: <2b056f70-5713-1ba3-3338-5fc8eed5599f@wisemo.com> Which brings back my generalized question from yesterday: Since X25519 is not the first "encrypt-only" algorithm in the OpenSSL universe, how was requesting certificates handled for such algorithms in the past? For example how would one request a DH certificate? Whatever was defined back then might be trivially extended to also handle X25519. On 30/06/2016 10:37, Erwann Abalea wrote: > Ok, you?re talking about OpenSSL command line tool only, I missed that > part. > > The solution should then be to modify apps/ca.c:certify() function to > add an arg, and avoid the call to X509_REQ_verify when desired. > >> Le 29 juin 2016 ? 19:17, Michael Scott > > a ?crit : >> >> Thanks Erwann, but that's not an answer to my question. >> >> To get the CA to sign (using RSA or anything) a certificate that >> contains an X25519 public key, that certificate must first submit to >> the CA something called a "Certificate request". This takes the form >> of the supplicant certificate, which is self-signed. However you >> cannot self-sign with an X25519 key (using the openssl command line >> tool), as it objects that X25519 does not support signature. >> >> So the issue arises around the "certificate request" process. There >> is I agree no problem in creating the certificate itself. >> >> On Wed, Jun 29, 2016 at 4:27 PM, Erwann Abalea >> > wrote: >> >> Bonjour, >> >> You may have a classic certificate containing your >> {X,Ed}{25519,448,whatever} public key once: >> >> * an OID is allocated to identify this type of public key (it >> will go into tbs.subjectPublicKeyInfo.algorithm.algorithm) >> * a set of associated optional parameters are defined for this >> OID (to go into tbs.subjectPublicKeyInfo.algorithm.parameters) >> * a canonical encoding for this type of public key is defined, >> so the key material can be enclosed into >> tbs.subjectPublicKeyInfo.subjectPublicKey >> >> >> This certificate may be RSA-signed or ECDSA-signed (or >> whatever-signed, in fact). >> >> For a CA to be able to Ed{25519,448,whatever}-sign something, the >> previous steps must have been done, plus: >> >> * an OID is allocated to identify the signature algorithm to >> apply (it will not be ECDSA) -> cert.signatureAlgorithm.algorithm >> * a set of associated optional parameters are defined for this >> OID -> cert.signatureAlgorithm.parameters >> * a canonical encoding for the signature value is defined, so >> it can be enclosed into cert.signatureValue >> >> >> All this is being discussed at CFRG. >> >>> Le 29 juin 2016 ? 16:46, Michael Scott >> > a ?crit : >>> >>> How do I do this? Using the OpenSSL command line tool, a >>> certificate request must be self-signed, but the X25519 elliptic >>> curve (newly supported in version 1.1.0), doesn't do signature, >>> it can only be used for key exchange. >>> >>> (Of course the X25519 Montgomery curve is birationally >>> equivalent to an Edwards curve which can do signature. And >>> indeed it is our intention to use the Edwards curve. But first I >>> need a CA-signed X25519 cert. But because of the above catch-22 >>> problem, I cannot create one.) >>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Jun 30 15:54:52 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 30 Jun 2016 15:54:52 +0000 Subject: [openssl-users] Creating an X25519-based Certificate In-Reply-To: <2b056f70-5713-1ba3-3338-5fc8eed5599f@wisemo.com> References: <3B854BA7-2662-4FA9-BA24-B062D75CBD3E@docusign.com> <1E082092-B0C9-4B6B-96CC-E4481039FD6F@docusign.com> <2b056f70-5713-1ba3-3338-5fc8eed5599f@wisemo.com> Message-ID: <02a5b1018db84181998cebfcf3e98d9a@usma1ex-dag1mb1.msg.corp.akamai.com> > Since X25519 is not the first "encrypt-only" algorithm in the > OpenSSL universe, how was requesting certificates handled for > such algorithms in the past? It wasn't. > For example how would one request a DH certificate? You couldn't. I don't recall anyone ever asking for such a thing on the public lists. From matt at openssl.org Thu Jun 30 16:11:58 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 30 Jun 2016 17:11:58 +0100 Subject: [openssl-users] Creating an X25519-based Certificate In-Reply-To: <02a5b1018db84181998cebfcf3e98d9a@usma1ex-dag1mb1.msg.corp.akamai.com> References: <3B854BA7-2662-4FA9-BA24-B062D75CBD3E@docusign.com> <1E082092-B0C9-4B6B-96CC-E4481039FD6F@docusign.com> <2b056f70-5713-1ba3-3338-5fc8eed5599f@wisemo.com> <02a5b1018db84181998cebfcf3e98d9a@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <577544CE.2040707@openssl.org> On 30/06/16 16:54, Salz, Rich wrote: >> Since X25519 is not the first "encrypt-only" algorithm in the >> OpenSSL universe, how was requesting certificates handled for >> such algorithms in the past? > > It wasn't. > >> For example how would one request a DH certificate? > > You couldn't. > > I don't recall anyone ever asking for such a thing on the public lists. > There is no standardised way of requesting a DH certificate that I know of. Nonetheless OpenSSL does support the generation of DH certificates, but it's a bit nasty: https://security.stackexchange.com/questions/44251/openssl-generate-different-types-of-self-signed-certificate/82868#82868 Matt From mike.scott at miracl.com Thu Jun 30 17:12:32 2016 From: mike.scott at miracl.com (Michael Scott) Date: Thu, 30 Jun 2016 18:12:32 +0100 Subject: [openssl-users] Creating an X25519-based Certificate In-Reply-To: <577544CE.2040707@openssl.org> References: <3B854BA7-2662-4FA9-BA24-B062D75CBD3E@docusign.com> <1E082092-B0C9-4B6B-96CC-E4481039FD6F@docusign.com> <2b056f70-5713-1ba3-3338-5fc8eed5599f@wisemo.com> <02a5b1018db84181998cebfcf3e98d9a@usma1ex-dag1mb1.msg.corp.akamai.com> <577544CE.2040707@openssl.org> Message-ID: On Thu, Jun 30, 2016 at 5:11 PM, Matt Caswell wrote: > > > On 30/06/16 16:54, Salz, Rich wrote: > >> Since X25519 is not the first "encrypt-only" algorithm in the > >> OpenSSL universe, how was requesting certificates handled for > >> such algorithms in the past? > > > > It wasn't. > > > >> For example how would one request a DH certificate? > > > > You couldn't. > > > > I don't recall anyone ever asking for such a thing on the public lists. > > > > There is no standardised way of requesting a DH certificate that I know of. > > Nonetheless OpenSSL does support the generation of DH certificates, but > it's a bit nasty: > > > https://security.stackexchange.com/questions/44251/openssl-generate-different-types-of-self-signed-certificate/82868#82868 > > That seems to be exactly what I was looking for! So create a bogus RSA cert and create its self-signed certificate request. But then use the -force_pubkey flag to substitute my own X25519 public key for the RSA public key, just prior to getting it signed by the CA. Reminds me of the cuckoo.. I would worry about the damage that could be done if -force_pubkey fell into the wrong hands :) Thanks! Mike > Matt > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Thu Jun 30 19:00:14 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 30 Jun 2016 19:00:14 +0000 Subject: [openssl-users] OpenSSL s_time output meaning In-Reply-To: <1467176234459-67092.post@n7.nabble.com> References: <1467176234459-67092.post@n7.nabble.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of danigrosu > Sent: Tuesday, June 28, 2016 22:57 > To: openssl-users at openssl.org > Subject: [openssl-users] OpenSSL s_time output meaning > > Using the `$ openssl s_time -connect localhost:443 -new -time 30` command > gives this output: > > No CIPHER specified > Collecting connection statistics for 30 seconds > ********** etc. > 8102 connections in 12.65s; 640.47 connections/user sec, bytes read 0 > 8102 connections in 31 real seconds, 0 bytes read per connection > > What is the difference between 8102 connections in 12.65s and 8102 > connections in 31 real seconds ? Use the source, Luke. Yes, the output is confusing; "real seconds" is not a particularly meaningful term. (What, the imaginary part is zero?) The value that's displayed there is the "wall-clock time" elapsed between the start of the test and when the report is produced. It's the sum of the time specified by -time (or the 30s default) plus the overhead that's not counted while timing actual OpenSSL operations, rounded to 1-second granularity. The 12.65s in the first line is the value of "totalTime", which is the accumulator for the timer the openssl command uses for timing the test. The s_time command starts this timer before the connection loop and stops it after the loop. The timer (in this case) counts only "user" time, that is time the process spends in user mode; that's why that line says "user sec". So this is telling you that your system uses about 1.5ms of user-mode CPU time per connection, and that it was able to make about 270 connections per second. I'm not sure what use that information might be to you, since you haven't told us why you're running s_time in the first place. -- Michael Wojcik Technology Specialist, Micro Focus From Erwann.Abalea at docusign.com Thu Jun 30 19:29:01 2016 From: Erwann.Abalea at docusign.com (Erwann Abalea) Date: Thu, 30 Jun 2016 19:29:01 +0000 Subject: [openssl-users] Creating an X25519-based Certificate In-Reply-To: <2b056f70-5713-1ba3-3338-5fc8eed5599f@wisemo.com> References: <3B854BA7-2662-4FA9-BA24-B062D75CBD3E@docusign.com> <1E082092-B0C9-4B6B-96CC-E4481039FD6F@docusign.com> <2b056f70-5713-1ba3-3338-5fc8eed5599f@wisemo.com> Message-ID: <391A64B7-0106-4526-B868-ED9950CD93D4@docusign.com> Maybe we just didn?t. At least not with the command line tools. The CHANGES file lists a merge between ? dh ?, ? gendh ?, and ? dhparam ? in 2000, but no evolution since then. The oldest version I could find is 0.9.6, and there?s no command-line DH key generation. Cordialement, Erwann Abalea Le 30 juin 2016 ? 16:58, Jakob Bohm > a ?crit : Which brings back my generalized question from yesterday: Since X25519 is not the first "encrypt-only" algorithm in the OpenSSL universe, how was requesting certificates handled for such algorithms in the past? For example how would one request a DH certificate? Whatever was defined back then might be trivially extended to also handle X25519. On 30/06/2016 10:37, Erwann Abalea wrote: Ok, you?re talking about OpenSSL command line tool only, I missed that part. The solution should then be to modify apps/ca.c:certify() function to add an arg, and avoid the call to X509_REQ_verify when desired. Le 29 juin 2016 ? 19:17, Michael Scott <mike.scott at miracl.com> a ?crit : Thanks Erwann, but that's not an answer to my question. To get the CA to sign (using RSA or anything) a certificate that contains an X25519 public key, that certificate must first submit to the CA something called a "Certificate request". This takes the form of the supplicant certificate, which is self-signed. However you cannot self-sign with an X25519 key (using the openssl command line tool), as it objects that X25519 does not support signature. So the issue arises around the "certificate request" process. There is I agree no problem in creating the certificate itself. On Wed, Jun 29, 2016 at 4:27 PM, Erwann Abalea > wrote: Bonjour, You may have a classic certificate containing your {X,Ed}{25519,448,whatever} public key once: * an OID is allocated to identify this type of public key (it will go into tbs.subjectPublicKeyInfo.algorithm.algorithm) * a set of associated optional parameters are defined for this OID (to go into tbs.subjectPublicKeyInfo.algorithm.parameters) * a canonical encoding for this type of public key is defined, so the key material can be enclosed into tbs.subjectPublicKeyInfo.subjectPublicKey This certificate may be RSA-signed or ECDSA-signed (or whatever-signed, in fact). For a CA to be able to Ed{25519,448,whatever}-sign something, the previous steps must have been done, plus: * an OID is allocated to identify the signature algorithm to apply (it will not be ECDSA) -> cert.signatureAlgorithm.algorithm * a set of associated optional parameters are defined for this OID -> cert.signatureAlgorithm.parameters * a canonical encoding for the signature value is defined, so it can be enclosed into cert.signatureValue All this is being discussed at CFRG. Le 29 juin 2016 ? 16:46, Michael Scott <mike.scott at miracl.com> a ?crit : How do I do this? Using the OpenSSL command line tool, a certificate request must be self-signed, but the X25519 elliptic curve (newly supported in version 1.1.0), doesn't do signature, it can only be used for key exchange. (Of course the X25519 Montgomery curve is birationally equivalent to an Edwards curve which can do signature. And indeed it is our intention to use the Edwards curve. But first I need a CA-signed X25519 cert. But because of the above catch-22 problem, I cannot create one.) 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 cheyendal at fortinet.com Thu Jun 30 19:34:58 2016 From: cheyendal at fortinet.com (Carl Heyendal) Date: Thu, 30 Jun 2016 19:34:58 +0000 Subject: [openssl-users] self-signed certificate won't work in my app but works with s_client Message-ID: I am working with the example apps in the "Networking Security with OpenSSL" book and up until now have been able to get client/server examples 1,2,3 to work. But now I'm trying to connect to an in-house tool but I'm getting the error "error 18:self signed certificate". Despite this error when I run my app (essentially client3), when I use s_client with the very same credentials...it works. I suspect that it has something to do with the ssl/tls api combination that I use in my 'client3' app. Here's the command and output for s_client that connects to the in-house tool which works: > openssl s_client -connect 192.168.1.99:16001 -CAfile ../_security/SipInspector/certificate.pem -key ../_security/client.pem Enter pass phrase for ../_security/client.pem: CONNECTED(00000003) depth=0 C = CA, ST = Ontario, L = Ottawa, O = SIP Inspector Ltd, OU = Development, CN = 192.168.1.99 verify return:1 --- Certificate chain 0 s:/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector Ltd/OU=Development/CN=192.168.1.99 i:/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector Ltd/OU=Development/CN=192.168.1.99 --- Server certificate -----BEGIN CERTIFICATE----- MIIFxTCCA62gAwIBAgIJALKQ3J5SEyjPMA0GCSqGSIb3DQEBCwUAMHkxCzAJBgNV BAYTAkNBMRAwDgYDVQQIDAdPbnRhcmlvMQ8wDQYDVQQHDAZPdHRhd2ExGjAYBgNV (snip) pt/q5/gKqRFbjyL0LDNz49vaSUYvbu3mgF2480Or4X+GPwemwdxJaF1pQw4C1WaF RyfVjDrLNhTvv+zKCbEPyrjXCweNVRVcp8lZ8R0HmXwfgevlCNz/GQo= -----END CERTIFICATE----- subject=/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector Ltd/OU=Development/CN=192.168.1.99 issuer=/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector Ltd/OU=Development/CN=192.168.1.99 --- No client certificate CA names sent --- SSL handshake has read 2309 bytes and written 509 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-DES-CBC3-SHA Server public key is 4096 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-DES-CBC3-SHA Session-ID: 5755C781D91CF3177DF624EA3599EE430DAB4790F325FAD9378FEAE7731C4497 Session-ID-ctx: Master-Key: D149008E43E29D658D29418C9F770B3D6018B1D7CA2F493027B0AC7C3BA8E53B572B68C371153568B8988A1E5F351839 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1465239425 Timeout : 300 (sec) Verify return code: 0 (ok) --- Here's the command and output when I run my app that tries to connect to the same in-house tool which fails: > ./client3 192.168.1.99 Enter PEM pass phrase: connecting to 192.168.1.99:16001 -Error with certificate at depth: 0 issuer = /C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector Ltd/OU=Development /CN=192.168.1.99 subject = /C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector Ltd/OU=Development/CN=192.168.1.99 err 18:self signed certificate ** client3.c:94 Error connecting SSL object 139788992993088:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:1180: > Here are the api's I call in the my app that utilize the same credentials used by the s_client command: SSL_CTX_new(SSLv23_method()); SSL_CTX_load_verify_locations(ctx, "../_security/SipInspector/certificate.pem", NULL) SSL_CTX_use_PrivateKey_file(ctx, "../_security/client.pem", SSL_FILETYPE_PEM) SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback); SSL_CTX_set_verify_depth(ctx, 4); SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2); And also I used the openssl verify command to double check the certificate against itself (not sure if this really does anything). Any help would be appreciated. Carl Heyendal | Software Developer 1826 Robertson Road | Ottawa, ON K2H 5Z6 | CANADA Office: +1 613-725-2980 x149 *** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***