RE: Is dhparam only needed by server when using DHE-related cipher suites
From: owner-openssl-us...@openssl.org On Behalf Of Yijun Wu Sent: Tuesday, 27 August, 2013 01:07 It seems that when DHE-related cipher suites are used connection can not be established if the dhparam is not set on the server side. However, when dhparam is set on the server side the connection can always be established regardless of whether it is set on the client side. Of course other parameters are set correct. DHE and DH-anon, yes. By definition of Diffie-Hellman both parties must use the same parameters (p, g, maybe qsize) and by definition of SSL/TLS for DHE and DHA params are chosen by the server and sent in ServerKeyExchange. (For fixed-DH they are in each cert and must be the same in both. Within an organization or small community this can be achieved by using the same CA which forces all certs to have, and thus all certified EEs to use, the same parameters. Otherwise you're pretty much on your own. Also note that released OpenSSL doesn't yet have fixed-DH, but it reportedly will soon.) OpenSSL disables the DH-anon suites by default, because using nonauthenticating suites is a bad idea, but does implement them. Analagously for ECHDE and ECDH-anon, versus fixed-ECDH. But here the picture changes some because there are about 3 dozen curves standardized (aka 'named' curves) for TLS, versus similar numbers standardized for other purposes, versus a near-infinite number of custom curves, but it's much more work to generate a good ECC curve than a good prime for DH (or DSA) so people almost always use the named curves. In fact people seem to mostly use the two named curves chosen by NSA for Suite B (P-256 and P-384), so in practice getting certs at both ends for fixed-ECDH to use the same curve is less difficult. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
PEM_read_RSA_PUBKEY() PEM_read_RSAPublicKey()
I've tried both to load public key from PEM file, but PEM_read_RSAPublicKey() failed. I can't get any information from manual, so I've googled a lot, and got that opnion: = You might try PEM_read_RSA_PUBKEY() instead of PEM_read_RSAPublicKey(). This is all about formats. The default public key file format generated by openssl is the PEM format. PEM_read_RSA_PUBKEY() reads the PEM format. PEM_read_RSAPublicKey() reads the PKCS#1 format. So if you want to stick to PEM_read_RSAPublicKey() you could generate the public key file using the PKCS#1 format by specifying the -outform DER option when generating the public key. = (From http://stackoverflow.com/questions/7818117/why-i-cant-read-openssl-generated-rsa-pub-key-with-pem-read-rsapublickey) But it's PEM_xxx, why it used to read from DER format? Then I tried it on DER format, but it still failed. So, where should I use that it? BTW: where is the source code of that two APIs? I've grep all the files under openssl, but only doc and./util/libeay.num. -- Cyberman Wu __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: PEM_read_RSA_PUBKEY() PEM_read_RSAPublicKey()
On Tue, Aug 27, 2013, Cyberman Wu wrote: I've tried both to load public key from PEM file, but PEM_read_RSAPublicKey() failed. It would help if you said what error you get or posted the file. See also: http://www.openssl.org/support/faq.html#PROG6 I can't get any information from manual The pem manual pages gives information: http://www.openssl.org/docs/crypto/pem.html The RSAPublicKey functions process an RSA public key using an RSA structure. The public key is encoded using a PKCS#1 RSAPublicKey structure. The RSA_PUBKEY functions also process an RSA public key using an RSA structure. However the public key is encoded using a SubjectPublicKeyInfo structure and an error occurs if the public key is not RSA. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
X509 CRLs
Hello all, I had a couple questions about X509 CRLs. 1) It appears that OpenSSL does not check my tree against the CRLs I provide. If I revoke my own leaf certificate, and establish mutually-authenticated SSL, OpenSSL does not prevent the connection from going through. However if I revoke the peer's leaf certificate, it will fail with the revoked certificate error. Is this by intention? Should I manually check my tree against the CRL before allowing the user to establish a connection? 2) Can a child CA revoke a parent CA? If I import a CRL to my system, should I check only the children of the CA for a matching serial and mark that certificate Revoked, or should I also check the parents for revocation? What about a certificate that is signed by a parent, but isn't in the child's chain? Two example PKI trees: A - B - C - D A - E - F - G Let's say that certificate authority B imports a CRL. Which certificates should be checked for revocation? Only C, D? Only B, C, D? Only A, B, C, D? All of them? Much appreciated, Thaddeus This email and any attached files are confidential and intended solely for the intended recipient(s). If you are not the named recipient you should not read, distribute, copy or alter this email. Any views or opinions expressed in this email are those of the author and do not represent those of the Futurex company. Warning: Although precautions have been taken to make sure no viruses are present in this email, the company cannot accept responsibility for any loss or damage that arise from the use of this email or attachments. This email and any attached files are confidential and intended solely for the intended recipient(s). If you are not the named recipient you should not read, distribute, copy or alter this email. Any views or opinions expressed in this email are those of the author and do not represent those of the Futurex company. Warning: Although precautions have been taken to make sure no viruses are present in this email, the company cannot accept responsibility for any loss or damage that arise from the use of this email or attachments. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] X509 CRLs
Bonjour, Le 27/08/2013 18:14, Thaddeus Fuller a écrit : Hello all, I had a couple questions about X509 CRLs. 1) It appears that OpenSSL does not check my tree against the CRLs I provide. If I revoke my own leaf certificate, and establish mutually-authenticated SSL, OpenSSL does not prevent the connection from going through. However if I revoke the peer's leaf certificate, it will fail with the revoked certificate error. Is this by intention? Should I manually check my tree against the CRL before allowing the user to establish a connection? If A needs to authenticate itself to B, then A presents its own certificate, and B must validate A's certificate: correct chaining and revocation status. A doesn't need to check that its own certificate isn't revoked before trying to send it to B, that's B's duty. 2) Can a child CA revoke a parent CA? If I import a CRL to my system, should I check only the children of the CA for a matching serial and mark that certificate Revoked, or should I also check the parents for revocation? What about a certificate that is signed by a parent, but isn't in the child's chain? A child CA cannot revoke a parent CA, of course. The revocation status check should be done for each certificate in the chain (except the root, for not so obvious reasons). Two example PKI trees: A - B - C - D A - E - F - G Let's say that certificate authority B imports a CRL. Which certificates should be checked for revocation? If you want to verify certificate D, then you must verify its revocation status regarding to a CRL produced by C. And then you must verify C's revocation status according to the CRL produced by B. And finally you must verify B's revocation status according to the CRL produced by A. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: PEM_read_RSA_PUBKEY() PEM_read_RSAPublicKey()
From: owner-openssl-us...@openssl.org On Behalf Of Dr. Stephen Henson Sent: Tuesday, 27 August, 2013 08:10 Adding a little: On Tue, Aug 27, 2013, Cyberman Wu wrote: I've tried both to load public key from PEM file, but PEM_read_RSAPublicKey() failed. It would help if you said what error you get or posted the file. See also: http://www.openssl.org/support/faq.html#PROG6 Preferably #PROG7 also, although that's not vital. I can't get any information from manual The pem manual pages gives information: http://www.openssl.org/docs/crypto/pem.html The RSAPublicKey functions process an RSA public key using an RSA structure. The public key is encoded using a PKCS#1 RSAPublicKey structure. The RSA_PUBKEY functions also process an RSA public key using an RSA structure. However the public key is encoded using a SubjectPublicKeyInfo structure and an error occurs if the public key is not RSA. And PEM can easily be distinguished by the dash lines: RSAPublicKey is BEGIN/END RSA PUBLIC KEY while RSA_PUBKEY (and also DSA_PUBKEY etc) is BEGIN/END PUBLIC KEY. The same two structures are supported in DER, and there if you lose track which is which you have to asn1parse and grovel. Usually PUBKEY is more likely because it is the default for commandline utilities like rsa -pubout and x509 -pubout . Though =1.0.0 rsa has undocumented options for RSAPublicKey. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
FIPS mode: failure during build-test of shared library: FIPS_check_incore_fingerprint:fingerprint does not match
I'm working with the Debian/Ubuntu openssl package for Ubuntu 13.10, Saucy, version 1.0.1e. I'm trying to adapt the Debian package-build to produce a FIPS-linked openssl. I've followed the procedure to download, build and install the FIPS canister v2.0.1 which was successful: $ ../../openssl-fips-2.0.1/test/fips_algvs fips_test_suite post FIPS-mode test application FIPS 2.0.1 validated test module 12 Jun 2012 DRBG AES-256-CTR DF test started DRBG AES-256-CTR DF test OK POST started Integrity test started Integrity test OK ... POST Success Power-up self test successful However, whilst building the shared-library version of openssl-1.0.1e (using a modified Debian package) the tests fail with: ... ./Configure shared --prefix=/usr/local --openssldir=/usr/local/lib/ssl --libdir=lib/x86_64-linux-gnu fips enable-ec_nistp_64_gcc_128 enable-ec_nistp_64_gcc_128 debian-amd64 ... test SSL protocol test ssl3 is forbidden in FIPS mode 46912496303808:error:2D06B06F:FIPS routines:FIPS_check_incore_fingerprint:fingerprint does not match:fips.c:232: test ssl2 is forbidden in FIPS mode 46912496303808:error:2D06B06F:FIPS routines:FIPS_check_incore_fingerprint:fingerprint does not match:fips.c:232: test tls1 46912496303808:error:2D06B06F:FIPS routines:FIPS_check_incore_fingerprint:fingerprint does not match:fips.c:232: make[2]: *** [test_ssl] Error 1 make[2]: Leaving directory `/home/all/SourceCode/openssl/openssl-1.0.1e.tj/test' make[1]: *** [tests] Error 2 make[1]: Leaving directory `/home/all/SourceCode/openssl/openssl-1.0.1e.tj' make: *** [build-stamp] Error 2 The Debian build script first builds the static library followed by the shared library. It runs the tests after each variant is built. The tests succeed for the static library: ... ./Configure no-shared --prefix=/usr/local --openssldir=/usr/local/lib/ssl --libdir=lib/x86_64-linux-gnu fips enable-ec_nistp_64_gcc_128 enable-ec_nistp_64_gcc_128 debian-amd64 ... test SSL protocol test ssl3 is forbidden in FIPS mode *** IN FIPS MODE *** Available compression methods: NONE 46912496300032:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips mode:ssl_lib.c:1692: 46912496300032:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips mode:ssl_lib.c:1692: test ssl2 is forbidden in FIPS mode *** IN FIPS MODE *** Available compression methods: NONE 46912496300032:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips mode:ssl_lib.c:1692: 46912496300032:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips mode:ssl_lib.c:1692: test tls1 *** IN FIPS MODE *** I've checked that the shared-library build test is linking against the correct libcrypto.so: $ ldd ../apps/openssl linux-vdso.so.1 = (0x7fffb61fe000) libssl.so.1.0.0 = /home/all/SourceCode/openssl/openssl-1.0.1e.tj/test/../libssl.so.1.0.0 (0x7f2376c5b000) libcrypto.so.1.0.0 = /home/all/SourceCode/openssl/openssl-1.0.1e.tj/test/../libcrypto.so.1.0.0 (0x7f237681) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f2376442000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f237623e000) /lib64/ld-linux-x86-64.so.2 (0x7f2376ec2000) And that libcrypto contains the FIPS symbols: $ objdump -t ../libcrypto.so.1.0.0 | grep -i fips | wc -l 812 From reading the source-code of 'openssl-fips/fips/fips.c' it seems that the fingerprint is created based upon the position and address of the fips object-code in the library but I can't be sure. I'm suspecting that the libcrypto.so build has munged the fingerprint-sensitive layout of the fips symbols and thus caused the failed check but I need to know precisely what the fingerprint is generated against in the object file in order to figure out what might have caused the problem. It could be a binutils/compiler/linker issue or it could be something the Debian build scripts have done. Can someone explain what the fingerprint is created against? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
