s_server configuration

2019-07-15 Thread Steven Madwin via openssl-users 


Hi All,

 

I’m trying to get an OCSP server operating in an SSL (really TLS1.2) 
environment. It works fine in the HTTP world, but I’m having issues with 
getting s_server to handle the communication in the Secure HTTPS world.

 

If anyone has any suggestions to get the connection to persist I’d be VERY 
appreciative!

 

This is what I’m seeing:

 

--- Using OpenSSL v1.1.1c to enable TLS on Port 8902 ---

 

C:\OpenSSL-Win64\bin>openssl  s_server -port 8902 -4 -certform PEM -cert 
"C:\OpenSSL-Win64\bin\PEM\test.cer" -cert_chain 
C:\OpenSSL-Win64\bin\PEM\DigiCertTrustChain.cer -keyform PEM -pass 
pass:password -key "C:\OpenSSL-Win64\bin\PEM\test_key.pem"  -status_verbose

 

Using default temp DH parameters

ACCEPT

 

cert_status: callback called

cert_status: AIA URL: http://ocsp.digicert.com

cert_status: Can't retrieve issuer certificate.

-BEGIN SSL SESSION PARAMETERS-

MFoCAQECAgMDBALAMAQABDBt6uS6sCfohxxHvmv7hPIXRbjKzDqNJqoCpymZR1qc

CpGHf1mBjQ5/B32R7/aXl8mhBgIEXS0L6KIEAgIcIKQGBAQBrQMCAQE=

-END SSL SESSION PARAMETERS-

Shared 
ciphers:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA

Signature Algorithms: 
RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512

Shared Signature Algorithms: 
RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512

Supported Elliptic Curve Point Formats: uncompressed

Supported Elliptic Groups: X25519:P-256:P-384

Shared Elliptic groups: X25519:P-256:P-384

---

No server certificate CA names sent

CIPHER is ECDHE-RSA-AES256-GCM-SHA384

Secure Renegotiation IS supported

POST / HTTP/1.1

Accept: */*

Content-Type: application/ocsp-request

Content-Length: 143

Character-Encoding: binary

User-Agent: PPKHandler

Host: gemma.adobe.com:8902

Connection: Keep-Alive

Cache-Control: no-cache

Cookie: AAMC_adobe_0=REGION%7C9; s_nr=1562971576381-Repeat; 
adcloud={%22_les_v%22:%22y%2Cadobe.com%2C1564005807%22}; 
AMCV_9E1005A551ED61CA0A490D45%40AdobeOrg=-1303530583%7CMCAID%7C2D05BCDE05032D0E-40001185A003F0F0%7CMCMID%7C06088709957453939181689303953590820094%7CMCAAMLH-1563576332%7C9%7CMCAAMB-1563576332%7Cj8Odv6LonN4r3an7LhD3WZrU1bUpAkFkkiY1ncBR96t2PTI%7CMCOPTOUT-1562978727s%7CNONE%7CvVersion%7C3.3.0%7CMCIDTS%7C18072%7CMCSYNCSOP%7C411-18079%7CMCCIDH%7C1521286796;
 
mbox=PC#ddd404f9c1d0418ba9692aaf983e9e03.28_36#1626216329|session#7b3f3fbfb1504526acdb639358290766#1562973437;
 s_vi=[CS]v1|2D05BCDE05032D0E-40001185A003F0F0[CE]; 
_fbp=fb.1.1561413807767.1078876052

 

0
 +00­ +0[1]

  _  


  _  

ƒ°â█g┘⌐├Z<₧é╚ @ERROR

shutting down SSL

CONNECTION CLOSED

 

 




 

Steven Madwin

Software PKI Engineer

Adobe Inc.

345 Park Avenue, MS-W15

San Jose, CA 95110-2704 USA

Phone:   408.536.4343

Fax: 408.536.6024

  steven.mad...@adobe.com

 

 



smime.p7s
Description: S/MIME cryptographic signature

Re: Drbg kat test data: Openssl-fips 2.0.16

2019-07-15 Thread Mark Minnoch 
Manish asked:

> There is DRBG kat test data in fips_drbg_selftest.h. (Openssl-fips-2.0.16)
> Can anyone let me know, What is the source of this constant arrays. NIST
> link or any other  source will be helpful?

I'm pretty sure that the test data for the DRBG KAT (known answer test)
came from the NIST algorithm test tool when the OpenSSL team tested all of
the algorithm implementations.

The CAVP also posts sample test vectors if you are looking for that sort of
thing:
https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/random-number-generators#DRBG

Mark J. Minnoch
Co-Founder, CISSP
KeyPair Consulting
+1 (805) 550-3231 <(805)%20550-3231> mobile
https://KeyPair.us 
https://www.linkedin.com/in/minnoch

*We expertly guide technology companies in achieving their FIPS 140 goals*

*Blog post: You Have Your FIPS Certificate. Now What?
*

RE: OpenSSL 1.1.1b - TLS server handshake fails when using CAPI engine - capi_rsa_priv_enc() - capi engine: function not supported

2019-07-15 Thread Michael Wojcik 
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> sandeep m.v
> Sent: Monday, July 15, 2019 11:56

> I'm seeing this issue - capi_rsa_priv_enc() - capi engine: function not 
> supported,
> when I tried to upgrade my application from using OpenSSL version 1.0.2r to 
> 1.1.1b.
> This is causing TLS handshake to fail.
> In my case, I'm creating a self signed certificate that is used by Server 
> application
> loading CAPI engine.
> Certificate is created by calling CertCreateSelfSignCertificate(--) - 
> wincrypt.h -
> using szOID_RSA_SHA256RSA  signature algorithm and "Microsoft Enhanced RSA and
> AES Cryptographic Provider".

It's been some years since I worked with OpenSSL CAPI support, and in 
particular I haven't done anything with the CAPI engine for 1.1.

For 1.0.2, though, I ended up forking the OpenSSL CAPI engine support and 
enhancing it in a number of places. I changed capi_load_privkey and the 
functions it calls (capi_find_key and capi_get_pkey) to silently determine if 
the provider type in the context was wrong, and if so correct it.

CAPI is a fairly horrible API (CNG is somewhat better), and in particular is 
very fragile when there's a mismatch between the provider type in the CAPI 
context and the provider type specified for the key. It may be that your CAPI 
context specifies a provider other than the Enhanced RSA and AES one.

The CAPI engine for 1.0.2 (at least the version I forked from) also had a 
shortcoming which Steve Henson had suggested a fix for, but which wasn't in the 
code. That's down in capi_get_key where it calls CryptGetUserKey. If 
CryptGetUserKey fails with NTE_NO_KEY (you have to call GetLastError to check), 
then try again with the other key type, by XORing keyspec with 3:

   if (!CryptGetUserKey(key->hprov, keyspec, >key))
  {
  success = FALSE;
  errcode = GetLastError();
  if (errcode == NTE_NO_KEY)
{
keyspec ^= 3;
success = CryptGetUserKey(key->hprov, keyspec, >key);
}
  ...
  }

This handles the case where you have an RSA key marked as a key-exchange key 
and you need a signing key, or vice versa.

All of that may be fixed already in the 1.1 CAPI engine, or be irrelevant to 
your problem, of course. But those are potential issues when using RSA keys 
with CAPI.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

OpenSSL 1.1.1b - TLS server handshake fails when using CAPI engine - capi_rsa_priv_enc() - capi engine: function not supported

2019-07-15 Thread sandeep m.v 
Hi,

This is regarding an issue reported here in this link -
https://github.com/openssl/openssl/issues/8872  - This is blocking my
development progress.
I'm seeing this issue - capi_rsa_priv_enc() - capi engine: function not
supported, when I tried to upgrade my application from using OpenSSL
version 1.0.2r to 1.1.1b.
This is causing TLS handshake to fail.
In my case, I'm creating a self signed certificate that is used by Server
application loading CAPI engine.
Certificate is created by calling CertCreateSelfSignCertificate(--) -
wincrypt.h - using szOID_RSA_SHA256RSA  signature algorithm and "Microsoft
Enhanced RSA and AES Cryptographic Provider".

This failure doesn't look like it's because of TLS1.3 as turning off TLS1.3
while configure with "no-tls1_3" also caused the same problem.
Here is the call stack that is causing the reported problem when
SSL_accept() is called.

 capi.dll!capi_rsa_priv_enc(int flen, const unsigned char * from, unsigned
char * to, rsa_st * rsa, int padding)
libcrypto-1_1.dll!RSA_private_encrypt(int flen, const unsigned char * from,
unsigned char * to, rsa_st * rsa, int padding)
libcrypto-1_1.dll!pkey_rsa_sign(evp_pkey_ctx_st * ctx, unsigned char * sig,
unsigned int * siglen, const unsigned char * tbs, unsigned int tbslen)
libcrypto-1_1.dll!EVP_PKEY_sign(evp_pkey_ctx_st * ctx, unsigned char * sig,
unsigned int * siglen, const unsigned char * tbs, unsigned int tbslen)
libcrypto-1_1.dll!EVP_DigestSignFinal(evp_md_ctx_st * ctx, unsigned char *
sigret, unsigned int * siglen)
libcrypto-1_1.dll!EVP_DigestSign(evp_md_ctx_st * ctx, unsigned char *
sigret, unsigned int * siglen, const unsigned char * tbs, unsigned int
tbslen)
libssl-1_1.dll!tls_construct_cert_verify(ssl_st * s, wpacket_st * pkt)
libssl-1_1.dll!write_state_machine(ssl_st * s)
libssl-1_1.dll!state_machine(ssl_st * s, int server)
libssl-1_1.dll!ossl_statem_accept(ssl_st * s)
libssl-1_1.dll!SSL_do_handshake(ssl_st * s)
libssl-1_1.dll!SSL_accept(ssl_st * s)



Is there a solution for this? Or
Do I need to switch to some other Signature algorithm like ECDSA? Can I use
this or anything else instead of RSA?
If I should switch to ECDSA, should I use "szOID_ECDSA_SHA256" (wincrypt.h)
as signature algorithm, use "PROV_EC_ECDSA_SIG" while calling
CryptAcquireContext() and call ENGINE_set_default() with ENGINE_METHOD_EC
to support ECDSA using capi.dll?

Thank you in advance.

-- 
Regards,
Sandeep

FW: BN_mod_exp() issue

2019-07-15 Thread Amritha Thorath 


Thanks,
[cid:image005.png@01D01EBC.D4993640]



Amritha Thorath
Cryptographic Software Developer


O: 703-267-6050 x 119


E: athor...@corsec.com

Website | Blog | 
Facebook | 
Twitter | 
LinkedIn

Opening Markets Through Security Certifications



From: Amritha Thorath
Sent: Monday, July 15, 2019 10:34 AM
To: 'openssl-users@openssl.org' 
Subject: BN_mod_exp() issue

Hi,

I'm trying to implement RSA decryption primitive (Refer 
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf; 
section 7.1.2.1) using OpenSSL.
I've tried to implement in the same manner shown in some testcases 
(https://github.com/openssl/openssl/blob/master/test/bntest.c).
>From the documentation, it is evident that message m can be generated with the 
>below equation:
m = (c^d) mod n
I use BN_mod_exp() to do this. My values for N, D and C are shown below:
N : 
bff722714050aebb23a9bd018c3e9ba26a47f53816eeac7e10543958702d9265c8d67784fe03c07bfceac05e7f2a434971dfa2a5ea461893450ced52fcb3f143a85fb3a9194417ff220258840a3359a104079ccd201afec091bab6587d4cfe0b95bba34ef74a70b392a92a93f026c9bed41eb4ec80452492a2ad524e6b0333c5787b34ee941829020bb75ee5dd216b3734823ddd547d50f8a7e711f8a24fd7dbc0bd2f062ccaba98cdbf62c15d2521b39ce44c53125604493e482ae35f945c4efff1d01414b0aad33de77b020ea4aedf3d88171fe51b22881bc70c639f8b6f1b5a70ed39aa121a8f44887dcbbfce29e1e508d1b0f093b476d81faa6a18bd

D : 
a13aec8eba3a09c7dc18404b0083c52c10a00771e8b0e5e7abc751b2d9e52cc4987ea93be62d3889eacf306b2ddb4d506e782a9fb7b8d0034147ae3cb94a59253e51c3100fcc856b2021603ee66262b13e3536998291a9ce0b980a7720267e693485b890265b3b75578505e1e31e70ebfa3520385333bf97f9522183039658efd9b09fc0bd67a7d3c32e23adada71320ada2135f1d06a9144033ff9e0037a3b7ed1f5729b6db5f02470ecdde9eb2d97c759c73d13889bae550ab97205b67ce2f91eefb487f18c19bc6dd8831a43b0d699c771e1a9c55a1d5d2ae975691789b5c0a814c4f5e3d6a8e9e5f75419194b2d7dfe06700f6891cae8b712b3af1f9ec71

C : 
534d1f57d948cac580b88b922bc47bc3d64c8cd1262bbf0944b99833ec94d072c1a1496be44d47a9c419dc403855a4b1cb2bb30e56e0cc5fd557d34373d785dbe70d67e30355fc228a353b05432a40874ba84253af5cc52d3ab4118e8ca1e28e6c9c610760e753f87a15912774ccb80b00ca21e85926143c1ed8385a607c4e55fa531f1f208bb3f23bc0c4eff4c272068f9939157bc61f5427cc32f017ef31f6363c8a736ec984da763ebea5eb94d83fa31d70223ec5503cfd97e598d883f43aca5e884b702a2f76d298659181cb5180e25faf56c9aa0ebe49413b9acbbefde95ec102ee4e351a8ff8d5a3fbdcee448ff466dffb45fdc0a0b3d31b3d192bb5cb

I keep getting a seg fault and I'm not sure why. My code and the error are 
shown below:

Code:

  BIGNUM *m = NULL, *n = NULL, *d = NULL, *c = NULL;

  int isValid = -1;

  n = BN_bin2bn(N, 256, n);
  d = BN_bin2bn(D, 256, d);
  c = BN_bin2bn(ciphertext, 256, d);

  if (c == NULL || n == NULL || d == NULL)
printf("\n\nC,N,D is NULL, BN_bin2bn() failed!!\n\n");

  isValid = BN_mod_exp(m, c, d, n, NULL);

  BN_free(n); BN_free(d); BN_free(c); BN_free(m);

The error is :

Program received signal SIGSEGV, Segmentation fault.
0x7792fd39 in fips_bn_ctx_start (ctx=0x0) at bn_ctx.c:261
261 if(ctx->err_stack || ctx->too_many)
(gdb) bt
#0  0x7792fd39 in fips_bn_ctx_start (ctx=0x0) at bn_ctx.c:261
#1  0x77932a55 in fips_bn_mod_exp_mont (rr=0x0, a=0x6a9b30, p=0x6a9b30, 
m=0x6a99c0, ctx=0x0, in_mont=0x0) at bn_exp.c:417
#2  0x779320f0 in fips_bn_mod_exp (r=0x0, a=0x6a9b30, p=0x6a9b30, 
m=0x6a99c0, ctx=0x0) at bn_exp.c:237
Thanks,
[cid:image005.png@01D01EBC.D4993640]



Amritha Thorath
Cryptographic Software Developer


O: 703-267-6050 x 119


E: athor...@corsec.com

Website | Blog | 
Facebook | 
Twitter | 
LinkedIn

Opening Markets Through Security Certifications