Re: Reg missing rc4-ia64.pl in openssl 1.1.1
Hi, Thanks for all the information related to missing rc4 assembly file for IA-64 architecture. *Richard : * The following mentioned degradation on nt64 compared to the same openssl version 1.1.1 build with out using the flags " "enable-weak-ssl-ciphers" and " enable-deprecated" . Thanks and Regards, Ram Krushna > Similarly If I build Openssl 1.1.1 on nt64? with flags > "enable-weak-ssl-ciphers" and " > > enable-deprecated"? , I witness degrade in performance.? Could you > please help me understand how > > these flags can be related to speed test of all ciphers and digests ?? > > Degradation, compared to what? > > Cheers, > Richard > > End of openssl-users Digest, Vol 54, Issue 49 > * >
Reg missing rc4-ia64.pl in openssl 1.1.1
Hi, In Openssl 1.1.1, the file "rc4-ia64.pl" is missing. This cause degradation of performance on AIX. Is this intentional for deprecating the support for RC4 ? Similarly If I build Openssl 1.1.1 on nt64 with flags "*enable-weak-ssl-ciphers" and "**enable-deprecated" , *I witness degrade in performance. Could you please help me understand how these flags can be related to speed test of all ciphers and digests ? Thanks and Regards, Ram Krushna
Reg Performance degradation on windows with openssl 1.1.1
Hi, I am building openssl 1.1.1 on windows with 2 different configurations and I see performance difference for des-cbc. 1) *"perl Configure VC-WIN64A enable-weak-ssl-ciphers enable-rc4 enable-deprecated no-shared enable-ssl3 no-asm --prefix= --openssldir= " * The speed test results for des-cbc with this configuration is as follows. >openssl.exe speed -evp des-cbc OpenSSL 1.1.1 11 Sep 2018 built on: Mon May 27 11:19:51 2019 UTC options:bn(64,64) rc4(int) des(long) aes(partial) idea(int) blowfish(ptr) compiler: cl /Zi /Fdossl_static.pdb /MT /Zl /Gs0 /GF /Gy " The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes des-cbc *24691.93k27284.78k25719.04k26508.45k 29497.51k25432.13k* 2) *perl Configure VC-WIN64A no-shared no-asm --prefix= --openssldir=* If I build it using above then the performance of des-cbc is faster. openssl.exe speed -evp des-cbc OpenSSL 1.1.1 11 Sep 2018 built on: Fri May 24 11:37:15 2019 UTC options:bn(64,64) rc4(int) des(long) aes(partial) idea(int) blowfish(ptr) compiler: cl /Zi /Fdossl_static.pdb /MT /Zl /Gs0 /GF /Gy /W3 /wd4090 /nologo /O2 -DL_ENDIAN -DOPENSSL_PIC The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes des-cbc *56789.82k65988.99k65978.20k67490.82k 66155.86k67321.86k* Could any one please suggest me how to debug the reason about slower performance with first configuration. Thanks and Regards, Ram Krushna
Re: Reg slowness seen in openssl 1.1.1
Hi , I have installed openssl from scratch and there I am not observing any degradation. But I built it with in my project, there I observe the degradation. The Configure file remains same , but still in my project I can see a difference that "dynamic-engine" is present in enabled feature list. But In Configure file its present in disabled list. So, Could anyone suggest how this can be disabled ? And I want to build the openssl outside my project) with dynamic-engine enabled. What Configure argument shall i pass or make changes in Configure file to achive that ? Thanks and Regards, Ram Krushna On Fri, May 10, 2019 at 6:46 AM ramakrushna mishra wrote: > Hi , > > The results on a AIX machine looks more bad If I am interpreting them > correctly. > > openssl 1.1.0e : > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 > bytes 16384 bytes > sha1 65019.16k 151552.49k 266107.41k 337113.93k > 360792.93k 364102.89k > > > openssl 1.1.1 : > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 > bytes 16384 bytes > sha1 10641.28k21433.09k38464.85k48496.92k > 49381.38k51755.48k > > could any one please confirm if my interpretation is correct ? > I doubt any issue with openssl 1.1.1 version with such wider user base. > How to debug this further ? > > Thanks and Regards, > Ram Krushna > > > On Fri, May 10, 2019 at 5:59 AM ramakrushna mishra < > rama.krush...@gmail.com> wrote: > >> Hi, >> >> Could anyone please help me wth it. >> >> Following are sslc speed results for SHA1. >> >> sslc speed sha1 >> Doing sha1 for 3s on 16 size blocks: 16858430 sha1's in 2.98s >> Doing sha1 for 3s on 64 size blocks: 14147528 sha1's in 3.00s >> Doing sha1 for 3s on 256 size blocks: 6436755 sha1's in 2.99s >> Doing sha1 for 3s on 1024 size blocks: 2055335 sha1's in 3.00s >> Doing sha1 for 3s on 8192 size blocks: 266404 sha1's in 2.99s >> Doing sha1 for 3s on 16384 size blocks: 152376 sha1's in 3.00s >> OpenSSL 1.1.0e 16 Feb 2017 >> built on: reproducible build, date unspecified >> options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) >> blowfish(ptr) >> compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS >> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 >> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m >> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM >> -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM >> -DOPENSSLDIR="\"/vobs_prgs/tools/linuxx86_64/openssl/install\"" >> -DENGINESDIR="\"/vobs_prgs/tools/linuxx86_64/openssl/install/lib/engines-1.1\"" >> The 'numbers' are in 1000s of bytes per second processed. >> type 16 bytes 64 bytes256 bytes 1024 bytes 8192 >> bytes 16384 bytes >> sha1 90515.06k 301813.93k 551106.78k 701554.35k >> 729893.50k 832176.13k >> >> >> >> sslc speed sha1 >> Doing sha1 for 3s on 16 size blocks: 16939397 sha1's in 2.99s >> Doing sha1 for 3s on 64 size blocks: 11489920 sha1's in 3.00s >> Doing sha1 for 3s on 256 size blocks: 5316410 sha1's in 2.99s >> Doing sha1 for 3s on 1024 size blocks: 2006834 sha1's in 3.00s >> Doing sha1 for 3s on 8192 size blocks: 273661 sha1's in 2.98s >> Doing sha1 for 3s on 16384 size blocks: 150159 sha1's in 2.99s >> OpenSSL 1.1.1 11 Sep 2018 >> built on: Tue Feb 12 18:18:22 2019 UTC >> options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) >> blowfish(ptr) >> compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -fPIC >> -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ >> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 >> -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM >> -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM >> -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DNDEBUG -fPIC >> The 'numbers' are in 1000s of bytes per second processed. >> type 16 bytes 64 bytes256 bytes 1024 bytes 8192 >> bytes 16384 bytes >> sha1 90645.60k 245118.29k 455184.27k 684999.34k >> 752292.25k 822811.06k >> >> Does not this means 1.1.1 process lesser number of bytes per second >> compared to 1.1.0e ? >> >> Thanks and Regards, >> Ram Krushna >> >> On Thu, May 9, 2019 at 11:46 PM Salz, Rich wrote: >> >>> *> *Could you please look into the program and let me know if >>> anything I am doing wrong ? >>> >>> > Or else What could be the issue ? >>> >>> >>> >>> Sorry, no not me. Maybe someone else on the list has ideas. >>> >>
Re: Reg slowness seen in openssl 1.1.1
Hi , The results on a AIX machine looks more bad If I am interpreting them correctly. openssl 1.1.0e : The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes sha1 65019.16k 151552.49k 266107.41k 337113.93k 360792.93k 364102.89k openssl 1.1.1 : The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes sha1 10641.28k21433.09k38464.85k48496.92k 49381.38k51755.48k could any one please confirm if my interpretation is correct ? I doubt any issue with openssl 1.1.1 version with such wider user base. How to debug this further ? Thanks and Regards, Ram Krushna On Fri, May 10, 2019 at 5:59 AM ramakrushna mishra wrote: > Hi, > > Could anyone please help me wth it. > > Following are sslc speed results for SHA1. > > sslc speed sha1 > Doing sha1 for 3s on 16 size blocks: 16858430 sha1's in 2.98s > Doing sha1 for 3s on 64 size blocks: 14147528 sha1's in 3.00s > Doing sha1 for 3s on 256 size blocks: 6436755 sha1's in 2.99s > Doing sha1 for 3s on 1024 size blocks: 2055335 sha1's in 3.00s > Doing sha1 for 3s on 8192 size blocks: 266404 sha1's in 2.99s > Doing sha1 for 3s on 16384 size blocks: 152376 sha1's in 3.00s > OpenSSL 1.1.0e 16 Feb 2017 > built on: reproducible build, date unspecified > options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) > blowfish(ptr) > compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS > -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM > -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM > -DOPENSSLDIR="\"/vobs_prgs/tools/linuxx86_64/openssl/install\"" > -DENGINESDIR="\"/vobs_prgs/tools/linuxx86_64/openssl/install/lib/engines-1.1\"" > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 > bytes 16384 bytes > sha1 90515.06k 301813.93k 551106.78k 701554.35k > 729893.50k 832176.13k > > > > sslc speed sha1 > Doing sha1 for 3s on 16 size blocks: 16939397 sha1's in 2.99s > Doing sha1 for 3s on 64 size blocks: 11489920 sha1's in 3.00s > Doing sha1 for 3s on 256 size blocks: 5316410 sha1's in 2.99s > Doing sha1 for 3s on 1024 size blocks: 2006834 sha1's in 3.00s > Doing sha1 for 3s on 8192 size blocks: 273661 sha1's in 2.98s > Doing sha1 for 3s on 16384 size blocks: 150159 sha1's in 2.99s > OpenSSL 1.1.1 11 Sep 2018 > built on: Tue Feb 12 18:18:22 2019 UTC > options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) > blowfish(ptr) > compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -fPIC > -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ > -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM > -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM > -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DNDEBUG -fPIC > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 > bytes 16384 bytes > sha1 90645.60k 245118.29k 455184.27k 684999.34k > 752292.25k 822811.06k > > Does not this means 1.1.1 process lesser number of bytes per second > compared to 1.1.0e ? > > Thanks and Regards, > Ram Krushna > > On Thu, May 9, 2019 at 11:46 PM Salz, Rich wrote: > >> *> *Could you please look into the program and let me know if anything >> I am doing wrong ? >> >> > Or else What could be the issue ? >> >> >> >> Sorry, no not me. Maybe someone else on the list has ideas. >> >
Re: Reg slowness seen in openssl 1.1.1
Hi, Could anyone please help me wth it. Following are sslc speed results for SHA1. sslc speed sha1 Doing sha1 for 3s on 16 size blocks: 16858430 sha1's in 2.98s Doing sha1 for 3s on 64 size blocks: 14147528 sha1's in 3.00s Doing sha1 for 3s on 256 size blocks: 6436755 sha1's in 2.99s Doing sha1 for 3s on 1024 size blocks: 2055335 sha1's in 3.00s Doing sha1 for 3s on 8192 size blocks: 266404 sha1's in 2.99s Doing sha1 for 3s on 16384 size blocks: 152376 sha1's in 3.00s OpenSSL 1.1.0e 16 Feb 2017 built on: reproducible build, date unspecified options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DOPENSSLDIR="\"/vobs_prgs/tools/linuxx86_64/openssl/install\"" -DENGINESDIR="\"/vobs_prgs/tools/linuxx86_64/openssl/install/lib/engines-1.1\"" The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes sha1 90515.06k 301813.93k 551106.78k 701554.35k 729893.50k 832176.13k sslc speed sha1 Doing sha1 for 3s on 16 size blocks: 16939397 sha1's in 2.99s Doing sha1 for 3s on 64 size blocks: 11489920 sha1's in 3.00s Doing sha1 for 3s on 256 size blocks: 5316410 sha1's in 2.99s Doing sha1 for 3s on 1024 size blocks: 2006834 sha1's in 3.00s Doing sha1 for 3s on 8192 size blocks: 273661 sha1's in 2.98s Doing sha1 for 3s on 16384 size blocks: 150159 sha1's in 2.99s OpenSSL 1.1.1 11 Sep 2018 built on: Tue Feb 12 18:18:22 2019 UTC options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -fPIC -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DNDEBUG -fPIC The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes sha1 90645.60k 245118.29k 455184.27k 684999.34k 752292.25k 822811.06k Does not this means 1.1.1 process lesser number of bytes per second compared to 1.1.0e ? Thanks and Regards, Ram Krushna On Thu, May 9, 2019 at 11:46 PM Salz, Rich wrote: > *> *Could you please look into the program and let me know if anything > I am doing wrong ? > > > Or else What could be the issue ? > > > > Sorry, no not me. Maybe someone else on the list has ideas. >
Re: Reg slowness seen in openssl 1.1.1
Hi ,
I can observe slowness with standalone c programs. Attached are the sample
c programs.
If I run them with openssl 1.1.1 and 1.1.0e version on Linux system (Linux
2.6.32-504.el6.x86_64 x86_64
). then I can see the difference. If I increase the number of loop in the
program, then the slowness increases.
Could you please look into the program and let me know if anything I am
doing wrong ?
Or else What could be the issue ?
Thanks and Regards,
Ram Krushna
On Thu, May 9, 2019 at 8:43 PM Salz, Rich wrote:
> So now you know where to start looking, I guess. You might also change
> your test program so that it calls the functions multiple times, to “smooth
> out” the overhead.
>
#include
#include
#include
int main(int argc, char *argv[])
{
char mess1[] = "Now is the time for all good men to come to the aid of
their country.";
char mess2[1024] ;
int inlen=70, outlen,i;
EVP_CIPHER_CTX *ctx;
unsigned char key[] = "0123456789abcdeF";
unsigned char iv[] = "1234567887654321";
if (argv[1] == NULL)
{
printf ("Usage: encdec \n");
exit (1);
}
int do_encrypt = atoi(argv[1]);
for(i =0;i<1000;i++)
{
ctx = EVP_CIPHER_CTX_new();
const EVP_CIPHER *cp = EVP_get_cipherbyname("AES-128-CBC");
EVP_CipherInit_ex(ctx, cp, NULL, key, iv,do_encrypt);
//EVP_CipherInit_ex(ctx, NULL, NULL, key, iv, do_encrypt);
if(!EVP_CipherUpdate(ctx, mess2, , mess1, inlen))
{
/* Error */
EVP_CIPHER_CTX_free(ctx);
return 0;
}
if(!EVP_CipherFinal_ex(ctx, mess2, ))
{
/* Error */
EVP_CIPHER_CTX_free(ctx);
return 0;
}
EVP_CIPHER_CTX_free(ctx);
}
return 1;
}
#include
#include
#include
int main(int argc, char *argv[])
{
EVP_MD_CTX *mdctx;
const EVP_MD *md;
char mess1[] = "Now is the time for all good men to come to the aid of their
country.\n";
char mess2[] = "Now is the time for all good men to come to the aid of their
country.\n";
unsigned char md_value[EVP_MAX_MD_SIZE];
unsigned int md_len, i;
int j=0;
if (argv[1] == NULL)
{
printf ("Usage: mdtest digestname\n");
exit (1);
}
md = EVP_get_digestbyname (argv[1]);
if (md == NULL)
{
printf ("Unknown message digest %s\n", argv[1]);
exit (1);
}
for (j=0;j<1000;j++)
{
mdctx = EVP_MD_CTX_new ();
EVP_DigestInit_ex (mdctx, md, NULL);
EVP_DigestUpdate (mdctx, mess1, strlen (mess1));
EVP_DigestUpdate (mdctx, mess2, strlen (mess2));
EVP_DigestFinal_ex (mdctx, md_value, _len);
EVP_MD_CTX_free (mdctx);
}
printf ("Digest is: ");
for (i = 0; i < md_len; i++)
printf ("%02x", md_value[i]);
printf ("\n");
exit (0);
}
Re: Reg slowness seen in openssl 1.1.1
Hi, Thank you for the response. If we compare in quantify attached is the results. Thanks and Regards, Ram Krushna On Thu, May 9, 2019 at 8:28 PM Salz, Rich wrote: > I would start with doing profiling on old and new versions to see where > the slowdown is. > Differences between: program rx (pid 6113) collected on PentiumIII (2599 MHz) by Quantify version 7.4 150915 and program rx (pid 98772) collected on PentiumIII (2599 MHz) by Quantify version 7.4 150915. Function name Calls Cycles % change + ERR_STATE_free 0 0 + EVP_camellia_128_ctr 0 0 + EVP_cast5_ecb 0 0 +EVP_cast5_cfb64 0 0 + ossl_init_thread_stop 0 0 + lh_OBJ_NAME_get_down_load 0 0 + EVP_cast5_ofb 0 0 + doall_util_fn 0 0 +sk_EX_CALLBACK_pop_free 0 0 + utrcdInit 0 0 + RAND_DRBG_secure_new 0 0 + rand_pool_new 0 0 + lh_OBJ_NAME_set_down_load 0 0 + ossl_init_load_crypto_nodelete 0 0 + EVP_aria_256_ccm 0 0 + pam_allow_val 0 0 + lh_OBJ_NAME_error 0 0 + ossl_init_get_thread_local 0 0 + openssl_lh_strcasehash 0 0 +rand_pool_entropy_available 0 0 + aesni_ecb_encrypt 0 0 + EVP_sha512_256 0 0 +close_random_device 0 0 + do_rand_init 0 0 + RAND_DRBG_set 0 0 +otmGetDigestCtx 0 0 + ossl_store_destroy_loaders_int 0 0 + o_names_init 0 0 + __strcasecmp_l_sse42 0 0 +do_rand_drbg_init_ossl_ 0 0 + fstat 0 0 +module_free 0 0 + ctr_BCC_update 0 0 + EVP_camellia_128_ofb 0 0 +ctr_XOR 0 0 + lh_OBJ_NAME_free 0 0 + syscall_random 0 0 +EVP_sm4_ofb 0 0 + ossl_init_add_all_ciphers 0 0 + EVP_sm4_cfb128 0 0 + expand 0 0 + pthread_self 0 0 +CRYPTO_secure_allocated 0 0 + contract 0 0 +rand_pool_add_begin 0 0 + rand_pool_add_end 0 0 + EVP_CIPHER_CTX_new 0 0 + EVP_aria_192_ofb 0 0 + EVP_aria_128_cfb1 0 0 + rand_pool_init 0 0 + sk_nid_triple_free 0 0 + EVP_camellia_256_ctr 0 0 + EVP_aria_256_cfb1 0 0 + getgid 0 0 + EVP_aria_256_cfb8 0 0 +ossl_init_engine_rdrand 0 0 +check_random_device 0 0 +do_err_strings_init 0 0 +do_engine_lock_init 0 0 + EVP_camellia_128_cbc 0 0 + do_rand_init_ossl_ 0 0 + int_cleanup_item 0 0 + OPENSSL_sk_new_reserve 0 0 + get_time_stamp 0 0 + EVP_CIPHER_CTX_key_length 0 0 + sk_ENGINE_CLEANUP_ITEM_new_null0 0 + EVP_camellia_192_cfb8 0 0 + aesni_ecb_cipher 0 0 + lh_ERR_STRING_DATA_new 0 0 +getegid 0 0 + EVP_aria_192_gcm 0 0 + RAND_DRBG_free 0 0 +init256 0 0 + EVP_CipherUpdate 0 0 + EVP_camellia_256_cbc 0 0 + EVP_aria_128_ctr 0 0 + ctr_update 0
Reg slowness seen in openssl 1.1.1
Hi, When we use following set of SSL methods ( openssl 1.1.1) for SHA1-digest, we are witnessing slowness compared to openssl 1.1.0e. EVP_get_digestbyname EVP_MD_CTX_new EVP_DigestInit_ex EVP_DigestUpdate EVP_DigestFinal_ex Could anyone please guide me about how to debug this issue. Thanks and Regards, Ram Krushna
Re: Reg Change in Error Code
Hi Matt, Thanks for the detailed response. As you suggested there is definitely a lot to improve in our code to convey the correct meaning of the code. I have tested with the changes and it conveyed the correct meaning now as you clearly stated. I just have one more doubt. Now I tried to test with the code with an ongoing customer scenario where we do not get any error or error string or the libssl method name as well. Mostly it happens when SSL_get_error() after SSL_do_handshake() returns SSL_ERROR_SYSCALL. Is there any way to capture more information about this error ? Thanks a lot again for your timely response. Regards, Ram Krushna On Sat, May 4, 2019 at 3:34 AM wrote: > Send openssl-users mailing list submissions to > openssl-users@openssl.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mta.openssl.org/mailman/listinfo/openssl-users > or, via email, send a message with subject or body 'help' to > openssl-users-requ...@openssl.org > > You can reach the person managing the list at > openssl-users-ow...@openssl.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openssl-users digest..." > > > Today's Topics: > >1. Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 > EAGAIN (John Unsworth) >2. Reg Change in Error Code (ramakrushna mishra) >3. Re: Reg Change in Error Code (Matt Caswell) >4. Re: Any timeframe for the 1.1.1c release? (Viktor Dukhovni) >5. Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 > EAGAIN (Viktor Dukhovni) > > > -- > > Message: 1 > Date: Fri, 3 May 2019 09:34:14 + > From: John Unsworth > To: "openssl-users@openssl.org" > Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 > EAGAIN > Message-ID: > < > dm6pr07mb4650af92014d45dbb2017095f5...@dm6pr07mb4650.namprd07.prod.outlook.com > > > > Content-Type: text/plain; charset="us-ascii" > > Testing changed code. > > Regards > John > > > From: openssl-users on behalf of Matt > Caswell > Sent: Friday, May 3, 2019 10:16 am > To: openssl-users@openssl.org > Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN > > CAUTION: This email originated from outside of Synchronoss. > > > On 02/05/2019 18:23, Viktor Dukhovni wrote: > >>> At this point you'd be calling SSL_get_error(), is there a lock that > >>> prevents writes between SSL_read() and SSL_read() and SSL_get_error()? > >> > >> The mutex does not protect SSL_get_error() calls. > > > > I think that's an application bug. The SSL_get_error() is using > > the same SSL handle as the SSL_read(), which can be materially > > altered by concurrent writes. (Matt, if you're still reading this > > thread, do you agree?) > > > > I would not release the mutex until after the call to SSL_get_error(). > > An SSL object should not be used in multiple threads at the same time no > matter > what the API call. This applies to SSL_get_error() as well. If you are > doing > that then that could most definitely cause the behaviour you are seeing. > > Matt > > -- next part -- > An HTML attachment was scrubbed... > URL: < > http://mta.openssl.org/pipermail/openssl-users/attachments/20190503/7209280b/attachment-0001.html > > > > -- > > Message: 2 > Date: Fri, 3 May 2019 20:48:05 +0530 > From: ramakrushna mishra > To: openssl-users@openssl.org > Subject: Reg Change in Error Code > Message-ID: > kkorzgv4ezpat6nxtioqjpvys-w2rvrva7yc0cbt5g...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > When client(openssl) is configured with TLSv1 and Server(java) was > configured with TLSv1_2, then in openssl version 1.1.0e we used to get the > error code : 337002677( 0x141640B5). But with openssl 1.1.1 upgrade the > error code changed to 337285301 > (0x141A90B5). Moreover Earlier in java also we used to see > "javax.net.ssl.SSLHandshakeException: Caused by: Remote host closed > connection during handshake " exception at the server end which is not seen > now. > > Following are my doubts. > > 1) Has anyone noticed this change ? > 2) Where these error codes ( 337002677) and (337285301) defined ? > 3) Why the java server will not throw the exception any more ? > > Any help is highly appreciated. > > Thanks and Regards, > Ram Krushna > ------ next part -- &
Reg Change in Error Code
Hi, When client(openssl) is configured with TLSv1 and Server(java) was configured with TLSv1_2, then in openssl version 1.1.0e we used to get the error code : 337002677( 0x141640B5). But with openssl 1.1.1 upgrade the error code changed to 337285301 (0x141A90B5). Moreover Earlier in java also we used to see "javax.net.ssl.SSLHandshakeException: Caused by: Remote host closed connection during handshake " exception at the server end which is not seen now. Following are my doubts. 1) Has anyone noticed this change ? 2) Where these error codes ( 337002677) and (337285301) defined ? 3) Why the java server will not throw the exception any more ? Any help is highly appreciated. Thanks and Regards, Ram Krushna
Reg Speed test and Assembly code usage
Hi, Could anyone please help me get the following information. -- How to verify that the openssl is using the assembly code ( when asm is enabled) instead of the c code for the algorithms ? -- I m observing a small degradation (2 % for 16 byte size) for des-ede3 on openssl1.1.1 for Solaris. This might not be suggested to use the algorithm, but for learning purpose is there something that I can do to see if this can be improved. Thanks and Regards, Ram Krushna
Reg solaris support for openssl 1.1.1b
Hi Dennis
Yes, 10-main.conf is modified for both the versions.
Following are changes.
<<< file 1:
/view/rdl117_linuxx86_64/vobs_tools/src/openssl-1.1.1b/Configurations/10-main.conf@
@/main/1
>>> file 2: 10-main.conf
-[16 changed to 16]-
< ASFLAGS => "/nologo /Zi",
---
> ASFLAGS => "/nologo",
-[44 changed to 44]-
<ASFLAGS => "/nologo /Zi",
---
>ASFLAGS => "/nologo",
-[211 changed to 211]-
< ex_libs => add("-lsocket -lnsl -ldl"),
---
> ex_libs => add("-lsocket -lnsl -ldl -lm -lrt"),
-[1226 changed to 1226]-
< lib_cflags => add("/Zi /Fdossl_static.pdb"),
---
> lib_cflags => add("/Fdossl_static.pdb"),
-[1228-1229 changed to 1228-1229]-
< dso_cflags => "/Zi /Fddso.pdb",
< bin_cflags => "/Zi /Fdapp.pdb",
---
> dso_cflags => "/Fddso.pdb",
> bin_cflags => "/Fdapp.pdb",
The error is coming for OPENSSL_sk_new_null which is changed in 1.1.1b
compared to 1.1.1 with https://github.com/openssl/openssl/pull/7721.
Can this be related ?
Thanks and Regards,
Ram Krushna
On Wed, Mar 27, 2019 at 4:07 PM wrote:
> Send openssl-users mailing list submissions to
> openssl-users@openssl.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mta.openssl.org/mailman/listinfo/openssl-users
> or, via email, send a message with subject or body 'help' to
> openssl-users-requ...@openssl.org
>
> You can reach the person managing the list at
> openssl-users-ow...@openssl.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openssl-users digest..."
>
>
> Today's Topics:
>
>1. Re: Internal IP Exposed (Kyle Hamilton)
>2. Re: Reg solaris support for openssl 1.1.1b (ramakrushna mishra)
>3. Re: Reg solaris support for openssl 1.1.1b (Dennis Clarke)
>4. Re: Building OpenSSL 1.1.1b for WinCE700 ( (Souju TANAKA))
>
>
> --
>
> Message: 1
> Date: Mon, 25 Mar 2019 22:09:31 -0500
> From: Kyle Hamilton
> To: Abdul Qoyyuum
> Cc: openssl-users
> Subject: Re: Internal IP Exposed
> Message-ID:
> 34rhm-wdvz2yonr2ds+3l9uzz9...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> That's a configuration issue with the servers, not an issue with the
> openssl command itself.
>
> There's no information on what the back-end HTTP server software is
> being used. If it were Apache, there would be a ServerName directive
> that could change the server's idea of what name it should refer to
> itself as. I don't have information on other server software
> configuration.
>
> -Kyle H
>
> On Sun, Mar 24, 2019 at 7:34 PM Abdul Qoyyuum
> wrote:
> >
> > Hi all,
> >
> > New to the mailing list and a complete newbie to openssl and the likes.
> There's a ticket by a client that I'm new at and he claims that there's a
> security problem with the openssl command to his servers.
> >
> > Internal IP exposed after running a openssl (version 1.1.0j) connect
> command:
> >
> > openssl s_client -connect 103.XX.XXX.XX:10443 -quiet
> >
> > Where 103.XX.XXX.XX is a Public IP. And after it shows the certificates,
> typed the following:
> >
> > GET /images HTTP/1.0
> >
> > And hit enter twice, the following gets displayed:
> >
> > HTTP/1.0 301 Moved Permanently
> > Date: Mon, 25 Mar 2019 00:10:13 GMT
> > Server: -x
> > Location: https://10.240.123.1:10443/images/
> > Connection: close
> > Content-Type: text/html; charset=utf-8
> > X-Frame-Options: SAMEORIGIN
> > Content-Security-Policy: frame-ancestors 'self'
> > X-XSS-Protection: 1; mode=block
> > X-Content-Type-Options: nosniff
> > Strict-Transport-Security: max-age=28800
> >
> >
> >
> > 301 Moved Permanently
> >
> > Moved Permanently
> > The document has moved https://10.240.123.1:10443/images/
> ">here.
> >
> > read:errno=0
> >
> > The 10.240.123.1 is an internal IP and it is exposed by this little
> method. Although not shown when using curl -kv -O command.
> >
> > Is there a way to cover up the "Location" or at least the internal IP
> from bein
Re: Reg solaris support for openssl 1.1.1b
> > Hi All, > Thanks for your responses. I am able to build openssl 1.1.1 on my solaris and able to run "openssl version". I followed the same procedure for openssl 1.1.1b and when I run "openssl version" seeing the mentioned error. i.e "ld.so.1: openssl: fatal: relocation error: file openssl: symbol OPENSSL_sk_new_null: referenced symbol not found Killed ". So, How come it works with openssl 1.1.1 and not with 1.1.1b. I am using the same machine and same procedure to configure and install it. So, Is there anything different that need to be done for 1.1.1b version ? Thanks and Regards, Ram Krushna > > On Sat, Mar 16, 2019 at 6:20 AM wrote: > >> Send openssl-users mailing list submissions to >> openssl-users@openssl.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://mta.openssl.org/mailman/listinfo/openssl-users >> or, via email, send a message with subject or body 'help' to >> openssl-users-requ...@openssl.org >> >> You can reach the person managing the list at >> openssl-users-ow...@openssl.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of openssl-users digest..." >> >> >> Today's Topics: >> >>1. Re: Reg solaris support for openssl 1.1.1b (Jakob Bohm) >>5. Re: Reg solaris support for openssl 1.1.1b (Dennis Clarke) >> >> >> -- >> >> Message: 1 >> Date: Fri, 15 Mar 2019 18:19:53 +0100 >> From: Jakob Bohm >> To: openssl-users@openssl.org >> Subject: Re: Reg solaris support for openssl 1.1.1b >> Message-ID: <649ef06e-0f64-65bb-cb43-cfde681fd...@wisemo.com> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> On 15/03/2019 14:33, Dennis Clarke wrote: >> > On 3/15/19 5:38 AM, Matthias St. Pierre wrote: >> >> My guess is that your binary is loading the system's shared libraries. >> >> To find out whether this is the case, try >> >> >> >> ??? ldd bin/openssl >> >> >> >> If my assumption is correct, you might have to set the LD_LIBRARY_PATH >> >> explicitely. >> > Actually LD_LIBRARY_PATH is evil. >> > >> > The correct way to do this is to compile with a RUNPATH set in the >> > output ELF files. >> LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when >> testing >> a newly compiled binary before installing the libraries to their final >> locations, perhaps >> on the same, perhaps on another machine. >> >> P.S. >> I don't known if the Solaris loader lets LD_LIBRARY_PATH override >> RUNPATH as >> presumed by the above answer. >> >> Enjoy >> >> Jakob >> -- >> Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 >> >> >> >> -- >> Message: 5 >> Date: Fri, 15 Mar 2019 20:49:30 -0400 >> From: Dennis Clarke >> To: openssl-users@openssl.org >> Subject: Re: Reg solaris support for openssl 1.1.1b >> Message-ID: <4b08232c-f734-987c-814c-5acef59f4...@blastwave.org> >> Content-Type: text/plain; charset=utf-8 >> >> On 3/15/19 1:19 PM, Jakob Bohm via openssl-users wrote: >> > On 15/03/2019 14:33, Dennis Clarke wrote: >> >> On 3/15/19 5:38 AM, Matthias St. Pierre wrote: >> >>> My guess is that your binary is loading the system's shared libraries. >> >>> To find out whether this is the case, try >> >>> >> >>> ldd bin/openssl >> >>> >> >>> If my assumption is correct, you might have to set the LD_LIBRARY_PATH >> >>> explicitely. >> >> Actually LD_LIBRARY_PATH is evil. >> >> >> >> The correct way to do this is to compile with a RUNPATH set in the >> >> output ELF files. >> > LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when >> > testing >> > a newly compiled binary before installing the libraries to their final >> > locations, perhaps >> > on the same, perhaps on another machine. >> > >> > P.S. >> > I don't known if the Solaris loader lets LD_LIBRARY_PATH override >> > RUNPATH as >> > presumed by the above answer. >> >> Yes it certainly does. Otherwise testing a new custom lib would be a >> royal pain as opposed to just a pain. Also most people still, after >> twenty years, know what LD_LIBRARY_PATH env var is for and it is a waste >> of breath trying to explain it after decades of watching folks skewer >> themselves over and over and over >> >> dc >> >> >> >> -- >> >> Subject: Digest Footer >> >> ___ >> openssl-users mailing list >> openssl-users@openssl.org >> https://mta.openssl.org/mailman/listinfo/openssl-users >> >> >> -- >> >> End of openssl-users Digest, Vol 52, Issue 19 >> * >> >
Re: Reg solaris support for openssl 1.1.1b
Hi All, Thanks for all your response. I have tried to set LD_LIBRARY_PATH to the lib path of newly installed openssl and still "./openssl version" fails with the same reason. There is another suggestion to "compile with a RUNPATH set in the output ELF files. " . Could anyone please provide more details about this and how to do it ? Thanks and Regards, Ram Krushna On Sat, Mar 16, 2019 at 6:20 AM wrote: > Send openssl-users mailing list submissions to > openssl-users@openssl.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mta.openssl.org/mailman/listinfo/openssl-users > or, via email, send a message with subject or body 'help' to > openssl-users-requ...@openssl.org > > You can reach the person managing the list at > openssl-users-ow...@openssl.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openssl-users digest..." > > > Today's Topics: > >1. Re: Reg solaris support for openssl 1.1.1b (Jakob Bohm) >5. Re: Reg solaris support for openssl 1.1.1b (Dennis Clarke) > > > -- > > Message: 1 > Date: Fri, 15 Mar 2019 18:19:53 +0100 > From: Jakob Bohm > To: openssl-users@openssl.org > Subject: Re: Reg solaris support for openssl 1.1.1b > Message-ID: <649ef06e-0f64-65bb-cb43-cfde681fd...@wisemo.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 15/03/2019 14:33, Dennis Clarke wrote: > > On 3/15/19 5:38 AM, Matthias St. Pierre wrote: > >> My guess is that your binary is loading the system's shared libraries. > >> To find out whether this is the case, try > >> > >> ??? ldd bin/openssl > >> > >> If my assumption is correct, you might have to set the LD_LIBRARY_PATH > >> explicitely. > > Actually LD_LIBRARY_PATH is evil. > > > > The correct way to do this is to compile with a RUNPATH set in the > > output ELF files. > LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when > testing > a newly compiled binary before installing the libraries to their final > locations, perhaps > on the same, perhaps on another machine. > > P.S. > I don't known if the Solaris loader lets LD_LIBRARY_PATH override > RUNPATH as > presumed by the above answer. > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 > > > > -- > Message: 5 > Date: Fri, 15 Mar 2019 20:49:30 -0400 > From: Dennis Clarke > To: openssl-users@openssl.org > Subject: Re: Reg solaris support for openssl 1.1.1b > Message-ID: <4b08232c-f734-987c-814c-5acef59f4...@blastwave.org> > Content-Type: text/plain; charset=utf-8 > > On 3/15/19 1:19 PM, Jakob Bohm via openssl-users wrote: > > On 15/03/2019 14:33, Dennis Clarke wrote: > >> On 3/15/19 5:38 AM, Matthias St. Pierre wrote: > >>> My guess is that your binary is loading the system's shared libraries. > >>> To find out whether this is the case, try > >>> > >>> ldd bin/openssl > >>> > >>> If my assumption is correct, you might have to set the LD_LIBRARY_PATH > >>> explicitely. > >> Actually LD_LIBRARY_PATH is evil. > >> > >> The correct way to do this is to compile with a RUNPATH set in the > >> output ELF files. > > LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when > > testing > > a newly compiled binary before installing the libraries to their final > > locations, perhaps > > on the same, perhaps on another machine. > > > > P.S. > > I don't known if the Solaris loader lets LD_LIBRARY_PATH override > > RUNPATH as > > presumed by the above answer. > > Yes it certainly does. Otherwise testing a new custom lib would be a > royal pain as opposed to just a pain. Also most people still, after > twenty years, know what LD_LIBRARY_PATH env var is for and it is a waste > of breath trying to explain it after decades of watching folks skewer > themselves over and over and over > > dc > > > > -- > > Subject: Digest Footer > > ___ > openssl-users mailing list > openssl-users@openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-users > > > -- > > End of openssl-users Digest, Vol 52, Issue 19 > * >
Re: Reg solaris support for openssl 1.1.1b
Hi, I am trying to upgrade openssl on solaris machine from 1.1.0e to 1.1.1b. The "uname -a " output from solaris is : > SunOS 5.10 Generic_147147-26 sun4v sparc sun4v > The Configure and installation of openssl was successful. But when i run "bin/openssl version" it fails with following error. "openssl version ld.so.1: openssl: fatal: relocation error: file openssl: symbol OPENSSL_sk_new_null: referenced symbol not found". could you please anyone let me know what could be the problem ? Thanks and regards, Ram Krushna
[openssl-users] Reg issue in alert message
Hi Matt,
Thank you for the response.
But I wanted to know the handshake behavior when client has support for
"TLSv1.3,TLSv1.2" and server has support for ("TLSv1.2,TLSv1") or
("TLSv1.2,SSLv3).
Both client and server is built with openssl 1.1.1 and the above connection
fails with handshake failure. The same connection works if server has
continious range of protocol version such as
("TLSv1.2,TLSv1.1,TLSv1,SSLv3).
So, is the handshake behavior change if the supported protocol versions are
not in continuous range ?
Thanks and regards,
Ram Krushna
On Wed, Oct 24, 2018 at 10:14 PM wrote:
> Send openssl-users mailing list submissions to
> openssl-users@openssl.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mta.openssl.org/mailman/listinfo/openssl-users
> or, via email, send a message with subject or body 'help' to
> openssl-users-requ...@openssl.org
>
> You can reach the person managing the list at
> openssl-users-ow...@openssl.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openssl-users digest..."
>
>
> Today's Topics:
>
>1. Re: Reg issue in alert message (Matt Caswell)
>2. Using SM2 ECIES in 1.1.1 (Akira Takahashi)
>3. Re: Using SM2 ECIES in 1.1.1 (Matt Caswell)
>4. openssl cms encrypt recipientInfo [questions for openssl
> developers]. ( ?)
>
>
> --
>
> Message: 1
> Date: Wed, 24 Oct 2018 13:57:04 +0100
> From: Matt Caswell
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] Reg issue in alert message
> Message-ID:
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 24/10/2018 13:25, ramakrushna mishra wrote:
> > Hi All,
> >
> > Thank you for all for providing the information.
> > I suspect we are using " SSL_MODE_SEND_FALLBACK_SCSV??" and that might
> > be causing the issue.? The team is looking into this issue now with the
> > provided information.?
> >
> > ?One doubt that came during? our investigation is :
> > " If client has highest version of TLS1.3 and server has support for
> > TLS1.2 and SLV3 only.? ?How the handshake will? proceed ? "
>
> The protocol will negotiate the highest commonly supported protocol
> version. So if the server supports TLS1.3 and the client only supports
> TLS1.2 then TLS1.2 will be used. Don't use SSLv3. That is disabled by
> default in current OpenSSL versions.
>
> Matt
>
> > I am not sure if this question should go to a new thread ?
> >
> > Thanks and Regards,
> > Ram Krushna
> >
> > On Wed, Oct 24, 2018 at 11:47 AM > <mailto:openssl-users-requ...@openssl.org>> wrote:
> >
> > Send openssl-users mailing list submissions to
> > ? ? ? ? openssl-users@openssl.org <mailto:openssl-users@openssl.org>
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > ? ? ? ? https://mta.openssl.org/mailman/listinfo/openssl-users
> > or, via email, send a message with subject or body 'help' to
> > ? ? ? ? openssl-users-requ...@openssl.org
> > <mailto:openssl-users-requ...@openssl.org>
> >
> > You can reach the person managing the list at
> > ? ? ? ? openssl-users-ow...@openssl.org
> > <mailto:openssl-users-ow...@openssl.org>
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of openssl-users digest..."
> >
> >
> > Today's Topics:
> >
> > ? ?1. Re: CAPI-Engine doc (Selva Nair)
> > ? ?2. Re: CAPI-Engine doc (Michael Wojcik)
> > ? ?3. Re: Reg issue in alert message (Michael Wojcik)
> > ? ?4. Re: CAPI-Engine doc (Jakob Bohm)
> > ? ?5. Re: Openssl Build Error- module unsafe for SAFESEH
> > ? ? ? image/Unable to generate SAFESEH image (sakdev)
> >
> >
> >
> --
> >
> > Message: 1
> > Date: Tue, 23 Oct 2018 11:22:04 -0400
> > From: Selva Nair mailto:selva.n...@gmail.com
> >>
> > To: richard.oehlin...@adbsafegate.com
> > <mailto:richard.oehlin...@adbsafegate.com>,
> > openssl-users@openssl.org <mailto:openssl-users@openssl.org>
> > Subject: Re: [openssl-users] CAPI-Engine doc
> > Message-ID:
> > ? ? ? ?
> > > <mailto:vfg_ntzajsqj%2bd...@mail.gmail.com>>
> > Content-Type: text/plain; charset="UTF-8&qu
[openssl-users] Reg issue in alert message
Hi All,
Thank you for all for providing the information.
I suspect we are using " SSL_MODE_SEND_FALLBACK_SCSV " and that might be
causing the issue. The team is looking into this issue now with the
provided information.
One doubt that came during our investigation is :
" If client has highest version of TLS1.3 and server has support for TLS1.2
and SLV3 only. How the handshake will proceed ? "
I am not sure if this question should go to a new thread ?
Thanks and Regards,
Ram Krushna
On Wed, Oct 24, 2018 at 11:47 AM wrote:
> Send openssl-users mailing list submissions to
> openssl-users@openssl.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mta.openssl.org/mailman/listinfo/openssl-users
> or, via email, send a message with subject or body 'help' to
> openssl-users-requ...@openssl.org
>
> You can reach the person managing the list at
> openssl-users-ow...@openssl.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openssl-users digest..."
>
>
> Today's Topics:
>
>1. Re: CAPI-Engine doc (Selva Nair)
>2. Re: CAPI-Engine doc (Michael Wojcik)
>3. Re: Reg issue in alert message (Michael Wojcik)
>4. Re: CAPI-Engine doc (Jakob Bohm)
>5. Re: Openssl Build Error- module unsafe for SAFESEH
> image/Unable to generate SAFESEH image (sakdev)
>
>
> --
>
> Message: 1
> Date: Tue, 23 Oct 2018 11:22:04 -0400
> From: Selva Nair
> To: richard.oehlin...@adbsafegate.com, openssl-users@openssl.org
> Subject: Re: [openssl-users] CAPI-Engine doc
> Message-ID:
> vfg_ntzajsqj+d...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Tue, Oct 23, 2018 at 10:38 AM Richard Oehlinger via openssl-users
> wrote:
> >
> > Hi!
> >
> > I'm trying to get a handle on the CAPI engine, because I need to have a
> > secure Keystore on Windows. Furthermore I need it to work with Qt's
> > QSslKey, which fortunately can be constructed by EVP_PKEY *.
> >
> > So far so good. The key is found, but when I try to use it in a SSL
> > connection i get following error:
> >
> > error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
> > error:1409B006:SSL routines:ssl3_send_server_key_exchange:EVP lib
>
> Which version of OpenSSL?
>
> > Trace Output is:
> >
> > Setting debug file to C:\Users\user\AppData\Local\Temp\engine.txt
> > Opening certificate store MY
> > capi_get_key, contname={4EBA52A8-AB4B-47DB-B777-2B26351F324C},
> > provname=Microsoft Enhanced Cryptographic Provider v1.0, type=1
> > Called CAPI_rsa_sign()
>
> This CSP cannot do SHA2 hashes so won't work unless you restrict
> signature algorithms or set TLS version to 1.1. I believe OpenSSL
> 1.1.0 will try to load The ".. Enhanced RSA AES .. Provider" which
> can handle SHA2 and may work. I say "may" because, if the key store is
> a legacy hardware token, it also depends on signature algorithms supported
> by the token and may be necessary to downgrade to TLS 1.1.
>
> Selva
>
>
> --
>
> Message: 2
> Date: Tue, 23 Oct 2018 15:37:24 +
> From: Michael Wojcik
> To: "openssl-users@openssl.org"
> Subject: Re: [openssl-users] CAPI-Engine doc
> Message-ID:
> <
> dm5pr18mb1324455050cc00bd3a2dd70ff9...@dm5pr18mb1324.namprd18.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="Windows-1252"
>
> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> > Of Richard Oehlinger via openssl-users
> > Sent: Tuesday, October 23, 2018 10:38
> >
> > I'm trying to get a handle on the CAPI engine, because I need to have a
> > secure Keystore on Windows. Furthermore I need it to work with Qt's
> > QSslKey, which fortunately can be constructed by EVP_PKEY *.
>
> What OpenSSL version are you using? Please remember to include this
> informtion in every question. (And, normally, we'd ask for the platform as
> well, but since CAPI is Windows-specific, we know that in this case.)
>
> > So far so good. The key is found, but when I try to use it in a SSL
> > connection i get following error:
> >
> > error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
> > error:1409B006:SSL routines:ssl3_send_server_key_exchange:EVP lib
> >
> > I use a current Windows 10. Do I need to use a different Algorithm in
> > order to work? Some googeling is indicating the provider might be wrong.
>
> I haven't looked at the CAPI engine code since 1.0.1j. At that time, I
> needed CAPI support and discovered there were various issues with the
> extant CAPI code, so I forked and rewrote it. That was some time back,
> obviously, and I'm afraid I never got around to pushing the changes back to
> openssl.org. (In fact, it was sufficiently long ago that I believe the
> organization was still reluctant to take contributions from people in the
> US at the time.)
>
> The biggest issue was with provider handling. CAPI is something of a
>
[openssl-users] Reg issue in alert message
Hi Matt, Thanks for your response. My client is built with openssl 1.0.0e and server with openssl 1.1.1. I have tried to collect information with wireshark, but I think as my server and client are running on same machine , it is not capturing anything. I have also tried with tshark on linux and got no traces again. I have this trouble both on nt64and linuxx86_64. Do we have any other mechanism to capture the traces ? We have internal tracing enabled and I can see following information in our tracing. ** [Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION --- SSL State: 16 before SSL initialization [Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x BIO --- ctrl to [02457660] (6 bytes => 0 (0x0)) [Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x BIO --- contents of a BIO dump: [Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION --- SSL_accept:before SSL initialization [Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x BIO --- read to [02463953] (5 bytes => 5 (0x5)) [Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x BIO --- contents of a BIO dump: - 16 03 01 00 b2. [Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x BIO --- read to [02463958] (178 bytes => 178 (0xB2)) [Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x BIO --- contents of a BIO dump: - 01 00 00 ae 03 03 10 b1-1e 8f f0 07 d6 28 d9 02 .(.. 0010 - b7 91 b4 3d 14 5a af 3e-09 96 2a cf ee 8b ca 30 ...=.Z.>..*0 0020 - cc 68 9f 2c 2e 6e 00 00-62 00 a5 00 a3 00 a1 00 .h.,.n..b... 0030 - 9f 00 6b 00 6a 00 69 00-68 00 39 00 38 00 37 00 ..k.j.i.h.9.8.7. 0040 - 36 00 9d 00 3d 00 35 00-a4 00 a2 00 a0 00 9e 00 6...=.5. 0050 - 67 00 40 00 3f 00 3e 00-33 00 32 00 31 00 30 00 g.@.?.>.3.2.1.0. 0060 - 9a 00 99 00 98 00 97 00-9c 00 3c 00 2f 00 96 00 ..<./... 0070 - 05 00 04 00 16 00 13 00-10 00 0d 00 0a 00 15 00 0080 - 12 00 0f 00 0c 00 09 00-ff *56 00* 01 00 00 23 00 .V#. 0090 - 23 00 00 00 0d 00 16 00-14 06 01 06 02 05 01 05 #... 00a0 - 02 04 01 04 02 03 01 03-02 02 01 02 02 00 0f 00 00b0 - 01 01 .. [Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION --- SSL_accept:before SSL initialization [Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x BIO --- write to [024725E0] (7 bytes => 7 (0x7)) [Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x BIO --- contents of a BIO dump: - 15 03 03 00 02 02 56 ..V [Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION --- write:fatal:unknown [Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION --- SSL_accept:error in error In the above dump , "56 00 " is present in the cipher suites sent in client hello. So, I think client have set TLS_FALLBACK_SCSV in cipher suite list in client hello. However there is no earlier failure to this handshake. As per your comment, client should only send it if it witnessed some earlier failure. In that case, I have following additional doubt. -- this set up is working when server is running with TLSv1.2 and only failing when server has both TLSv1,2 and TLSv1.3 ( i.e with openssl1.1.1). So are there any changes in openssl1.1.1 which will effect this behavior when compared to openssl1.0.0e version ? Thanks and Regards, Ram Krushna On Mon, Oct 22, 2018 at 11:21 PM wrote: > Send openssl-users mailing list submissions to > openssl-users@openssl.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mta.openssl.org/mailman/listinfo/openssl-users > or, via email, send a message with subject or body 'help' to > openssl-users-requ...@openssl.org > > You can reach the person managing the list at > openssl-users-ow...@openssl.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openssl-users digest..." > > > Today's Topics: > >1. Re: What to do with deprecation errors (Salz, Rich) >2. Re: What to do with deprecation errors (Matt Caswell) >3. Re: To disable CBC ciphers (Jakob Bohm) >4. Reg issue in alert message (ramakrushna mishra) >5. Re: Reg issue in alert message (Matt Caswell) >6. Re: What to do with deprecation errors (Skip Carter) > > > -- > > Message: 1 > Date: Mon, 22 Oct 2018 02:08:23 + > From: "Salz, Rich" > To: Skip Carter , "openssl-users@openssl.org" > > Subject: R
[openssl-users] Reg issue in alert message
Hi, I am facing an issue after openssl upgrade to 1.1.1. I have a odbc client with maximum version support up to TLSv1.2 and my database is running with TLSv1.2,TLsv1.3. The handhake is failing and I am getting following contents on my BIO dump. "15 03 03 00 02 02 56" . If i have understood correctly this is for alert message and But I could not find any reference to alert description at ( https://tools.ietf.org/id/draft-ietf-tls-tls13-25.html#alert-protocol ) corresponding to 56. So, Could you please help me figure out what does this correspond to ? Moreover I have following doubt. -- If my TLSv1.2 client does not handle the "downgrade sentinel " present in server hello ( TLSv1.3 , will it create any problem ? -- In the above example client is receving error such as "SSL Handshake Failure reason [error:1407743E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert inappropriate fallback]." ? Could you please help me to hint me about how to debug this ? Thanks and Regards, Ram Krushna -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
