Re: Small memory leak on multithreaded server
On Thu, Nov 20, 2014, Barbe, Charles wrote: > Hello, > > I have noticed a small and consistent memory leak in my multithreaded openssl > server and am wondering if somebody can help me figure out what I need to do > to free it when my application closes. I am on OpenSSL version 1.0.1j. Here's > how I reproduce the leak: > > 1) Start up my server > 2) Load my homepage with Chrome > 3) Load my homepage with IE > 4) Load my homepage with Firefox > > I can do any combination of steps 2,3 and 4 above (ie. leave some of them > out) and I always get the same amount of memory left over after I shut down > my application. I believe this means that this is some sort of global > information that OpenSSL is hanging on to and not something in my SSL > connection structure. > > Specifically I get 20 blocks totaling 253 bytes. I have stack traces of where > each block is allocated but I cannot figure out how this memory should be > cleaned up. Each of the 20 blocks filter down to 1 of 5 root stack traces. > The stack traces are: > > Repeated 6 times: > 0x085c519c: asn1_item_ex_combine_new at tasn_new.c:164 > 0x085c7fd8: ASN1_item_ex_d2i at tasn_dec.c:315 (discriminator 1) > 0x085c81dc: asn1_template_noexp_d2i at tasn_dec.c:706 > 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 > 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 > 0x085c80a8: ASN1_item_d2i at tasn_dec.c:136 > 0x0867b368: X509V3_EXT_d2i at v3_lib.c:177 > 0x08682f3c: x509v3_cache_extensions at v3_purp.c:464 > 0x08683698: x509v3_cache_extensions at v3_purp.c:722 > (inlined by) X509_check_issued at v3_purp.c:706 > 0x0866fddc: check_issued at x509_vfy.c:417 > 0x086716d0: X509_verify_cert at x509_vfy.c:212 > 0x086967c0: ssl3_output_cert_chain at s3_both.c:387 > 0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365 > 0x0868b864: ssl3_accept at s3_srvr.c:418 > 0x086982f4: ssl23_get_client_hello at s23_srvr.c:657 > 0x08698bb8: ssl23_accept at s23_srvr.c:213 > > Repeated 6 times: > 0x085d12a4: ASN1_STRING_set at asn1_lib.c:389 > 0x085c715c: asn1_ex_c2i at tasn_dec.c:1056 > 0x085c7334: asn1_d2i_ex_primitive at tasn_dec.c:836 > 0x085c7fc8: ASN1_item_ex_d2i at tasn_dec.c:198 > 0x085c82a0: asn1_template_noexp_d2i at tasn_dec.c:734 > 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 > 0x085c7a20: ASN1_item_ex_d2i at tasn_dec.c:331 > 0x085c81dc: asn1_template_noexp_d2i at tasn_dec.c:706 > 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 > 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 > 0x085c80a8: ASN1_item_d2i at tasn_dec.c:136 > 0x0867b368: X509V3_EXT_d2i at v3_lib.c:177 > 0x08682f3c: x509v3_cache_extensions at v3_purp.c:464 > 0x08683698: x509v3_cache_extensions at v3_purp.c:722 > (inlined by) X509_check_issued at v3_purp.c:706 > 0x0866fddc: check_issued at x509_vfy.c:417 > 0x086716d0: X509_verify_cert at x509_vfy.c:212 > 0x086967c0: ssl3_output_cert_chain at s3_both.c:387 > 0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365 > 0x0868b864: ssl3_accept at s3_srvr.c:418 > 0x086982f4: ssl23_get_client_hello at s23_srvr.c:657 > 0x08698bb8: ssl23_accept at s23_srvr.c:213 > > Repeated 6 times: > 0x085d13bc: ASN1_STRING_type_new at asn1_lib.c:429 > 0x085c71f4: asn1_ex_c2i at tasn_dec.c:1032 > 0x085c7334: asn1_d2i_ex_primitive at tasn_dec.c:836 > 0x085c7fc8: ASN1_item_ex_d2i at tasn_dec.c:198 > 0x085c82a0: asn1_template_noexp_d2i at tasn_dec.c:734 > 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 > 0x085c7a20: ASN1_item_ex_d2i at tasn_dec.c:331 > 0x085c81dc: asn1_template_noexp_d2i at tasn_dec.c:706 > 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 > 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 > 0x085c80a8: ASN1_item_d2i at tasn_dec.c:136 > 0x0867b368: X509V3_EXT_d2i at v3_lib.c:177 > 0x08682f3c: x509v3_cache_extensions at v3_purp.c:464 > 0x08683698: x509v3_cache_extensions at v3_purp.c:722 > (inlined by) X509_check_issued at v3_purp.c:706 > 0x0866fddc: check_issued at x509_vfy.c:417 > 0x086716d0: X509_verify_cert at x509_vfy.c:212 > 0x086967c0: ssl3_output_cert_chain at s3_both.c:387 > 0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365 > 0x0868b864: ssl3_accept at s3_srvr.c:418 > 0x086982f4: ssl23_get_client_hello at s23_srvr.c:657 > 0x08698bb8: ssl23_accept at s23_srvr.c:213 > > Once: > 0x0866380c: sk_new at stack.c:125 > 0x0866380c: sk_new at stack.c:125 > 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 > 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 > 0x085c80a8: ASN1_item_d2i at tasn_dec.c:136 > 0x0867b368: X509V3_EXT_d2i at v3_lib.c:177 > 0x08682f3c: x509v3_cache_extensions at v3_purp.c:464 > 0x08683698: x509v3_cache_extensions at v3_purp.c:722 > (inlined by) X509_check_issued at v3_purp.c:706 > 0x0866fddc: check_issued at x509_vfy.c:417 > 0x086716d0: X509_verify_cert at x509_vfy.c:212 > 0x086967c0: ssl3_output_cert_chain at s3_both.c:387 > 0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365 > 0x0868b864: ssl3_accept at s3_srvr.c:418 > 0x086982f4: ssl23_get_client_hello at s23_srvr.c:657 > 0x08698bb8: ssl2
Re: Small memory leak on multithreaded server
On Thu, Nov 20, 2014 at 10:19:32PM +, Barbe, Charles wrote: > I can do any combination of steps 2,3 and 4 above (ie. leave some > of them out) and I always get the same amount of memory left over > after I shut down my application. I believe this means that this > is some sort of global information that OpenSSL is hanging on to > and not something in my SSL connection structure. > > Specifically I get 20 blocks totaling 253 bytes. I have stack > traces of where each block is allocated but I cannot figure out > how this memory should be cleaned up. Each of the 20 blocks filter > down to 1 of 5 root stack traces. The stack traces are: A fixed amount of memory that is not deallocated and is independent of the number of operations performed, is NOT a memory leak. Librariers to allocate memory for the lifetime of the process during one time initialization or first use of a function. This is normal. Tracking this down is a waste of time IMHO. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Small memory leak on multithreaded server
> Any help would be appreciated. This could be one of two problems. First, it could be an issue with your code and the way you handle cleanup. To help diagnose this, please show us your cleanup code. Second, it could be the memory leak from the compression methods. This is a well known problem dating back a few years that has not been fixed. See, for example, http://rt.openssl.org/Ticket/Display.html?id=2561&user=guest&pass=guest. On Thu, Nov 20, 2014 at 5:19 PM, Barbe, Charles wrote: > Hello, > > I have noticed a small and consistent memory leak in my multithreaded openssl > server and am wondering if somebody can help me figure out what I need to do > to free it when my application closes. I am on OpenSSL version 1.0.1j. Here's > how I reproduce the leak: > > 1) Start up my server > 2) Load my homepage with Chrome > 3) Load my homepage with IE > 4) Load my homepage with Firefox > > I can do any combination of steps 2,3 and 4 above (ie. leave some of them > out) and I always get the same amount of memory left over after I shut down > my application. I believe this means that this is some sort of global > information that OpenSSL is hanging on to and not something in my SSL > connection structure. > > Specifically I get 20 blocks totaling 253 bytes. I have stack traces of where > each block is allocated but I cannot figure out how this memory should be > cleaned up. Each of the 20 blocks filter down to 1 of 5 root stack traces. > The stack traces are: > > Repeated 6 times: > 0x085c519c: asn1_item_ex_combine_new at tasn_new.c:164 > 0x085c7fd8: ASN1_item_ex_d2i at tasn_dec.c:315 (discriminator 1) > 0x085c81dc: asn1_template_noexp_d2i at tasn_dec.c:706 > 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 > 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 > 0x085c80a8: ASN1_item_d2i at tasn_dec.c:136 > 0x0867b368: X509V3_EXT_d2i at v3_lib.c:177 > 0x08682f3c: x509v3_cache_extensions at v3_purp.c:464 > 0x08683698: x509v3_cache_extensions at v3_purp.c:722 > (inlined by) X509_check_issued at v3_purp.c:706 > 0x0866fddc: check_issued at x509_vfy.c:417 > 0x086716d0: X509_verify_cert at x509_vfy.c:212 > 0x086967c0: ssl3_output_cert_chain at s3_both.c:387 > 0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365 > 0x0868b864: ssl3_accept at s3_srvr.c:418 > 0x086982f4: ssl23_get_client_hello at s23_srvr.c:657 > 0x08698bb8: ssl23_accept at s23_srvr.c:213 > > Repeated 6 times: > 0x085d12a4: ASN1_STRING_set at asn1_lib.c:389 > 0x085c715c: asn1_ex_c2i at tasn_dec.c:1056 > 0x085c7334: asn1_d2i_ex_primitive at tasn_dec.c:836 > 0x085c7fc8: ASN1_item_ex_d2i at tasn_dec.c:198 > 0x085c82a0: asn1_template_noexp_d2i at tasn_dec.c:734 > 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 > 0x085c7a20: ASN1_item_ex_d2i at tasn_dec.c:331 > 0x085c81dc: asn1_template_noexp_d2i at tasn_dec.c:706 > 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 > 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 > 0x085c80a8: ASN1_item_d2i at tasn_dec.c:136 > 0x0867b368: X509V3_EXT_d2i at v3_lib.c:177 > 0x08682f3c: x509v3_cache_extensions at v3_purp.c:464 > 0x08683698: x509v3_cache_extensions at v3_purp.c:722 > (inlined by) X509_check_issued at v3_purp.c:706 > 0x0866fddc: check_issued at x509_vfy.c:417 > 0x086716d0: X509_verify_cert at x509_vfy.c:212 > 0x086967c0: ssl3_output_cert_chain at s3_both.c:387 > 0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365 > 0x0868b864: ssl3_accept at s3_srvr.c:418 > 0x086982f4: ssl23_get_client_hello at s23_srvr.c:657 > 0x08698bb8: ssl23_accept at s23_srvr.c:213 > > Repeated 6 times: > 0x085d13bc: ASN1_STRING_type_new at asn1_lib.c:429 > 0x085c71f4: asn1_ex_c2i at tasn_dec.c:1032 > 0x085c7334: asn1_d2i_ex_primitive at tasn_dec.c:836 > 0x085c7fc8: ASN1_item_ex_d2i at tasn_dec.c:198 > 0x085c82a0: asn1_template_noexp_d2i at tasn_dec.c:734 > 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 > 0x085c7a20: ASN1_item_ex_d2i at tasn_dec.c:331 > 0x085c81dc: asn1_template_noexp_d2i at tasn_dec.c:706 > 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 > 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 > 0x085c80a8: ASN1_item_d2i at tasn_dec.c:136 > 0x0867b368: X509V3_EXT_d2i at v3_lib.c:177 > 0x08682f3c: x509v3_cache_extensions at v3_purp.c:464 > 0x08683698: x509v3_cache_extensions at v3_purp.c:722 > (inlined by) X509_check_issued at v3_purp.c:706 > 0x0866fddc: check_issued at x509_vfy.c:417 > 0x086716d0: X509_verify_cert at x509_vfy.c:212 > 0x086967c0: ssl3_output_cert_chain at s3_both.c:387 > 0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365 > 0x0868b864: ssl3_accept at s3_srvr.c:418 > 0x086982f4: ssl23_get_client_hello at s23_srvr.c:657 > 0x08698bb8: ssl23_accept at s23_srvr.c:213 > > Once: > 0x0866380c: sk_new at stack.c:125 > 0x0866380c: sk_new at stack.c:125 > 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 > 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 > 0x085c80a8: ASN1_item_d2i at tasn_dec.c:136 > 0x0867b368: X509V3_EXT_d2i at v3_lib.c:177 > 0x08682f3c: x509v3_cache_extensions at v3_p
Small memory leak on multithreaded server
Hello, I have noticed a small and consistent memory leak in my multithreaded openssl server and am wondering if somebody can help me figure out what I need to do to free it when my application closes. I am on OpenSSL version 1.0.1j. Here's how I reproduce the leak: 1) Start up my server 2) Load my homepage with Chrome 3) Load my homepage with IE 4) Load my homepage with Firefox I can do any combination of steps 2,3 and 4 above (ie. leave some of them out) and I always get the same amount of memory left over after I shut down my application. I believe this means that this is some sort of global information that OpenSSL is hanging on to and not something in my SSL connection structure. Specifically I get 20 blocks totaling 253 bytes. I have stack traces of where each block is allocated but I cannot figure out how this memory should be cleaned up. Each of the 20 blocks filter down to 1 of 5 root stack traces. The stack traces are: Repeated 6 times: 0x085c519c: asn1_item_ex_combine_new at tasn_new.c:164 0x085c7fd8: ASN1_item_ex_d2i at tasn_dec.c:315 (discriminator 1) 0x085c81dc: asn1_template_noexp_d2i at tasn_dec.c:706 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 0x085c80a8: ASN1_item_d2i at tasn_dec.c:136 0x0867b368: X509V3_EXT_d2i at v3_lib.c:177 0x08682f3c: x509v3_cache_extensions at v3_purp.c:464 0x08683698: x509v3_cache_extensions at v3_purp.c:722 (inlined by) X509_check_issued at v3_purp.c:706 0x0866fddc: check_issued at x509_vfy.c:417 0x086716d0: X509_verify_cert at x509_vfy.c:212 0x086967c0: ssl3_output_cert_chain at s3_both.c:387 0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365 0x0868b864: ssl3_accept at s3_srvr.c:418 0x086982f4: ssl23_get_client_hello at s23_srvr.c:657 0x08698bb8: ssl23_accept at s23_srvr.c:213 Repeated 6 times: 0x085d12a4: ASN1_STRING_set at asn1_lib.c:389 0x085c715c: asn1_ex_c2i at tasn_dec.c:1056 0x085c7334: asn1_d2i_ex_primitive at tasn_dec.c:836 0x085c7fc8: ASN1_item_ex_d2i at tasn_dec.c:198 0x085c82a0: asn1_template_noexp_d2i at tasn_dec.c:734 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 0x085c7a20: ASN1_item_ex_d2i at tasn_dec.c:331 0x085c81dc: asn1_template_noexp_d2i at tasn_dec.c:706 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 0x085c80a8: ASN1_item_d2i at tasn_dec.c:136 0x0867b368: X509V3_EXT_d2i at v3_lib.c:177 0x08682f3c: x509v3_cache_extensions at v3_purp.c:464 0x08683698: x509v3_cache_extensions at v3_purp.c:722 (inlined by) X509_check_issued at v3_purp.c:706 0x0866fddc: check_issued at x509_vfy.c:417 0x086716d0: X509_verify_cert at x509_vfy.c:212 0x086967c0: ssl3_output_cert_chain at s3_both.c:387 0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365 0x0868b864: ssl3_accept at s3_srvr.c:418 0x086982f4: ssl23_get_client_hello at s23_srvr.c:657 0x08698bb8: ssl23_accept at s23_srvr.c:213 Repeated 6 times: 0x085d13bc: ASN1_STRING_type_new at asn1_lib.c:429 0x085c71f4: asn1_ex_c2i at tasn_dec.c:1032 0x085c7334: asn1_d2i_ex_primitive at tasn_dec.c:836 0x085c7fc8: ASN1_item_ex_d2i at tasn_dec.c:198 0x085c82a0: asn1_template_noexp_d2i at tasn_dec.c:734 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 0x085c7a20: ASN1_item_ex_d2i at tasn_dec.c:331 0x085c81dc: asn1_template_noexp_d2i at tasn_dec.c:706 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 0x085c80a8: ASN1_item_d2i at tasn_dec.c:136 0x0867b368: X509V3_EXT_d2i at v3_lib.c:177 0x08682f3c: x509v3_cache_extensions at v3_purp.c:464 0x08683698: x509v3_cache_extensions at v3_purp.c:722 (inlined by) X509_check_issued at v3_purp.c:706 0x0866fddc: check_issued at x509_vfy.c:417 0x086716d0: X509_verify_cert at x509_vfy.c:212 0x086967c0: ssl3_output_cert_chain at s3_both.c:387 0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365 0x0868b864: ssl3_accept at s3_srvr.c:418 0x086982f4: ssl23_get_client_hello at s23_srvr.c:657 0x08698bb8: ssl23_accept at s23_srvr.c:213 Once: 0x0866380c: sk_new at stack.c:125 0x0866380c: sk_new at stack.c:125 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 0x085c80a8: ASN1_item_d2i at tasn_dec.c:136 0x0867b368: X509V3_EXT_d2i at v3_lib.c:177 0x08682f3c: x509v3_cache_extensions at v3_purp.c:464 0x08683698: x509v3_cache_extensions at v3_purp.c:722 (inlined by) X509_check_issued at v3_purp.c:706 0x0866fddc: check_issued at x509_vfy.c:417 0x086716d0: X509_verify_cert at x509_vfy.c:212 0x086967c0: ssl3_output_cert_chain at s3_both.c:387 0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365 0x0868b864: ssl3_accept at s3_srvr.c:418 0x086982f4: ssl23_get_client_hello at s23_srvr.c:657 0x08698bb8: ssl23_accept at s23_srvr.c:213 Once: 0x08663990: sk_insert at stack.c:151 0x085c8204: asn1_template_noexp_d2i at tasn_dec.c:715 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 0x085c80a8: ASN1_item_d2i at tasn_dec
Re: X.509 Public Key Fingerprints
On Thu, Nov 20, 2014 at 12:16:41PM -0700, Philip Prindeville wrote:
> I'm also looking for a function to generate a fingerprint (either MD5 or
> SHA-1 digest)
> over a public key DER string.
C or command-line? On the command-line:
$ pkey_digest() {
openssl x509 -in "$1" -noout -pubkey |
openssl pkey -pubin -outform DER |
openssl dgst -"$2" -binary |
hexdump -ve '/1 "%02X"'; printf "\n"
}
$ pkey_digest cert1.pem md5
$ pkey_digest cert2.pem sha256
...
In C:
const char *digest_alg; /* = "sha1" for example */
const EVP_MD *md;
unsigned char mdbuf[EVP_MAX_MD_SIZE];
unsigned char *buf;
unsigned char *buf2;
unsigned int len;
unsigned int len2;
X509 *cert;
/* get a cert from somewhere */
/* choose a value for digest_alg */
if ((md = EVP_get_digestbyname(digest_alg)) == 0)
/* error */
len = i2d_X509_PUBKEY(X509_get_X509_PUBKEY(cert), NULL);
buf2 = buf = (unsigned char *) OPENSSL_malloc(len);
if (buf)
i2d_X509_PUBKEY(X509_get_X509_PUBKEY(cert), &buf2);
else
/* error */
OPENSSL_assert(buf2 - buf == len);
if (ok = EVP_Digest(buf, len, mdbuf, &len2, md, 0))
OPENSSL_free(buf);
if (! ok)
/* error */
/* Encode len2 bytes of digest in buf to hex or whatever */
--
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: X.509 Public Key Fingerprints
Did you ever get anywhere on this? I’m also looking for a function to generate a fingerprint (either MD5 or SHA-1 digest) over a public key DER string. Thanks. On Aug 15, 2012, at 2:53 AM, Curt Sampson wrote: > I'm designing a protocol that requests certificates for specific public > keys known to the client. (I.e., the client says, "give me all of the > certs you know that are for one of these public keys," and the server > responds with those certs.) > > In order to keep the request size small, I'd like to include public > key fingerprints rather than full public keys in the request. Is there > a standard way to generate a fingerprint for a public key included in > X.509 and/or PKIX certificates? Or should I just roll my own? > > (We're using 2048-bit RSA keys, BTW, but the ideal solution shouldn't be > restricted to that.) > > If I do roll my own, I'm thinking that the SHA-1 hash > of the public key's DER representation (as generated by > i2d_X509_PUBKEY(X509_get_X509_PUBKEY(cert))) would do the trick. There > don't appear to be any particular security issues here, since I can > verify the certs themselves after receipt to have the actual public key > I'm looking for, and be signed correctly and all of that. Any thoughts? > > cjs __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: What version(s) of SSL/TLS are supported in openssl 1.0.1g
> Would any one be able to let me know what versions of SSL (if applicable) > and TLS is supported in openssl 1.0.1g > All of them. Its up to you to trim what you don't want. You can remove protocols (and other features) at compile time with, for example: ./config no-ssl2 no-ssl3 no-comp Or, you can remove them at runtime with, for example: const SSL_METHOD* method = SSLv23_method(); SSL_CTX* context = SSL_CTX_new(method); long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_COMPRESSION; SSL_CTX_set_options(context, flags); __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Digital Certificates
> Even assuming he figures out how to tis his algorithm into Openssl, how
> would he even being to specify his custom algorithm in the cert? Wouldn't
> he have to define his own OID for the algorithm?
Yup.Getting an OID arc is pretty easy:
http://www.alvestrand.no/objectid/1.3.6.1.4.1.html
--
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz
:��I"Ϯ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
Re: Digital Certificates
On Thu, Nov 20, 2014, Salz, Rich wrote: > > If, I want to use my own algorithm instead of rsa or sha1 in the digital > > certificates, is it possible ? > > if yes then how ? > > I thought I answered this. It is hard work, it is not documented, you're on > your own. I agree with the "hard work" opinion ;-) This can be done and one ENGINE for gost does in fact implement new public key algorithms which aren't part of OpenSSL. In outline you do something like this... 1. Write ASN.1 modules for public key and private key formats and (if relevant) parameters. Write translation functions to convert from ASN.1 to and from EVP_PKEY structures. Optionally include printing functions. Make an EVP_PKEY_ASN1_METHOD based on these. 2. Write cryptographic functions to generate parameters (if required), private keys, sign and verify. Adding appropriate controls and string based controls will make the algorith usable from the openssl utility. Wrap the lot in an EVP_PKEY_METHOD. 3. Place the two methods in a ENGINE so it loads and registers them. 4. Test extensively using the pkey, pkeyutl, genpkey and pkeyparam utilities. 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
Re: Digital Certificates
On Thu, Nov 20, 2014 at 10:42:01PM +0530, Niraj Sorathiya wrote: > Any API or software tool can help me ? NO. And likely you're not even asking the right question. If you really wish to pursue this line of inquiry, post a detailed description of your algorithm, and why you want to extend OpenSSL to support it. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Schanner secu
On 19/11/2014 22:37, Gilles Vollant wrote: On https://support.microsoft.com/kb/2992611 we can read Some customers have reported an issue that is related to the changes in this release. These changes added the following new cipher suites to Windows Server 2008 R2 and Windows Server 2012. In order to give customers more control over whether these cipher suites are used in the short term, we are removing them from the default cipher suite priority list in the registry. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 In other words, they disabled the stronger suites rather than fixingthe actual compatibility issue (which was the removal of anunnecessary "supported points format" extension, which was sentinprevious versions). So if Mr. Idrassi was right AND if OpenSSL 1.0.0/1.0.0a/1.0.0b were the only affected clients, then this is not the best possiblefix. On the other hand, if some other SSL library would fail if presented withthe 3 "new" suites (the GCM suites without ECDSA certs), then their fix is correct and just helps the old OpenSSL versions by chance. 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 Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Digital Certificates
Hi, Any API or software tool can help me ? -Niraj On 20-Nov-2014 9:06 PM, "Salz, Rich" wrote: > > If, I want to use my own algorithm instead of rsa or sha1 in the > digital certificates, is it possible ? > > if yes then how ? > > I thought I answered this. It is hard work, it is not documented, you're > on your own. >
RE: Digital Certificates
Even assuming he figures out how to tis his algorithm into Openssl, how would
he even being to specify his custom algorithm in the cert? Wouldn't he have to
define his own OID for the algorithm?
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Salz, Rich
Sent: Thursday, November 20, 2014 7:32 AM
To: openssl-users@openssl.org
Subject: RE: Digital Certificates
> If, I want to use my own algorithm instead of rsa or sha1 in the
> digital certificates, is it possible ? if yes then how ?
I thought I answered this. It is hard work, it is not documented, you're on
your own.
H 7 m
)z{, RǫJ i Lj)b )z{, )z{, h ^t Ƨj & ^ %
RE: version question
Should probably be asked on the OpenSSH mailing lists. My guess is that you will need to install a newer version of OpenSSL. -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of David Flatley Sent: Wednesday, November 19, 2014 12:35 PM To: openssl-users@openssl.org Subject: version question I am trying to build Openssh 6.7p1 on a Red Hat 5.6 x86_64 system with Red Hat openssl-0.9.8e-31, which is the latest Red Hat openssl version. The Openssh build checks openssl versions and requires 0.9.8f. Is there a work around for this? Thanks. David Flatley __ 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
What version(s) of SSL/TLS are supported in openssl 1.0.1g
Hello, Would any one be able to let me know what versions of SSL (if applicable) and TLS is supported in openssl 1.0.1g Thank you in advance.
RE: Digital Certificates
> If, I want to use my own algorithm instead of rsa or sha1 in the digital > certificates, is it possible ? > if yes then how ? I thought I answered this. It is hard work, it is not documented, you're on your own.
RE: version question
Download OpenSSL 0.9.8f and install it somewhere it stays separate from the RHEL system package, say /opt/openssl098f. Building it would be something like this: ./config --prefixdir=/opt/openssl098f --openssldir=/opt/openssl098f make make install Then whatever you have to do for OpenSSH to point it at that version. If the resulting OpenSSH executables need to run somewhere else (not on this build machine) you would also need to build them with the OpenSSL libraries linked statically instead of dynamically. Andrew From: owner-openssl-us...@openssl.org on behalf of David Flatley Sent: Wednesday, November 19, 2014 12:35 PM To: openssl-users@openssl.org Subject: version question I am trying to build Openssh 6.7p1 on a Red Hat 5.6 x86_64 system with Red Hat openssl-0.9.8e-31, which is the latest Red Hat openssl version. The Openssh build checks openssl versions and requires 0.9.8f. Is there a work around for this? Thanks. David Flatley __ 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: Unable to sign a certificate: for Java codesigning
> From: owner-openssl-us...@openssl.org On Behalf Of Joerg Schmitz > Sent: Saturday, November 15, 2014 12:16 > I hope you can help me. I'm about to sign jar-files with a self created > certificate > using OpenSSL. The jar-File contains an old Java-Applet which Java is > blocking > (as long as it is not signed) in the browser since version 7.51. Once it is > signed, > I just have to install the certificate (in the system / browser / JRE). > Right now I have a problem signing the certification request (see below "Step > 7"): > "unable to load certificate". What do I have to change to pass this step? That's already answered. > In addition I am not sure about the further steps (which I also added below). > Could you pls also tell me if these are right? But as to the others: > 1.) Create folder structure cd test mkdir private certs newcerts conf export > csr > echo '01' > serial touch index.txt export > OPENSSL_CONF=/home/joerg/cacerts/myca/openssl.cnf Those are all run together and need to be separated, but are then reasonable. > 2.) Create the Certificate Authority > openssl req -new -x509 -days 3650 -keyform PEM -outform PEM > -keyout test/private/cakey.pem -out test/cacert.pem By default req -new -x509 is only valid for 30 days. If you want your apps to last longer than that, choose a suitably longer period in days. You use 365 for the child cert below, and the CA needs to be at least that long. Since you need to install any reissued root cert in each client, you probably want to make it longer like 5 or 10 years as long as you're confident you will keep your privatekey secure and noone else can get at it to create unauthorized certs and thus apps. > 3.) Copy the CA into a format which can be managed by the Java-keystore: > openssl x509 -outform der -in test/cacert.pem -out test/cacert.crt Not needed. keytool has been able to read cert in PEM a long time. (The API for a *program* doesn't, or not easily, but keytool does.) > 4.) Generate Keystore > keytool -genkey -keystore javakeystore.jks -alias test Create keystore *and generate privatekey*. > 5.) Check Keystore > keytool -list -keystore javakeystore.jks -storepass "whatever" > 6.) Create certification request > keytool -certreq -v -file test/certs/caRequest.csr -alias "test" -keystore > javakeystore.jks -storepass "whatever" > 7.) Sign the certificate with the CA > openssl ca -days 365 -in test/certs/caRequest.csr -out > test/newcerts/caRequest.pem -policy policy_anything > My plan is to continue like this: > 8.) > openssl x509 -in test/newcerts/caRequest.pem -out test/newcerts/caRequest.pem > -outform PEM > 9.) > openssl x509 -outform der -in test/newcerts/caRequest.pem -out > test/newcerts/caRequest.crt Not needed. Current Java (7 or 8) keytool can read PEM even with the comments 'ca' adds. > 10.) Concatenate the certificate chain > cat test/newcerts/caRequest.pem test/cacert.pem > > test/newcerts/caRequest.chain Not needed if you separately load the one-and-only CA cert as you do. > 11.) Indicate that I trust this CA > keytool -import -trustcacerts -file test/cacert.pem -alias test -keystore > javakeystore.jks -storepass "whatever" On this step the -alias must NOT MATCH your privatekey entry which is 'test'. Maybe 'myroot'. -trustcacerts is not relevant here, only when importing *some* child certs. > 12.) Import it into your keystore > keytool -import -file test\newcerts\caRequest.chain -alias test1 -keystore > javakeystore.jks -storepass "whatever" This step must be -alias test to MATCH the privatekey entry. > 13.) Sign jar file > jarsigner -keystore javakeystore.jks TestApplet.jar test __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
new c_rehash, was RE: differing outputs using cli utility and c interface
> From: owner-openssl-us...@openssl.org On Behalf Of Malatesh Ankasapur > Sent: Tuesday, November 18, 2014 23:17 Note: you should post a new topic as a new message, not a reply. subject fixed > citrix reciever using the symbolic link .pem certificate so i did c_rehash > for my ceritficate > 1. openssl-0.9.8e created 1 hash value for my certificate. but i dont know > why openssl-1.0.0 is creating 2 hash value > suppose i am going to update openssl in my linux, its depends on the libc, > its difficult to update i think. > is any other solution to create 2 hash values for same file with > openssl-0.9.8e I don't see any situation where 1.0.0 (or any other) c_rehash would *create* two hash values. 1.0.0 or later does use a *different* hash algorithm (for cert and CRL names) than 0.9.8 and earlier, and a different hash algorithm produces different values. If you do 0.9.8 c_rehash AND 1.0.0+ c_rehash, TOGETHER they will produce 2 different hash values and resulting links (or copies) for each cert or CRL. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Digital Certificates
Hi, Thanks for your suggestion.. If, I want to use my own algorithm instead of rsa or sha1 in the digital certificates, is it possible ? if yes then how ? And it is like a learning exercise for me. Regards, Niraj. On 19-Nov-2014 9:28 PM, "Salz, Rich" wrote: > > I have developed one algorithm like RSA so how can I use my algorithm > with OPENSSL to secure Tcp/ip connections. > > Adding new algorithms to openssl is not trivial. It's also not really > documented. Good luck! > > For what it's worth, developing your own crypto algorithms is generally a > bad idea, unless it is a learning exercise. A free opinion, worth what you > paid for it :) > > >
Re: X509_verify_cert: How to retrieve the actual CRLs used to verifiy a certificate?
Am 19.11.14 um 17:20 schrieb Stephan Mühlstrasser:
Hi,
via X509_LOOKUP_load_file() resp. X509_LOOKUP_add_dir() I'm adding a PEM
file containing multiple CRLs and/or a directory containing hashed CRL
files to a X509_STORE.
Then I'm using the X509_verify_cert() function to verify a certificate.
After verification is successful, I would like to get the actual CRL
object that was used to verify the certificate. How can that be done? Do
I have to plug into the get_crl() callback function of the X509_STORE
structure?
I now found a way to get the CRL. To answer my own question, it works
like this:
Before X509_verify_cert() is called, the original "cert_crl" function
pointer from the X509_STORE_CTX structure is saved. Then the "cert_crl"
function pointer is overriden with my own function that calls the
original function. If the verification succeds, the crl object is saved.
Pseudo code:
int (*cert_crl_orig)(X509_STORE_CTX *ctx, X509_CRL *crl, X509 *x);
int
my_cert_crl(X509_STORE_CTX *ctx, X509_CRL *crl, X509 *x)
{
int ok = cert_crl_orig(ctx, crl, x);
if (ok)
{
}
return ok;
}
verify_cert()
{
X509_STORE_CTX *csc = X509_STORE_CTX_new();
cert_crl_orig = csc->cert_crl;
csc->cert_crl = my_cert_crl;
if (X509_verify_cert(csc) < 0)
{
...
}
}
Regards
Stephan
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
version question
I am trying to build Openssh 6.7p1 on a Red Hat 5.6 x86_64 system with Red Hat openssl-0.9.8e-31, which is the latest Red Hat openssl version. The Openssh build checks openssl versions and requires 0.9.8f. Is there a work around for this? Thanks. David Flatley __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
