Re: [openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG

[Jakob Bohm]

On 11/09/2015 23:26, Michael Heide wrote:

Am Fri, 11 Sep 2015 15:07:20 +0200 schrieb Jakob Bohm :


2.3.1 RFC2985 form Timestamp countersignature Attribute

This one.

I thought so, many people think this one is proprietary,
not realizing it was in the original PKCS#9 document.

I have not encountered this before, which signing authority,
AlgorithmIdentifier and year (first digits of timestamp) did
you see this with?

Various intermediate certs. Verisign, Symantec, etc.
But now I see, did't got it before: the root is always "Thawte Timestamping CA" 
-- using md5WithRSAEncryption.

In other words, the Verisign/Symantec conglomerate,
which for many years used that timestamping facility
across all its brands, including German brands
"geotrust"and "tc trustcenter".

However, I don't think they stopped using MD5 for all
but the old top level CA a long time ago by now.


Example:
https://www.virustotal.com/en/file/1d1bb76575e780123814259eb2dbbf26f1c9035d8f0d4bab682703823b06323f/analysis/

I'll have to have a look at that.



Have you considered the possibility that this may be an
ISO/IEC 9796-1 or -2 signature (an old format broken in
1999 for 9796-1 and for 9796-2/MD5 and in 2009 for
9796-2/SHA-1)?

ISO/IEC 9796-1 / -2 seems to be completely different signing schemes. That's not the case 
here. It's only the encryptedDigest which differs, everything else is quite like the 
other timestamps you describe in "2.3.1".

ISO/IEC 9796-1/-1 specifies a different way of doing
the encryptedDigest calculation, not a different
surrounding OSI/ITU structure around it.


Btw: Windows verifies those with success, valid signatures. But you are right, maybe 
those are "fakes" (the intermediate ones) or broken in another way.

Not so fast.  From what you describe, these use an
old/wrong way of doing the EncryptedDigest calculation,
and it is highly likely that Microsoft have had to make
a (hopefully limited) exception for those historic timestamps.



Due to the likely weakness of this scheme, [...]

I'm a layman here, but I don't think the differences in the scheme itself 
provides the weakness, not in this case. There's only one difference: The 
signature algorithm is not confirmed by the encryptedDigest. But it is via 
other places and it is sha1 for the timestamp itself (20 bytes in length).

I'm no expert either, but from what I read, the weakness
was precisely in the way the 128/160 bit hash was turned
into a 1024+ bit number to be "encrypted" with the RSA
private key.

The PKCS#1 v2.x format (still not supported by Microsoft)
was designed to provide the best possible way of doing
this safely, while the older PKCS#1 v1.x format was less
carefully designed, though it still seems to be holding up.

The ISO/IEC 9796-1 and -2 formats were badly designed, and
simply using a zero-padded hash value would be even worse.

The dangers in all cases are about what happens if someone
bad carefully constructs signing request (which wouldn't
match any actual outer signature and would thus not be in
a valid signature timestamp signature), they could use the
answers to calculate the keys of the timestamping authority,
a bit similar (though not exactly) to how someone calculated
the private key used by Sony to sign approved PS3 software
disks.

This is why I am asking which specific authorities and
periods made the mistake of calculating the input to the
"encryption" wrong, and when they stopped doing so.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG

[Jakob Bohm]

On 11/09/2015 23:26, Michael Heide wrote:

Various intermediate certs. Verisign, Symantec, etc.
But now I see, did't got it before: the root is always "Thawte Timestamping CA" 
-- using md5WithRSAEncryption.

Example:
https://www.virustotal.com/en/file/1d1bb76575e780123814259eb2dbbf26f1c9035d8f0d4bab682703823b06323f/analysis/

Where can I see the actual file (Not the virustotal
description of the signature), I would need to look
at the actual details to make sense of this.

By the way, whomever signed this seems to be mixing
competing CAs (GlobalSign for the cert, Symantec for
the timestamp).

And this file is very new (July 2015), are you sure
it uses the nonstandard EncryptedDigest calculation?

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG

[Michael Heide]

Am Mon, 14 Sep 2015 16:39:15 +0200 schrieb Jakob Bohm :

> Where can I see the actual file (Not the virustotal
> description of the signature), I would need to look
> at the actual details to make sense of this.

I think you have to use some kind of a subscription and use their APIs to 
access their database. 

I've searched the web and found:
http://admdownload.adobe.com/bin/live/flashplayer18ax_ha_install.exe
(md5: 0c6b5474223a4b5bf90a46844ed865db)

Seems to be a file with the same criteria here. 

> By the way, whomever signed this seems to be mixing
> competing CAs (GlobalSign for the cert, Symantec for
> the timestamp).

Why not? ;-)

> And this file is very new (July 2015), are you sure
> it uses the nonstandard EncryptedDigest calculation?

No, I'm not. Maybe I'm doing something wrong. I don't know. 

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

Re: [openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG

[Jakob Bohm]

On 14/09/2015 17:40, Michael Heide wrote:

By the way, whomever signed this seems to be mixing
competing CAs (GlobalSign for the cert, Symantec for
the timestamp).

Why not? ;-)

Because using the timestamp server is generally a paid
service included in the certificate purchase.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


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

Re: [openssl-users] Behaviour facing a broken OCSP responder

[Salz, Rich]

 
> Are these the only three error codes ?

Nope.  It's not standardized at all sadly
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to enable FIPS mode by default of the OpenSSL FIPS modules

[Steve Marquess]

On 09/14/2015 05:21 PM, security veteran wrote:
> I asked this question from a different thread, but thought it may be the
> best to start a new thread to discuss this question since it sounds like
> a big deal to me.
> 
> I've built an openssl library with the FIPS objects modules, and I was
> testing the new lib files by replacing the original library files such
> as libcrypto.so with the new ones.
> 
> From the FIPS user guide I understand that any applications which need
> to use the OpenSSL FIPS modules will need to run the API FIPS_mode_set
> to enable the FIPS mode.
> 
> This sounds like a big issue to me: there are may other libraries/ services 
> which depends on OpenSSL. For example, Python, Apache, PostgreSQL, etc.
> 
> If the /FIPS_mode_set /API needs to be invoked in order to enable the
> FIPS mode, how can we make third party library/ services like Python and
> Apache to invoke this API?
> 
> Is there any other way to make the FIPS mode always enabled?

Well ... yes and no. It depends.

The OpenSSL FIPS module User Guide
(https://openssl.org/docs/fips/UserGuide-2.0.pdf) discusses use of the
OPENSSL_Config() call and the global openssl.conf configuration file. In
theory you could toggle FIPS mode for all the applications on a system
with in one swell foop.

In practice it's not that easy, because when you enable FIPS mode you
also automatically disable use of all "non-allowed" cryptography. Many
applications not specifically written to accommodate the restrictions of
FIPS module may not behave gracefully. Some (OpenSSH for instance)
require extensive hacks for FIPS mode.

Apache httpd does have native FIPS support, but you'll need to invoke
the right buildtime and runtime options; the typical httpd binary
install won't have FIPS support.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@opensslfoundation.com
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Question about Openssl FIPS module and Python-openssl

[Salz, Rich]

>Is there anyway to make the FIPS mode always enabled by default in the library 
>layer, so that there's no need to invoke the FIPS_mode_set API?

No.  You'd have to end up calling some explicit routine of your own which 
called FIPS_mode_set.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] How to enable FIPS mode by default of the OpenSSL FIPS modules

[security veteran]

I asked this question from a different thread, but thought it may be the
best to start a new thread to discuss this question since it sounds like a
big deal to me.

I've built an openssl library with the FIPS objects modules, and I was
testing the new lib files by replacing the original library files such
as libcrypto.so with the new ones.

>From the FIPS user guide I understand that any applications which need
to use the OpenSSL FIPS modules will need to run the API FIPS_mode_set
to enable the FIPS mode.

This sounds like a big issue to me: there are may other libraries/
services which depends on OpenSSL. For example, Python, Apache,
PostgreSQL, etc.

If the *FIPS_mode_set *API needs to be invoked in order to enable the
FIPS mode, how can we make third party library/ services like Python
and Apache to invoke this API?

Is there any other way to make the FIPS mode always enabled?

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

[openssl-users] Question about Openssl FIPS module and Python-openssl

[security veteran]

Thanks John.

In that case it may be more complicated to invoke the *FIPS_mode_set
*API from the Python layer. Is there anyway to make the FIPS mode
always enabled by default in the library layer, so that there's no
need to invoke the FIPS_mode_set API?

Thanks.



Your first question should be presented to the Python developers that
provide support for OpenSSL.  They would be the user of the OpenSSL
API.  I'm not a Python expert, but somewhere they would have a native
layer that leverages the OpenSSL API.  This native layer code would need
to invoke FIPS_mode_set().  The question is whether our not they expose
a knob to the Python user layer to enable/disable FIPS.  Maybe someone
on this mailer happens to know the answer.  If not, reach out to the
Python developer community.

Regarding your second question, FIPS_mode_set() needs to be invoked once
within each process space.  Therefore, if your Python code was all
running in a single process space, then you'd only need to invoke it
once.  But if you're spawning multiple processes, then you'll need to
invoke it whenever a new process was created.


On 09/14/2015 03:51 PM, security veteran wrote:
>* Hi,
*>>* I've built an openssl library with the FIPS objects modules, and I was
*>* testing the new lib files by replacing the original library files such
*>* as libcrypto.so with the new ones.
*>>* From the FIPS user guide I understand that any applications which need
*>* to use the OpenSSL FIPS modules will need to run the API FIPS_mode_set
*>* to enable the FIPS mode.
*>>* My question is, for the applications/ libraries like Python-openssl
*>* which depends on the openssl libraries, how do I make the
*>* Python-openssl module to run the FIPS_mode_set API, in order to
*>* initialize/enable FIPS mode?
*>>* Also, does the FIPS_mode_set API only need to be run once by one of
*>* the applications/ libraries which use OpenSSL?
*>>* Thanks for your helps!
*>>>* ___
*>* openssl-users mailing list
*>* To unsubscribe:
https://mta.openssl.org/mailman/listinfo/openssl-users
*
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Behaviour facing a broken OCSP responder

[jonetsu]

> From: "Salz, Rich"  
> Date: 09/14/15 16:07 

> Are you talking about the command-line?


Yes.


> It would be great if someone sent in a patch that standardized
> and documented exit codes, like 0 for got a "good"
> response, "1" for got a "bad" response, and 10 for got an
> unparseable response


Are these the only three error codes ?



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

[openssl-users] Behaviour facing a broken OCSP responder

[jonetsu]

Hello,


The documentation does not seem too clear about what the behaviour exactly is 
when OpenSSL deals with a broken OCSP responder.  For instance, one that would 
send an OK without any contents.  We call openssl from an application and would 
like to know what is returned in such a case, or in the case of any broken 
responder.


Thanks.



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

[openssl-users] Question about Openssl FIPS module and Python-openssl

[security veteran]

Hi,

I've built an openssl library with the FIPS objects modules, and I was
testing the new lib files by replacing the original library files such as
libcrypto.so with the new ones.

>From the FIPS user guide I understand that any applications which need to
use the OpenSSL FIPS modules will need to run the API FIPS_mode_set to
enable the FIPS mode.

My question is, for the applications/ libraries like Python-openssl which
depends on the openssl libraries, how do I make the Python-openssl module
to run the FIPS_mode_set API, in order to initialize/enable FIPS mode?

Also, does the FIPS_mode_set API only need to be run once by one of the
applications/ libraries which use OpenSSL?

Thanks for your helps!
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Behaviour facing a broken OCSP responder

[Salz, Rich]

> The documentation does not seem too clear about what the behaviour
> exactly is when OpenSSL deals with a broken OCSP responder.  For instance,
> one that would send an OK without any contents.  We call openssl from an
> application and would like to know what is returned in such a case, or in the
> case of any broken responder.

Broken can mean so many things.  You included an example.

Are you talking about the command-line?  It would be great if someone sent in a 
patch that standardized and documented exit codes, like 0 for got a "good" 
response, "1" for got a "bad" response, and 10 for got an unparseable response"
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG

[Jakob Bohm]

On 14/09/2015 17:40, Michael Heide wrote:

Am Mon, 14 Sep 2015 16:39:15 +0200 schrieb Jakob Bohm :


Where can I see the actual file (Not the virustotal
description of the signature), I would need to look
at the actual details to make sense of this.

I think you have to use some kind of a subscription and use their APIs to 
access their database.

I've searched the web and found:
http://admdownload.adobe.com/bin/live/flashplayer18ax_ha_install.exe
(md5: 0c6b5474223a4b5bf90a46844ed865db)

Seems to be a file with the same criteria here.

That one is a big surprise to me.

It seems that as late as in August 17 2015 (4 weeks ago),
Symantec/Verisign issued a timestamp signature, whose
"EncryptedDigest"was made on the following non-standard
input:

00|01|FF...|00|00 87 34 69 20 D5 4C 68 F4 B1 30 6DEA 3E 40 CC B7 71 AC 1D

The first parts (00|01|FF...|00) form the PKCS#1 padding
for a PCS#1 v1.x signature.

But the last part is a 20 byte string that doesn't seem to
match anything permitted by PKCS#1 v1.5 (or v2.1).  I also
note that the SignerInfo specifies "version 1" (aka PKCS#7
v1.5), so I don't think this could be the elusive PKCS#7
v1.4 signature format.

It might hypothetically be an SHA1 SUM, but the initial 00
byte looks strange.

I am struggling a bit with trying to figure out what bytes
are covered by the hash value, so far I have failed to
manually extract a relevant subset of of the message, but I
may have made some basic mistake since I usually don't do
this by hand.


Well, the good news is that at least the PKCS#1 padding is
still there, which makes it a lot less vulnerable than what
your e-mails made me think.


...

And this file is very new (July 2015), are you sure
it uses the nonstandard EncryptedDigest calculation?

No, I'm not. Maybe I'm doing something wrong. I don't know.

It seems not, now I really wonder what is going on.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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