Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Viktor Dukhovni]

> On Jul 24, 2018, at 7:40 AM, Graham Leggett  wrote:
> 
> Or is it correct in v1.1.0 and above to just not initialise anything at all, 
> not clean anything up at all, and expect openssl to “do the right thing” when 
> mod_ssl is unloaded?

Yes.  And *especially* when the code that depends on OpenSSL is itself a 
library.
OpenSSL is now (and should ideally always have been) self-initializing.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openssl asn1parse -length

[Christian Böhme]

On 24.07.2018 11:41, Jakob Bohm wrote:

> Best option is to download the documents that specify the DER
> (or BER) ASN.1 Encoding, which is the X.690 (2015) ITU-T
> "recommendation" which was a freely downloadable PDF last time
> I checked.

[…]

> For example, the one you show below is thus:
> 0x30 (TAG for SEQUENCE)
> Some length value large enough to hold what follows, see X.690
>   0x06 (TAG for OBJECT id)
>   Any definite encoding of length = 9 bytes(127 possibilities)
>   0x2A (The bytes of pkcs7-envelopedData=1.2.840.113549.1.7.3)
>   0x86 .840
>   0x48
>   0x86 .113549
>   0xF7
>   0x0D
>   0x01 .1
>   0x07 .7
>   0x03 .3
> Rest not needed for identification of a pkcs7-envelopedData file.
> 
> Note that same length values can be encoded in more than one way
> if the file is in BER format, as is often the case with PKCS#7
> files.

Thanks heaps for your input.  Much appreciated!


Cheers,
Christian

-- 
*Christian Böhme*

Developer System Integration

CLOUD

*CLOUD & HEAT Technologies GmbH*
Königsbrücker Str. 96 (Halle 15) | 01099 Dresden
Tel: +49 351 479 3670 - 100
Fax: +49 351 479 3670 - 110
E-Mail: christian.boe...@cloudandheat.com 

Web: https://www.cloudandheat.com 

Handelsregister: Amtsgericht Dresden
Registernummer: HRB 30549
USt.-Ident.-Nr.: DE281093504
Geschäftsführer: Nicolas Röhrs




signature.asc
Description: OpenPGP digital signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Graham Leggett]

On 24 Jul 2018, at 12:15, Graham Leggett  wrote:

> Over at httpd we’re struggling with crashes and instability caused by 
> attempts by various independent libraries we link to, all of which in turn 
> link to openssl, initialising openssl multiple times. In turn these separate 
> libraries might de-initialise openssl on shutdown expecting a re-initiailise 
> to work and hilarity ensues.
> 
> What is the correct way to handle openssl initialisation when multiple 
> independent libraries are all trying to initialise openssl independently of 
> one another?
> 
> Is there reference counting of some kind?
> 
> Could instability be caused by not matching the correct teardown function 
> calls with the correct setup function calls?

Focusing a little closer on openssl v1.1.0 we get the following, but this also 
seems broken at first glance.

https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_init_crypto.html

"Once OPENSSL_cleanup() has been called the library cannot be reinitialised”.

In our case, httpd will load mod_ssl (and in APR apr_crypto_openssl) which is 
in turn linked to openssl, and during a restart the module (and therefore the 
link to openssl I believe) will be unloaded, and thus OPENSSL_cleanup() will 
fail when httpd finally exits and calls atexit.

Am I interpreting the above correctly?

Or is it correct in v1.1.0 and above to just not initialise anything at all, 
not clean anything up at all, and expect openssl to “do the right thing” when 
mod_ssl is unloaded?

Regards,
Graham
—

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Using a TPM to sign CSRs

[Kaarthik Sivakumar]

  
  
Hello
I need to create a key pair using a TPM (proprietary) and build a
  CSR and sign it using it the TPM as well. Currently I dont have an
  engine interface to talk to the TPM. I do the following:
1. generate key pair in the TPM. private key is kept private in
  the TPM and public key can be obtained out of the TPM
2. use the public key to generate a CSR (X509_REQ_init(), etc)

3. Get the hash of the CSR (X509_REQ_digest())
4. Pass the digest to the TPM and get back signature
5. Add signature to the CSR - I dont see any way to do this. Is
  there an openssl API to perform this step? I dont think I can use
  X509_REQ_sign() since that will use the private key provided or if
  I have an engine interface then it will call the engine to do the
  signing. Is there a way to call sign() and make it call my
  function that can do the step 4 above?
Thanks!


  -kaarthik-
  

  

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Graham Leggett]

Hi all,

Over at httpd we’re struggling with crashes and instability caused by attempts 
by various independent libraries we link to, all of which in turn link to 
openssl, initialising openssl multiple times. In turn these separate libraries 
might de-initialise openssl on shutdown expecting a re-initiailise to work and 
hilarity ensues.

What is the correct way to handle openssl initialisation when multiple 
independent libraries are all trying to initialise openssl independently of one 
another?

Is there reference counting of some kind?

Could instability be caused by not matching the correct teardown function calls 
with the correct setup function calls?

Regards,
Graham
—

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openssl asn1parse -length

[Jakob Bohm]

On 23/07/2018 16:56, Christian Böhme wrote:

Hello all,

I have been trying to find a way to ascertain that the contents of a file
is a DER-encoded ASN.1 structure such as

$ openssl version
OpenSSL 1.0.2g  1 Mar 2016

$ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -i
 0:d=0  hl=4 l= 978 cons: SEQUENCE
 4:d=1  hl=2 l=   9 prim:  OBJECT:pkcs7-envelopedData
15:d=1  hl=4 l= 963 cons:  cont [ 0 ]
19:d=2  hl=4 l= 959 cons:   SEQUENCE
23:d=3  hl=2 l=   1 prim:INTEGER   :03
26:d=3  hl=3 l= 133 cons:SET
29:d=4  hl=3 l= 130 cons: cont [ 3 ]
32:d=5  hl=2 l=   1 prim:  INTEGER   :00
35:d=5  hl=2 l=  27 cons:  cont [ 0 ]
37:d=6  hl=2 l=   9 prim:   OBJECT:PBKDF2
48:d=6  hl=2 l=  14 cons:   SEQUENCE
50:d=7  hl=2 l=   8 prim:OCTET STRING  [HEX 
DUMP]:64C8DCE92BE6CF80
60:d=7  hl=2 l=   2 prim:INTEGER   :0800
64:d=5  hl=2 l=  46 cons:  SEQUENCE
66:d=6  hl=2 l=  11 prim:   OBJECT:id-alg-PWRI-KEK
79:d=6  hl=2 l=  31 cons:   SEQUENCE
81:d=7  hl=2 l=  11 prim:OBJECT:camellia-256-cbc
94:d=7  hl=2 l=  16 prim:OCTET STRING  [HEX 
DUMP]:DC131C842F099909DF465439C1B06038
   112:d=5  hl=2 l=  48 prim:  OCTET STRING  [HEX 
DUMP]:7BEFFB307D05C8242A040B371EEA3C6F59F082C415057BF5A71F67437B92668CEED9C46B0F57B4E4A077B1651892D9D5
   162:d=3  hl=4 l= 816 cons:SEQUENCE
   166:d=4  hl=2 l=   9 prim: OBJECT:pkcs7-data
   177:d=4  hl=2 l=  31 cons: SEQUENCE
   179:d=5  hl=2 l=  11 prim:  OBJECT:camellia-256-cbc
   192:d=5  hl=2 l=  16 prim:  OCTET STRING  [HEX 
DUMP]:995169EEF15C876E5F1A92DAF6A129D7
   210:d=4  hl=4 l= 768 prim: cont [ 0 ]

Since the files to test are rather large, I'd be content with being able
to have only the first couple of bytes inspected.  It would appear that the
-length  option allows to do just that.  However, whatever argument specified,
I get this:

$ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 4
Error in encoding
140548547200664:error:0D07207B:asn1 encoding routines:ASN1_get_object:header 
too long:asn1_lib.c:157:
$ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 16
Error in encoding
140076397213336:error:0D07209B:asn1 encoding routines:ASN1_get_object:too 
long:asn1_lib.c:147:
$ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 32
Error in encoding
139879438956184:error:0D07209B:asn1 encoding routines:ASN1_get_object:too 
long:asn1_lib.c:147:
$ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 64
Error in encoding
139887577974424:error:0D07209B:asn1 encoding routines:ASN1_get_object:too 
long:asn1_lib.c:147:
$ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 128
Error in encoding
140008118994584:error:0D07209B:asn1 encoding routines:ASN1_get_object:too 
long:asn1_lib.c:147:
$ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 256
Error in encoding
140518349809304:error:0D07209B:asn1 encoding routines:ASN1_get_object:too 
long:asn1_lib.c:147:
$ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 512
Error in encoding
140042967262872:error:0D07209B:asn1 encoding routines:ASN1_get_object:too 
long:asn1_lib.c:147:

etcpp.  The files to test are expected to be at least 512 bytes in size.

What's the expected behaviour of the  -length  option, BTW?


Best option is to download the documents that specify the DER
(or BER) ASN.1 Encoding, which is the X.690 (2015) ITU-T
"recommendation" which was a freely downloadable PDF last time
I checked.

Note: For clarity, DER is basically the BER but using the
simplest byte sequence for everything.  BER can usually be
converted to DER without knowing the data format specification
(such as RFC2315 for EnvelopedData).

From there, you can see that a DER (and BER) file is based on
the following structure, nested and/or repeated as necessary:

  TAG    An encoding of a data type number such as SEQUENCE
   or "OBJECT" (Actually an OID).
  Length Byte length of contents (Variable length length
   encoding, see X.690)
  Actual contents bytes according to TAG and specific data
   type such as pkcs7 or X.509 etc.  Binary encoding
   of each type is in X.690
  Repeat terminator if Length was the (BER only) indefinite
       code used when a program starts output before
   knowing the final length (See X.690)

For example, the one you show below is thus:
0x30 (TAG for SEQUENCE)
Some length value large enough to hold what follows, see X.690
  0x06 (TAG for OBJECT id)
  Any definite encoding of length = 9 bytes(127 possibilities)
  0x2A (The bytes of pkcs7-envelopedData=1.2.840.113549.1.7.3)
  0x86 .840
  0x48
  0x86 .113549
  0xF7
  0x0D
  0x01 .1
  0x07 .7
  0x03 .3
Rest not needed for identification of a pkcs7-envelopedData file.