Changing private key passphrase using PHP OpenSSL
How can I do this? I posed the question on Stack Overflow as well: http://stackoverflow.com/questions/13588822/how-to-change-the-passphrase-of-a- private-key-using-phps-openssl-module I'd like to use the PHP functions rather than calling OpenSSL directly, as this could make the my app less portable. Thanks! Sam. signature.asc Description: This is a digitally signed message part.
How do I tell openssl where its configuration file is, without a commandline argument?
The simpler variant of this question, vis how to tell openssl where the configuration file is, is a FAQ, and I have seen it countless times over the past few years, as a result of my searches using Google. However, my present situation is a bit different. I am developing perl programs that must make SSL connections to secure servers, and some of my programs that do this have been working fine for as much as five years. However, a couple of them have started to fail with a handful of secure sites that have new 'extended validation' certificates. This is the only consistent difference between those sites that I can still connect to and those that I can't. For those who don't know, web programming using Perl involves a number of complicated packages, most of which are written in perl, and unfortunately, the perl package that is responsible for SSL/TLS connections is buried deep in the bowels of the most complex of these, and it requires that openssl is installed. I do have openssl installed (this is on Windows (several varieties including WXP, Windows 7 and Windows Server 2008, both 32 bit and 64 bit), but I have not added it's bin directory to the system path (to date, I haven't had to). I know I can ensure my perl programs can find it by adding that path to the system path, but there remains the problem that every time I start openssl from a commandline without passing the path to the configuration file as a commandline argument, it complains that the file couldn't be found is some Unix path I can't remember (but beginning with '/usr').. Hence the question: Is it possible to tell openssl where the configuration file is, e.g. by setting an environment variable, without passing a commandline argument? Thanks Ted __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Is PKCS5_PBKDF2_HMAC() thread safe?
Thank you Jeff. I will take a look. -Bill On Nov 27, 2012, at 5:59 AM, Jeffrey Walton wrote: On Mon, Nov 26, 2012 at 5:59 PM, Bill Durant cipherte...@gmail.com wrote: Hello: Is PKCS5_PBKDF2_HMAC() thread safe? See the Is OpenSSL thread-safe? under the PROG section: http://www.openssl.org/support/faq.html. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How do I tell openssl where its configuration file is, without a commandline argument?
On 28 Nov 2012, at 12:31 PM, Ted Byers wrote: Is it possible to tell openssl where the configuration file is, e.g. by setting an environment variable, without passing a commandline argument? If I remember correctly, you can set the OPENSSL_CONF environment variable to the path of the config file you want. The SSL_CERT_DIR and SSL_CERT_FILE environment variables might also be helpful (depending on what you need). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL test for SSL renegotiation
From: owner-openssl-us...@openssl.org On Behalf Of Hermes Flying Sent: Tuesday, 27 November, 2012 07:13 To: openssl-...@openssl.org; openssl-users@openssl.org Answering only -users, this is not a -dev question. How can I test if my server is vulnerable for SSL renegotiation? I tried the following (using `OpenSSL 0.9.8j-fips 07 Jan 2009`: I doubt it. 5746 was first implemented (or at least first released) in 0.9.7m 25 Feb 2010. The attack it addresses wasn't even disclosed until Nov 2009 (and 0.9.7l was rushed out to disable all renegotiation pending the real fix then under discussion). Check your version again. `openssl s_client -connect 10.2.10.54:443` I see it connects, it brings the certificate chain, it shows the server certificate, and last: SSL handshake has read 2275 bytes and written 465 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit Secure Renegotiation IS supported snip What does `Secure Renegotiation IS supported` mean? It means RFC5746 is supported: the client proposed either the extension or the 'signaling' suite and the server accepted (with extension). Thus the initial negotiation is known not to have been subject to the Apache prefix attack. Any (subsequent) renegotiations will also be known to be sequenced properly, but AFAIK there is no attack against renegotiations unless the (first) negotiation was anull enull which is just loony. This doesn't necessarily mean 5746 is *enforced*; some servers also accept legacy renegotiation from clients that don't implement 5746. That SSL renegotiation is allowed? That's a separate question. One can implement 5746 for initial negotiation but not support later renegotiation. AFAIK Tomcat/Coyote uses either Java-builtin SSL (JSSE) or APR=OpenSSL and JSSE has no way to disable renegotiation, although since the implementation of 5746 (6u22 according to http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-17633 0.html ) it does need an option to reenable legacy unsafe renegotiation, which I hope Tomcat wouldn't do. (Note that there are other security flaws and fixes in Java, so for your server to be secure overall you may need 6u22.) OpenSSL does have an option to prohibit all renegotiation, but I don't know if Tomcat can use that since it may *need* (server) renegotiation depending on configuration. OpenSSL since 0.9.8m normally prohibits legacy renegotiation, but has an option to enable which I hope Tomcat wouldn't do. Then I did but did not get an exception or get the certificate again: I assume you did R,return to invoke (client) renegotiation. s_client renegotiation does not display the cert, but the verify callbacks show a cert was received, and with -msg you can see it. verify error:num=20:unable to get local issuer certificate verify return:1 verify error:num=27:certificate not trusted verify return:1 verify error:num=21:unable to verify the first certificate verify return:1 I assume you (also) sent an HTTP request to get the following response: HTTP/1.1 200 OK Server: Apache-Coyote/1.1 snip So is the server vulnerable to SSL renegotiation or not? Probably not, but see above. Note the above considers only protocol level -- can Mallory create a spliced request that kindof-appears associated with Alice's auth? That request produces a real vulnerability only if the server uses client auth to control access and functionality -- which is one way Apache can be configured but not the only way. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: New features in openssl-1.0.1c
From: owner-openssl-us...@openssl.org On Behalf Of Edward Shishkin Sent: Monday, 26 November, 2012 13:56 I'd like to use new openssl features (GCM, CMAC, etc), but have troubles: with standard flags (-lssl -lcrypto) compilation failed: Compilation did not fail; linking did. Your question below is better. test.c:(.text+0x7f): undefined reference to `CRYPTO_gcm128_new' test.c:(.text+0x9e): undefined reference to `CRYPTO_gcm128_setiv' test.c:(.text+0xbd): undefined reference to `CRYPTO_gcm128_encrypt' test.c:(.text+0xd8): undefined reference to `CRYPTO_gcm128_tag' test.c:(.text+0xe4): undefined reference to `CRYPTO_gcm128_release' Any ideas how to link it properly? Make sure you link with 1.0.1* libararies and it should work. Did you install 1.0.1* to the system-default location on your system, or are you using a copy somewhere else, and if so how did you tell your toolchain where to look for tjat copy (and what is your toolchain, if other than the GCC/binutils which that error format suggests)? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: default RSA and DHE sizes for DHE-RSA-AES128-SHA?
From: owner-openssl-us...@openssl.org On Behalf Of Kumar Ghanta Sent: Wednesday, 28 November, 2012 14:47 Can somebody please tell me what default sizes for RSA and DHE are being used for the below ciphers in openssl? DHE-RSA-AES128-SHA DHE-RSA-AES256-SHA I don't know what you mean by default sizes. For all ciphersuites using DHE-RSA: - the RSA key used by the server to sign in ServerKX is the RSA privatekey (or keypair) matching its certificate, both of which are configured (and exist in advance). The size of an RSA signature is the size of the key. - if client auth is used, the RSA key used by the client to sign in CertVer is the privatekey matching its cert, ditto. - both parties' DH public values are the size of the DH group specified by the server. For OpenSSL server this is configured (directly) by SSL_[CTX_]set_tmp_dh, or by the callback set by SSL_[CTX_]set_tmp_dh_callback. The only place there's a default is *generating* a keypair that is put into a certificate and later used. In that case, genrsa or gendh defaults to 512 and req -new defaults to a configured value which in turn defaults to 512. dsaparam (DSA params can be used as DH params by ignoring q) does generation only if you specify numbits. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
