From jb-openssl at wisemo.com Fri Oct 2 14:08:06 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 2 Oct 2015 16:08:06 +0200 Subject: [openssl-users] Strictness of comparing distinguished names Message-ID: <560E8FC6.1060009@wisemo.com> Dear list, I have encountered a behavior difference between the CMS routines in OpenSSL and the equivalent functionality in another CMS implementation, and I wonder which is the correct behavior. I was examining a CMS signature made by someone else and found that some implementations accepted it as valid while others said it was not valid. In this particular CMS signature, the distinguished name of the certificate issuer is encoded slightly differently in the certificate and in the PKCS#7 SignerInfo structure. Specifically, one element of the name is tagged as a T61STRING in the actual certificate, but as a UTF8STRING in the SignerInfo.issuerAndSerialNumber.issuer field. This name element is actually pure 7 bit printable ASCII (letters and underscores) in this particular case, so the two encodings have the same length and the same content- bytes, only different tag bytes. I found that openssl accepts this difference, while at least one Java version does not. So I am wondering what the officially correct behavior is when verifying such a case. Should the SignerInfo.issuerAndSerialNumber.issuer be treated as matching or as not matching a certificate in which an otherwise identical string is tagged differently but represents the same textual value (because it uses only the common subset of the two string encodings)? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Fri Oct 2 14:20:54 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 2 Oct 2015 10:20:54 -0400 Subject: [openssl-users] Strictness of comparing distinguished names In-Reply-To: <560E8FC6.1060009@wisemo.com> References: <560E8FC6.1060009@wisemo.com> Message-ID: > So I am wondering what the officially correct behavior is > when verifying such a case. Should the > SignerInfo.issuerAndSerialNumber.issuer be treated as > matching or as not matching a certificate in which an > otherwise identical string is tagged differently but > represents the same textual value (because it uses only > the common subset of the two string encodings)? DN's are required to be encoded with UTF8String since RFC 3280 (circa 2004). RFC 4158, Certification Path Building, tells us some agents may not handle encodings well, like BMPString. I think you may have found a few examples. Jeff From jb-openssl at wisemo.com Fri Oct 2 14:56:13 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 2 Oct 2015 16:56:13 +0200 Subject: [openssl-users] Strictness of comparing distinguished names In-Reply-To: References: <560E8FC6.1060009@wisemo.com> Message-ID: <560E9B0D.8020403@wisemo.com> On 02/10/2015 16:20, Jeffrey Walton wrote: >> So I am wondering what the officially correct behavior is >> when verifying such a case. Should the >> SignerInfo.issuerAndSerialNumber.issuer be treated as >> matching or as not matching a certificate in which an >> otherwise identical string is tagged differently but >> represents the same textual value (because it uses only >> the common subset of the two string encodings)? > DN's are required to be encoded with UTF8String since RFC 3280 (circa 2004). > > RFC 4158, > > Certification Path Building, tells us some agents may not handle > encodings well, like BMPString. I think you may have found a few > examples. Detailed testing (before my post) showed that both implementations handle both encodings on their own, and that neither implementation is restricted to the PKIX subset in this regard. Thus the issue is this: Suppose an actual, trusted CA certificate (and thus all the certificates issued under it) encodes an element of the CA distinguished name using the T61STRING type permitted by the original ITU standards. An end-entity holding such an issued certificate then uses a signing tool which "canonicalizes" the issuer name to its PKIX UTF8STRING equivalent before outputting the SignerInfo.issuerAndSerialNumber.issuer element of the signature. Now the question is who is at fault here: - CMS implementations that refuse to accept the signature because a part of the SignerInfo.issuerAndSerialNumber.issuer value uses a different option from the relevant ASN.1 CHOICE, thus causing its purely DER-normalized form to be binary different from the purely DER-normalized form of the same distinguished name found during certificate chain building. - The signing tool that changed this aspect of the distinguished name when generating the signature. At least one of the tools involved is buggy, question is which one. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From mail.mthakkar at gmail.com Sat Oct 3 13:31:50 2015 From: mail.mthakkar at gmail.com (Mitesh Thakkar) Date: Sat, 3 Oct 2015 19:01:50 +0530 Subject: [openssl-users] SSL_R_UNABLE_TO_LOAD_SSL2_MD5_ROUTINES Message-ID: Hello, I am using libcsoap in C language to make web service call to HTTPS url. libcsoap uses nanohttp to connect to openssl. All above was working well in CentOS version less then 7. In CentOS 7, it is not working and behaving as below: In the first try of connection it is working well and gets response from web service. In the second try onwards it gives error - SSL_R_UNABLE_TO_LOAD_SSL2_MD5_ROUTINES all the time. If I restart whole my application then again it works once and then again second time onward above error. Here is the version information: #rpm -qa|grep openssl openssl-libs-1.0.1e-42.el7.9.x86_64 openssl-debuginfo-1.0.1e-42.el7.9.x86_64 openssl-1.0.1e-42.el7.9.x86_64 openssl-devel-1.0.1e-42.el7.9.x86_64 Please Advise. - Mitesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sat Oct 3 16:08:03 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 3 Oct 2015 16:08:03 +0000 Subject: [openssl-users] SSL_R_UNABLE_TO_LOAD_SSL2_MD5_ROUTINES In-Reply-To: References: Message-ID: <20151003160802.GT18165@mournblade.imrryr.org> On Sat, Oct 03, 2015 at 07:01:50PM +0530, Mitesh Thakkar wrote: > In the first try of connection it is working well and gets response from > web service. In the second try onwards it gives error - > SSL_R_UNABLE_TO_LOAD_SSL2_MD5_ROUTINES > all the time. Something ran OpenSSL library cleanup after the first call and deregistered all the digests. If it is not your application, then it the library that uses OpenSSL on your behalf. The failure is in SSL_CTX_new(), which should typically be done just once, and re-used for a second connection. Clearly you're calling it again, and this type with the OpenSSL library already "finalized". -- Viktor. From yan at seiner.com Sun Oct 4 11:03:50 2015 From: yan at seiner.com (Yan Seiner) Date: Sun, 04 Oct 2015 07:03:50 -0400 Subject: [openssl-users] Verifying a certificate chain Message-ID: <56110796.40004@seiner.com> I am trying to figure out what I have done wrong. I have a certificate from PositiveSSL for my email server. I have the root certificate and the intermediate certs installed in /etc/ssl/certs/. However, I still cannot verify my certificate. I can't figure out what I have done wrong. I've been wrestling with this for a long time, and I am out of ideas. I am not that familiar with ssl certs - they usually "just work". This one, however, is kicking my butt. an at yan-ThinkPad-W530:~$ openssl s_client -connect mail.seiner.com:587 -starttls smtp CONNECTED(00000003) depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = mail.seiner.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = mail.seiner.com verify error:num=27:certificate not trusted verify return:1 depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = mail.seiner.com verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=mail.seiner.com i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA --- Server certificate -----BEGIN CERTIFICATE----- MIIFUTCCBDmgAwIBAgIQQZM9mOpCf6BQO3apU1Xk4jANBgkqhkiG9w0BAQsFADCB kDELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxNjA0BgNV BAMTLUNPTU9ETyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBD QTAeFw0xNTEwMDEwMDAwMDBaFw0xODEwMjYyMzU5NTlaMFMxITAfBgNVBAsTGERv bWFpbiBDb250cm9sIFZhbGlkYXRlZDEUMBIGA1UECxMLUG9zaXRpdmVTU0wxGDAW BgNVBAMTD21haWwuc2VpbmVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAKzE7KEEg4I5zIkNa9PzNvDXJLJ0jFb+BXrC80CP0WgcnzDk4+M2tp9I WK3h8zHVAMj4mIUbzZYYYys0J5WyjlGclk6bPnYcuCyhyZkeevq3ZkIEbNPNlO2K ao0K9kjuLZomIPVaXsp2xtHuWU6u/Sz+XXIvlTaLuLxM6p74Z8R7DyM3iMa3/8XN 1OT624BKq6xFCas1gMPjAsLrCltDAkQIAT3pute2IsnoL082HSL0Lz8IEPELvwX0 eEmJrkB9mKvk6OoQApaZT1nZlUKtP/xfQSRt8dajR+IJWBkTG8zcWPwgReWgW5nZ 3hT07SKvYsCQO0LU6lxsQmn4UwH74GMCAwEAAaOCAeEwggHdMB8GA1UdIwQYMBaA FJCvajqUWgvYkOoSVnPfQ7Q6KNrnMB0GA1UdDgQWBBS7eRbyTVxk3hndQRXlC46K ExFddDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggr BgEFBQcDAQYIKwYBBQUHAwIwTwYDVR0gBEgwRjA6BgsrBgEEAbIxAQICBzArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8uY29tL0NQUzAIBgZngQwB AgEwVAYDVR0fBE0wSzBJoEegRYZDaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09N T0RPUlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNybDCBhQYIKwYB BQUHAQEEeTB3ME8GCCsGAQUFBzAChkNodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9D T01PRE9SU0FEb21haW5WYWxpZGF0aW9uU2VjdXJlU2VydmVyQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wLwYDVR0RBCgwJoIPbWFp bC5zZWluZXIuY29tghN3d3cubWFpbC5zZWluZXIuY29tMA0GCSqGSIb3DQEBCwUA A4IBAQAWAEcGiQmPdeaFvK+oGumzeecVdmXYbYfuQ71kFrlmH+O/Ju9beKcF+D4D ZiybDREpzG9p3u2sCVhExttL1QL4tJejMnsIupnzNtWcFZfVt4c8Sf0ed8Q+DL91 vTjrBQ5t2sRVzqfMYv+VC/TCK/5bQwcGwfKRKP7JNwBSz3/QBN6UhJfaiN6gzMSQ s7Mn6Et4xrkiyeJIrxEgkdiStccH9EDZP9ZSY9SEd4xLHopKF9Mvkt/2Wrkmv4Az Kn+zccB8XDaceNgAw3AMwg4bLLK5u9T96cKQ3Eo4E1yvdVMmHNeP5t/Teb0xoTsT hAol+K8Jw30Oi3rLOYHiug5InS6m -----END CERTIFICATE----- subject=/OU=Domain Control Validated/OU=PositiveSSL/CN=mail.seiner.com issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA --- No client certificate CA names sent --- SSL handshake has read 3057 bytes and written 698 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : DHE-RSA-AES256-SHA256 Session-ID: E685C52BC4BB67DA59B0CB7B5EF99D3CD64A70C7209E2D7AFF964B0671CA7878 Session-ID-ctx: Master-Key: 04DE100CFDE53A47F9220EEDE393F026680F0543309EA1CD327B2AB088AB8529D6C2E2FB68223308E84EB3F07BCBBD2D Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1443956465 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- 250 HELP From yan at seiner.com Sun Oct 4 11:58:42 2015 From: yan at seiner.com (Yan Seiner) Date: Sun, 04 Oct 2015 07:58:42 -0400 Subject: [openssl-users] Verifying a certificate chain In-Reply-To: <56110796.40004@seiner.com> References: <56110796.40004@seiner.com> Message-ID: <56111472.8040908@seiner.com> On 10/04/2015 07:03 AM, Yan Seiner wrote: > I am trying to figure out what I have done wrong. > > I have a certificate from PositiveSSL for my email server. I have the > root certificate and the intermediate certs installed in /etc/ssl/certs/. > > However, I still cannot verify my certificate. I can't figure out > what I have done wrong. I've been wrestling with this for a long > time, and I am out of ideas. > > I am not that familiar with ssl certs - they usually "just work". This > one, however, is kicking my butt. Never mind. I tried one more thing and it worked. I concatenated my cert onto the bundle and used that. cat mail_seiner_com.pem PositiveSSL.pem > mail_seiner_com_bundle.pem I'm not sure why neither exim4 nor dovecot would accept my cert and then a ca cert but rather wanted them all in one bundle. It now validates correctly. yan at yan-ThinkPad-W530:~$ openssl s_client -connect mail.seiner.com:587 -starttls smtp -CApath /etc/ssl/certs CONNECTED(00000003) depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root verify return:1 depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority verify return:1 depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA verify return:1 depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = mail.seiner.com verify return:1 --- Certificate chain 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=mail.seiner.com i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root --- Server certificate -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- subject=/OU=Domain Control Validated/OU=PositiveSSL/CN=mail.seiner.com issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA --- No client certificate CA names sent --- SSL handshake has read 6936 bytes and written 698 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : DHE-RSA-AES256-SHA256 Session-ID: 30ADE9920D1BD0EC207BC77EBDA03D44AC6EA22658A1FEF788061C5B3C14FB73 Session-ID-ctx: Master-Key: F9AFA07FD0D81D0ED1F3265F126844345251BBB221AF0BE22204B7469AF5B4783129255AB04525743906A598E3582C0E Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1443959631 Timeout : 300 (sec) Verify return code: 0 (ok) --- 250 HELP From openssl-users at dukhovni.org Sun Oct 4 15:22:57 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 4 Oct 2015 15:22:57 +0000 Subject: [openssl-users] Verifying a certificate chain In-Reply-To: <56111472.8040908@seiner.com> References: <56110796.40004@seiner.com> <56111472.8040908@seiner.com> Message-ID: <20151004152256.GX18165@mournblade.imrryr.org> On Sun, Oct 04, 2015 at 07:58:42AM -0400, Yan Seiner wrote: > >I have a certificate from PositiveSSL for my email server. I have the > >root certificate and the intermediate certs installed in /etc/ssl/certs/. man c_rehash > >However, I still cannot verify my certificate. I can't figure out what I > >have done wrong. I've been wrestling with this for a long time, and I am > >out of ideas. > > > >I am not that familiar with ssl certs - they usually "just work". This > >one, however, is kicking my butt. > Never mind. I tried one more thing and it worked. > > I concatenated my cert onto the bundle and used that. > > cat mail_seiner_com.pem PositiveSSL.pem > mail_seiner_com_bundle.pem > > I'm not sure why neither exim4 nor dovecot would accept my cert and then a > ca cert but rather wanted them all in one bundle. > > It now validates correctly. > > yan at yan-ThinkPad-W530:~$ openssl s_client -connect mail.seiner.com:587 > -starttls smtp -CApath /etc/ssl/certs It is also possible that your MSA does not load "missing" certificates from the default store. -- Viktor. From rashid_m180 at yahoo.com Mon Oct 5 11:02:37 2015 From: rashid_m180 at yahoo.com (Rashid Mahmood) Date: Mon, 5 Oct 2015 11:02:37 +0000 (UTC) Subject: [openssl-users] OpenSSL Client mode: Rejecting weak DH parameters Message-ID: <892104896.525994.1444042957981.JavaMail.yahoo@mail.yahoo.com> Hi, Currently OpenSSL in Client mode stops handshake only if the keylength of?Server?selected DH parameters is less than 768 bit (hardcoded in source). Is there any way to set the minimum key length usingpublic APIs? In my client i want to stop handshake if the keylength of?Server?selected DH parameters is less than 2048bit. Preferred way would be to set via API e.g. Option setting exposed by OpenSSL. Kind Regards, Rashid Mahmood -------------- next part -------------- An HTML attachment was scrubbed... URL: From walter.h at mathemainzel.info Mon Oct 5 11:58:15 2015 From: walter.h at mathemainzel.info (Walter H.) Date: Mon, 5 Oct 2015 13:58:15 +0200 Subject: [openssl-users] Problem checking certificate with OCSP Message-ID: Hello, attached is the certificate and its chain of https://revoked.grc.com/ doing this: openssl ocsp -no_nonce -issuer chain.pem -cert cert.pem -text -url http://ocsp2.globalsign.com/gsdomainvalg2 goves the following: OCSP Request Data: Version: 1 (0x0) Requestor List: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: 45658DA20174402FF48B3A6AC0BC69208095C7CA Issuer Key Hash: 96ADFAB05BB983642A76C21C8A69DA42DCFEFD28 Serial Number: 112155688D380775DA34C5DF97433ED3F6A7 Error querying OCSP responsder 139928584042312:error:27076072:OCSP routines:PARSE_HTTP_LINE1:server response error:ocsp_ht.c:250:Code=403,Reason=Forbidden where is the problem for this strange error? I'm running CentOS 6.7 64-bit, and OpenSSL is the latest provided update from repository; Thanks; Greetings, Walter -------------- next part -------------- A non-text attachment was scrubbed... Name: cert.pem Type: application/octet-stream Size: 1798 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chain.pem Type: application/octet-stream Size: 2878 bytes Desc: not available URL: From steve at openssl.org Mon Oct 5 15:11:01 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 5 Oct 2015 15:11:01 +0000 Subject: [openssl-users] Problem checking certificate with OCSP In-Reply-To: References: Message-ID: <20151005151101.GA12587@openssl.org> On Mon, Oct 05, 2015, Walter H. wrote: > Hello, > > attached is the certificate and its chain of https://revoked.grc.com/ > > doing this: > > openssl ocsp -no_nonce -issuer chain.pem -cert cert.pem -text -url > http://ocsp2.globalsign.com/gsdomainvalg2 > > goves the following: > > OCSP Request Data: > Version: 1 (0x0) > Requestor List: > Certificate ID: > Hash Algorithm: sha1 > Issuer Name Hash: 45658DA20174402FF48B3A6AC0BC69208095C7CA > Issuer Key Hash: 96ADFAB05BB983642A76C21C8A69DA42DCFEFD28 > Serial Number: 112155688D380775DA34C5DF97433ED3F6A7 > Error querying OCSP responsder > 139928584042312:error:27076072:OCSP routines:PARSE_HTTP_LINE1:server response > error:ocsp_ht.c:250:Code=403,Reason=Forbidden > > where is the problem for this strange error? > Some OCSP responders need the host header, try adding: -header Host ocsp2.globalsign.com Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From noloader at gmail.com Mon Oct 5 15:55:36 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 5 Oct 2015 11:55:36 -0400 Subject: [openssl-users] How to enforce DH field size in the client? Message-ID: Hi Everyone, Based on the docs for SSL_CTX_set_tmp_dh_callback(3), the callback is supposed to be invoked for DH parameter selection. The docs also avoid/fail to state its a server only feature, so its not clear to me if the client is able to use it. Its appears SSL_CTX_set_tmp_dh_callback and/or SSL_set_tmp_dh_callback are not invoked at the client when the temporary pubic key is selected, so there does not appear to be a way to query the field size and fail the connection. ARe clients supposed to be informed of DH parameter selection via SSL_CTX_set_tmp_dh_callback and/or SSL_set_tmp_dh_callback? Or is there another method available? At the client, how do we enforce minimum Diffie-Hellman field sizes? Jeff From openssl-users at dukhovni.org Mon Oct 5 18:46:52 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 5 Oct 2015 18:46:52 +0000 Subject: [openssl-users] How to enforce DH field size in the client? In-Reply-To: References: Message-ID: <20151005184651.GJ15070@mournblade.imrryr.org> On Mon, Oct 05, 2015 at 11:55:36AM -0400, Jeffrey Walton wrote: > Based on the docs for SSL_CTX_set_tmp_dh_callback(3), the callback is > supposed to be invoked for DH parameter selection. The docs also > avoid/fail to state its a server only feature, so its not clear to me > if the client is able to use it. This is a server-only interface. > Its appears SSL_CTX_set_tmp_dh_callback and/or SSL_set_tmp_dh_callback > are not invoked at the client when the temporary pubic key is > selected, so there does not appear to be a way to query the field size > and fail the connection. Not via this interface. > Are clients supposed to be informed of DH parameter selection via > SSL_CTX_set_tmp_dh_callback and/or SSL_set_tmp_dh_callback? No. > At the client, how do we enforce minimum Diffie-Hellman field sizes? This should be possible via configuration, not just explicit API calls from applications that go to the extra trouble. Some work in that direction is in the master branch (future 1.1.0). There are ways to determine the server handshake group size, but this is not a good long-term interface for applications. See the new (1.0.2) SSL_get_server_tmp_key() function in commit: 2001129f096d10bbd815936d23af3e97daf7882d and how it is used in that commit. -- Viktor. From alanchee_89 at msn.com Wed Oct 7 07:10:07 2015 From: alanchee_89 at msn.com (Alan Chee) Date: Wed, 7 Oct 2015 15:10:07 +0800 Subject: [openssl-users] OpenSSL 0.9.6a PRNG algorithm weakness Message-ID: Hi, I saw an advisory on exploiting a PRNG weakness in OpenSSL versions up to 0.9.6a by using several short PRNG requests. It looks interesting. Do you have any idea for the details of the attacking technique? Thanks in advance! Regards,Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From KThirumal at inautix.co.in Wed Oct 7 13:54:40 2015 From: KThirumal at inautix.co.in (Thirumal, Karthikeyan) Date: Wed, 7 Oct 2015 13:54:40 +0000 Subject: [openssl-users] [openssl-dev] Elliptical Cipher Suites In-Reply-To: <20151007125558.GA15070@mournblade.imrryr.org> References: <55A0598A7539EC4BAB296D8BBA5AC122BFFC6464@WTPCPMBMEM07.ams.bnymellon.net> <20151007125558.GA15070@mournblade.imrryr.org> Message-ID: <55A0598A7539EC4BAB296D8BBA5AC122BFFC66F0@WTPCPMBMEM07.ams.bnymellon.net> Vik Am using 0.9.8a version. Am trying to fix few weak ciphers in my SSL connection and also to make Elliptical cipher suites enable. I see that ECDHE ciphers are elliptical - need more info on this. Thanks & Regards ________________________ Karthikeyan Thirumal -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: Wednesday, October 07, 2015 6:26 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Elliptical Cipher Suites On Wed, Oct 07, 2015 at 12:14:38PM +0000, Thirumal, Karthikeyan wrote: > Can some one tell me how to enable all the Elliptical Cipher suites ? > Is there a single flag to enable all of the elliptical ciphers ? This question belongs on the openssL-users list, and even there much more detail needs to be provided along with the question. * Compiling OpenSSL or using a precompiled version? * Which version? * Writing a program that use the API, or using the command-line tools? * What motivates this question? What have you tried and what were the results? -- Viktor. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ****************************************************** This message and any files or attachments sent with this message contain confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute, copy or use any part of this email. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return Email. Email transmission cannot be guaranteed to be secure or error-free as information can be intercepted, corrupted, lost, destroyed, late, incomplete or may contain viruses. The sender, therefore, does not accept liability for any errors or omissions in the contents of this message, which arise as a result of email transmission. ****************************************************** From openssl-users at dukhovni.org Wed Oct 7 14:50:33 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 7 Oct 2015 14:50:33 +0000 Subject: [openssl-users] [openssl-dev] Elliptical Cipher Suites In-Reply-To: <55A0598A7539EC4BAB296D8BBA5AC122BFFC66F0@WTPCPMBMEM07.ams.bnymellon.net> References: <55A0598A7539EC4BAB296D8BBA5AC122BFFC6464@WTPCPMBMEM07.ams.bnymellon.net> <20151007125558.GA15070@mournblade.imrryr.org> <55A0598A7539EC4BAB296D8BBA5AC122BFFC66F0@WTPCPMBMEM07.ams.bnymellon.net> Message-ID: <20151007145033.GH15070@mournblade.imrryr.org> On Wed, Oct 07, 2015 at 01:54:40PM +0000, Thirumal, Karthikeyan wrote: > Vik That's not my name. > Am using 0.9.8a version. Am trying to fix few weak ciphers in my SSL > connection and also to make Elliptical cipher suites enable. > I see that ECDHE ciphers are elliptical - need more info on this. ECC is not supported in OpenSSL 0.9.8. You need at least OpenSSL 1.0.0, preferably 1.0.1 or 1.0.2, and 0.9.8 and 1.0.0 are end-of-life rather soon. -- Viktor. From rashid_m180 at yahoo.com Thu Oct 8 08:10:09 2015 From: rashid_m180 at yahoo.com (ramahmoo) Date: Thu, 8 Oct 2015 01:10:09 -0700 (MST) Subject: [openssl-users] How to enforce DH field size in the client? In-Reply-To: <20151005184651.GJ15070@mournblade.imrryr.org> References: <20151005184651.GJ15070@mournblade.imrryr.org> Message-ID: <1444291809294-60480.post@n7.nabble.com> >>This should be possible via configuration, not just explicit API >>calls from applications that go to the extra trouble. How is it possible via configuration? I have seen in s3_clnt.c, openssl check for server dh prime size against a hardcoded value /if ((!SSL_C_IS_EXPORT(s->s3->tmp.new_cipher) && dh_size < 768) || (SSL_C_IS_EXPORT(s->s3->tmp.new_cipher) && dh_size < 512)) { SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM, SSL_R_DH_KEY_TOO_SMALL); goto f_err; } / Why it is not possible to initialize the compared constant key size via some public method? -- View this message in context: http://openssl.6102.n7.nabble.com/How-to-enforce-DH-field-size-in-the-client-tp60442p60480.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From KThirumal at inautix.co.in Thu Oct 8 10:33:59 2015 From: KThirumal at inautix.co.in (Thirumal, Karthikeyan) Date: Thu, 8 Oct 2015 10:33:59 +0000 Subject: [openssl-users] [openssl-dev] Elliptical Cipher Suites In-Reply-To: <20151007145033.GH15070@mournblade.imrryr.org> References: <55A0598A7539EC4BAB296D8BBA5AC122BFFC6464@WTPCPMBMEM07.ams.bnymellon.net> <20151007125558.GA15070@mournblade.imrryr.org> <55A0598A7539EC4BAB296D8BBA5AC122BFFC66F0@WTPCPMBMEM07.ams.bnymellon.net> <20151007145033.GH15070@mournblade.imrryr.org> Message-ID: <55A0598A7539EC4BAB296D8BBA5AC122BFFC819E@WTPCPMBMEM07.ams.bnymellon.net> Thank you - That helps ! Thanks & Regards ________________________ Karthikeyan Thirumal -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: Wednesday, October 07, 2015 8:21 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] [openssl-dev] Elliptical Cipher Suites On Wed, Oct 07, 2015 at 01:54:40PM +0000, Thirumal, Karthikeyan wrote: > Vik That's not my name. > Am using 0.9.8a version. Am trying to fix few weak ciphers in my SSL > connection and also to make Elliptical cipher suites enable. > I see that ECDHE ciphers are elliptical - need more info on this. ECC is not supported in OpenSSL 0.9.8. You need at least OpenSSL 1.0.0, preferably 1.0.1 or 1.0.2, and 0.9.8 and 1.0.0 are end-of-life rather soon. -- Viktor. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ****************************************************** This message and any files or attachments sent with this message contain confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute, copy or use any part of this email. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return Email. Email transmission cannot be guaranteed to be secure or error-free as information can be intercepted, corrupted, lost, destroyed, late, incomplete or may contain viruses. The sender, therefore, does not accept liability for any errors or omissions in the contents of this message, which arise as a result of email transmission. ****************************************************** From Michal.Trojnara at mirt.net Thu Oct 8 14:57:56 2015 From: Michal.Trojnara at mirt.net (Michal Trojnara) Date: Thu, 8 Oct 2015 16:57:56 +0200 Subject: [openssl-users] stunnel 5.24 released Message-ID: <56168474.9000309@mirt.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear Users, I have released version 5.24 of stunnel. The ChangeLog entry: Version 5.24, 2015.10.08, urgency: MEDIUM * New features - Custom CRL verification was replaced with the internal OpenSSL functionality. - *BSD support for "transparent = destination" and client-side "protocol = socks". This feature should work at least on FreeBSD, OpenBSD and OS X. - Added a new "protocolDomain" option for the NTLM authentication (thx to Andreas Botsikas). - Improved compatibility of the NTLM phase 1 message (thx to Andreas Botsikas). - "setuid" and "setgid" options are now also available in service sections. They can be used to set owner and group of the Unix socket specified with "accept". - Added support for the new OpenSSL 1.0.2 SSL options. - Added OPENSSL_NO_EGD support (thx to Bernard Spil). - VC autodetection added to makew32.bat (thx to Andreas Botsikas). * Bugfixes - Fixed the RESOLVE [F0] TOR extension support in SOCKS5. - Fixed the error code reported on the failed bind() requests. - Fixed the sequential log id with the FORK threading. - Restored the missing Microsoft.VC90.CRT.manifest file. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: ab2e5a1034d422951ddad21b572eb7fa8efb4c4ce04bc86536c6845f3d02b07e stunnel-5.24.tar.gz f6c38d51c2708f3eddbad651091bf0b59e4149a1d0c1e3b227b033f126c6dbee stunnel-5.24-installer.exe ed2a2c5f280970bd5f5efcecbc1dbbd06f66efb68102af31c27d33e3beb48bb5 stunnel-5.24-android.zip Best regards, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWFoR0AAoJEC78f/DUFuAU/toP/0xkTZGeUUQwBuT2wWqo0X7K YGPs1y+WJ6ef/E9Ax9xiceWRUcMAtu8POM/BSgNdnCGPEtUXhCcNkD+wyp329Fub dc6cxeK4hE0BlcAzkkTT7t2TSNGIzoBiDp4w0RBDjiRTFWNrf6nBP3SoeZ2zlNAM Ue73sIEdLgdT87Ndwyn2oaP4dKLSlgXHWfeXjBH4x2gjBfWZsmPc6sZ4BMDYU6Zg 7O8rZ3ToBjdd+UxatDLhTva7gxJnMVDACri456Ic0mIqg2eiL+8qlXDoT7mvV3Xo WVGIBwRO7SUY69nx2TUR/fdsoP7ktbcDAX9sdEfHs20WINTuS910wTmKESkLTipB w4iHyCC+nr5B/eOGvzNpf3FmsjVNs1Vh8k3Ly3Ya8DxhgD9IJF5t/K/4NziWh6ZE yvuiOIwKByK+grmdVeRNIqPCxiJ48IdX8C9S3+8ozjaZ8YBLxjftUkENIcLJW3tb QwpXdYTeIh1HUgEvAx0Jxt/K3HAjxlnhyNkJaZEQEh/MeYXkQ62OXXMJ+/XyG5xz tZh0tCIURV87Mup6T4xcA8vmcSgsQLZnJ+GARwFGWQqjAMFOMh4VgCDXKp9bb8q3 u+tRTgQRp9RZyPZw7ehxwnUqOEuSPH7tYmVP85Zbn05GYmoBzQg4qnhAu8Z/AR82 7VE4jPYZWBPIgS5nLZ+s =D7VR -----END PGP SIGNATURE----- From yogeshdorbala at gmail.com Fri Oct 9 05:06:10 2015 From: yogeshdorbala at gmail.com (Sri Yogesh Dorbala) Date: Fri, 9 Oct 2015 10:36:10 +0530 Subject: [openssl-users] AES_KEY and AES_BLOCK_SIZE cannot be resolved Message-ID: Hello, I am facing a weird problem here. I wish to run a C program(works fine using gcc) on android. I have installed ndk for eclipse and have setup the basic things correctly. I have linked openssl library(.so files) to the project. I included "openssl/aes.h" header file. There are no errors shown there. Also, methods such as AES_set_encrypt_key aren't facing any issue but I am getting error at AES_KEY / AES_BLOCK_SIZE saying type/symbol cannot be resolved. How to fix this? Are these defined elsewhere in some other headers? Kindly let me know. Thanks, Yogesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Fri Oct 9 06:15:54 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 9 Oct 2015 08:15:54 +0200 Subject: [openssl-users] AES_KEY and AES_BLOCK_SIZE cannot be resolved In-Reply-To: References: Message-ID: <56175B9A.6090805@wisemo.com> On 09/10/2015 07:06, Sri Yogesh Dorbala wrote: > Hello, > > I am facing a weird problem here. > > I wish to run a C program(works fine using gcc) on android. I have > installed ndk for eclipse and have setup the basic things correctly. I > have linked openssl library(.so files) to the project. > > I included "openssl/aes.h" header file. There are no errors shown > there. Also, methods such as |AES_set_encrypt_key| aren't facing any > issue but I am getting error at |AES_KEY / AES_BLOCK_SIZE| saying > |type/symbol cannot be resolved|. How to fix this? Are these defined > elsewhere in some other headers? Kindly let me know. > General reminders: On Android, the OpenSSL copy included in the OS is not an officially supported Android API, and App developers are generally advised to compiler their own copy. Also, recent versions of Android may or may not have replaced vanilla OpenSSL by Google's modified BoringSSL. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From karel-de-macil at wanadoo.fr Fri Oct 9 10:20:56 2015 From: karel-de-macil at wanadoo.fr (karel-de-macil at wanadoo.fr) Date: Fri, 9 Oct 2015 12:20:56 +0200 (CEST) Subject: [openssl-users] using openssl to validate an external AES program Message-ID: <1345330568.7555.1444386056802.JavaMail.www@wwinf1e11> Hi all, i'm curently trying to use openssl to validate my own aes program. The first thing i'm trying to to is to validate the return of openssl with aes-128-cbc and some entry i have found here : https://tools.ietf.org/html/rfc3602 Case #1: Encrypting 16 bytes (1 block) using AES-CBC with 128-bit key Key : 0x06a9214036b8a15b512e03d534120006 IV : 0x3dafba429d9eb430b422da802c9fac41 Plaintext : "Single block msg" Ciphertext: 0xe353779c1079aeb82708942dbe77181a the command line i launch is the following :~/git/aes/openssl$ od -c clear3.txt 0000000 S i n g l e b l o c k m s g 0000020 openssl enc -nosalt -aes-128-cbc -in clear3.txt -e -out test.enc -K 06a9214036b8a15b512e03d534120006 -iv 3dafba429d9eb430b422da802c9fac41 :~/git/aes/openssl$ od -x test.enc 0000000 53e3 9c77 7910 b8ae 0827 2d94 77be 1a18 0000020 7cb9 5e82 781c 4651 2d54 6939 bc41 5de5 0000040 The first 16 bit are the answer given but what are the 16 following one ? bellow that, my own program is AES-128 , not aes-128-cbc but for a msg of 16 bit only and a nul iv there should be no difference for what i understand. but when i use the following number found here : http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf PLAINTEXT: 00112233445566778899aabbccddeeff KEY: 000102030405060708090a0b0c0d0e0f round[10].output 69c4e0d86a7b0430d8cdb78070b4c55a i get the following :~/git/aes/openssl$ od -x clear2.txt 0000000 1100 3322 5544 7766 9988 bbaa ddcc ffee 0000020 :~/git/aes/openssl$ openssl enc -nosalt -in clear2.txt -out encrypted.dat -e -aes-128-cbc -k 000102030405060708090a0b0c0d0e0f -iv 00000000000000000000000000000000 abel at adminstation:~/git/aes/openssl$ od -x encrypted.dat 0000000 1c0f d284 0304 2a7c fd51 6e50 2462 cef7 0000020 9a65 ecff 71d8 3aa6 8290 2233 d5ba f0d3 0000040 which is not at all what i'm expecting. So what is my error ? when i look here : https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_Block_Chaining_.28CBC.29 it seems like with a null iv vectore and for a 16 bit length message, aes and aes-cbc should be the same. where am i wrong ? best regards and thnaks for your kind support. Abel Artiste en herbe,musicien , informaticien, roliste , tout et son contraire Blog Perso karel-de-macil at wanadoo.fr From erwann.abalea at opentrust.com Fri Oct 9 11:01:55 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Fri, 9 Oct 2015 13:01:55 +0200 Subject: [openssl-users] using openssl to validate an external AES program In-Reply-To: <1345330568.7555.1444386056802.JavaMail.www@wwinf1e11> References: <1345330568.7555.1444386056802.JavaMail.www@wwinf1e11> Message-ID: <9D0F5841-5C2D-4DCE-8E8E-7B8264D7A9B1@opentrust.com> Bonjour, > Le 9 oct. 2015 ? 12:20, karel-de-macil at wanadoo.fr a ?crit : > [?] > Case #1: Encrypting 16 bytes (1 block) using AES-CBC with 128-bit key > Key : 0x06a9214036b8a15b512e03d534120006 > IV : 0x3dafba429d9eb430b422da802c9fac41 > Plaintext : "Single block msg" > Ciphertext: 0xe353779c1079aeb82708942dbe77181a > > the command line i launch is the following > > :~/git/aes/openssl$ od -c clear3.txt > 0000000 S i n g l e b l o c k m s g > 0000020 > openssl enc -nosalt -aes-128-cbc -in clear3.txt -e -out test.enc -K 06a9214036b8a15b512e03d534120006 -iv 3dafba429d9eb430b422da802c9fac41 > > :~/git/aes/openssl$ od -x test.enc > 0000000 53e3 9c77 7910 b8ae 0827 2d94 77be 1a18 > 0000020 7cb9 5e82 781c 4651 2d54 6939 bc41 5de5 > 0000040 > > The first 16 bit are the answer given but what are the 16 following one ? Padding, so the decryption process knows how many useful octets were encrypted. In your case, since the block is full, padding adds another block. > > bellow that, my own program is AES-128 , not aes-128-cbc but for a msg of 16 bit only and a nul iv there should be no difference for what i understand. > > but when i use the following number found here : > > http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf > > PLAINTEXT: 00112233445566778899aabbccddeeff > KEY: > 000102030405060708090a0b0c0d0e0f > > round[10].output 69c4e0d86a7b0430d8cdb78070b4c55a > > i get the following > > :~/git/aes/openssl$ od -x clear2.txt > 0000000 1100 3322 5544 7766 9988 bbaa ddcc ffee > 0000020 > :~/git/aes/openssl$ openssl enc -nosalt -in clear2.txt -out encrypted.dat -e -aes-128-cbc -k 000102030405060708090a0b0c0d0e0f -iv 00000000000000000000000000000000 -k is not the same as -K. Cordialement, Erwann Abalea From nicholas.vonwaltsleben at voss-solutions.com Fri Oct 9 12:13:00 2015 From: nicholas.vonwaltsleben at voss-solutions.com (Nicholas von Waltsleben) Date: Fri, 9 Oct 2015 14:13:00 +0200 Subject: [openssl-users] Clarification on FIPS Tested Configurations Message-ID: Hi I am seeking clarification on what Section 2 (Tested Configurations) of the OpenSSL FIPS 140-2 Security Policy means. Are these: a) specific configurations that are known to work b) the only configurations permitted by the relevant NIST certifications? I initially believed/assumed that as long as I could compile the OpenSSL FIPS module, without any source changes and following the prescribed steps exactly, I could use it on our platform. However the more I look at the Security Policy the less sure I am whether that is the case. Regards, Nic -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Fri Oct 9 13:05:43 2015 From: marquess at openssl.com (Steve Marquess) Date: Fri, 9 Oct 2015 09:05:43 -0400 Subject: [openssl-users] Clarification on FIPS Tested Configurations In-Reply-To: References: Message-ID: <5617BBA7.2090002@openssl.com> On 10/09/2015 08:13 AM, Nicholas von Waltsleben wrote: > Hi > > I am seeking clarification on what Section 2 (Tested Configurations) of > the OpenSSL FIPS 140-2 Security Policy means. Are these: > > a) specific configurations that are known to work > b) the only configurations permitted by the relevant NIST certifications? > > I initially believed/assumed that as long as I could compile the OpenSSL > FIPS module, without any source changes and following the prescribed > steps exactly, I could use it on our platform. However the more I look > at the Security Policy the less sure I am whether that is the case. Like most things FIPS 140-2 there isn't a simple "bright line" answer. The platforms (technically "Operational Environments" or "OEs" in FIPS-speak) shown in Table 2 of the Security Policy document are the platforms that have been formally tested. Only those are directly covered by the FIPS 140-2 validation. However, there are two important considerations to keep in mind. The first is the question of what constitutes a match between the OEs listed in Table 2 and your target environment of interest. Conventional wisdom (not all of which is clearly written, incidentally) holds that any two "processor architectures" are equivalent. So for instance any two processors implementing the ARMv7 instruction set including NEON are equivalent, even though the specific make and mode of that processor (or SoC) may differ: AM335x Cortex?A8 and Qualcomm Snapdragon APQ8060 for instance. Ditto any two x86 processors that both support AES-NI (Intel Xeon 5675 and Intel Core i5?2430M, say). These processor "architectures" are shown in parentheses in the third column of Table 2. The second consideration is something called "user affirmation" which is documented in one of the canons of FIPS 140-2 scripture, the Implementation Guidance (I.G.) document ("guidance" is FIPS-speak for "mandatory requirement"): http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf. User affirmation is documented in section G.5 of the I.G. Basically that says that the end user of a validated module can "affirm" use of a validation module on a platform (OE) that was not formally tested: "The CMVP allows user porting of a validated software, firmware or hybrid cryptographic module to a operational environment which was not included as part of the validation testing. The validation status is maintained in the new operational environment without retesting in the new operational environment as long as the porting rules are followed." So basically if you can build the OpenSSL FIPS Object Module for your platform of interest, exactly as documented in the Security Policy, then you can "user affirm" its validity for that platform. Note that means *no* modifications at all, not even to the commands used for building from the source tarball. The OpenSSL FIPS module is very portable and the validations (#1747 and #2398) include a lot of platforms, so your target of interest is probably already covered either directly or via G.5 user affirmation. Note that I have heard from some vendors that some of their DoD clients won't accept user affirmation, but that's an additional requirement imposed by those organizations and not by FIPS 140-2 or the CMVP. Some platforms of interest may require source code mods, or non-default build-time options, in which case user affirmation is not an option. So what to do in that case, or when user affirmation isn't accepted by your end customer? You can pay to have your platform of interest added to an existing validation. That is how the #1747 validation came to include over a hundred platforms; over time several dozen sponsors paid for those platform tests to add their platforms of specific interest. We're still doing "change letter" updates for new platforms though now those are being added to a copycat "re-brand" validation, #2398[*]. If you don't want to engage us to add your platform to the existing OpenSSL FIPS Object Module validation(s) you can clone it yourself (via what is known as an "alternative Scenario 1A/1B" or "re-brand" validation). At one point the CMVP appeared to be actively encouraging those "re-brand" validations, and now it appears they may be discouraging them but as always it's hard to know what they'll do at any point in time. -Steve M. [*] The tediously ugly details of why this is so can be found at http://openssl.com/fips/ransom.html -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From dlobron at akamai.com Fri Oct 9 15:33:07 2015 From: dlobron at akamai.com (David Lobron) Date: Fri, 9 Oct 2015 11:33:07 -0400 Subject: [openssl-users] d2i_RSAPrivateKey not working on a private key Message-ID: Hello openssl people, I am trying to read a private key of a certificate into memory using d2i_RSAPrivateKey. I'm able to read the certificate without a problem, but when I pass the private key to d2i_RSAPrivateKey, it fails to parse. I do not see an error message or errno being set - d2i_RSAPrivateKey simply returns NULL. I've generated a self-signed cert which reproduces the problem, and I've attached it to this message (this is a throwaway cert, not in use for anything, so I'm knowingly sending the private key). The command I used to generate this cert and its key was: openssl req -x509 -newkey rsa:1024 -keyout key.pem -out cert.pem -days 36500 -nodes -outform PEM I have another cert where the private key *is* parseable by d2i_RSAPrivateKey. I printed out both certs from the command line, and compared them. They appear almost identical. The only difference I see is that when I print the attached unparseable cert, the Signature Algorithm section has 8 lines of hex. In the parseable cert, I see 15 lines of hex. Both certs use sha1WithRSAEncryption as the algorithm, with 1024 bits. Can anyone help me understand why the private key in the attached cert is not readable by d2i_RSAPrivateKey? I'm running these tests on a Mac, but the same thing happens on Ubuntu Linux. Thank you, David Printout of the attached cert, which fails to parse with d2i_RSAPrivateKey: MacBook-Air:self_signed dlobron$ openssl x509 -in cert.1024.combined -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 17702003413458844255 (0xf5aa2650b7f77a5f) Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, ST=Massachusetts, L=Cambridge, O=Akamai Technologies, OU=KMI, CN=akamai.normandy_authority.client_gateway_ca.1/emailAddress=dlobron at akamai.com Validity Not Before: Oct 8 15:47:30 2015 GMT Not After : Jan 16 15:47:30 2016 GMT Subject: C=US, ST=Massachusetts, L=Cambridge, O=Akamai Technologies, OU=KMI, CN=akamai.normandy_authority.client_gateway_ca.1/emailAddress=dlobron at akamai.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:c2:33:df:d8:cb:c9:6e:a4:98:f0:b7:b1:06:51: 77:f8:6c:36:4b:f3:ab:fc:09:ab:98:13:d5:0a:03: 63:31:c4:ce:6f:02:12:b5:c4:4c:83:17:39:c2:b8: 27:89:a5:80:56:36:72:19:8b:9a:dd:e5:e2:22:60: 53:96:f9:4d:c0:f1:c6:06:5f:1b:95:de:b7:8e:d2: ef:e8:ff:84:81:73:45:c9:a5:52:6d:af:8e:6a:16: bf:23:97:66:5e:d8:1f:0e:e9:1b:d3:03:e3:cd:4c: 02:2f:68:f0:a5:70:a3:90:f5:19:8d:f5:6b:d1:87: e7:82:39:f9:09:1b:ee:56:f9 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 2F:D9:17:38:F0:9E:03:2C:57:E5:FF:20:24:BC:F1:AA:2C:35:AB:D5 X509v3 Authority Key Identifier: keyid:2F:D9:17:38:F0:9E:03:2C:57:E5:FF:20:24:BC:F1:AA:2C:35:AB:D5 X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha1WithRSAEncryption 5d:5c:c0:10:c3:60:10:c5:d4:30:cf:90:41:32:d9:73:1f:03: 66:a5:3b:ca:e2:99:2f:89:10:0e:4d:d6:b3:1d:97:ae:0a:54: 46:0b:a8:51:02:97:c6:41:32:16:db:7c:77:28:e8:df:73:70: a0:01:73:b6:84:90:b5:a8:b7:54:53:7d:a9:cd:81:33:35:6d: 58:5e:ba:e2:7d:34:7a:32:c9:fd:4f:07:18:75:a7:53:3d:61: 1b:98:7a:e6:92:5b:74:39:e1:ab:b2:6a:51:4a:56:c5:99:1e: d7:7a:7a:b6:32:e8:ca:f2:33:bc:3f:d5:3c:3f:87:2a:9f:ab: 37:c8 -------------- next part -------------- A non-text attachment was scrubbed... Name: cert.1024.combined Type: application/octet-stream Size: 2124 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2863 bytes Desc: not available URL: From public at frank4dd.com Fri Oct 9 23:28:56 2015 From: public at frank4dd.com (Frank Migge) Date: Sat, 10 Oct 2015 08:28:56 +0900 Subject: [openssl-users] d2i_RSAPrivateKey not working on a private key In-Reply-To: References: Message-ID: <56184DB8.4070201@frank4dd.com> Hi David, Your attached sample certificate and private key (1024 bit RSA) works fine. I am reading it with PEM_read_PrivateKey( fp, &key, NULL, NULL), and also PEM_read_bio_PrivateKey(pkeybio, NULL, 0, NULL) works. If you could post the code or code fragment that creates the problem? d2i_RSAPrivateKey() is not reading PEM, just making sure... Best wishes, Frank Migge > David Lobron > Saturday, October 10, 2015 12:33 AM > Hello openssl people, > > I am trying to read a private key of a certificate into memory using > d2i_RSAPrivateKey. I'm able to read the certificate without a problem, > but when I pass the private key to d2i_RSAPrivateKey, it fails to > parse. I do not see an error message or errno being set - > d2i_RSAPrivateKey simply returns NULL. I've generated a self-signed > cert which reproduces the problem, and I've attached it to this > message (this is a throwaway cert, not in use for anything, so I'm > knowingly sending the private key). The command I used to generate > this cert and its key was: > > openssl req -x509 -newkey rsa:1024 -keyout key.pem -out cert.pem -days > 36500 -nodes -outform PEM > > I have another cert where the private key *is* parseable by > d2i_RSAPrivateKey. I printed out both certs from the command line, and > compared them. They appear almost identical. The only difference I see > is that when I print the attached unparseable cert, the Signature > Algorithm section has 8 lines of hex. In the parseable cert, I see 15 > lines of hex. Both certs use sha1WithRSAEncryption as the algorithm, > with 1024 bits. > > Can anyone help me understand why the private key in the attached cert > is not readable by d2i_RSAPrivateKey? I'm running these tests on a > Mac, but the same thing happens on Ubuntu Linux. > > Thank you, > > David > > Printout of the attached cert, which fails to parse with > d2i_RSAPrivateKey: > > MacBook-Air:self_signed dlobron$ openssl x509 -in cert.1024.combined > -text -noout > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 17702003413458844255 (0xf5aa2650b7f77a5f) > Signature Algorithm: sha1WithRSAEncryption > Issuer: C=US, ST=Massachusetts, L=Cambridge, O=Akamai Technologies, > OU=KMI, > CN=akamai.normandy_authority.client_gateway_ca.1/emailAddress=dlobron at akamai.com > Validity > Not Before: Oct 8 15:47:30 2015 GMT > Not After : Jan 16 15:47:30 2016 GMT > Subject: C=US, ST=Massachusetts, L=Cambridge, O=Akamai Technologies, > OU=KMI, > CN=akamai.normandy_authority.client_gateway_ca.1/emailAddress=dlobron at akamai.com > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (1024 bit) > Modulus: > 00:c2:33:df:d8:cb:c9:6e:a4:98:f0:b7:b1:06:51: > 77:f8:6c:36:4b:f3:ab:fc:09:ab:98:13:d5:0a:03: > 63:31:c4:ce:6f:02:12:b5:c4:4c:83:17:39:c2:b8: > 27:89:a5:80:56:36:72:19:8b:9a:dd:e5:e2:22:60: > 53:96:f9:4d:c0:f1:c6:06:5f:1b:95:de:b7:8e:d2: > ef:e8:ff:84:81:73:45:c9:a5:52:6d:af:8e:6a:16: > bf:23:97:66:5e:d8:1f:0e:e9:1b:d3:03:e3:cd:4c: > 02:2f:68:f0:a5:70:a3:90:f5:19:8d:f5:6b:d1:87: > e7:82:39:f9:09:1b:ee:56:f9 > Exponent: 65537 (0x10001) > X509v3 extensions: > X509v3 Subject Key Identifier: > 2F:D9:17:38:F0:9E:03:2C:57:E5:FF:20:24:BC:F1:AA:2C:35:AB:D5 > X509v3 Authority Key Identifier: > keyid:2F:D9:17:38:F0:9E:03:2C:57:E5:FF:20:24:BC:F1:AA:2C:35:AB:D5 > > X509v3 Basic Constraints: > CA:TRUE > Signature Algorithm: sha1WithRSAEncryption > 5d:5c:c0:10:c3:60:10:c5:d4:30:cf:90:41:32:d9:73:1f:03: > 66:a5:3b:ca:e2:99:2f:89:10:0e:4d:d6:b3:1d:97:ae:0a:54: > 46:0b:a8:51:02:97:c6:41:32:16:db:7c:77:28:e8:df:73:70: > a0:01:73:b6:84:90:b5:a8:b7:54:53:7d:a9:cd:81:33:35:6d: > 58:5e:ba:e2:7d:34:7a:32:c9:fd:4f:07:18:75:a7:53:3d:61: > 1b:98:7a:e6:92:5b:74:39:e1:ab:b2:6a:51:4a:56:c5:99:1e: > d7:7a:7a:b6:32:e8:ca:f2:33:bc:3f:d5:3c:3f:87:2a:9f:ab: > 37:c8 > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Sent with Postbox -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: not available URL: From nicholas.vonwaltsleben at voss-solutions.com Mon Oct 12 05:36:49 2015 From: nicholas.vonwaltsleben at voss-solutions.com (Nicholas von Waltsleben) Date: Mon, 12 Oct 2015 07:36:49 +0200 Subject: [openssl-users] Clarification on FIPS Tested Configurations In-Reply-To: <5617BBA7.2090002@openssl.com> References: <5617BBA7.2090002@openssl.com> Message-ID: On Fri, Oct 9, 2015 at 3:05 PM, Steve Marquess wrote: > On 10/09/2015 08:13 AM, Nicholas von Waltsleben wrote: > > Hi > > > > I am seeking clarification on what Section 2 (Tested Configurations) of > > the OpenSSL FIPS 140-2 Security Policy means. Are these: > > > > a) specific configurations that are known to work > > b) the only configurations permitted by the relevant NIST certifications? > > > > I initially believed/assumed that as long as I could compile the OpenSSL > > FIPS module, without any source changes and following the prescribed > > steps exactly, I could use it on our platform. However the more I look > > at the Security Policy the less sure I am whether that is the case. > > Like most things FIPS 140-2 there isn't a simple "bright line" answer. > > The platforms (technically "Operational Environments" or "OEs" in > FIPS-speak) shown in Table 2 of the Security Policy document are the > platforms that have been formally tested. Only those are directly > covered by the FIPS 140-2 validation. > > However, there are two important considerations to keep in mind. The > first is the question of what constitutes a match between the OEs listed > in Table 2 and your target environment of interest. Conventional wisdom > (not all of which is clearly written, incidentally) holds that any two > "processor architectures" are equivalent. So for instance any two > processors implementing the ARMv7 instruction set including NEON are > equivalent, even though the specific make and mode of that processor (or > SoC) may differ: AM335x Cortex?A8 and Qualcomm Snapdragon APQ8060 for > instance. Ditto any two x86 processors that both support AES-NI (Intel > Xeon 5675 and Intel Core i5?2430M, say). These processor "architectures" > are shown in parentheses in the third column of Table 2. > > The second consideration is something called "user affirmation" which is > documented in one of the canons of FIPS 140-2 scripture, the > Implementation Guidance (I.G.) document ("guidance" is FIPS-speak for > "mandatory requirement"): > http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf. > > User affirmation is documented in section G.5 of the I.G. Basically that > says that the end user of a validated module can "affirm" use of a > validation module on a platform (OE) that was not formally tested: "The > CMVP allows user porting of a validated software, firmware or hybrid > cryptographic module to a operational environment which was not included > as part of the validation testing. The validation status is > maintained in the new operational environment without retesting in the > new operational environment as long as the porting rules are followed." > So basically if you can build the OpenSSL FIPS Object Module for your > platform of interest, exactly as documented in the Security Policy, then > you can "user affirm" its validity for that platform. Note that means > *no* modifications at all, not even to the commands used for building > from the source tarball. > > The OpenSSL FIPS module is very portable and the validations (#1747 and > #2398) include a lot of platforms, so your target of interest is > probably already covered either directly or via G.5 user affirmation. > Note that I have heard from some vendors that some of their DoD clients > won't accept user affirmation, but that's an additional requirement > imposed by those organizations and not by FIPS 140-2 or the CMVP. > > Some platforms of interest may require source code mods, or non-default > build-time options, in which case user affirmation is not an option. So > what to do in that case, or when user affirmation isn't accepted by your > end customer? You can pay to have your platform of interest added to an > existing validation. That is how the #1747 validation came to include > over a hundred platforms; over time several dozen sponsors paid for > those platform tests to add their platforms of specific interest. We're > still doing "change letter" updates for new platforms though now those > are being added to a copycat "re-brand" validation, #2398[*]. > > If you don't want to engage us to add your platform to the existing > OpenSSL FIPS Object Module validation(s) you can clone it yourself (via > what is known as an "alternative Scenario 1A/1B" or "re-brand" > validation). At one point the CMVP appeared to be actively encouraging > those "re-brand" validations, and now it appears they may be > discouraging them but as always it's hard to know what they'll do at any > point in time. > > -Steve M. > > [*] The tediously ugly details of why this is so can be found at > http://openssl.com/fips/ransom.html > > > ?Thanks ?for the informative response Steve. We aren't using anything exotic in terms of our platform (Ubuntu 12.04 on VMware ESX) but it isn't an exact match for anything already certified. If we update to a 3.4 kernel and assume that our customer will be running ESX 5.1 then I believe we would be covered by #1747. I will need to get some direction from our partner regarding the acceptability of 'user affirmation'. -Nic -------------- next part -------------- An HTML attachment was scrubbed... URL: From sins at cisco.com Mon Oct 12 07:39:00 2015 From: sins at cisco.com (Sindhu S. (sins)) Date: Mon, 12 Oct 2015 07:39:00 +0000 Subject: [openssl-users] Reg : Openssl peak memory usage Message-ID: Hi all, We are planning to run on openwrt router(Embedded device) and trying to understand the memory requirement. I would like to know, what's the run time memory ,peak memory . Please let me know ,if there is any documentation, tool , or command to do the same. Below are the details of kernel version and openssl version. 519 => openssl version OpenSSL 1.0.1f 6 Jan 2014 521 => uname -a Linux snbi-tb-c 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Thanks, Sindhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlobron at akamai.com Mon Oct 12 14:34:50 2015 From: dlobron at akamai.com (David Lobron) Date: Mon, 12 Oct 2015 10:34:50 -0400 Subject: [openssl-users] openssl-users Digest, Vol 11, Issue 5 In-Reply-To: References: Message-ID: <76D28034-71CE-48B1-A78F-05D099E095BD@akamai.com> > Your attached sample certificate and private key (1024 bit RSA) works fine. > I am reading it with PEM_read_PrivateKey( fp, &key, NULL, NULL), and also > PEM_read_bio_PrivateKey(pkeybio, NULL, 0, NULL) works. > > If you could post the code or code fragment that creates the problem? > d2i_RSAPrivateKey() is not reading PEM, just making sure... Thanks very much, Frank. My code reads the PEM file, base64-decodes it, and passes the resulting DER value to d2i_RSAPrivateKey. I verified that I can extract the private key with d2i_PrivateKey from the DER formatted data, and I can call SSL_CTX_use_PrivateKey with it on my SSL context without a problem. It's only when I call d2i_RSAPrivateKey I encounter a problem. I have included the code below, with annotations (it's in Objective-C). I've got custom classes for X509Certificate and X509PrivateKey. I use them like this: X509Certificate *cert = [X509Certificate certificateWithPemEncodedFile:certFile]; X509PrivateKey *privKey = [X509PrivateKey privateKeyWithPemEncodedFile:keyFile]; [cert validateWithPrivateKey:privKey]; [privKey validate]; That last call to [privKey validate] is where things fail currently. The validateWithPrivateKey method works fine, and it looks like this: - (void)validateWithPrivateKey:(X509PrivateKey *)key { SSL_CTX *sslContext; [self validate]; sslContext = SSL_CTX_new(TLSv1_server_method()); NS_DURING { NSData *d = [key der]; const unsigned char *p = (const unsigned char *)[d bytes]; EVP_PKEY *pkey = d2i_PrivateKey(EVP_PKEY_RSA, NULL, &p, [d length]); if (!sslContext) [NSException raise:X509CertificateExcInternalError format:@"SSL_CTX_new failed: %@", sslErrorString()]; if (SSL_CTX_use_certificate(sslContext, _x) != 1) [NSException raise:X509CertificateExcInvalidCertificate format:@"SSL_CTX_use_certificate failed: %@", sslErrorString()]; if (SSL_CTX_use_PrivateKey(sslContext, pkey) != 1) [NSException raise:X509CertificateExcInvalidPrivateKey format:@"SSL_CTX_use_PrivateKey_ASN1 failed: %@", sslErrorString()]; SSL_CTX_free(sslContext); } NS_HANDLER { if (sslContext) SSL_CTX_free(sslContext); [localException raise]; } NS_ENDHANDLER } (That initial call to "self validate" simply validates the cert object's SSL_CTX). I initialize my private key object as follows: - (id)initWithPemEncodedFile:(NSString *)path { NSData *d = nil; NS_DURING { NSString *s; NSArray *inputLines; // read the file s = [NSString stringWithContentsOfFile:path]; if (s == nil || [s length] == 0) [NSException raise:X509CertificateExcParameterError format:@"File %@ is empty or cannot be read", path]; inputLines = [s componentsSeparatedByString:@"\n"]; d = [X509Certificate decodePemFragmentFromLines:inputLines withBoundaryPhrases:[NSArray arrayWithObjects:@"PRIVATE KEY", @"RSA PRIVATE KEY", nil]]; } NS_HANDLER { [self release]; [localException raise]; } NS_ENDHANDLER return [self initWithDer:d]; } The decodePemFragmentFromLines method looks like this: // Extract part of a PEM-encoded message, base64-decode it, and return an NSData object + (NSData *)decodePemFragmentFromLines:(NSArray *)inputLines withBoundaryPhrases:(NSArray *)boundaryPhrases { NSEnumerator *e = [inputLines objectEnumerator]; NSMutableString *b64 = [NSMutableString string]; NSString *s; NSString *boundaryPhrase = nil; NSString *startBoundary = nil; NSString *endBoundary = nil; while ((s = [e nextObject]) != nil) { NSEnumerator *e = [boundaryPhrases objectEnumerator]; while ((boundaryPhrase = [e nextObject]) != nil) { startBoundary = [NSString stringWithFormat:@"-----BEGIN %@-----", boundaryPhrase]; if ([s isEqualToString:startBoundary]) { endBoundary = [NSString stringWithFormat:@"-----END %@-----", boundaryPhrase]; break; } } if (endBoundary != nil) break; } if (s == nil) [NSException raise:X509CertificateExcParameterError format:@"Start boundary \"%@\" not found", startBoundary]; while ((s = [e nextObject]) != nil) { if ([s isEqualToString:endBoundary]) break; [b64 appendString:s]; } if (s == nil) [NSException raise:X509CertificateExcParameterError format:@"End boundary \"%@\" not found", endBoundary]; return base64Decode(b64); } The initWithDer method is simply: - (id)initWithDer:(NSData *)der { if ((self = [super init]) != nil) { _der = [der copy]; } return self; } All of the above works as expected, but when I call d2i_RSAPrivateKey on the _der object, it fails. Here is the code that throws the exception: // validate; throws exception if key invalid - (void)validate { const unsigned char *p = (unsigned char *)[_der bytes]; RSA *r = d2i_RSAPrivateKey(0, &p, [_der length]); int n; if (r == 0) [NSException raise:X509CertificateExcInvalidPrivateKey format:@"cannot decode RSA private key"]; NS_DURING { switch (n = RSA_check_key(r)) { case 1: // ok break; default: [NSException raise:X509CertificateExcInvalidPrivateKey format:@"RSA_check_key() returned %d", n]; } } NS_HANDLER { RSA_free(r); [localException raise]; } NS_ENDHANDLER RSA_free(r); } Thanks for any help you can give here! --David -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2863 bytes Desc: not available URL: From jb-openssl at wisemo.com Mon Oct 12 15:50:16 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 12 Oct 2015 17:50:16 +0200 Subject: [openssl-users] Reg : Openssl peak memory usage In-Reply-To: References: Message-ID: <561BD6B8.1070101@wisemo.com> On 12/10/2015 09:39, Sindhu S. (sins) wrote: > > Hi all, > > We are planning to run on openwrt router(Embedded device) and trying > to understand the memory requirement. > > I would like to know, what?s the run time memory ,peak memory . > > Please let me know ,if there is any documentation, tool , or > command to do the same. > Because OpenSSL is a library, the memory requirement depends a lot on whatever it is used for. For example, if OpenSSL is used for the https web user interface, some of the memory will be allocated for each simultaneous connections from the web browser(s) to the router. If OpenSSL in a server is used for client certificate validation (logging in with user certificates), there should be additional memory used for every trusted CA certificate in the configuration (because they all need to be sent to the other end as part of the request for user authentication). If OpenSSL is used in an SSL client (such as curl or wget), and the trusted CA certificates are stored in the flash file system using the "hashed symlinks" technique, there will usually only be a need to load the actually used CA certificate into memory, while the alternative of putting all the trusted CA certificates in a single file requires them all to be loaded into memory. When using the openssl command line tool, the amount of memory used depends heavily on the command and data specified. In the end, there is no substitute for measuring the actual process memory usage during the actual intended load scenarios. For long running processes (such as the http server process), this can be done by simply reading the various files under /proc// and comparing different uses and configurations. For short running processes (such as wget, curl or the openssl command line tool), there is probably some generic UNIX/Linux command to report this, similar to how the "time" command can measure execution time. > Below are the details of kernel version and openssl version. > > 519 => openssl version > > OpenSSL 1.0.1f 6 Jan 2014 > (Pretty old, there have been lots of security fixes since then). > 521 => uname -a > > Linux snbi-tb-c 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 > UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > Hmm, that looks like a desktop, most OpenWrt installs are on MIPS or ARM, though I have seen it on low end x86 too (such as Geode and Via CPUs). P.S. On most existing OpenWrt installs, there is actually plenty of RAM, but a shortage of flash storage space, though exceptions have occurred. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From fm at frank4dd.com Wed Oct 14 02:57:20 2015 From: fm at frank4dd.com (Frank Migge) Date: Wed, 14 Oct 2015 11:57:20 +0900 Subject: [openssl-users] d2i_RSAPrivateKey not working on a private key In-Reply-To: <76D28034-71CE-48B1-A78F-05D099E095BD@akamai.com> References: <76D28034-71CE-48B1-A78F-05D099E095BD@akamai.com> Message-ID: <561DC490.3010808@frank4dd.com> Hi David, I didn't spot the error in your code. But since d2i_RSAPrivateKey() fails on the DER data, how about a workaround? If your remaining code works fine, you could extract the RSA key from the EVP_PKEY object (which you are getting with d2i_PrivateKey), e.g. RSA *rsakey; rsakey = EVP_PKEY_get1_RSA(privkey); // this reads EVP_PKEY, best to test before to ensure it is RSA if (RSA_check_key(rsakey)) { printf("RSA key is valid.\n"); } else { printf("Error validating RSA key.\n"); } RSA_print_fp(stdout, rsakey, 3); ... Alternatively, building a test case around d2i_RSAPrivateKey() to see if the DER format is valid, e.g. converting the PEM key into DER using the OpenSSL commandline, and binary-compare with the programs DER data. openssl rsa -inform PEM -in test-key.pem -outform DER -out key.bin Best Wishes, Frank > David Lobron > Monday, October 12, 2015 11:34 PM > > Thanks very much, Frank. My code reads the PEM file, base64-decodes > it, and passes the resulting DER value to d2i_RSAPrivateKey. I > verified that I can extract the private key with d2i_PrivateKey from > the DER formatted data, and I can call SSL_CTX_use_PrivateKey with it > on my SSL context without a problem. It's only when I call > d2i_RSAPrivateKey I encounter a problem. I have included the code > below, with annotations (it's in Objective-C). > > I've got custom classes for X509Certificate and X509PrivateKey. I use > them like this: > > X509Certificate *cert = [X509Certificate > certificateWithPemEncodedFile:certFile]; > X509PrivateKey *privKey = [X509PrivateKey > privateKeyWithPemEncodedFile:keyFile]; > [cert validateWithPrivateKey:privKey]; > [privKey validate]; > > That last call to [privKey validate] is where things fail currently. > The validateWithPrivateKey method works fine, and it looks like this: > > - (void)validateWithPrivateKey:(X509PrivateKey *)key > { > SSL_CTX *sslContext; > > [self validate]; > sslContext = SSL_CTX_new(TLSv1_server_method()); > NS_DURING { > NSData *d = [key der]; > const unsigned char *p = (const unsigned char *)[d bytes]; > EVP_PKEY *pkey = d2i_PrivateKey(EVP_PKEY_RSA, NULL, &p, [d length]); > if (!sslContext) > [NSException raise:X509CertificateExcInternalError > format:@"SSL_CTX_new failed: %@", sslErrorString()]; > if (SSL_CTX_use_certificate(sslContext, _x) != 1) > [NSException raise:X509CertificateExcInvalidCertificate > format:@"SSL_CTX_use_certificate failed: %@", sslErrorString()]; > if (SSL_CTX_use_PrivateKey(sslContext, pkey) != 1) > [NSException raise:X509CertificateExcInvalidPrivateKey > format:@"SSL_CTX_use_PrivateKey_ASN1 failed: %@", sslErrorString()]; > SSL_CTX_free(sslContext); > } NS_HANDLER { > if (sslContext) > SSL_CTX_free(sslContext); > [localException raise]; > } NS_ENDHANDLER > } > > (That initial call to "self validate" simply validates the cert > object's SSL_CTX). > > I initialize my private key object as follows: > > - (id)initWithPemEncodedFile:(NSString *)path > { > NSData *d = nil; > NS_DURING { > NSString *s; > NSArray *inputLines; > > // read the file > s = [NSString stringWithContentsOfFile:path]; > if (s == nil || [s length] == 0) > [NSException raise:X509CertificateExcParameterError format:@"File %@ > is empty or cannot be read", path]; > inputLines = [s componentsSeparatedByString:@"\n"]; > d = [X509Certificate decodePemFragmentFromLines:inputLines > withBoundaryPhrases:[NSArray arrayWithObjects:@"PRIVATE KEY", @"RSA > PRIVATE KEY", nil]]; > } NS_HANDLER { > [self release]; > [localException raise]; > } NS_ENDHANDLER > return [self initWithDer:d]; > > } > > The decodePemFragmentFromLines method looks like this: > > // Extract part of a PEM-encoded message, base64-decode it, and return > an NSData object > + (NSData *)decodePemFragmentFromLines:(NSArray *)inputLines > withBoundaryPhrases:(NSArray *)boundaryPhrases > { > NSEnumerator *e = [inputLines objectEnumerator]; > NSMutableString *b64 = [NSMutableString string]; > NSString *s; > NSString *boundaryPhrase = nil; > NSString *startBoundary = nil; > NSString *endBoundary = nil; > > while ((s = [e nextObject]) != nil) { > NSEnumerator *e = [boundaryPhrases objectEnumerator]; > while ((boundaryPhrase = [e nextObject]) != nil) { > startBoundary = [NSString stringWithFormat:@"-----BEGIN %@-----", > boundaryPhrase]; > if ([s isEqualToString:startBoundary]) { > endBoundary = [NSString stringWithFormat:@"-----END %@-----", > boundaryPhrase]; > break; > } > } > if (endBoundary != nil) > break; > } > if (s == nil) > [NSException raise:X509CertificateExcParameterError format:@"Start > boundary \"%@\" not found", startBoundary]; > while ((s = [e nextObject]) != nil) { > if ([s isEqualToString:endBoundary]) > break; > [b64 appendString:s]; > } > if (s == nil) > [NSException raise:X509CertificateExcParameterError format:@"End > boundary \"%@\" not found", endBoundary]; > return base64Decode(b64); > } > > The initWithDer method is simply: > > - (id)initWithDer:(NSData *)der > { > if ((self = [super init]) != nil) { > _der = [der copy]; > } > return self; > } > > All of the above works as expected, but when I call d2i_RSAPrivateKey > on the _der object, it fails. Here is the code that throws the exception: > > // validate; throws exception if key invalid > - (void)validate > { > const unsigned char *p = (unsigned char *)[_der bytes]; > RSA *r = d2i_RSAPrivateKey(0, &p, [_der length]); > int n; > if (r == 0) > [NSException raise:X509CertificateExcInvalidPrivateKey format:@"cannot > decode RSA private key"]; > NS_DURING { > switch (n = RSA_check_key(r)) { > case 1: // ok > break; > default: > [NSException raise:X509CertificateExcInvalidPrivateKey > format:@"RSA_check_key() returned %d", n]; > } > } NS_HANDLER { > RSA_free(r); > [localException raise]; > } NS_ENDHANDLER > RSA_free(r); > > } > > Thanks for any help you can give here! > > --David > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Sent with Postbox -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: not available URL: From bkaduk at akamai.com Wed Oct 14 03:12:10 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 13 Oct 2015 22:12:10 -0500 Subject: [openssl-users] d2i_RSAPrivateKey not working on a private key In-Reply-To: <561DC490.3010808@frank4dd.com> References: <76D28034-71CE-48B1-A78F-05D099E095BD@akamai.com> <561DC490.3010808@frank4dd.com> Message-ID: <561DC80A.3010004@akamai.com> Hi Frank, Thanks for these thoughts. On 10/13/2015 09:57 PM, Frank Migge wrote: > Hi David, > > I didn't spot the error in your code. But since d2i_RSAPrivateKey() > fails on the DER data, how about a workaround? If your remaining code > works fine, you could extract the RSA key from the EVP_PKEY object > (which you are getting with d2i_PrivateKey), e.g. > > RSA *rsakey; > rsakey = EVP_PKEY_get1_RSA(privkey); // this reads EVP_PKEY, best > to test before to ensure it is RSA > > if (RSA_check_key(rsakey)) { printf("RSA key is valid.\n"); } > else { printf("Error validating RSA key.\n"); } > > RSA_print_fp(stdout, rsakey, 3); > ... > > Alternatively, building a test case around d2i_RSAPrivateKey() to see > if the DER format is valid, e.g. converting the PEM key into DER using > the OpenSSL commandline, and binary-compare with the programs DER data. I worked with David some offline, and it seems that the problematic file was the DER encoding of a PKCS8_PRIV_KEY_INFO, with the pkey ASN1_ANY element being an octet string containing the DER encoding of the actual RSAPrivateKey object (checked using openssl asn1parse). So it seems that calling d2i_RSAPrivateKey() on it directly would necessarily fail, since that ASN.1 decoder has no provision to skip the bits in the PKCS#8 container. I think we're in agreement that the EVP interfaces are friendlier to use, at this point, though. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From paulvon73 at gmail.com Thu Oct 15 11:51:28 2015 From: paulvon73 at gmail.com (paul von) Date: Thu, 15 Oct 2015 19:51:28 +0800 Subject: [openssl-users] Convert a x509 cert with PEM format Message-ID: Hi All: i have met a problem. Now i am wirting a c function that convert a PEM x509 cert in a buffer (yes, the pem x509 cert is in the buffer, not in a pem file) into a DER x509 cert in a buffer (not in der file)too. I wrote the c code: // inBuff-->IN_BIO-->X509-->outBuff int buf_cert_convert_pem_to_der(const unsigned char *in, int inLen, unsigned char *out, int *outLen) { int ret = 0; BIO *bio_in = NULL; X509 *x509 = NULL; unsigned char *der_cert_buff = NULL; int len = 0; bio_in = BIO_new_mem_buf((void *)in, inLen); if(bio_in == NULL) { printf("BIO_new_mem_buf a bio_in error! \n"); ret = -1; goto err; } if (!PEM_read_bio_X509(bio_in, &x509, NULL, NULL)) { printf("PEM_read_bio_X509 read x509 cert from bio error! \n"); ret = -1; goto err; } len = i2d_X509(x509, NULL); if (len <= 0) { printf("i2d_X509 read x509 cert length error! \n"); ret = -1; goto err; } if(len > *outLen) { printf("the out buff length is not enough for the x509 cert error! \n"); ret = -1; goto err; } der_cert_buff = (unsigned char *)malloc(len); if(der_cert_buff == NULL) { printf("alloc mem error! \n"); ret = -1; goto err; } memset(der_cert_buff, 0, len); len = i2d_X509(x509, &der_cert_buff); //???? if (len <= 0) { printf("i2d_X509 read x509 cert error! \n"); ret = -1; goto err; } //debug printf("der file len: %d bytes \n", len); memcpy(out, der_cert_buff, len); *outLen = len; ret = 0; err: // Does der_cert_buff need free manually? when i free manually, it will collapse. I donot know why. It always free manually when you use **poiter? /* if (der_cert_buff != NULL) free(der_cert_buff); */ if (bio_in != NULL) BIO_free(bio_in); if (x509 != NULL) X509_free(x509); return ret; } Question: 1. Am i right? when i debug this program i always wrong... I cannot find out the reason. 2. In the funtion i2d_X509(x509, &der_cert_buff), Does der_cert_buff need to be free manually? when i free ,it would collapse -:( thanks. BTWa: I wrote a test c code bellow: // test for buf_cert_convert_pem_to_der #define PEM_CERT_FILE "test_cert.pem" #define DER_CERT_FILE "test_cert.der" int test5() { int inLen = 0, outLen = DATA_BUFF_LEN; unsigned char in[DATA_BUFF_LEN], out[DATA_BUFF_LEN]; FILE *pem_f = NULL, *der_f = NULL; unsigned long fileLen = 0; int ret = 0; fileLen = get_file_size(PEM_CERT_FILE); if(fileLen < 0) { printf("get pem file length error\n"); ret = -1; goto err; } if((pem_f = fopen(PEM_CERT_FILE, "r")) == NULL) { printf("open pem file error! \n"); ret = -1; goto err; } memset(in, 0, DATA_BUFF_LEN); do { ret = fread(in, DATA_BUFF_LEN, 1, pem_f); }while(ret > 0); if(ret < 0) { printf("read pem file error\n"); ret = -1; goto err; } ret = 0; memset(out, 0, DATA_BUFF_LEN); ret = buf_cert_convert_pem_to_der(in, fileLen, out, &outLen); if(ret != 0) { printf("buf_cert_convert_pem_to_der error\n"); ret = -1; goto err; } if((der_f = fopen(DER_CERT_FILE, "wb+")) == NULL) { printf("open der file error! \n"); ret = -1; goto err; } ret = fwrite(out, outLen, 1, der_f); if(ret <= 0) { printf("write der file error \n"); ret = -1; goto err; } ret = 0; printf("buf_cert_convert_pem_to_der ok! \n"); err: if(der_f != NULL) fclose(der_f); if(pem_f != NULL) fclose(pem_f); return ret; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From paulvon73 at gmail.com Thu Oct 15 12:08:27 2015 From: paulvon73 at gmail.com (paul von) Date: Thu, 15 Oct 2015 20:08:27 +0800 Subject: [openssl-users] Convert a x509 cert with PEM format In-Reply-To: References: Message-ID: i write a c function which convert a pem cert file to a der cert file, it is ok. On Thu, Oct 15, 2015 at 7:51 PM, paul von wrote: > Hi All: > > i have met a problem. Now i am wirting a c function that convert a > PEM x509 cert in a buffer (yes, the pem x509 cert is in the buffer, not in > a pem file) into a DER x509 cert in a buffer (not in der file)too. I wrote > the c code: > > // inBuff-->IN_BIO-->X509-->outBuff > int buf_cert_convert_pem_to_der(const unsigned char *in, int inLen, > unsigned char *out, int *outLen) > { > int ret = 0; > BIO *bio_in = NULL; > X509 *x509 = NULL; > unsigned char *der_cert_buff = NULL; > int len = 0; > > bio_in = BIO_new_mem_buf((void *)in, inLen); > if(bio_in == NULL) > { > printf("BIO_new_mem_buf a bio_in error! \n"); > ret = -1; > goto err; > } > > if (!PEM_read_bio_X509(bio_in, &x509, NULL, NULL)) > { > printf("PEM_read_bio_X509 read x509 cert from bio error! \n"); > ret = -1; > goto err; > } > > len = i2d_X509(x509, NULL); > if (len <= 0) > { > printf("i2d_X509 read x509 cert length error! \n"); > ret = -1; > goto err; > } > > if(len > *outLen) > { > printf("the out buff length is not enough for the x509 cert error! \n"); > ret = -1; > goto err; > } > > der_cert_buff = (unsigned char *)malloc(len); > if(der_cert_buff == NULL) > { > printf("alloc mem error! \n"); > ret = -1; > goto err; > } > > memset(der_cert_buff, 0, len); > len = i2d_X509(x509, &der_cert_buff); //???? > if (len <= 0) > { > printf("i2d_X509 read x509 cert error! \n"); > ret = -1; > goto err; > } > //debug > printf("der file len: %d bytes \n", len); > > memcpy(out, der_cert_buff, len); > *outLen = len; > ret = 0; > > err: > // Does der_cert_buff need free manually? when i free manually, it will > collapse. I donot know why. It always free manually when you use **poiter? > /* > if (der_cert_buff != NULL) > free(der_cert_buff); > */ > if (bio_in != NULL) > BIO_free(bio_in); > if (x509 != NULL) > X509_free(x509); > > return ret; > } > > Question: > 1. Am i right? when i debug this program i always wrong... I cannot find > out the reason. > 2. In the funtion i2d_X509(x509, &der_cert_buff), Does der_cert_buff > need to be > free manually? when i free ,it would collapse -:( > thanks. > > BTWa: I wrote a test c code bellow: > // test for buf_cert_convert_pem_to_der > #define PEM_CERT_FILE "test_cert.pem" > #define DER_CERT_FILE "test_cert.der" > int test5() > { > int inLen = 0, outLen = DATA_BUFF_LEN; > unsigned char in[DATA_BUFF_LEN], out[DATA_BUFF_LEN]; > FILE *pem_f = NULL, *der_f = NULL; > unsigned long fileLen = 0; > int ret = 0; > > fileLen = get_file_size(PEM_CERT_FILE); > if(fileLen < 0) > { > printf("get pem file length error\n"); > ret = -1; > goto err; > } > > if((pem_f = fopen(PEM_CERT_FILE, "r")) == NULL) > { > printf("open pem file error! \n"); > ret = -1; > goto err; > } > > memset(in, 0, DATA_BUFF_LEN); > do > { > ret = fread(in, DATA_BUFF_LEN, 1, pem_f); > }while(ret > 0); > > if(ret < 0) > { > printf("read pem file error\n"); > ret = -1; > goto err; > } > ret = 0; > > memset(out, 0, DATA_BUFF_LEN); > ret = buf_cert_convert_pem_to_der(in, fileLen, out, &outLen); > if(ret != 0) > { > printf("buf_cert_convert_pem_to_der error\n"); > ret = -1; > goto err; > } > > if((der_f = fopen(DER_CERT_FILE, "wb+")) == NULL) > { > printf("open der file error! \n"); > ret = -1; > goto err; > } > > ret = fwrite(out, outLen, 1, der_f); > if(ret <= 0) > { > printf("write der file error \n"); > ret = -1; > goto err; > } > ret = 0; > > printf("buf_cert_convert_pem_to_der ok! \n"); > > err: > if(der_f != NULL) > fclose(der_f); > if(pem_f != NULL) > fclose(pem_f); > return ret; > } > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Walter.H at mathemainzel.info Thu Oct 15 13:49:06 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Thu, 15 Oct 2015 15:49:06 +0200 Subject: [openssl-users] Problem checking certificate with OCSP In-Reply-To: <20151005151101.GA12587@openssl.org> References: <20151005151101.GA12587@openssl.org> Message-ID: <561FAED2.6070006@mathemainzel.info> On 5.10.2015 17:11, Dr. Stephen Henson wrote: > On Mon, Oct 05, 2015, Walter H. wrote: > >> Hello, >> >> attached is the certificate and its chain of https://revoked.grc.com/ >> >> doing this: >> >> openssl ocsp -no_nonce -issuer chain.pem -cert cert.pem -text -url >> http://ocsp2.globalsign.com/gsdomainvalg2 >> >> goves the following: >> >> OCSP Request Data: >> Version: 1 (0x0) >> Requestor List: >> Certificate ID: >> Hash Algorithm: sha1 >> Issuer Name Hash: 45658DA20174402FF48B3A6AC0BC69208095C7CA >> Issuer Key Hash: 96ADFAB05BB983642A76C21C8A69DA42DCFEFD28 >> Serial Number: 112155688D380775DA34C5DF97433ED3F6A7 >> Error querying OCSP responsder >> 139928584042312:error:27076072:OCSP routines:PARSE_HTTP_LINE1:server response >> error:ocsp_ht.c:250:Code=403,Reason=Forbidden >> >> where is the problem for this strange error? >> > Some OCSP responders need the host header, try adding: > > -header Host ocsp2.globalsign.com Thanks for this hint; When doing this openssl ocsp -CAfile /etc/pki/tls/certs/ca-bundle.trust.crt -no_nonce -issuer issuer.pem -cert cert.pem -text -url http://ocsp2.globalsign.com/gsdomainvalg2 -header Host ocsp2.globalsign.com ca-bundle.trust.crt is the certstore of my centos issuer.pem is the intermediate certificate, used signing cert.pem cert.pem is the certificate that should be checked then I get this error: Response Verify Failure 139966083565384:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:126:Verify error:unable to get local issuer certificate srvr.pem: revoked This Update: Oct 13 07:20:48 2015 GMT Next Update: Oct 16 07:20:48 2015 GMT Reason: unspecified Revocation Time: Apr 23 15:44:10 2014 GMT when I use use chain.pem (contains both the intermediate and the root certificate) as -CAfile then it works; I want to do the following: I get the server certificate and the chain except of the root; and then I want to verify with this, if the certificate is valid, revoked or has expired so I have 3 files cert.pem the certificate itself issuer.pem the intermediate that was used signing the certificate chain.pem any certificate of the chain except the certificate itself and the root the following script should do the job ... #!/bin/sh CAFILE=/etc/pki/tls/certs/ca-bundle.trust.crt CERT=srvr.pem ISSUER=issuer.pem OCSPURL=$(openssl x509 -in $CERT -noout -ocsp_uri) OCSPHOST=$(echo "$OCSPURL" |gawk -F\/ '{ print $3 }' -) openssl ocsp -CAfile $CAFILE -no_nonce -issuer $ISSUER -cert $CERT -url "$OCSPURL" -header Host $OCSPHOST but failes with 139966083565384:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:126:Verify error:unable to get local issuer certificate why? it can't be the solution to generate a new "cert store" (the concat of chain.pem and the real cert store) for each certificate I want to verify ... Thanks, Walter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4312 bytes Desc: S/MIME Cryptographic Signature URL: From eabesea at rambler.ru Sat Oct 17 20:12:23 2015 From: eabesea at rambler.ru (=?koi8-r?B?5dfHxc7JyiD2xczUz87P1tPLyco=?=) Date: Sat, 17 Oct 2015 23:12:23 +0300 Subject: [openssl-users] Problem building openssl with mingw Message-ID: <1445112743.530574.20700.57990@mail.rambler.ru> Hello everyone! I'm trying to build openssl 1.0.1p with x64 mingw-w64 5.1.0. I run ./Configure --openssldir=$PWD/dist shared mingw64 && make CC=x86_64-w64-mingw32-gcc RANLIB=ranlib && make install It's configured as needed and starts to compile. It compiles libcrypto. I get a libcrypto.a in my openssl folder. But then I get following error: touch: setting times of `lib': Permission denied which prevents compile from continue. I'm running Windows 10. What's the problem? Evgeniy . -------------- next part -------------- An HTML attachment was scrubbed... URL: From Walter.H at mathemainzel.info Tue Oct 20 13:25:31 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Tue, 20 Oct 2015 15:25:31 +0200 Subject: [openssl-users] Problems with openssl verify -crl_check ... Message-ID: <562640CB.3000301@mathemainzel.info> Hello, openssl verify -CAfile root.pem -untrusted issuer.pem srvr.pem gives this output srvr.pem: OK but openssl verify -CAfile root.pem -crl_check -untrusted issuer.pem srvr.pem gives this: srvr.pem: C = US, OU = Domain Control Validated, CN = revoked.grc.com error 3 at 0 depth lookup:unable to get certificate CRL and doing this: openssl verify -CAfile root.pem -crl_check issuer.pem gives a similar result issuer.pem: C = BE, O = GlobalSign nv-sa, CN = GlobalSign Domain Validation CA - G2 error 3 at 0 depth lookup:unable to get certificate CRL the used certificate for these command-line samples are attached ... (the SSL/TLS certificate and the whole chain of revoked.grc.com) please, can someone tell me how to check the CRL of certificate using openssl command-line? Thanks, Walter -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: root.pem URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: issuer.pem URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: srvr.pem URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4312 bytes Desc: S/MIME Cryptographic Signature URL: From plucas at splunk.com Tue Oct 20 23:07:43 2015 From: plucas at splunk.com (Paul Lucas) Date: Tue, 20 Oct 2015 23:07:43 +0000 Subject: [openssl-users] SSL_CTX_set_verify() callback and current depth Message-ID: <7384F235-36E0-45E6-B9F9-0EB3A6D17913@splunk.com> I'm writing my own callback function in C for SSL_CTX_set_verify() to perform additional certificate checks (when the preverify_ok parameter is 1). However, I want to perform the checks only for the leaf certificate (depth = 0). There is the function X509_STORE_CTX_get_error_depth() that gets the depth of the error; but I want the current depth even when there is no error so I can perform my additional checks only when depth=0. (Note that the function SSL_CTX_get_verify_depth() returns the depth limit and not the current depth.) Is there any way to do what I want? - Paul From jonetsu at teksavvy.com Wed Oct 21 16:02:22 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Wed, 21 Oct 2015 12:02:22 -0400 Subject: [openssl-users] CAVP protocol testing - what does it really consist of ? Message-ID: <691b48b5035cb4a734b3570e6c70689a@teksavvy.com> Hello, Sorry if this is a bit beside OpenSSL per se, the idea behind this post is to perhaps have some information form the OpenSSL experience with FIPS validation. ?There was so much effort put into FIPS compliance that it would not be far-fetched to consider that there is also knowledge about what seems to be /protocol/ testing. I would like to know what's involved in the CAVP testing of the SSH protocol. ?I browsed the NIST CAVP web site, browsed some documents, although I haven't found any satisfying, technically-oriented, document on what has to be done if say, I have an editor opened with the SSH source code. ?Not the fully gruesome details, but an overview of how such testing works. Any comment appreciated ! From Michael.Wojcik at microfocus.com Wed Oct 21 15:34:16 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 21 Oct 2015 15:34:16 +0000 Subject: [openssl-users] SSL_CTX_set_verify() callback and current depth In-Reply-To: <7384F235-36E0-45E6-B9F9-0EB3A6D17913@splunk.com> References: <7384F235-36E0-45E6-B9F9-0EB3A6D17913@splunk.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Paul Lucas > Sent: Tuesday, October 20, 2015 19:08 > > I'm writing my own callback function in C for SSL_CTX_set_verify() to perform > additional certificate checks (when the preverify_ok parameter is 1). > However, I want to perform the checks only for the leaf certificate (depth = > 0). > > There is the function X509_STORE_CTX_get_error_depth() that gets the > depth of the error; but I want the current depth even when there is no error > so I can perform my additional checks only when depth=0. (Note that the > function SSL_CTX_get_verify_depth() returns the depth limit and not the > current depth.) > > Is there any way to do what I want? I thought get_error_depth returned the current depth even when there is no "error". The preverifyOk parameter tells the callback whether OpenSSL thinks there's a problem; the callback is invoked regardless, for each certificate in the chain, and get_error_depth should tell you what the depth is on each call, even if preverifyOk is true (nonzero). A quick browse through x509_vfy.c (for 1.0.1p) suggests that ctx->error_depth, which is what get_error_depth returns, is always set before calling the callback. -- Michael Wojcik Technology Specialist, Micro Focus From marquess at openssl.com Wed Oct 21 18:18:02 2015 From: marquess at openssl.com (Steve Marquess) Date: Wed, 21 Oct 2015 14:18:02 -0400 Subject: [openssl-users] CAVP protocol testing - what does it really consist of ? In-Reply-To: <691b48b5035cb4a734b3570e6c70689a@teksavvy.com> References: <691b48b5035cb4a734b3570e6c70689a@teksavvy.com> Message-ID: <5627D6DA.20403@openssl.com> On 10/21/2015 12:02 PM, jonetsu wrote: > > Hello, > > > Sorry if this is a bit beside OpenSSL per se, the idea behind this > post is to perhaps have some information form the OpenSSL experience > with FIPS validation. There was so much effort put into FIPS > compliance that it would not be far-fetched to consider that there is > also knowledge about what seems to be /protocol/ testing. > > > I would like to know what's involved in the CAVP testing of the SSH > protocol. I browsed the NIST CAVP web site, browsed some documents, > although I haven't found any satisfying, technically-oriented, > document on what has to be done if say, I have an editor opened with > the SSH source code. Not the fully gruesome details, but an overview > of how such testing works. See Appendix B of the OpenSSL FIPS User Guide: https://openssl.org/docs/fips/UserGuide-2.0.pdf The specific algorithm tests have changed quite a bit since then (constant change is part of the fun), but the general concept is the same. The algorithm testing is the easiest part of FIPS 140-2 validations. Note the CAVP only tests specific cryptographic algorithms, not cryptographic protocol suites like SSH (secsh). OpenSSH itself is just application code from the perspective of FIPS 140-2 and thus out of scope (as is OpenSSL; the OpenSSL FIPS Object Module is a separate software component carefully crafted to satisfy the peculiar restrictions and requirements of FIPS 140-2). Also note that converting stock OpenSSH to exclusive use of FIPS validated cryptographic is a non-trivial exercise. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From jonetsu at teksavvy.com Wed Oct 21 19:22:51 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Wed, 21 Oct 2015 15:22:51 -0400 Subject: [openssl-users] CAVP protocol testing - what does it really consist of ? In-Reply-To: <5627D6DA.20403@openssl.com> References: <691b48b5035cb4a734b3570e6c70689a@teksavvy.com> <5627D6DA.20403@openssl.com> Message-ID: <09f38f7634283f2efc0e7482e11b8415@teksavvy.com> > From: "Steve Marquess" > Date: 10/21/15 14:18 > See Appendix B of the OpenSSL FIPS User Guide: > ?https://openssl.org/docs/fips/UserGuide-2.0.pdf Thanks. > The specific algorithm tests have changed quite a bit since then > (constant change is part of the fun), but the general concept is the > same. The algorithm testing is the easiest part of FIPS 140-2 validations. What would you consider being the difficult parts ? > Note the CAVP only tests specific cryptographic algorithms, not > cryptographic protocol suites like SSH (secsh). OpenSSH itself is just > application code from the perspective of FIPS 140-2 and thus out of > scope ... It has to do with NDcPP 1.0 I think. ?Key agreement schemes and key derivation functions? for several security-related communications protocols (SNMP, TLS, SSH, etc.)? must now be tested as part of the algorithm test process. ? From dj at deadhat.com Wed Oct 21 20:01:11 2015 From: dj at deadhat.com (dj at deadhat.com) Date: Wed, 21 Oct 2015 20:01:11 -0000 Subject: [openssl-users] CAVP protocol testing - what does it really consist of ? In-Reply-To: <09f38f7634283f2efc0e7482e11b8415@teksavvy.com> References: <691b48b5035cb4a734b3570e6c70689a@teksavvy.com> <5627D6DA.20403@openssl.com> <09f38f7634283f2efc0e7482e11b8415@teksavvy.com> Message-ID: <02f97ccbe7dca53915c4bc4ff47aea58.squirrel@www.deadhat.com> I my experience of getting CAVP certification on my own (non openssl) designs it is like this: 1) Pay few ten thousands of dollars to a certification company. 2) They send you a questionnaire about the algorithms you have in the implementation. 3) You fill that in and return it to them with design documentation 4) Questions and answers go back and forth. 5) They send you test vectors to try out 6) At some point either you visit them or they visit you and they exercise the system against some vectors to make sure you aren't cheating. 7) They submit paperwork to NIST 8) You await your listing on the NIST website. The difficult bit is the vector generation software. Specs like SP800-90 have many degrees of freedom. The vector generating software doesn't have nearly the degrees of freedom that the spec has, so there is reasonable certainty that you can't reproduce the vectors they provide because your implementation doesn't do things in the same order as the vector generator software supplied by NIST. This is when you get into deep discussions with the test house and send of interpretations to NIST to try and get it resolved. Bad specs, bad vectors = bad certification experience. >> From: "Steve Marquess" >> Date: 10/21/15 14:18 >> See Appendix B of the OpenSSL FIPS User Guide: > >> ??https://openssl.org/docs/fips/UserGuide-2.0.pdf > > Thanks. > >> The specific algorithm tests have changed quite a bit since then >> (constant change is part of the fun), but the general concept is the >> same. The algorithm testing is the easiest part of FIPS 140-2 >> validations. > > What would you consider being the difficult parts ? > >> Note the CAVP only tests specific cryptographic algorithms, not >> cryptographic protocol suites like SSH (secsh). OpenSSH itself is just >> application code from the perspective of FIPS 140-2 and thus out of >> scope ... > > > It has to do with NDcPP 1.0 I think. ??Key agreement schemes and key > derivation functions?? > for several security-related communications protocols (SNMP, TLS, SSH, > etc.)?? > must now be tested as part of the algorithm test process. ?? > > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From daniyar at ex.ua Thu Oct 22 09:29:56 2015 From: daniyar at ex.ua (Daniyar) Date: Thu, 22 Oct 2015 12:29:56 +0300 Subject: [openssl-users] Fwd: OpenSSL SE In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From ghudson at mit.edu Thu Oct 22 20:21:38 2015 From: ghudson at mit.edu (Greg Hudson) Date: Thu, 22 Oct 2015 16:21:38 -0400 Subject: [openssl-users] Elliptic curve implementation sanity check Message-ID: I am working on implementing the SPAKE2 algorithm[1] for a krb5 pre-authentication mechanism, and would like to double-check some conclusions I've drawn about elliptic curve implementations. For SPAKE2, I need to compute T=xG+wM and K=x(S-wN), where x is a random scalar, w is a scalar derived from a shared secret, G is the base point, and M and N are constant points in the subgroup of the base point, and S is a point presented by the other party. (There is a similar pair of computations by the other party, S=yG+wN and K=y(T-wM).) Side channels which reveal information about x, w, xG, wM, or wN could affect the security of the mechanism. I also need to be able to serialize and deserialize the scalar x; side channels in that serialization could also affect the security of the mechanism. Performance on common platforms is important, as password-based initial authentication currently only uses symmetric operations. A 128-bit security level is adequate. The conclusions I have come to are: * OpenSSL's P-256 is the fastest applicable open-source implementation usable by a C library. Curve25519 implementations are inapplicable because they don't do point addition. The curve math primitives of current ed25519 implementations are not applicable because verifier operations (such as double multiply) are not implemented in constant time. * There may be some timing-channel pitfalls in nistz256 point addition, but only in vanishingly unlikely cases (xG=wM, S=wN, w is the order of the base point, etc.). * On architectures where nistz256 is not implemented, a default OpenSSL build will use the generic Weierstrass implementation. I haven't been able to determine whether there are significant timing channels in that implementation. * There are likely timing channels in the serialization of scalars, due to BIGNUM being variable-length. They might not be significant enough to be exploitable. Does that all seem correct? [1] https://tools.ietf.org/html/draft-irtf-cfrg-spake2 From bbrumley at gmail.com Fri Oct 23 12:27:05 2015 From: bbrumley at gmail.com (Billy Brumley) Date: Fri, 23 Oct 2015 15:27:05 +0300 Subject: [openssl-users] Elliptic curve implementation sanity check In-Reply-To: References: Message-ID: > * On architectures where nistz256 is not implemented, a default > OpenSSL build will use the generic Weierstrass implementation. I > haven't been able to determine whether there are significant timing > channels in that implementation. Researches have been beating up "the generic Weierstrass implementation" since 2009. BBB From marquess at openssl.com Fri Oct 23 14:04:35 2015 From: marquess at openssl.com (Steve Marquess) Date: Fri, 23 Oct 2015 10:04:35 -0400 Subject: [openssl-users] CAVP protocol testing - what does it really consist of ? In-Reply-To: <09f38f7634283f2efc0e7482e11b8415@teksavvy.com> References: <691b48b5035cb4a734b3570e6c70689a@teksavvy.com> <5627D6DA.20403@openssl.com> <09f38f7634283f2efc0e7482e11b8415@teksavvy.com> Message-ID: <562A3E73.1010903@openssl.com> On 10/21/2015 03:22 PM, jonetsu wrote: >> From: "Steve Marquess" >> Date: 10/21/15 14:18 >> See Appendix B of the OpenSSL FIPS User Guide: > >> https://openssl.org/docs/fips/UserGuide-2.0.pdf > > Thanks. > >> The specific algorithm tests have changed quite a bit since then >> (constant change is part of the fun), but the general concept is the >> same. The algorithm testing is the easiest part of FIPS 140-2 validations. > > What would you consider being the difficult parts ? The CMVP part. The CAVP requirements are fairly well articulated and consistently applied. New versions of the CAVS tool, and newly introduced test vectors, occasionally have problems but those can usually be worked out without too much grief. The wait time for CAVP approvals is also a lot more predictable. The CMVP, on the other hand, is not nearly as predictable or consistent. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From michel.sales at free.fr Mon Oct 26 12:21:24 2015 From: michel.sales at free.fr (Michel) Date: Mon, 26 Oct 2015 13:21:24 +0100 Subject: [openssl-users] suggested enhancement documentation or warning for pkey command line tool Message-ID: <000901d10fe8$d53fc2d0$7fbf4870$@sales@free.fr> Hi, I believe it might be usefull to remind in the documentation that the -cipher argment for openssl pkey command line tool is silently ignore when combined with -outform DER. May be it is worth to add a warning too ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Oct 26 13:02:40 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 26 Oct 2015 13:02:40 +0000 Subject: [openssl-users] suggested enhancement documentation or warning for pkey command line tool In-Reply-To: <000901d10fe8$d53fc2d0$7fbf4870$@sales@free.fr> References: <000901d10fe8$d53fc2d0$7fbf4870$@sales@free.fr> Message-ID: <20151026130240.GM5570@mournblade.imrryr.org> On Mon, Oct 26, 2015 at 01:21:24PM +0100, Michel wrote: > I believe it might be usefull to remind in the documentation that the > -cipher argment for openssl pkey command line tool is silently ignore when > combined with -outform DER. > > May be it is worth to add a warning too ? I think a fatal error would be appropriate. If you want encrypted DER keys, you'll need PKCS#8 or PKCS#12. -- Viktor. From emildotchevski at gmail.com Mon Oct 26 20:36:49 2015 From: emildotchevski at gmail.com (Emil Dotchevski) Date: Mon, 26 Oct 2015 13:36:49 -0700 Subject: [openssl-users] Blocking SSL_write possibly buffering? Message-ID: Greetings, I am using OpenSSL in *blocking* mode, with SSL_MODE_AUTO_RETRY set. I have this situation: Peer 1 (server): SSL_write 16K bytes --> success SSL_write N bytes, N<16K --> success SSL_read (correctly hangs waiting for data) Peer 2 (client): SSL_read 16K+N bytes --> hangs That is, Peer 1 breaks a data buffer that's larger than 16K in two pieces and it succeeds writing both pieces but does no more writes (calls SSL_read), while Peer 2 attempts to read the whole thing and hangs. I'm reasoning that I'd get this behavior if for some reason the second call to SSL_write decided to buffer up the data rather than sending it immediately, but my reading of the documentation is that it's not supposed to do that. Any help is greatly appreciated! Thanks, Emil -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonetsu at teksavvy.com Mon Oct 26 20:44:59 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Mon, 26 Oct 2015 16:44:59 -0400 Subject: [openssl-users] 'FIPS_CIPHERINIT:disabled' in fips mode error in 1.0.1e Message-ID: <2cf2b40879bce346242c8e1c2e7b922b@teksavvy.com> In 1.0.1e the following is observed when using OpenSSL in FIPS mode: ?% OPENSSL_FIPS=1 openssl pkcs12 -export -in ?/tmp/ipsec.d/certs/192.168.11.1 -inkey ?/tmp/ipsec.d/private/192.168.11.1 -name 192.168.11.1 -out ?/tmp/ipsec.d/192.168.11.1.p12 -password pass:"" ?3067167952:error:060A60A3:digital envelope? ?routines:FIPS_CIPHERINIT:disabled for fips:fips_enc.c:142: ?3067167952:error:06074078:digital envelope ?routines:EVP_PBE_CipherInit:keygen failure:evp_pbe.c:205: ?3067167952:error:23077073:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 algor ?cipherinit error:p12_decr.c:83: ?3067167952:error:2306C067:PKCS12 ?routines:PKCS12_item_i2d_encrypt:encrypt error:p12_decr.c:175: ?3067167952:error:23073067:PKCS12 routines:PKCS12_pack_p7encdata:encrypt? ?error:p12_add.c:202: In 'Re: PKCS12 keystore creation failing in fips mode' (May 29, 2013 9:15pm) the following is said: ? "That's a bug in 1.0.1 in that it tries to use an unapproved ? algorithm in FIPS mode. ?Workaround: use the -descert option." It is not possible for us to upgrade OpenSSL, but it would be possible to apply a patch. ?Does a patch exist that fixes this problem and if so, where can it be found ? ?I do not know how development is organized for OpenSSL (bug tracker, git ?) Thanks ! From rosect190 at yahoo.com Mon Oct 26 20:42:25 2015 From: rosect190 at yahoo.com (rosect190 at yahoo.com) Date: Mon, 26 Oct 2015 20:42:25 +0000 (UTC) Subject: [openssl-users] OCSP_sendreq_bio() References: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> Message-ID: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> Hi, I need some help on this call. I am building an OCSP client following guide in openssl and compile the code in Cygwin environment. My openssl version is 1.0.1h. With HTTP based OCSP, the code works fine. But, with HTTPs, the code gets stuck at the call to OCSP_sendreq_bio(). Further debugging shows that OCSP_sendreq_nbio() does not return. Did I need to something extra to deal with HTTPs based connection? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Oct 27 01:21:13 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 27 Oct 2015 02:21:13 +0100 Subject: [openssl-users] suggested enhancement documentation or warning for pkey command line tool In-Reply-To: <20151026130240.GM5570@mournblade.imrryr.org> References: <000901d10fe8$d53fc2d0$7fbf4870$@sales@free.fr> <20151026130240.GM5570@mournblade.imrryr.org> Message-ID: <562ED189.2040405@wisemo.com> On 26/10/2015 14:02, Viktor Dukhovni wrote: > On Mon, Oct 26, 2015 at 01:21:24PM +0100, Michel wrote: > >> I believe it might be usefull to remind in the documentation that the >> -cipher argment for openssl pkey command line tool is silently ignore when >> combined with -outform DER. >> >> May be it is worth to add a warning too ? > I think a fatal error would be appropriate. If you want encrypted > DER keys, you'll need PKCS#8 or PKCS#12. > But the issue is how to make the key conversion command in the openssl command line tool encrypt the output file, not which encryption format it should use. More specifically, the issue is that the currently recommended command "openssl pkey", allegedly silently omits the encryption when told not to Base64 encode the encrypted key, which is complete nonsense and would be considered a security issue in any other tool. I see no particular reason why the "openssl pkey" command should not encrypt the key in exactly the same way as it does when Base64 encoding the key, in other words the difference between -outform DER and -outform PEM should be *only* the Base64 encoding and the associated decorative text lines. Doing something highly dangerous (outputting a private key unencrypted contrary to user request) in response to an unrelated option (-outform DER) is a really bad thing. While on this subject, it would be most useful if all the openssl command line tools that can output private keys supported the same command line options to indicate encryption or lack thereof, specifically, those commands that currently default to unencrypted should still accept the "-nodes" command, and should complain if invoked with the "-passout" option but no encryption request. 5 to 10 years later, it should then be possible to change the default to encrypted, confident that adding explicit "-nodes" to scripts and examples will not fail on any reasonably maintained systems (including systems where openssl is built by some upstream OS maker). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From openssl-users at dukhovni.org Tue Oct 27 02:42:47 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 27 Oct 2015 02:42:47 +0000 Subject: [openssl-users] suggested enhancement documentation or warning for pkey command line tool In-Reply-To: <562ED189.2040405@wisemo.com> References: <000901d10fe8$d53fc2d0$7fbf4870$@sales@free.fr> <20151026130240.GM5570@mournblade.imrryr.org> <562ED189.2040405@wisemo.com> Message-ID: <20151027024246.GU5570@mournblade.imrryr.org> On Tue, Oct 27, 2015 at 02:21:13AM +0100, Jakob Bohm wrote: > More specifically, the issue is that the currently > recommended command "openssl pkey", allegedly silently > omits the encryption when told not to Base64 encode the > encrypted key. I agree this is a bug, and needs to be fixed. A fatal error seems best for now. Encrypting the DER object is more difficult, since the result needs to be able carry algorithm and IV metadata, which in the PEM version is *not* part of the base64 encoding. -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CBC,BCD9FB9A94F887A6CD391BBB244D01FC ... base64 bits... -----END RSA PRIVATE KEY----- For this to be generically possible with DER payloads, we'd need a new ASN.1 type for this type of encapsulation, which starts to look rather like a generalization of PKCS#8. Below is asn1parse output for a v2 pkcs8 object that uses aes-128-cbc. 0:d=0 hl=4 l= 719 cons: SEQUENCE 4:d=1 hl=2 l= 73 cons: SEQUENCE 6:d=2 hl=2 l= 9 prim: OBJECT :PBES2 17:d=2 hl=2 l= 60 cons: SEQUENCE 19:d=3 hl=2 l= 27 cons: SEQUENCE 21:d=4 hl=2 l= 9 prim: OBJECT :PBKDF2 32:d=4 hl=2 l= 14 cons: SEQUENCE 34:d=5 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:C81795B560A892AA 44:d=5 hl=2 l= 2 prim: INTEGER :0800 48:d=3 hl=2 l= 29 cons: SEQUENCE 50:d=4 hl=2 l= 9 prim: OBJECT :aes-128-cbc ... That would not be a simple or compatible change, so "pkey" would need to automatically switch to "pkcs8" when DER output is requested in combination with encryption, and there'd need to be some logic around automatically selecting v1.5 vs. v2.0 PBE algorithms. Is there a suitable standard DER format for generically encrypted objects that can generalize and replace PKCS#8? -- Viktor. From jb-openssl at wisemo.com Tue Oct 27 03:50:04 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 27 Oct 2015 04:50:04 +0100 Subject: [openssl-users] suggested enhancement documentation or warning for pkey command line tool In-Reply-To: <20151027024246.GU5570@mournblade.imrryr.org> References: <000901d10fe8$d53fc2d0$7fbf4870$@sales@free.fr> <20151026130240.GM5570@mournblade.imrryr.org> <562ED189.2040405@wisemo.com> <20151027024246.GU5570@mournblade.imrryr.org> Message-ID: <562EF46C.3030701@wisemo.com> On 27/10/2015 03:42, Viktor Dukhovni wrote: > On Tue, Oct 27, 2015 at 02:21:13AM +0100, Jakob Bohm wrote: > >> More specifically, the issue is that the currently >> recommended command "openssl pkey", allegedly silently >> omits the encryption when told not to Base64 encode the >> encrypted key. > I agree this is a bug, and needs to be fixed. A fatal error seems > best for now. > > Encrypting the DER object is more difficult, since the result needs > to be able carry algorithm and IV metadata, which in the PEM version > is *not* part of the base64 encoding. > > -----BEGIN RSA PRIVATE KEY----- > Proc-Type: 4,ENCRYPTED > DEK-Info: AES-128-CBC,BCD9FB9A94F887A6CD391BBB244D01FC > > ... base64 bits... > -----END RSA PRIVATE KEY----- I forgot about the IV (the others could be automagically guessed by code trying each in turn or based on options). > For this to be generically possible with DER payloads, we'd need > a new ASN.1 type for this type of encapsulation, which starts to > look rather like a generalization of PKCS#8. Below is asn1parse > output for a v2 pkcs8 object that uses aes-128-cbc. > > 0:d=0 hl=4 l= 719 cons: SEQUENCE > 4:d=1 hl=2 l= 73 cons: SEQUENCE > 6:d=2 hl=2 l= 9 prim: OBJECT :PBES2 > 17:d=2 hl=2 l= 60 cons: SEQUENCE > 19:d=3 hl=2 l= 27 cons: SEQUENCE > 21:d=4 hl=2 l= 9 prim: OBJECT :PBKDF2 > 32:d=4 hl=2 l= 14 cons: SEQUENCE > 34:d=5 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:C81795B560A892AA > 44:d=5 hl=2 l= 2 prim: INTEGER :0800 > 48:d=3 hl=2 l= 29 cons: SEQUENCE > 50:d=4 hl=2 l= 9 prim: OBJECT :aes-128-cbc > ... > > That would not be a simple or compatible change, so "pkey" would > need to automatically switch to "pkcs8" when DER output is requested > in combination with encryption, and there'd need to be some logic > around automatically selecting v1.5 vs. v2.0 PBE algorithms. Automatically switching methods would be just as big a surprise (but at least not as insecure) as the current behavior,so as long as pkey produces the "old SSLeay" PEM-needing format by default, the best solution would be to fatally reject attempts to produce that format is DER. Of cause there should be no fatal error if other options indicate a request for an unencrypted key (e.g. -nodes) or a format that works without extra PEM fields (e.g. PKCS#8). However to the extent not already there, there really should be an option to select between "old SSLeay" and PKCS#8 with various PBE algorithms. Preferably based on similar options in other openssl subcommands (apps), such as the -v1 and -v2 options to the pkcs8 subcommand, the additions would be -v0 alg for the old format and -nodes for not encrypting on output. Ideally, this could go in shared code used by all the private key file writing subcommands (apps). This is needed because some programs require the old input format for encrypted keys, while others require PKCS#8 (and a few accept either with autodetect). Transition proposal: Initially, a patch for supported OpenSSL versions would simply add the fatal error when trying to output the old encrypted private key format as DER. Next the version after 1.0.2 could add consistent private key encryption options to all the affected apps, while keeping the historic defaults of each command. Documentation would encourage explicitly specifying the desired format even if it happens to be the current default. Then after a long transition period (to get all manner of administrator scripts, tutorials and distribution tools updated), the defaults could change to something more consistent, but this would be years into the future. Think time between "LTS" distribution releases (varies by vendor), plus the traditional 5 year upgrade cycle in professional enterprises. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From tom.kacvinsky at vectorcast.com Tue Oct 27 17:13:16 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Tue, 27 Oct 2015 13:13:16 -0400 Subject: [openssl-users] Cryptographic export laws + OpenSSL Message-ID: Hi, What US cryptographic export laws apply to OpenSSL? I am in need of distributing the run time libraries (not the development kit), but I don't want to run afoul of export laws. Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Tue Oct 27 18:17:08 2015 From: marquess at openssl.com (Steve Marquess) Date: Tue, 27 Oct 2015 14:17:08 -0400 Subject: [openssl-users] Cryptographic export laws + OpenSSL In-Reply-To: References: Message-ID: <562FBFA4.3060401@openssl.com> On 10/27/2015 01:13 PM, Tom Kacvinsky wrote: > Hi, > > What US cryptographic export laws apply to OpenSSL? I am in need of > distributing the run time libraries (not the development kit), but I > don't want to run afoul of export laws. U.S. export law is a mess. Both "EAR" and "ITAR" can apply to OpenSSL derived code (ask me how I know from expensive personal experience). I get asked this question a lot in private E_mails, usually from corporate managers or lawyers. I have a standard blurb I send in response: We aren't lawyers, and don't pretend to have an adequate understanding of U.S. export regulations (or those of any other nation, for that matter). You really need to consult with competent export control lawyers. U.S. exports controls are complex and quite nonsensical from the perspective of the uninitiated professional software developer. That said, the standard blurb expressing our personal, unofficial, non-authoritative, uninformed, unverified, and thoroughly worthless opinion follows: The OpenSSL project is comprised almost entirely of non-U.S. citizens who reside outside of the U.S., as do the principal computer systems on which this software is developed, stored, and distributed. Hence the OpenSSL project proper does not submit notifications to, or obtain any export permissions from, the U.S. Department of Commerce or Department of State. OpenSSL Software Services (OSS) is a U.S. corporation. The function of the OSF is to handle commercial contracting for OpenSSL developers, some of who realize most or all of their personal income from such work. When OSS itself supplies software to clients who desire to export we do perform the TSU filing. However, vendors who import from openssl.org and then export independently of OSS are responsible for their own BIS and/or DDTC filings for their resulting products. Since the OpenSSL product in most applications meets the BIS definition of "open source" (a definition different than the conventional use of that term, incidentally) for ECCN 5D002 it typically qualifies for the TSU exception which amounts to an electronic notification and a source code distribution or online reference to same. Note that notification is required for every distinct version of such software, which can add up to a lot of notifications. Incidentally the Apache Software Foundation does a nice job of explaining it: http://www.apache.org/dev/crypto.html. They have also automated the notification process to streamline the otherwise substantial manpower cost. There is also some discussion of export restrictions in Appendix F of the OpenSSL FIPS Object Module User Guide, http://www.openssl.org/docs/fips/UserGuide.pdf Again, you really need to seek appropriate legal counsel and should not make any decisions based on any comments by OSF or OpenSSL. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From michel.sales at free.fr Tue Oct 27 19:32:07 2015 From: michel.sales at free.fr (Michel) Date: Tue, 27 Oct 2015 20:32:07 +0100 Subject: [openssl-users] suggested enhancement documentation or warning for pkey command line tool In-Reply-To: <562ED189.2040405@wisemo.com> References: <000901d10fe8$d53fc2d0$7fbf4870$@sales@free.fr> <20151026130240.GM5570@mournblade.imrryr.org> <562ED189.2040405@wisemo.com> Message-ID: <002101d110ee$2b2aa150$817fe3f0$@sales@free.fr> Thanks Viktor for your answer, and Jakob for clarifying my thought. My english isn't good enough to argue with both of you, but obviously, I do agree with what you have proposed. Michel. -----Message d'origine----- De?: openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de Jakob Bohm Envoy??: mardi 27 octobre 2015 02:21 ??: openssl-users at openssl.org Objet?: Re: [openssl-users] suggested enhancement documentation or warning for pkey command line tool On 26/10/2015 14:02, Viktor Dukhovni wrote: > On Mon, Oct 26, 2015 at 01:21:24PM +0100, Michel wrote: > >> I believe it might be usefull to remind in the documentation that the >> -cipher argment for openssl pkey command line tool is silently ignore when >> combined with -outform DER. >> >> May be it is worth to add a warning too ? > I think a fatal error would be appropriate. If you want encrypted > DER keys, you'll need PKCS#8 or PKCS#12. > But the issue is how to make the key conversion command in the openssl command line tool encrypt the output file, not which encryption format it should use. More specifically, the issue is that the currently recommended command "openssl pkey", allegedly silently omits the encryption when told not to Base64 encode the encrypted key, which is complete nonsense and would be considered a security issue in any other tool. I see no particular reason why the "openssl pkey" command should not encrypt the key in exactly the same way as it does when Base64 encoding the key, in other words the difference between -outform DER and -outform PEM should be *only* the Base64 encoding and the associated decorative text lines. Doing something highly dangerous (outputting a private key unencrypted contrary to user request) in response to an unrelated option (-outform DER) is a really bad thing. While on this subject, it would be most useful if all the openssl command line tools that can output private keys supported the same command line options to indicate encryption or lack thereof, specifically, those commands that currently default to unencrypted should still accept the "-nodes" command, and should complain if invoked with the "-passout" option but no encryption request. 5 to 10 years later, it should then be possible to change the default to encrypted, confident that adding explicit "-nodes" to scripts and examples will not fail on any reasonably maintained systems (including systems where openssl is built by some upstream OS maker). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From Walter.H at mathemainzel.info Tue Oct 27 20:21:54 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Tue, 27 Oct 2015 21:21:54 +0100 Subject: [openssl-users] OCSP_sendreq_bio() In-Reply-To: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> References: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> Message-ID: <562FDCE2.6070309@mathemainzel.info> On 26.10.2015 21:42, rosect190 at yahoo.com wrote: > Hi, I need some help on this call. > > I am building an OCSP client following guide in openssl and compile > the code in Cygwin environment. My openssl version is 1.0.1h. > > With HTTP based OCSP, the code works fine. But, with HTTPs, the code > gets stuck at the call to OCSP_sendreq_bio(). Further debugging shows > that OCSP_sendreq_nbio() does not return. > > Did I need to something extra to deal with HTTPs based connection? > OCSP must not be https ... the same with CRL download ... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4312 bytes Desc: S/MIME Cryptographic Signature URL: From ethan.rahn at gmail.com Tue Oct 27 22:35:42 2015 From: ethan.rahn at gmail.com (Ethan Rahn) Date: Tue, 27 Oct 2015 15:35:42 -0700 Subject: [openssl-users] Need help understanding tradeoffs of "-dsaparam" in dhparam Message-ID: Hello, I'm trying to understand the tradeoffs of using "-dsaparam" in the openssl "dhparam" command. I know that it won't create a strong prime , but I'm not understanding the tradeoffs with that very well. The wikipedia page says that primes with the strong property are not considered necessary by some cryptography experts, but I don't know what the tradeoffs of using "-dsaparam" are. Please note this is being used for a ( nginx-based ) SSL server if that helps provide context. I know that it is much faster. For generating a 2048-bit diffie-hellman parameter using "-dsaparam" takes ~10 seconds vs. ~30 minutes for the strong prime defaults on the server I'm testing it on. The downside is not very clear to me however. I know the man pages say "DH parameter generation with the -dsaparam option is much faster, and the recommended exponent length is shorter, which makes DH key exchange more efficient. Beware that with such DSA-style DH parameters, a fresh DH key should be created for each use to avoid small-subgroup attacks that may be possible otherwise." This isn't clear to me if each connection the SSL server makes should use a different dsaparam based dhparam? Is there another meaning here? Any clarifications on what I should beware of when using -dsaparam and what a "new use" is when knowing when to make fresh dh keys would be very appreciated. Thanks, Ethan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mksarav at gmail.com Wed Oct 28 03:56:45 2015 From: mksarav at gmail.com (M K Saravanan) Date: Wed, 28 Oct 2015 11:56:45 +0800 Subject: [openssl-users] Where to find the OCSP response signer cert if the OCSP response does not contain one? Message-ID: Hi, If the OCSP responder does not send the response signer certificate in the OCSP response, then how can we find the signer certificate? I was doing a simple test to verify google certificate via OCSP like this: $ openssl ocsp -issuer ./www.google.com.sg-issuer.cer -CAfile ./ca.cer -cert ./www.google.com.sg.cer -url http://clients1.google.com/ocsp -header Host clients1.google.com -no_nonce Response Verify Failure 2283136:error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found:ocsp_vfy.c:91: ./www.google.com.sg.cer: good This Update: Oct 27 14:35:13 2015 GMT Next Update: Nov 3 14:35:13 2015 GMT Upon checking the wireshark capture, I found the OCSP response does not send signer cert, but only the responderID (byKey). In such scenario, where do I find the OCSP response signer cert? with regards, Saravanan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mksarav at gmail.com Wed Oct 28 09:24:30 2015 From: mksarav at gmail.com (M K Saravanan) Date: Wed, 28 Oct 2015 17:24:30 +0800 Subject: [openssl-users] Where to find the OCSP response signer cert if the OCSP response does not contain one? In-Reply-To: References: Message-ID: Hi, > Upon checking the wireshark capture, I found the OCSP response does not send > signer cert, but only the responderID (byKey). > > In such scenario, where do I find the OCSP response signer cert? Clarifying my own question. https://tools.ietf.org/html/rfc6960#section-4.2.2.3 says: --------------- The purpose of the ResponderID information is to allow clients to find the certificate used to sign a signed OCSP response. Therefore, the information MUST correspond to the certificate that was used to sign the response. The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature. ----------------- I understand that it is not mandatory to send the OCSP response signer certificate in the OCSP response. So in such cases, where to find the OCSP response signer certificate? That is my question. with regards, Saravanan From jonetsu at teksavvy.com Wed Oct 28 15:20:05 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Wed, 28 Oct 2015 11:20:05 -0400 Subject: [openssl-users] OpenSSL public repository, bug tracker ? Message-ID: <8c4620c3ef98f0427921ff49769d08d1@teksavvy.com> Sorry if this is answered elsewhere ... Is the version control repository as well as the bug tracker of public read access ? Is it possible to find a specific commit in the OpenSSL repository that would hopefully fix a single discovered/reported bug ? We have hit the 'FIPS_CIPHERINIT:disabled for fips' in the 1.0.1e version running in FIPS mode and would like to apply the cde fix that hopefully fixes only that problem. ?Is it possible ? Thanks. From rsalz at akamai.com Wed Oct 28 15:28:22 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 28 Oct 2015 15:28:22 +0000 Subject: [openssl-users] OpenSSL public repository, bug tracker ? In-Reply-To: <8c4620c3ef98f0427921ff49769d08d1@teksavvy.com> References: <8c4620c3ef98f0427921ff49769d08d1@teksavvy.com> Message-ID: > Is the version control repository as well as the bug tracker of public read > access ? https://www.openssl.org/source/ From jb-openssl at wisemo.com Wed Oct 28 15:44:33 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 28 Oct 2015 16:44:33 +0100 Subject: [openssl-users] OCSP_sendreq_bio() In-Reply-To: <562FDCE2.6070309@mathemainzel.info> References: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <562FDCE2.6070309@mathemainzel.info> Message-ID: <5630ED61.2080106@wisemo.com> On 27/10/2015 21:21, Walter H. wrote: > On 26.10.2015 21:42, rosect190 at yahoo.com wrote: >> Hi, I need some help on this call. >> >> I am building an OCSP client following guide in openssl and compile >> the code in Cygwin environment. My openssl version is 1.0.1h. >> >> With HTTP based OCSP, the code works fine. But, with HTTPs, the code >> gets stuck at the call to OCSP_sendreq_bio(). Further debugging shows >> that OCSP_sendreq_nbio() does not return. >> >> Did I need to something extra to deal with HTTPs based connection? >> > OCSP must not be https ... > the same with CRL download ... Really, I thought that was only a recent cop out rule to cater to clients with inferior SSL libraries that can't handle the recursion. Of cause one should not initiate an HTTPS connection to a server to (directly or indirectly) validate the servers certificate for another such connection, but I know no inherent reason not to use HTTPS for CRL and OCSP access as long as infinite recursion is avoided, preferably through the choice of server certificates. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From jb-openssl at wisemo.com Wed Oct 28 15:47:55 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 28 Oct 2015 16:47:55 +0100 Subject: [openssl-users] Where to find the OCSP response signer cert if the OCSP response does not contain one? In-Reply-To: References: Message-ID: <5630EE2B.8070602@wisemo.com> On 28/10/2015 10:24, M K Saravanan wrote: > Hi, > >> Upon checking the wireshark capture, I found the OCSP response does not send >> signer cert, but only the responderID (byKey). >> >> In such scenario, where do I find the OCSP response signer cert? > Clarifying my own question. > > https://tools.ietf.org/html/rfc6960#section-4.2.2.3 says: > > --------------- > The purpose of the ResponderID information is to allow clients to > find the certificate used to sign a signed OCSP response. Therefore, > the information MUST correspond to the certificate that was used to > sign the response. > > The responder MAY include certificates in the certs field of > BasicOCSPResponse that help the OCSP client verify the responder's > signature. > ----------------- > I understand that it is not mandatory to send the OCSP response signer > certificate in the OCSP response. So in such cases, where to find the OCSP > response signer certificate? That is my question. Obvious first check is to see if it is the CA certificate that issued thecertificate you are checking. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From marquess at openssl.com Wed Oct 28 16:27:21 2015 From: marquess at openssl.com (Steve Marquess) Date: Wed, 28 Oct 2015 12:27:21 -0400 Subject: [openssl-users] OCSP_sendreq_bio() In-Reply-To: <5630ED61.2080106@wisemo.com> References: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <562FDCE2.6070309@mathemainzel.info> <5630ED61.2080106@wisemo.com> Message-ID: <5630F769.9050201@openssl.com> On 10/28/2015 11:44 AM, Jakob Bohm wrote: > On 27/10/2015 21:21, Walter H. wrote: >> ... >>> >> OCSP must not be https ... >> the same with CRL download ... > Really, I thought that was only a recent cop out rule to > cater to clients with inferior SSL libraries that can't > handle the recursion. > > Of cause one should not initiate an HTTPS connection to > a server to (directly or indirectly) validate the servers > certificate for another such connection, but I know no > inherent reason not to use HTTPS for CRL and OCSP access > as long as infinite recursion is avoided, preferably > through the choice of server certificates. There are environments where https must be used for OCSP, due to policy fiat and/or firewall restrictions. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From Walter.H at mathemainzel.info Wed Oct 28 16:36:18 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Wed, 28 Oct 2015 17:36:18 +0100 Subject: [openssl-users] OCSP_sendreq_bio() In-Reply-To: <5630ED61.2080106@wisemo.com> References: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <562FDCE2.6070309@mathemainzel.info> <5630ED61.2080106@wisemo.com> Message-ID: <5630F982.5050209@mathemainzel.info> On 28.10.2015 16:44, Jakob Bohm wrote: > On 27/10/2015 21:21, Walter H. wrote: >> On 26.10.2015 21:42, rosect190 at yahoo.com wrote: >>> Hi, I need some help on this call. >>> >>> I am building an OCSP client following guide in openssl and compile >>> the code in Cygwin environment. My openssl version is 1.0.1h. >>> >>> With HTTP based OCSP, the code works fine. But, with HTTPs, the code >>> gets stuck at the call to OCSP_sendreq_bio(). Further debugging >>> shows that OCSP_sendreq_nbio() does not return. >>> >>> Did I need to something extra to deal with HTTPs based connection? >>> >> OCSP must not be https ... >> the same with CRL download ... > Really, I thought that was only a recent cop out rule to > cater to clients with inferior SSL libraries that can't > handle the recursion. both OCSP and CRLs are signed, and this is enough for validation, there is no need of SSL; and an infinite recursion would be implied because of the need of validating these SSL-certificates the same way as the origin SSL-certificate ... but be aware the CRLs can be in an LDAP - done by bad CAs; OCSP must be HTTP Walter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4312 bytes Desc: S/MIME Cryptographic Signature URL: From Walter.H at mathemainzel.info Wed Oct 28 16:52:51 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Wed, 28 Oct 2015 17:52:51 +0100 Subject: [openssl-users] OCSP_sendreq_bio() In-Reply-To: <5630F769.9050201@openssl.com> References: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <562FDCE2.6070309@mathemainzel.info> <5630ED61.2080106@wisemo.com> <5630F769.9050201@openssl.com> Message-ID: <5630FD63.1030104@mathemainzel.info> On 28.10.2015 17:27, Steve Marquess wrote: > There are environments where https must be used for OCSP, due to policy > fiat and/or firewall restrictions. > > -Steve M. OCSP works through proxies; there is no reason for having such strange setups ... Walter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4312 bytes Desc: S/MIME Cryptographic Signature URL: From jb-openssl at wisemo.com Wed Oct 28 17:34:43 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 28 Oct 2015 18:34:43 +0100 Subject: [openssl-users] OCSP_sendreq_bio() In-Reply-To: <5630F982.5050209@mathemainzel.info> References: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <562FDCE2.6070309@mathemainzel.info> <5630ED61.2080106@wisemo.com> <5630F982.5050209@mathemainzel.info> Message-ID: <56310733.8080909@wisemo.com> On 28/10/2015 17:36, Walter H. wrote: > On 28.10.2015 16:44, Jakob Bohm wrote: >> On 27/10/2015 21:21, Walter H. wrote: >>> On 26.10.2015 21:42, rosect190 at yahoo.com wrote: >>>> Hi, I need some help on this call. >>>> >>>> I am building an OCSP client following guide in openssl and compile >>>> the code in Cygwin environment. My openssl version is 1.0.1h. >>>> >>>> With HTTP based OCSP, the code works fine. But, with HTTPs, the >>>> code gets stuck at the call to OCSP_sendreq_bio(). Further >>>> debugging shows that OCSP_sendreq_nbio() does not return. >>>> >>>> Did I need to something extra to deal with HTTPs based connection? >>>> >>> OCSP must not be https ... >>> the same with CRL download ... >> Really, I thought that was only a recent cop out rule to >> cater to clients with inferior SSL libraries that can't >> handle the recursion. > both OCSP and CRLs are signed, and this is enough for validation, > there is no need of SSL; How about privacy. Especially OCSP queries are very revealing, as they indicate the party sending the query is using that particular 3rd party certificate at that very moment. If the generals computer requests OCSP validation for weather.com, followed by OCSP validation for a service that reports sunrise/sunset, followed by OCSP validation for the e-mail certificates of his top lieutenants, this is as revealing as if he had sent the message "attack at dawn" in the clear. > and an infinite recursion would be implied because of > the need of validating these SSL-certificates the same way > as the origin SSL-certificate ... > Only if the SSL certificate for the OCSP or CRL server references itself as a way to check for revocation of *that* certificate (larger multi-step loops could also be built). However with careful choice/generation of certificates for the OCSP/CRL server, this can be easily avoided. > but be aware the CRLs can be in an LDAP - done by bad CAs; > OCSP must be HTTP I have mostly seen that for site-local CAs that already integrate all their other work with the same LDAP servers. I guess it could also be done by genuine X.500 directory systems as originally envisioned by the ITU (i.e. publishing the actual public phone book via DAP or LDAP, with distinguished names representing their originally intended phone book fields and certificates issued to phone line subscribes according to the usual telephone network hierarchy, CN=US,ST=CA,C=Klondyke,... Serial=1-555-555-5555), Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From reinier.torenbeek at gmail.com Wed Oct 28 20:42:45 2015 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Wed, 28 Oct 2015 16:42:45 -0400 Subject: [openssl-users] Const qualifier for EVP_PKEY parameters in pub_encode method Message-ID: <56313345.7000306@gmail.com> Hi, While implementing an engine, I run into the following prototype that I need to implement: struct evp_pkey_asn1_method_st { int (*pub_encode)(X509_PUBKEY *pub, *const* EVP_PKEY *pk); } /* EVP_PKEY_ASN1_METHOD */; Inside this function, I want to assign pk to pub->pkey (and do the necessary up and down reffing of the EVP_PKEYs involved). But that is not allowed, because of the const qualifier on pk. For now, I have just worked around the compiler complaints by casting to a non-const, but I wonder whether this will bite me at some point? Thanks, Reinier -------------- next part -------------- An HTML attachment was scrubbed... URL: From reinier.torenbeek at gmail.com Wed Oct 28 20:54:59 2015 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Wed, 28 Oct 2015 16:54:59 -0400 Subject: [openssl-users] Freeing of const char * fields in ASN1_OBJECT Message-ID: <56313623.1040100@gmail.com> Hi, The following looks wrong and actually resulted in a crash for me before I decided to do things differently: In asn1/asn1.h, the fields sn and ln in ASN1_OBJECT are defined as const char *: 211 typedef struct asn1_object_st 212 { 213 const char *sn,*ln; 214 int nid; 215 int length; 216 const unsigned char *data; /* data remains const after init */ 217 int flags; /* Should we free this one */ 218 } ASN1_OBJECT; but in asn1/a_object.c, the get casted to void * and freed: 378 void ASN1_OBJECT_free(ASN1_OBJECT *a) 379 { 380 if (a == NULL) return; 381 if (a->flags & ASN1_OBJECT_FLAG_DYNAMIC_STRINGS) 382 { 383 #ifndef CONST_STRICT /* disable purely for compile-time strict const checking. Doing this on a "real" compile will cause memory leaks */ 384 if (a->sn != NULL) OPENSSL_free((void *)a->sn); 385 if (a->ln != NULL) OPENSSL_free((void *)a->ln); 386 #endif Given that a lot of the code is supposed to be self-describing (due to lack of documentation), it is somewhat disturbing that I can not rely on the const qualifiers to be honored. Any thoughts on this? Thanks, Reinier From Walter.H at mathemainzel.info Wed Oct 28 20:58:06 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Wed, 28 Oct 2015 21:58:06 +0100 Subject: [openssl-users] OCSP_sendreq_bio() In-Reply-To: <56310733.8080909@wisemo.com> References: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <562FDCE2.6070309@mathemainzel.info> <5630ED61.2080106@wisemo.com> <5630F982.5050209@mathemainzel.info> <56310733.8080909@wisemo.com> Message-ID: <563136DE.2000103@mathemainzel.info> On 28.10.2015 18:34, Jakob Bohm wrote: > On 28/10/2015 17:36, Walter H. wrote: >> On 28.10.2015 16:44, Jakob Bohm wrote: >>> On 27/10/2015 21:21, Walter H. wrote: >>>> On 26.10.2015 21:42, rosect190 at yahoo.com >>>> wrote: >>>>> Hi, I need some help on this call. >>>>> >>>>> I am building an OCSP client following guide in openssl and >>>>> compile the code in Cygwin environment. My openssl version is 1.0.1h. >>>>> >>>>> With HTTP based OCSP, the code works fine. But, with HTTPs, the >>>>> code gets stuck at the call to OCSP_sendreq_bio(). Further >>>>> debugging shows that OCSP_sendreq_nbio() does not return. >>>>> >>>>> Did I need to something extra to deal with HTTPs based connection? >>>>> >>>> OCSP must not be https ... >>>> the same with CRL download ... >>> Really, I thought that was only a recent cop out rule to >>> cater to clients with inferior SSL libraries that can't >>> handle the recursion. >> both OCSP and CRLs are signed, and this is enough for validation, >> there is no need of SSL; > How about privacy. Especially OCSP queries are very > revealing, as they indicate the party sending the query > is using that particular 3rd party certificate at that > very moment. > what would someone really know, if he would catch the OCSP request of the attached certificate? privacy is not really the problem ... there is one thing that is problematic - especially if the CA is somewhat stupid: using one responder certificate for all OCSP responses for any end entity certificate ... (the specific RFC says, that it is discouraged to do so) faking the OCSP response by 3rd party to pretend a good certificate even it is bad, is quite a little bit difficult, but easy if the CA is stupid ... so it is a bad idea having a OCSP Responder certificate that was not signed by the CA that has signed the end entitiy certificate > Only if the SSL certificate for the OCSP or CRL server > references itself as a way to check for revocation of > *that* certificate (larger multi-step loops could also > be built). > > However with careful choice/generation of certificates > for the OCSP/CRL server, this can be easily avoided. > easily - are you sure? example: (a) you want to check cert 1 that was signed by the CAs cert A (b) the server uses certificate 2 that was signed by the CAs cert B with https this would be the following: to access the CRL or OCSP of cert 1, you need to validate cert 2, that itself is needed to access the CRL or OCSP of cert 2, too? do you really think is makes any sense, using https for CRLs download or OCSP? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ssl-cert.pem URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4312 bytes Desc: S/MIME Cryptographic Signature URL: From Michael.Wojcik at microfocus.com Thu Oct 29 03:02:43 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 29 Oct 2015 03:02:43 +0000 Subject: [openssl-users] Freeing of const char * fields in ASN1_OBJECT In-Reply-To: <56313623.1040100@gmail.com> References: <56313623.1040100@gmail.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Reinier Torenbeek > Sent: Wednesday, October 28, 2015 16:55 > > In asn1/asn1.h, the fields sn and ln in ASN1_OBJECT are defined as const > char *: > > 211 typedef struct asn1_object_st > 212 { > 213 const char *sn,*ln; > 214 int nid; > 215 int length; > 216 const unsigned char *data; /* data remains const after > init */ > 217 int flags; /* Should we free this one */ > 218 } ASN1_OBJECT; > > but in asn1/a_object.c, the get casted to void * and freed: >... > > Given that a lot of the code is supposed to be self-describing (due to > lack of documentation), it is somewhat disturbing that I can not rely on > the const qualifiers to be honored. Any thoughts on this? It's a well-known problem with the semantics of const in C. The parameter to free() cannot have the const qualifier, because the semantics of free say that the object referred to by the pointer reaches the end of its lifetime during the call to free(), and attempting to use it after that results in Undefined Behavior. However, it is perfectly reasonable to want to allocate storage, initialize (and even alter) its contents, but have that object treated only as an rvalue elsewhere. This is a very typical use case for a library or other code that presents an ADT (abstract data type) to a caller. The mechanism for informing a caller that an object should not be modified is the const qualifier. There are only two ways around this problem. One is for the ADT implementation to keep both a const and a non-const pointer to the same area, publish the const one, and use the non-const one for freeing. That's a rather absurd duplication of effort (and a small amount of storage) just to account for C's simplistic const/free semantics. The other way, which is the one everyone uses, is to cast away the constness of the pointer when passing it to free. Note that the problem arises in other contexts. That's why C++ has a category of casts just for this purpose (casting away constness). Another case you often see is a function in an external library that never modifies the object pointed to by a parameter, but failed to declare it as const (generally because it was written by someone who doesn't understand C, which is to say ~97% of all C programmers). As a rule of thumb, when a function parameter itself is a pointer to a const-qualified object type (this doesn't apply to const pointers to non-const objects), you should be able to assume that the function does not change the object. When a function parameter is a pointer to a non-const-qualified aggregate type (struct or union) that happens to include const-qualified members, do NOT assume that there are no cases in which those objects are modified. You really have to check the implementation of that function. C function contracts are weak. Now, a *good* public C library will implement proper ADTs. It will define them as pointers to incomplete structures, so you can't go poking around inside them; it will give you construction and cleanup functions; and it will give you accessor functions. Some people will complain that at that point you're no longer writing C - you're reinventing C++ - to which I'd reply that they don't really understand C or C++. -- Michael Wojcik Technology Specialist, Micro Focus From jb-openssl at wisemo.com Thu Oct 29 10:07:58 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 29 Oct 2015 11:07:58 +0100 Subject: [openssl-users] OCSP_sendreq_bio() In-Reply-To: <563136DE.2000103@mathemainzel.info> References: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <562FDCE2.6070309@mathemainzel.info> <5630ED61.2080106@wisemo.com> <5630F982.5050209@mathemainzel.info> <56310733.8080909@wisemo.com> <563136DE.2000103@mathemainzel.info> Message-ID: <5631EFFE.2050405@wisemo.com> On 28/10/2015 21:58, Walter H. wrote: > On 28.10.2015 18:34, Jakob Bohm wrote: >> On 28/10/2015 17:36, Walter H. wrote: >>> On 28.10.2015 16:44, Jakob Bohm wrote: >>>> On 27/10/2015 21:21, Walter H. wrote: >>>>> On 26.10.2015 21:42, rosect190 at yahoo.com >>>>> wrote: >>>>>> Hi, I need some help on this call. >>>>>> >>>>>> I am building an OCSP client following guide in openssl and >>>>>> compile the code in Cygwin environment. My openssl version is >>>>>> 1.0.1h. >>>>>> >>>>>> With HTTP based OCSP, the code works fine. But, with HTTPs, the >>>>>> code gets stuck at the call to OCSP_sendreq_bio(). Further >>>>>> debugging shows that OCSP_sendreq_nbio() does not return. >>>>>> >>>>>> Did I need to something extra to deal with HTTPs based connection? >>>>>> >>>>> OCSP must not be https ... >>>>> the same with CRL download ... >>>> Really, I thought that was only a recent cop out rule to >>>> cater to clients with inferior SSL libraries that can't >>>> handle the recursion. >>> both OCSP and CRLs are signed, and this is enough for validation, >>> there is no need of SSL; >> How about privacy. Especially OCSP queries are very >> revealing, as they indicate the party sending the query >> is using that particular 3rd party certificate at that >> very moment. >> > what would someone really know, if he would catch the OCSP request of > the attached certificate? > privacy is not really the problem ... > She (Eve) would know that the requesting party Alice was talking to Bob at the very moment she sent Trent the OCSP *request* for Bob's certificate. And by just listening to that one address (the unencrypted requests being sent to OCSP responder Trent), Eve would essentially get the Internet equivalent of having (almost complete) real time copies of everybody's phone bill/call records. Who was calling who at what time. That's very valuable private information which Eve could otherwise get only by monitoring traffic at thousands of Internet routers. And as an added bonus, she gets to see when Alice is reading e-mails signed by Bob (because Alice's e-mail program would make an OCSP request when it checks the signature as she opens the mail that is already stored behind Alice's high strength firewall. With https-encrypted OCSP transactions, all she can see is that Alice is doing *something* that involves checking *some* *unknown* certificate issued by Trent. Only Alice and Trent would know which one. With https-encrypted CRL requests, Eve can see much less, as all she will know is the first time in each CRL-period Alice is checking some Trent-issued certificate, and perhaps even less if Trent has other popular data on that https server or Alice's computer downloads the CRLs for trusted CAs on a schedule regardless if Alice is even in the building. If Trent is a provider of Antivirus, a popular video download site or anything else that responds to millions of other https downloads unrelated to interesting activity, putting the CRLs on that same server will make even this information near impossible to observe. CRLs over http reveals the CRL access information with more accuracy as it cannot get hidden in a flux of other requests. On the authenticity side, using https provides a direct proof that non only is the validity information not stale (past its end date), but it is the most recent the server had at the time of the request, not slightly older information provided by an active attacker who wants to use a compromised certificate a little bit longer than the time it takes the CA to revoke it. For OCSP that could alternatively be achieved without the other benefits by using the nonce option in the OCSP request, but this alternative would not solve the other problems and wouldn't work for CRLs. > there is one thing that is problematic - especially if the CA is > somewhat stupid: > using one responder certificate for all OCSP responses for any end > entity certificate ... > (the specific RFC says, that it is discouraged to do so) This is not about the OCSP-response signing certificate (or the CRL signing certificate). Those are unavoidable and have already established practices for avoiding the chicken/egg problem of revocation checking. It is about the https SSL certificate of the web server that provides access to the OCSP-response service and/or the CRL download service. > > faking the OCSP response by 3rd party to pretend a good certificate > even it is bad, > is quite a little bit difficult, but easy if the CA is stupid ... > > so it is a bad idea having a OCSP Responder certificate > that was not signed by the CA that has signed the end entitiy certificate > >> Only if the SSL certificate for the OCSP or CRL server >> references itself as a way to check for revocation of >> *that* certificate (larger multi-step loops could also >> be built). >> >> However with careful choice/generation of certificates >> for the OCSP/CRL server, this can be easily avoided. >> > easily - are you sure? > > example: > > (a) you want to check cert 1 that was signed by the CAs cert A > (b) the server uses certificate 2 that was signed by the CAs cert B > > with https this would be the following: > to access the CRL or OCSP of cert 1, you need to validate cert 2, > that itself is needed to access the CRL or OCSP of cert 2, too? > As I said it involves recursion and the trick is to terminate that recursion before it gets infinitely deep. One obvious way is that at some (not too deep) level of recursion, the certificate to be checked (whose private key is that of a trusted CA-owned machine anyway) doesn't specify an OCSP responder or a https CRL URL, just like the rules that already govern the revocation checking extensions in OCSP- signing and CRL-signing certificates. And the checking of that shared deep-level CA-owned certificate is a lot less revealing of Alice's activity than the checking of a specific certificate related to Alice's current non-protocol activity. Another obvious way would be for that final https server to do OCSP-stapling, thus terminating the recursion for any relying party (Alice) whose client software knows how to parse and validate OCSP-stapled validity proofs. > do you really think is makes any sense, using https for CRLs download > or OCSP? > See my longer response above about the specific security dangers inherent in using plain http for OCSP and (to a lesser degree) CRLs. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From walter.h at mathemainzel.info Thu Oct 29 13:30:21 2015 From: walter.h at mathemainzel.info (Walter H.) Date: Thu, 29 Oct 2015 14:30:21 +0100 Subject: [openssl-users] Thoughts about security, privacy, ... (was: OCSP_sendreq_bio()) In-Reply-To: <5631EFFE.2050405@wisemo.com> References: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <562FDCE2.6070309@mathemainzel.info> <5630ED61.2080106@wisemo.com> <5630F982.5050209@mathemainzel.info> <56310733.8080909@wisemo.com> <563136DE.2000103@mathemainzel.info> <5631EFFE.2050405@wisemo.com> Message-ID: <2df14a9cef1403650fc83588b959371d.1446125421@squirrel.mail> Hello Jabob, On Thu, October 29, 2015 11:07, Jakob Bohm wrote: > On 28/10/2015 21:58, Walter H. wrote: >> On 28.10.2015 18:34, Jakob Bohm wrote: >>> On 28/10/2015 17:36, Walter H. wrote: >>>>>> OCSP must not be https ... >>>>>> the same with CRL download ... >>>>> Really, I thought that was only a recent cop out rule to >>>>> cater to clients with inferior SSL libraries that can't >>>>> handle the recursion. >>>> both OCSP and CRLs are signed, and this is enough for validation, >>>> there is no need of SSL; >>> How about privacy. Especially OCSP queries are very >>> revealing, as they indicate the party sending the query >>> is using that particular 3rd party certificate at that >>> very moment. >>> >> what would someone really know, if he would catch the OCSP request of >> the attached certificate? >> privacy is not really the problem ... >> > She (Eve) would know that the requesting party Alice > was talking to Bob at the very moment she sent Trent > the OCSP *request* for Bob's certificate. > > [...] equivalent of having (almost complete) real time > copies of everybody's phone bill/call records. > Who was calling who at what time. this is not a problem as long as the public keys (the certificates) are not really public; because in your example Eve doesn't have the knowledge which certificate the specific serial number has ... if the public keys (the certificates) are searchable by public - the worst case direct by a search engine like google - then you would get an absolute security whole: think of some bad boys, they could get such certificates and get two things with these: a valid e-mail address and everything they need to send encrypted data to this e-mail address, and with this: they can send anything: malware, spyware, whatever; no antivirus, spamfilter, or whatever on any mailserver would stop such emails; everything hangs on the client ... the scenario you gave above is the less problem ... >> there is one thing that is problematic - especially if the CA is >> somewhat stupid: >> using one responder certificate for all OCSP responses for any end >> entity certificate ... >> (the specific RFC says, that it is discouraged to do so) > This is not about the OCSP-response signing certificate > (or the CRL signing certificate). No it is about them ... https://www.rfc-editor.org/rfc/pdfrfc/rfc6960.txt.pdf (stupid CAs - I know at least one - ignore the section on top of page 17) with such CAs it is easy to pretend something different ... >> faking the OCSP response by 3rd party to pretend a good certificate >> even it is bad, >> is quite a little bit difficult, but easy if the CA is stupid ... >> >>> However with careful choice/generation of certificates >>> for the OCSP/CRL server, this can be easily avoided. >>> >> easily - are you sure? >> >> example: >> >> (a) you want to check cert 1 that was signed by the CAs cert A >> (b) the server uses certificate 2 that was signed by the CAs cert B >> >> with https this would be the following: >> to access the CRL or OCSP of cert 1, you need to validate cert 2, >> that itself is needed to access the CRL or OCSP of cert 2, too? >> > As I said it involves recursion and the trick is to > terminate that recursion before it gets infinitely > deep. it is more a deadlock than a recursion ... > Another obvious way would be for that final https > server to do OCSP-stapling, this would be a solution but as soon as using SSL/TLS layer communication for CRL download or OCSP, for whatever reason, accepting OCSP-stapling is strongly discouraged, this is nearly like self-signed ... I'd say security is more important privacy; Greetings, Walter From reinier.torenbeek at gmail.com Thu Oct 29 20:31:49 2015 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Thu, 29 Oct 2015 16:31:49 -0400 Subject: [openssl-users] Freeing of const char * fields in ASN1_OBJECT In-Reply-To: References: <56313623.1040100@gmail.com> Message-ID: <56328235.8090708@gmail.com> Hi Michael, Many thanks for the extensive explanation, I understand the rationale now. > Now, a *good* public C library will implement proper ADTs. Indeed I am used to using ADT mechanisms so I did not run into this issue anywhere else before. It will be a lot of work to make all types abstracted in OpenSSL... However, as a compromise, I wonder how much work it would be to at least provide encapsulating allocator/initializer and free functions for all datatypes. In that case, the const qualifier for some fields in the struct would make complete sense and the fact that the const field is allocated/freed by the library is then no longer anybody else's business. My problem was indeed resolved by using OBJ_create(), so from now on I will be looking for creation functions rather than assuming that I am supposed/allowed to create my own structs directly. Reinier PS: apparently there are more reasons to cast away const-ness; I ran into the following in objects/obj_lib.c: 65 ASN1_OBJECT *OBJ_dup(const ASN1_OBJECT *o) 66 { 67 ASN1_OBJECT *r; 68 int i; 69 char *ln=NULL,*sn=NULL; 70 unsigned char *data=NULL; 71 72 if (o == NULL) return(NULL); 73 if (!(o->flags & ASN1_OBJECT_FLAG_DYNAMIC)) 74 return((ASN1_OBJECT *)o); /* XXX: ugh! Why? What kind of 75 duplication is this??? */ On 10/28/15 11:02 PM, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Reinier Torenbeek >> Sent: Wednesday, October 28, 2015 16:55 >> >> In asn1/asn1.h, the fields sn and ln in ASN1_OBJECT are defined as const >> char *: >> >> 211 typedef struct asn1_object_st >> 212 { >> 213 const char *sn,*ln; >> 214 int nid; >> 215 int length; >> 216 const unsigned char *data; /* data remains const after >> init */ >> 217 int flags; /* Should we free this one */ >> 218 } ASN1_OBJECT; >> >> but in asn1/a_object.c, the get casted to void * and freed: >> ... >> >> Given that a lot of the code is supposed to be self-describing (due to >> lack of documentation), it is somewhat disturbing that I can not rely on >> the const qualifiers to be honored. Any thoughts on this? > It's a well-known problem with the semantics of const in C. > > The parameter to free() cannot have the const qualifier, because the semantics of free say that the object referred to by the pointer reaches the end of its lifetime during the call to free(), and attempting to use it after that results in Undefined Behavior. > > However, it is perfectly reasonable to want to allocate storage, initialize (and even alter) its contents, but have that object treated only as an rvalue elsewhere. This is a very typical use case for a library or other code that presents an ADT (abstract data type) to a caller. > > The mechanism for informing a caller that an object should not be modified is the const qualifier. > > There are only two ways around this problem. One is for the ADT implementation to keep both a const and a non-const pointer to the same area, publish the const one, and use the non-const one for freeing. That's a rather absurd duplication of effort (and a small amount of storage) just to account for C's simplistic const/free semantics. > > The other way, which is the one everyone uses, is to cast away the constness of the pointer when passing it to free. > > Note that the problem arises in other contexts. That's why C++ has a category of casts just for this purpose (casting away constness). Another case you often see is a function in an external library that never modifies the object pointed to by a parameter, but failed to declare it as const (generally because it was written by someone who doesn't understand C, which is to say ~97% of all C programmers). > > As a rule of thumb, when a function parameter itself is a pointer to a const-qualified object type (this doesn't apply to const pointers to non-const objects), you should be able to assume that the function does not change the object. When a function parameter is a pointer to a non-const-qualified aggregate type (struct or union) that happens to include const-qualified members, do NOT assume that there are no cases in which those objects are modified. You really have to check the implementation of that function. > > C function contracts are weak. > > Now, a *good* public C library will implement proper ADTs. It will define them as pointers to incomplete structures, so you can't go poking around inside them; it will give you construction and cleanup functions; and it will give you accessor functions. Some people will complain that at that point you're no longer writing C - you're reinventing C++ - to which I'd reply that they don't really understand C or C++. > From hokusai at gmx.ch Fri Oct 30 12:27:43 2015 From: hokusai at gmx.ch (hokusai at gmx.ch) Date: Fri, 30 Oct 2015 13:27:43 +0100 Subject: [openssl-users] Clarification about content of folder /ocsp Message-ID: An HTML attachment was scrubbed... URL: From mseaborn62 at hotmail.com Fri Oct 30 14:00:07 2015 From: mseaborn62 at hotmail.com (Mark) Date: Fri, 30 Oct 2015 07:00:07 -0700 (MST) Subject: [openssl-users] FIPS OpenSSL Test Harness and RSA PSS In-Reply-To: <1446120598356-60789.post@n7.nabble.com> References: <1446120598356-60789.post@n7.nabble.com> Message-ID: <1446213607371-60798.post@n7.nabble.com> We have moved to just using Salt 0 for now but would like to get some help with the Salt Len 62 issues. Does anyone have any special instructions for this? -- View this message in context: http://openssl.6102.n7.nabble.com/FIPS-OpenSSL-Test-Harness-and-RSA-PSS-tp60789p60798.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From rsalz at akamai.com Fri Oct 30 20:15:05 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 30 Oct 2015 20:15:05 +0000 Subject: [openssl-users] Clarification about content of folder /ocsp In-Reply-To: References: Message-ID: > I could not find any API documentation about the code in /crypto/ocsp. Does it mean that these functions are not part of the official API and therefore should not be directly used? ? No, it just means that the documentation has not been written. From matt at openssl.org Fri Oct 30 20:22:57 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 30 Oct 2015 20:22:57 +0000 Subject: [openssl-users] Clarification about content of folder /ocsp In-Reply-To: References: Message-ID: <5633D1A1.7040906@openssl.org> On 30/10/15 20:15, Salz, Rich wrote: > >> I could not find any API documentation about the code in /crypto/ocsp. Does it mean that these functions are not part of the official API and therefore should not be directly used? > > No, it just means that the documentation has not been written. Steve wrote some documentation for OCSP not that long ago. Looks like its only in master though: https://www.openssl.org/docs/manmaster/crypto/OCSP_sendreq_new.html https://www.openssl.org/docs/manmaster/crypto/OCSP_response_status.html https://www.openssl.org/docs/manmaster/crypto/OCSP_response_find_status.html https://www.openssl.org/docs/manmaster/crypto/OCSP_REQUEST_new.html https://www.openssl.org/docs/manmaster/crypto/OCSP_request_add1_nonce.html https://www.openssl.org/docs/manmaster/crypto/OCSP_cert_to_id.html Matt From michael at stroeder.com Fri Oct 30 20:42:15 2015 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Fri, 30 Oct 2015 21:42:15 +0100 Subject: [openssl-users] Thoughts about security, privacy, ... In-Reply-To: <2df14a9cef1403650fc83588b959371d.1446125421@squirrel.mail> References: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <562FDCE2.6070309@mathemainzel.info> <5630ED61.2080106@wisemo.com> <5630F982.5050209@mathemainzel.info> <56310733.8080909@wisemo.com> <563136DE.2000103@mathemainzel.info> <5631EFFE.2050405@wisemo.com> <2df14a9cef1403650fc83588b959371d.1446125421@squirrel.mail> Message-ID: <5633D627.607@stroeder.com> Walter H. wrote: > On Thu, October 29, 2015 11:07, Jakob Bohm wrote: >> She (Eve) would know that the requesting party Alice >> was talking to Bob at the very moment she sent Trent >> the OCSP *request* for Bob's certificate. >> >> [...] equivalent of having (almost complete) real time >> copies of everybody's phone bill/call records. >> Who was calling who at what time. > > this is not a problem as long as the public keys (the certificates) are > not really public; > because in your example Eve doesn't have the knowledge which certificate > the specific serial number has ... > > if the public keys (the certificates) are searchable by public - the worst > case direct by a search engine like google - then you would get an > absolute security whole: Update for you: https://crt.sh/ Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4245 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Fri Oct 30 20:38:32 2015 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Fri, 30 Oct 2015 21:38:32 +0100 Subject: [openssl-users] OCSP_sendreq_bio() In-Reply-To: <5630F982.5050209@mathemainzel.info> References: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <562FDCE2.6070309@mathemainzel.info> <5630ED61.2080106@wisemo.com> <5630F982.5050209@mathemainzel.info> Message-ID: <5633D548.5070605@stroeder.com> Walter H. wrote: > On 28.10.2015 16:44, Jakob Bohm wrote: >> On 27/10/2015 21:21, Walter H. wrote: >>> On 26.10.2015 21:42, rosect190 at yahoo.com wrote: >>>> Hi, I need some help on this call. >>>> >>>> I am building an OCSP client following guide in openssl and compile the >>>> code in Cygwin environment. My openssl version is 1.0.1h. >>>> >>>> With HTTP based OCSP, the code works fine. But, with HTTPs, the code gets >>>> stuck at the call to OCSP_sendreq_bio(). Further debugging shows that >>>> OCSP_sendreq_nbio() does not return. >>>> >>>> Did I need to something extra to deal with HTTPs based connection? >>>> >>> OCSP must not be https ... >>> the same with CRL download ... >> Really, I thought that was only a recent cop out rule to >> cater to clients with inferior SSL libraries that can't >> handle the recursion. > both OCSP and CRLs are signed, and this is enough for validation, > there is no need of SSL; There are some privacy concerns with OCSP usage. So using TLS to protect the traffic against sniffing would be good. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4245 bytes Desc: S/MIME Cryptographic Signature URL: From Walter.H at mathemainzel.info Fri Oct 30 21:23:36 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Fri, 30 Oct 2015 22:23:36 +0100 Subject: [openssl-users] Thoughts about security, privacy, ... In-Reply-To: <5633D627.607@stroeder.com> References: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <562FDCE2.6070309@mathemainzel.info> <5630ED61.2080106@wisemo.com> <5630F982.5050209@mathemainzel.info> <56310733.8080909@wisemo.com> <563136DE.2000103@mathemainzel.info> <5631EFFE.2050405@wisemo.com> <2df14a9cef1403650fc83588b959371d.1446125421@squirrel.mail> <5633D627.607@stroeder.com> Message-ID: <5633DFD8.1000102@mathemainzel.info> On 30.10.2015 21:42, Michael Str?der wrote: > Walter H. wrote: >> On Thu, October 29, 2015 11:07, Jakob Bohm wrote: >>> She (Eve) would know that the requesting party Alice >>> was talking to Bob at the very moment she sent Trent >>> the OCSP *request* for Bob's certificate. >>> >>> [...] equivalent of having (almost complete) real time >>> copies of everybody's phone bill/call records. >>> Who was calling who at what time. >> this is not a problem as long as the public keys (the certificates) are >> not really public; >> because in your example Eve doesn't have the knowledge which certificate >> the specific serial number has ... >> >> if the public keys (the certificates) are searchable by public - the worst >> case direct by a search engine like google - then you would get an >> absolute security whole: > Update for you: https://crt.sh/ > you know the difference between SSL and S/MIME? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4312 bytes Desc: S/MIME Cryptographic Signature URL: From wilson.judson at gmail.com Sat Oct 31 04:41:13 2015 From: wilson.judson at gmail.com (Judson Wilson) Date: Fri, 30 Oct 2015 21:41:13 -0700 Subject: [openssl-users] Renegotiation procedure (server side) Message-ID: I have seen several sources suggest that the following psuedo code procedure should force a renegotiation before proceeding: SSL_renegotiate(...); while(SSL_renegotation_pending(...)) SSL_do_handshake(...); I am using non-blocking I/O, and have ommitted error handling and any lower-level I/O management from this example. Calling this from the server, I see a Hello Request sent from the server to the client, and a Client Hello sent from the client to the server. Then nothing happens; the server does not respond. I believe that SSL_do_handshake does nothing to handle the actual handshake in this scenario. The code appears to be stuck in the loop. What is the actual sequence of events, from an API user perspective, that should result in a successful renegotiation? I have a theory, but I'd like some untainted feedback. :) Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Sat Oct 31 12:01:00 2015 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sat, 31 Oct 2015 13:01:00 +0100 Subject: [openssl-users] Thoughts about security, privacy, ... In-Reply-To: <5633DFD8.1000102@mathemainzel.info> References: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <562FDCE2.6070309@mathemainzel.info> <5630ED61.2080106@wisemo.com> <5630F982.5050209@mathemainzel.info> <56310733.8080909@wisemo.com> <563136DE.2000103@mathemainzel.info> <5631EFFE.2050405@wisemo.com> <2df14a9cef1403650fc83588b959371d.1446125421@squirrel.mail> <5633D627.607@stroeder.com> <5633DFD8.1000102@mathemainzel.info> Message-ID: <5634AD7C.2020200@stroeder.com> Walter H. wrote: > On 30.10.2015 21:42, Michael Str?der wrote: >> Walter H. wrote: >>> On Thu, October 29, 2015 11:07, Jakob Bohm wrote: >>>> She (Eve) would know that the requesting party Alice >>>> was talking to Bob at the very moment she sent Trent >>>> the OCSP *request* for Bob's certificate. >>>> >>>> [...] equivalent of having (almost complete) real time >>>> copies of everybody's phone bill/call records. >>>> Who was calling who at what time. >>> this is not a problem as long as the public keys (the certificates) are >>> not really public; >>> because in your example Eve doesn't have the knowledge which certificate >>> the specific serial number has ... >>> >>> if the public keys (the certificates) are searchable by public - the worst >>> case direct by a search engine like google - then you would get an >>> absolute security whole: >> Update for you: https://crt.sh/ >> > you know the difference between SSL and S/MIME? I know the difference very well - probably even longer than you. Note: 1. Google's certificate transparency project is not limited to certain certificate types. 2. Privacy concerns are raised because of browsers validating server certs via OCSP during TLS connect. => OCSP should be feasible over TLS in the spirit of RFC 7258. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4245 bytes Desc: S/MIME Cryptographic Signature URL: From Walter.H at mathemainzel.info Sat Oct 31 18:11:29 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Sat, 31 Oct 2015 19:11:29 +0100 Subject: [openssl-users] Thoughts about security, privacy, ... In-Reply-To: <5634AD7C.2020200@stroeder.com> References: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <562FDCE2.6070309@mathemainzel.info> <5630ED61.2080106@wisemo.com> <5630F982.5050209@mathemainzel.info> <56310733.8080909@wisemo.com> <563136DE.2000103@mathemainzel.info> <5631EFFE.2050405@wisemo.com> <2df14a9cef1403650fc83588b959371d.1446125421@squirrel.mail> <5633D627.607@stroeder.com> <5633DFD8.1000102@mathemainzel.info> <5634AD7C.2020200@stroeder.com> Message-ID: <56350451.1040107@mathemainzel.info> On 31.10.2015 13:01, Michael Str?der wrote: > Walter H. wrote: >> On 30.10.2015 21:42, Michael Str?der wrote: >>> Walter H. wrote: >>>> On Thu, October 29, 2015 11:07, Jakob Bohm wrote: >>>>> She (Eve) would know that the requesting party Alice >>>>> was talking to Bob at the very moment she sent Trent >>>>> the OCSP *request* for Bob's certificate. >>>>> >>>>> [...] equivalent of having (almost complete) real time >>>>> copies of everybody's phone bill/call records. >>>>> Who was calling who at what time. >>>> this is not a problem as long as the public keys (the certificates) are >>>> not really public; >>>> because in your example Eve doesn't have the knowledge which certificate >>>> the specific serial number has ... >>>> >>>> if the public keys (the certificates) are searchable by public - the worst >>>> case direct by a search engine like google - then you would get an >>>> absolute security whole: >>> Update for you: https://crt.sh/ >>> >> you know the difference between SSL and S/MIME? > I know the difference very well - probably even longer than you. sorry I don't think so, because you didn't really reply anything in connection with S/MIME as I mentioned, you gave an "update" relevant to SSL ... > Note: > 1. Google's certificate transparency project is not limited to certain > certificate types. sure? give me a hint for finding S/MIME certificates, finding my own would be nice; for SSL/TLS-certificates I don't need this, I use just this > 2. Privacy concerns are raised because of browsers validating server certs via > OCSP during TLS connect. are you sure, think of validating a certificate like this: X509v3 Subject Alternative Name: DNS:rsc.cdn77.org, DNS:*.rsc.cdn77.org, DNS:*.c.cdn77.org, DNS:cdn.perfdrive.com, DNS:www.secure.nsw.gov.au, DNS:www.cdn77.com, DNS:info.gossipslots.eu, DNS:*.r2games.com, DNS:cdn.medio.com, DNS:*.cdn77-ssl.net, DNS:static.netverify.com, DNS:static.popads.net, DNS:c1.popads.net, DNS:cdn77.clickfun.com, DNS:content.thunderkick.com, DNS:cdn.xsolla.com, DNS:cdns.kinguin.net, DNS:cdn.ometria.com, DNS:static.victorinox.com, DNS:images.victorinox.com, DNS:uat.static.victorinox.com, DNS:static1.zuerich.com, DNS:uat.images.victorinox.com, DNS:ret.tyroodr.com, DNS:unic.static.victorinox.com, DNS:static.jumio.com, DNS:static.netswipe.com, DNS:cdn77.clickfuncasino.com, DNS:assets.victorinox.com, DNS:cache.graphicslib.viator.com, DNS:cache.vtrcdn.com, DNS:m.vtrcdn.com, DNS:partner.vtrcdn.com, DNS:cdn.qbaka.net, DNS:i.gocollette.com, DNS:cdn.ctnsnet.com, DNS:videos.kinkylove.com, DNS:images.kinkylove.com, DNS:cdn.igopost.com, DNS:cdn3.merchenta.com, DNS:cdn.sscontent.com, DNS:cnt.booming.de, DNS:cdn.exactag.com, DNS:cdn.garantibil.se, DNS:cloud.majestic.co.uk, DNS:cdn.eprofessional.de, DNS:cdn.webstaurantstore.com, DNS:cdn.darkstarrisen.com, DNS:static-vid.ibotta.com, DNS:cdn.contentdn.net, DNS:cdn.nailsuperstore.com, DNS:info.drakecasino.eu, DNS:media.lingeriestyling.com, DNS:info.gtbets.eu, DNS:cdn.levenhuk.com, DNS:cdn.axonify.com, DNS:cdn.propellant.dk, DNS:static.scania.com, DNS:cdn.majestic.co.uk, DNS:cdn.professionalthemes.nyc and what it would say to me, if I knew that you just validated a certificate of CA x with serial 36635145454, then tell me where there is a raise of privacy concerns ... > => OCSP should be feasible over TLS in the spirit of RFC 7258. as long as many CAs even have their 2048 bit root keys,*) they had many years before ... there is no need for OCSP over TLS *) some had them years ago using MD5, then using SHA1 and maybe now using SHA2 ... security and usability has a higher priority for me than privacy ... Greetings, Walter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4312 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Sat Oct 31 22:23:34 2015 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sat, 31 Oct 2015 23:23:34 +0100 Subject: [openssl-users] Thoughts about security, privacy, ... In-Reply-To: <56350451.1040107@mathemainzel.info> References: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <562FDCE2.6070309@mathemainzel.info> <5630ED61.2080106@wisemo.com> <5630F982.5050209@mathemainzel.info> <56310733.8080909@wisemo.com> <563136DE.2000103@mathemainzel.info> <5631EFFE.2050405@wisemo.com> <2df14a9cef1403650fc83588b959371d.1446125421@squirrel.mail> <5633D627.607@stroeder.com> <5633DFD8.1000102@mathemainzel.info> <5634AD7C.2020200@stroeder.com> <56350451.1040107@mathemainzel.info> Message-ID: <56353F66.6050008@stroeder.com> Walter H. wrote: > On 31.10.2015 13:01, Michael Str?der wrote: >> Walter H. wrote: >>> On 30.10.2015 21:42, Michael Str?der wrote: >>>> Walter H. wrote: >>>>> On Thu, October 29, 2015 11:07, Jakob Bohm wrote: >>>>>> She (Eve) would know that the requesting party Alice >>>>>> was talking to Bob at the very moment she sent Trent >>>>>> the OCSP *request* for Bob's certificate. >>>>>> >>>>>> [...] equivalent of having (almost complete) real time >>>>>> copies of everybody's phone bill/call records. >>>>>> Who was calling who at what time. >>>>> this is not a problem as long as the public keys (the certificates) are >>>>> not really public; >>>>> because in your example Eve doesn't have the knowledge which certificate >>>>> the specific serial number has ... >>>>> >>>>> if the public keys (the certificates) are searchable by public - the worst >>>>> case direct by a search engine like google - then you would get an >>>>> absolute security whole: >>>> Update for you: https://crt.sh/ >>>> >>> you know the difference between SSL and S/MIME? >> I know the difference very well - probably even longer than you. > sorry I don't think so, because you didn't really reply anything in connection > with S/MIME as I mentioned, So, so... > give me a hint for finding S/MIME certificates, finding my own would be nice; You claim that clear-text OCSP requests are not a privacy issue. So you should explain how you keep your *public*-key cert from being intercepted somewhere. You can't. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4245 bytes Desc: S/MIME Cryptographic Signature URL: