Prime number generation goes in infinite loop in OpenAT
Hi, We are using openSSL in OpenAT-FXT modem. the version used is 0.9.8h. When I am calling function to generate keys, it goes into infinite loop inside the function and system got crashed. By entering traces, I checked the flow of code Code is given below const int kBits = 4096; RSA *rsa = RSA_new(); BIGNUM *f4 = BN_new(); BN_GENCB *cb = NULL; BN_set_word(f4, RSA_F4); static const char rnd_seed[] = string to make the random number generator think it has entropy; RAND_seed(rnd_seed, sizeof(rnd_seed)); ret = RSA_generate_key_ex(rsa, kBits, f4, cb); rsa_builtin_keygen(rsa, bits, e_value, cb); BN_generate_prime_ex(rsa-p, bitsp, 0, NULL, NULL, cb) i=BN_is_prime_fasttest_ex(ret,checks,ctx,0,cb); //this function returns 0, so it goes back on loop: to make a random number j = witness(check, A, A1, A1_odd, k, ctx, mont); //witness is returning 1 Any help to solve the problem be appreciated __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Declare BN_CTX on stack (not BN_CTX*)
I'm trying to declare a BN_CTX on the stack (with a subsequent call to BN_CTX_init) to stay out of the memory manager. When I do, I get an error: aggregate ‘BN_CTX’ has incomplete type and cannot be defined I've included openssl/bn.h, so I'm kind of surprised I can't compile. (openssl/bn.h has some typedefs and comments about definitions in ossl_typ.h). Grepping sources: $ grep -R BN_CTX_init * ... crypto/bn/exp.c:BN_CTX_init(ctx); does not show me anything interesting because it looks like I'm doing what exp.c is doing: BN_CTX ctx; BIGNUM a,b,c,r,rr,t,l; ... BN_CTX_init(ctx); How do I declare a BN_CTX on the stack? Thanks in advance. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DH_compute_key query
Steve, It is word aligned. I tried different ways to prepend the value in DH-d but it is not working. When I dump the memory it shows leading zeros but when I print the same DH-d using BN_print_fp it does not show zeros which is expected but leading zeros are not increasing the num_bytes (BN_num_bytes for computed string is returning lesser value than DH_size) to 160 it is always returning 159. BN_print_fp output: 9FCB0280F7125C3C05329F27BD71028F77A9E319CDAAFECFA49042B0254B04C4F4A0C2374BB23573C524FBDCF1F304D7B70C4F5A7F25275A9C4A8035480BBC807D7CE218CDEC34C5A9A1FAC38E96EEF6CEE00D22AB6AFC6FE0574C22466365AA3B32F98267934801CBF35508D0870B1DE33C498F094ABF6037AFB21CDFF661 Memory dump of DH-d 1cdff661 6037afb2 8f094abf 1de33c49 08d0870b 01cbf355 82679348 aa3b32f9 22466365 6fe0574c 22ab6afc f6cee00d c38e96ee c5a9a1fa 18cdec34 807d7ce2 35480bbc 5a9c4a80 5a7f2527 d7b70c4f dcf1f304 73c524fb 374bb235 c4f4a0c2 b0254b04 cfa49042 19cdaafe 8f77a9e3 27bd7102 3c05329f 80f7125c 009fcb02 Thanks, Sindya -- View this message in context: http://openssl.6102.n7.nabble.com/DH-compute-key-query-tp13943p48183.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DH_compute_key query
it is BIGNUM-d not DH-d -- View this message in context: http://openssl.6102.n7.nabble.com/DH-compute-key-query-tp13943p48184.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Prime number generation goes in infinite loop in OpenAT
Hi, I also experienced going into an infinite loop using BN_generate_prime_ex() function. I my case it was because I didn't fully understand how to use 'add' and 'rem' parameters. I am now assuming they should be used as in dh_builtin_genparams(), in dh_gen.c. I am not qualified to discuss how the underlying logic should have been coded, but only considering the programming style, I am quite sure that 'looping' from inside a 'for' instruction using various 'goto' can be avoided. For example : probable_prime(), 'again' and 'loop' tags, line 383 and 390, or probable_prime_dh_safe(), line 476 (OpenSSL v1.0.2). Le 16/01/2014 11:35, Nischal a écrit : Hi, We are using openSSL in OpenAT-FXT modem. the version used is 0.9.8h. When I am calling function to generate keys, it goes into infinite loop inside the function and system got crashed. By entering traces, I checked the flow of code Code is given below const int kBits = 4096; RSA *rsa = RSA_new(); BIGNUM *f4 = BN_new(); BN_GENCB *cb = NULL; BN_set_word(f4, RSA_F4); static const char rnd_seed[] = string to make the random number generator think it has entropy; RAND_seed(rnd_seed, sizeof(rnd_seed)); ret = RSA_generate_key_ex(rsa, kBits, f4, cb); rsa_builtin_keygen(rsa, bits, e_value, cb); BN_generate_prime_ex(rsa-p, bitsp, 0, NULL, NULL, cb)Hi all, i=BN_is_prime_fasttest_ex(ret,checks,ctx,0,cb); //this function returns 0, so it goes back on loop: to make a random number j = witness(check, A, A1, A1_odd, k, ctx, mont); //witness is returning 1 Any help to solve the problem be appreciated __ 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: DH_compute_key query
Thanks Steve. Issue is fixed please ignore my previous email. -- View this message in context: http://openssl.6102.n7.nabble.com/DH-compute-key-query-tp13943p48186.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Prime number generation goes in infinite loop in OpenAT
On Thu, Jan 16, 2014 at 10:35:41AM +, Nischal wrote: We are using openSSL in OpenAT-FXT modem. the version used is 0.9.8h. When I am calling function to generate keys, it goes into infinite loop inside the function and system got crashed. You should be using OpenSSL 0.9.8y, or if possible 1.0.1f. Is the complete lack of entropy intended to stay that way? If so, you must not proceed with the key generation. You need to provide an interface for users to load externally generated keys into the device, before which time it should refuse to perform any operations that require private keys. Code is given below const int kBits = 4096; RSA *rsa = RSA_new(); BIGNUM *f4 = BN_new(); BN_GENCB *cb = NULL; BN_set_word(f4, RSA_F4); static const char rnd_seed[] = string to make the random number generator think it has entropy; RAND_seed(rnd_seed, sizeof(rnd_seed)); ret = RSA_generate_key_ex(rsa, kBits, f4, cb); ... -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Declare BN_CTX on stack (not BN_CTX*)
[Sorry for top-post - Outlook Web Client] I would say that BN_CTX_init() is deprecated and you should be using BN_CTX * ctx = BN_CTX_new(); Indeed, https://www.openssl.org/docs/crypto/BN_CTX_new.html says BN_CTX_init() (deprecated) initializes an existing uninitialized BN_CTX. This should not be used for new programs. Use BN_CTX_new() instead. Regards, Carl From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on behalf of Jeffrey Walton [noloa...@gmail.com] Sent: 16 January 2014 20:28 To: OpenSSL Users List Subject: Declare BN_CTX on stack (not BN_CTX*) I'm trying to declare a BN_CTX on the stack (with a subsequent call to BN_CTX_init) to stay out of the memory manager. When I do, I get an error: aggregate ‘BN_CTX’ has incomplete type and cannot be defined I've included openssl/bn.h, so I'm kind of surprised I can't compile. (openssl/bn.h has some typedefs and comments about definitions in ossl_typ.h). Grepping sources: $ grep -R BN_CTX_init * ... crypto/bn/exp.c:BN_CTX_init(ctx); does not show me anything interesting because it looks like I'm doing what exp.c is doing: BN_CTX ctx; BIGNUM a,b,c,r,rr,t,l; ... BN_CTX_init(ctx); How do I declare a BN_CTX on the stack? Thanks in advance. __ 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
How to check the client use which protocol or extensions to connect the server ?
Hi, I write a SSL server, enable zlib, TLS 1.0/1.1/1.2, can I check the client use which TLS protocol, or whether the client use zlib compression ? Thanks, Dongsheng __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Declare BN_CTX on stack (not BN_CTX*)
On Fri, Jan 17, 2014 at 4:38 AM, Carl Young carlyo...@keycomm.co.uk wrote: ... I would say that BN_CTX_init() is deprecated and you should be using BN_CTX * ctx = BN_CTX_new(); Yeah, it works with BN_CTX *. I was hoping to keep out of the memory manager since it seems like a waste when it can be placed on the stack. Indeed, https://www.openssl.org/docs/crypto/BN_CTX_new.html says BN_CTX_init() (deprecated) initializes an existing uninitialized BN_CTX. This should not be used for new programs. Use BN_CTX_new() instead. Odd its still being used in the source code. Jeff From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on behalf of Jeffrey Walton [noloa...@gmail.com] Sent: 16 January 2014 20:28 To: OpenSSL Users List Subject: Declare BN_CTX on stack (not BN_CTX*) I'm trying to declare a BN_CTX on the stack (with a subsequent call to BN_CTX_init) to stay out of the memory manager. When I do, I get an error: aggregate ‘BN_CTX’ has incomplete type and cannot be defined I've included openssl/bn.h, so I'm kind of surprised I can't compile. (openssl/bn.h has some typedefs and comments about definitions in ossl_typ.h). Grepping sources: $ grep -R BN_CTX_init * ... crypto/bn/exp.c:BN_CTX_init(ctx); does not show me anything interesting because it looks like I'm doing what exp.c is doing: BN_CTX ctx; BIGNUM a,b,c,r,rr,t,l; ... BN_CTX_init(ctx); How do I declare a BN_CTX on the stack? Thanks in advance. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
How to check the client use which protocol or extensions to connect the server ?
Hi, I write a SSL server, enable zlib, TLS 1.0/1.1/1.2, can I check the client use which TLS protocol, or whether the client use zlib compression ? Thanks, Dongsheng __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Cross compiling 1.2.2 for the Analog Devices Blackfin -- FIPS_text_start()/FIPS_text_end() returns 0 on the target
Hi folks, I'm almost out of my depth, and really need help on the next step. I've that the in-system fingerprint comparison fails with a FINGERPRINT_premain: FIPS_signature mismatch error incore DEBUG=1 output gives: = TARGET: elf32-bfinfdpic FIPS_rodata_end=000D5374 FIPS_rodata_start=000D00A0 FIPS_signature=00107F34 FIPS_text_end=000622F4 FIPS_text_start=0003CD28 FINGERPRINT_ascii_value=000D5D68 DOTrodata=000D00A0 DOTrodata_OFF=000D00A0 DOTtext=0003CAF0 DOTtext_OFF=0003CAF0 TSTART 568 TLEN 153036 TOFF 249132 INCORE_ADJUST 4 RSTART 0 RLEN 21204 ROFF 852128 FSTART 23752 FLEN 40 FOFF 875880 Signature is: 9b51309edb5d373a6f1e5b0c3cc8e554317539ae = I've created a test file to examine the various parameters. On the device, it shows: = Computed: c1133792c1ced10fadfe2ab6eb7946d79bfec490 HMAC_SHA1_SIG: 9b51309edb5d373a6f1e5b0c3cc8e554317539ae FIPS_text_start(): 0 FIPS_text_end()=0 FIPS_rodata_start=48038048 (0x2DD00A0) FIPS_rodata_end=48059252 (0x2DD5374) = So, I see these issues: 1) FIPS_text_start()/FIPS_text_end() returns 0 2) rodata start/end both offset by 0x2D0 Can anybody help point me to my next steps? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Declare BN_CTX on stack (not BN_CTX*)
On Fri, Jan 17, 2014 at 09:57:00AM -0500, Jeffrey Walton wrote: BN_CTX_init() (deprecated) initializes an existing uninitialized BN_CTX. This should not be used for new programs. Use BN_CTX_new() instead. Odd its still being used in the source code. Not that odd. Libraries are free to make use of their own opaque data types, but applications are not. When the data type internals change, applications don't break. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Declare BN_CTX on stack (not BN_CTX*)
On Fri, Jan 17, 2014 at 11:16 AM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Fri, Jan 17, 2014 at 09:57:00AM -0500, Jeffrey Walton wrote: BN_CTX_init() (deprecated) initializes an existing uninitialized BN_CTX. This should not be used for new programs. Use BN_CTX_new() instead. Odd its still being used in the source code. Not that odd. Libraries are free to make use of their own opaque data types, but applications are not. When the data type internals change, applications don't break. I have no problem with them having their private structures. I have no problems with opaque structures. If I have to have it, I'd like to put it on the stack minimize the cost of using it. Its hard to claim safe harbor in its private when an application is forced to use it (the application crashes in the BN_* routine if its absent). Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Cross compiling 1.2.2 for the Analog Devices Blackfin -- FIPS_text_start()/FIPS_text_end() returns 0 on the target
Are you compiling for the uclinux distro or something similar? Are you using the 16 or 32-bit arch? Are you utilizing the DSP or trying to? It might be nice to know more about the parameters you are passing to the compiler and what compiler that you are using. My area is in primarily ARM devices, but these kinds of questions would get you are bit farther than what is provided. On Fri, Jan 17, 2014 at 9:00 AM, Mike Crowe drmikecr...@gmail.com wrote: Hi folks, I'm almost out of my depth, and really need help on the next step. I've that the in-system fingerprint comparison fails with a FINGERPRINT_premain: FIPS_signature mismatch error incore DEBUG=1 output gives: = TARGET: elf32-bfinfdpic FIPS_rodata_end=000D5374 FIPS_rodata_start=000D00A0 FIPS_signature=00107F34 FIPS_text_end=000622F4 FIPS_text_start=0003CD28 FINGERPRINT_ascii_value=000D5D68 DOTrodata=000D00A0 DOTrodata_OFF=000D00A0 DOTtext=0003CAF0 DOTtext_OFF=0003CAF0 TSTART 568 TLEN 153036 TOFF 249132 INCORE_ADJUST 4 RSTART 0 RLEN 21204 ROFF 852128 FSTART 23752 FLEN 40 FOFF 875880 Signature is: 9b51309edb5d373a6f1e5b0c3cc8e554317539ae = I've created a test file to examine the various parameters. On the device, it shows: = Computed: c1133792c1ced10fadfe2ab6eb7946d79bfec490 HMAC_SHA1_SIG: 9b51309edb5d373a6f1e5b0c3cc8e554317539ae FIPS_text_start(): 0 FIPS_text_end()=0 FIPS_rodata_start=48038048 (0x2DD00A0) FIPS_rodata_end=48059252 (0x2DD5374) = So, I see these issues: 1) FIPS_text_start()/FIPS_text_end() returns 0 2) rodata start/end both offset by 0x2D0 Can anybody help point me to my next steps? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Stacy Devino StacyDevino.com KF5NQI Mobile, Web, Audio, Hardware
Re: Cross compiling 1.2.2 for the Analog Devices Blackfin -- FIPS_text_start()/FIPS_text_end() returns 0 on the target
Hi Stacy, sorry, should have included that:
On Fri, Jan 17, 2014 at 12:17 PM, Stacy Devino childoftheh...@gmail.com wrote:
Are you compiling for the uclinux distro or something similar?
ucLinux -- 2.6.34
Are you using the 16 or 32-bit arch?
The blackfin is a 32-bit little-endian machine
Are you utilizing the DSP or trying to?
Not utilizing DSP. Running the FIPS code as-is.
A typical compile looks like:
bfin-linux-uclibc-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIO -O3
-fomit-frame-pointer -Wall -DHMAC_EXT=\${HMAC_EXT:-sha1}\ -DEMBED
-D__uClinux__ -I/opt/uclinux-usb34-rc5-bootecc-prod1 -mcpu=bf524-any
-c -o fips.o fips.c
The link for fipscanister looks like:
bfin-linux-uclibc-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIO -O3
-fomit-frame-pointer -Wall -DHMAC_EXT=sha1 -r -nostdlib -o
fipscanister.o fips_start.o fips.o ../crypto/aes/aes_cfb.o
../crypto/aes/aes_ecb.o ../crypto/aes/aes_ofb.o ../crypto/bn/bn_add.o
../crypto/bn/bn_blind.o ../crypto/bn/bn_ctx.o ../crypto/bn/bn_div.o
../crypto/bn/bn_exp2.o ../crypto/bn/bn_exp.o ../crypto/bn/bn_gcd.o
../crypto/bn/bn_lib.o ../crypto/bn/bn_mod.o ../crypto/bn/bn_mont.o
../crypto/bn/bn_mul.o ../crypto/bn/bn_prime.o ../crypto/bn/bn_rand.o
../crypto/bn/bn_recp.o ../crypto/bn/bn_shift.o ../crypto/bn/bn_sqr.o
../crypto/bn/bn_word.o ../crypto/bn/bn_x931p.o
../crypto/buffer/buf_str.o ../crypto/cryptlib.o
../crypto/des/cfb64ede.o ../crypto/des/cfb64enc.o
../crypto/des/cfb_enc.o ../crypto/des/ecb3_enc.o
../crypto/des/ecb_enc.o ../crypto/des/ofb64ede.o
../crypto/des/ofb64enc.o ../crypto/des/fcrypt.o
../crypto/des/set_key.o ../crypto/dsa/dsa_utl.o
../crypto/dsa/dsa_sign.o ../crypto/dsa/dsa_vrf.o ../crypto/err/err.o
../crypto/evp/digest.o ../crypto/evp/enc_min.o ../crypto/evp/e_aes.o
../crypto/evp/e_des3.o ../crypto/evp/p_sign.o ../crypto/evp/p_verify.o
../crypto/mem_clr.o ../crypto/mem.o ../crypto/rand/md_rand.o
../crypto/rand/rand_egd.o ../crypto/rand/randfile.o
../crypto/rand/rand_lib.o ../crypto/rand/rand_os2.o
../crypto/rand/rand_unix.o ../crypto/rand/rand_win.o
../crypto/rsa/rsa_lib.o ../crypto/rsa/rsa_none.o
../crypto/rsa/rsa_oaep.o ../crypto/rsa/rsa_pk1.o
../crypto/rsa/rsa_pss.o ../crypto/rsa/rsa_ssl.o
../crypto/rsa/rsa_x931.o ../crypto/sha/sha1dgst.o
../crypto/sha/sha256.o ../crypto/sha/sha512.o ../crypto/uid.o
../crypto/bn/bn_asm.o ../crypto/aes/aes_core.o ../crypto/aes/aes_cbc.o
../crypto/des/des_enc.o ../crypto/des/fcrypt_b.o
sha/fips_sha1_selftest.o hmac/fips_hmac.o hmac/fips_hmac_selftest.o
rand/fips_rand.o rand/fips_rand_selftest.o des/fips_des_selftest.o
aes/fips_aes_selftest.o dsa/fips_dsa_ossl.o dsa/fips_dsa_gen.o
dsa/fips_dsa_selftest.o dsa/fips_dsa_key.o dsa/fips_dsa_lib.o
dsa/fips_dsa_sign.o rsa/fips_rsa_eay.o rsa/fips_rsa_gen.o
rsa/fips_rsa_selftest.o rsa/fips_rsa_x931g.o rsa/fips_rsa_sign.o
rsa/fips_rsa_lib.o dh/fips_dh_check.o dh/fips_dh_gen.o
dh/fips_dh_key.o dh/fips_dh_lib.o fips_end.o
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Cross compiling 1.2.2 for the Analog Devices Blackfin -- FIPS_text_start()/FIPS_text_end() returns 0 on the target
Hi folks, I've patched fips_canister.c to properly retrieve the blackfin instruction pointer. When I run openssl on the target now, I now get reasonable numbers (though they still don't match incore). === root:/ OPENSSL_FIPS=1 openssl ciphers FIPS SIG: sig: 0x2e1f9e0 FIPS_text_start: 0x2d3cd88 FIPS_text_end=0x2d624cc FIPS_rodata_start=0x2dd0294 FIPS_rodata_end=0x2dd5568 FIPS_signature=0x2e361fc .text:0x2d3cd88+153412=0x2d624cc .rodata:0x2dd0294+21204=0x2dd5568 Computed: 3098a7d1ede446fb5c4bef2d5568b7ea7edd2f68 HMAC_SHA1_SIG: 1f176a4fb51e3f477180c7d62f5af03c900d8e8c FINGERPRINT_premain: FIPS_signature mismatch === FWIW, incore shows: === FIPS_rodata_end=000D5568 FIPS_rodata_start=000D0294 FIPS_signature=001081FC FIPS_text_end=000624CC FIPS_text_start=0003CD88 FINGERPRINT_ascii_value=000D6000 DOTrodata=000D0294 DOTrodata_OFF=000D0294 DOTtext=0003CB50 DOTtext_OFF=0003CB50 TSTART 568 TLEN 153412 TOFF 249216 INCORE_ADJUST -8 RSTART 0 RLEN 21204 ROFF 852628 FSTART 23916 FLEN 40 FOFF 876544 Signature is: 1f176a4fb51e3f477180c7d62f5af03c900d8e8c === __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
ASN1_generate_v3: reading X509 extension via the API
Hi all,
I am trying to load the name and value of an X509 extension programmatically
via the API (in other words, the openssl.cnf file isn't being used), and I am
struggling with openssl telling me that the tag doesn't exist.
The extension I want to load has the name keyUsage and value
nonRepudiation,digitalSignature,keyEncipherment, and the error I get looks
like this:
139684350600856:error:0D0B10C2:asn1 encoding routines:ASN1_CB:unknown
tag:asn1_gen.c:303:tag=nonRepudiation,digitalSignature,keyEncipherment
The code that is trying to load in the extension looks like this:
/* find the name of the extension */
if (!(obj = OBJ_txt2obj(name, 0))) {
// error handler, this works fine when name has value keyUsage
}
type = ASN1_generate_v3((char *)val, NULL);
if (type == NULL) {
// we bomb out here with val as
nonRepudiation,digitalSignature,keyEncipherment
When I initialise openssl, I run the following two functions:
OpenSSL_add_all_algorithms();
ERR_load_crypto_strings();
Can anyone shed some light on what I might be doing wrong?
The code above was obtained by reverse engineering openssl itself, what is
throwing me is that I can't see how openssl understands the words
nonRepudiation,digitalSignature,keyEncipherment when my code doesn't.
Regards,
Graham
--
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Addition of TLS 1.2 client-side support causing failures to Windows servers
Hello, Our organization just switched some of our environments to using openssl-1.0.1e, and since doing so connections from those machines to our Windows servers fail where they used to succeed. I've done some investigation into openssl and I have the problem narrowed to the list of cipher suites offered in the client hello when TLS 1.2 is switched on. Specifically, if I do 'openssl s_client -no_tls1_2 ...' on the latest openssl-1.0.1f it will succeed, and fail otherwise. From a debugger I can set client_version to 1.1 during the function ssl_cipher_list_to_bytes and reset to 1.2 upon exit of that function and connection will again succeed. Our Windows servers only go up to TLSv1, and the key indication of a failed connection is that openssl s_client will claim that 'Secure Renegotiation IS NOT supported'. However, if I use openssl-1.0.0k against the same server it will report that 'Secure Renegotiation IS supported'. Does anyone have any idea what's going on? Can someone recommend some next steps I can try? Thanks, -- Jeff Franklin Software Engineer, Identity and Access Management UW Information Technology University of Washington __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Addition of TLS 1.2 client-side support causing failures to Windows servers
On Fri, Jan 17, 2014 at 06:05:37PM -0800, Jeff Franklin wrote: Our Windows servers only go up to TLSv1, and the key indication of a failed connection is that openssl s_client will claim that 'Secure Renegotiation IS NOT supported'. However, if I use openssl-1.0.0k against the same server it will report that 'Secure Renegotiation IS supported'. Does anyone have any idea what's going on? Can someone recommend some next steps I can try? http://ietf.10.n7.nabble.com/Windows-2003-TLS-64-ciphersuite-limit-td392649.html https://www.mail-archive.com/openssl-users@openssl.org/msg72735.html http://openssl.6102.n7.nabble.com/Verisign-Problem-with-smtp-tls-td47834i20.html Definitely FAQ time... Old Windows Exchange and IIS servers without appropriate patches choke when RC4-SHA and RC4-MD5 are not in the top 64 cipher-suites. Solution is Windows server upgrade. Work-around is cipherlist tweaks that ensure at least RC4-SHA is sent in the first 64. One can disable TLSv1.2 (which is not supported by these servers) or tweak the cipherlist as I've posted previously. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
