Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
The way this is supposed to work is by using a timestamp from a trusted timestamp server to show the certificate was valid at the time the code was signed. See the following text from the draft code signing baseline requirements from the CA/Browser forum: 8.2.1: ... With the exception of revocation checking for time-stamped and expired Certificates, Platforms are expected to validate Code Signatures in accordance with RFC 5280 when first encountered. Subsequent signature validation MAY ignore revocation, especially if rejecting the Code will cause the device to fail to boot. When a Platform encounters a Certificate that fails to validate due to revocation, the Platform should not permit the Code to execute. When a Platform encounters a Certificate that fails to validate for reasons other than revocation, the Platform should treat the Code as unsigned. Ordinarily, a Code Signature created by a Subscriber is only considered valid until expiration of the Certificate. However, the “Timestamp” method and the “Signing Service” methods permit Code to remain valid for longer periods of time. 1. Timestamp Method: In this method, the Subscriber signs the Code, appends its Code Signing Certificate and submits it to a Timestamp Authority to be time-stamped. The resulting package can be considered valid after expiration of the Code Signing Certificate and expiration of the Timestamp Authority certificate if the timestamp is dated prior to the Certificate’s expiration date and any applicable revocation date. (See Section 13.2.) 2. Signing Service Method: In this method, the Subscriber uses the service to sign compiled code, binary, file, app, or similar object. Alternatively, the service MAY sign a digest of the preceding objects. The resulting Code Signature is valid up to the expiration time of the Signing Service’s Code Signing Certificate and any applicable revocation date, whichever comes first. Signing Services MAY also timestamp signed objects. This is much better than simply ignoring all date validation. -Tim -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Woodhouse, David via RT Sent: Wednesday, July 22, 2015 9:10 AM Cc: openssl-dev@openssl.org Subject: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled There are various circumstances in which it makes no sense to be checking the start and end times of a certificate's validity. When validating OS kernel drivers, or indeed when validating the OS kernel itself when the firmware loads it, we *really* don't want to have a built-in obsolescence date after which the system will no longer function. That would be a bad thing even if we *could* reliably trust the system's real time clock at this stage in the boot sequence. This patch gives us a way to disable the time checks entirely, by using X509_VERIFY_PARAM_set_time() with a time of -1. There is a slight risk here — if anyone was genuinely using the value of -1 to check if a certificate chain was indeed valid in the last second of 1969. I judge that risk to be negligible. And it certainly shouldn't be externally triggerable — if an attacker could influence the value passed to X509_VERIFY_PARAM_set_time() then all bets were off w.r.t. time-based checks anyway. If there are serious concerns, however, I can provide an alternative patch which adds an X509_V_FLAG_NO_CHECK_TIME flag for this purpose instead. I'm happy with anything except the existing version in the UEFI source tree that everyone is shipping, which just disables the time check if OPENSSL_SYS_UEFI is set¹. That one I *don't* like. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ¹ http://scanmail.trustwave.com/?c=4062d=w5av1VNIDJq7CuEBC-sOxIBHFHbcisoH_n4fAJKpMgs=5u=http%3a%2f%2fgit%2einfradead%2eorg%2fusers%2fdwmw2%2fopenssl%2egit%2fcommitdiff%2f2fb12afc2ceb This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
Hi David, I think that both your proposals will add vulnerabilities. With your proposal I anticipate that many careless application developers will disable the date checking forever. As a result, consumers will be blaming openssl, not these developers. Current solution for kernels and other firmware without a reliable RTC is to issue certificates that are valid from 1969 to 2037. We will have a Y2037 problem similar to Y2000 but this is a wide problem, much wider than openssl can solve at the moment. Regards, Alex Gostrer On Wed, Jul 22, 2015 at 6:09 AM, Woodhouse, David via RT r...@openssl.org wrote: There are various circumstances in which it makes no sense to be checking the start and end times of a certificate's validity. When validating OS kernel drivers, or indeed when validating the OS kernel itself when the firmware loads it, we *really* don't want to have a built-in obsolescence date after which the system will no longer function. That would be a bad thing even if we *could* reliably trust the system's real time clock at this stage in the boot sequence. This patch gives us a way to disable the time checks entirely, by using X509_VERIFY_PARAM_set_time() with a time of -1. There is a slight risk here — if anyone was genuinely using the value of -1 to check if a certificate chain was indeed valid in the last second of 1969. I judge that risk to be negligible. And it certainly shouldn't be externally triggerable — if an attacker could influence the value passed to X509_VERIFY_PARAM_set_time() then all bets were off w.r.t. time-based checks anyway. If there are serious concerns, however, I can provide an alternative patch which adds an X509_V_FLAG_NO_CHECK_TIME flag for this purpose instead. I'm happy with anything except the existing version in the UEFI source tree that everyone is shipping, which just disables the time check if OPENSSL_SYS_UEFI is set¹. That one I *don't* like. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ¹ http://git.infradead.org/users/dwmw2/openssl.git/commitdiff/2fb12afc2ceb ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3952] [PATCH] Introduce OPENSSL_SYS_UEFI for rand configuration
For secure boot (and other services), OpenSSL is built as part of the
Tianocore UEFI firmware. It does not use the normal makefiles; it has
its own build system and provides its own #defines and list of files to
be built:
https://github.com/tianocore/edk2/blob/master/CryptoPkg/Library/Openssl
Lib/OpensslLib.inf
I'm open to suggestions on how best to generate opensslconf.h for it,
and keep that OpensslLib.inf up to date. To start with, though, this
simply gets the right version of RAND_poll() for OPENSSL_SYS_UEFI.
(I'm not even going to think about the asm bits yet.)
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
From 5429a6ba5bf0ec1f4cef61bea24b59b2dc06ac79 Mon Sep 17 00:00:00 2001
From: Long, Qin qin.l...@intel.com
Date: Wed, 22 Jul 2015 10:04:18 +0100
Subject: [PATCH] Add UEFI flag for rand build
Add OPENSSL_SYS_UEFI flag for RAND handling;
---
crypto/rand/rand_unix.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/rand/rand_unix.c b/crypto/rand/rand_unix.c
index 72f8617..bb70a5b 100644
--- a/crypto/rand/rand_unix.c
+++ b/crypto/rand/rand_unix.c
@@ -116,7 +116,7 @@
#include openssl/rand.h
#include rand_lcl.h
-#if !(defined(OPENSSL_SYS_WINDOWS) || defined(OPENSSL_SYS_WIN32) || defined(OPENSSL_SYS_VMS) || defined(OPENSSL_SYS_OS2) || defined(OPENSSL_SYS_VXWORKS) || defined(OPENSSL_SYS_NETWARE))
+#if !(defined(OPENSSL_SYS_WINDOWS) || defined(OPENSSL_SYS_WIN32) || defined(OPENSSL_SYS_VMS) || defined(OPENSSL_SYS_OS2) || defined(OPENSSL_SYS_VXWORKS) || defined(OPENSSL_SYS_NETWARE) || defined(OPENSSL_SYS_UEFI))
# include sys/types.h
# include sys/time.h
@@ -419,7 +419,7 @@ int RAND_poll(void)
* defined(OPENSSL_SYS_VXWORKS) ||
* defined(OPENSSL_SYS_NETWARE)) */
-#if defined(OPENSSL_SYS_VXWORKS)
+#if defined(OPENSSL_SYS_VXWORKS) || defined(OPENSSL_SYS_UEFI)
int RAND_poll(void)
{
return 0;
--
2.4.3
smime.p7s
Description: S/MIME cryptographic signature
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC][PATCH] Fixing OPENSSL_NO_STDIO
I'm willing to forward them to you, and if you want to review and rebase, etc., that would make it quicker. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz -Original Message- From: David Woodhouse [mailto:dw...@infradead.org] Sent: Wednesday, July 22, 2015 6:09 PM To: Salz, Rich; openssl-dev@openssl.org Subject: Re: [openssl-dev] [RFC][PATCH] Fixing OPENSSL_NO_STDIO On Wed, 2015-07-22 at 16:02 +, Salz, Rich wrote: To what extent is the OPENSSL_NO_STDIO build expected to actually work? It seems fairly unloved. I have a a complete fix sitting in my queue for a few months now. Is that sitting in a visible git tree somewhere, and/or could you share, please? If I can move them towards fixes which are at least *destined* for upstream, that would be a step in the right direction... Thanks. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Wed, 2015-07-22 at 14:52 +, Tim Hollebeek wrote: The way this is supposed to work is by using a timestamp from a trusted timestamp server to show the certificate was valid at the time the code was signed. That would be great. Unfortunately, if the UEFI firmware were suddenly to start insisting upon that then a lot of operating systems would no longer boot. I don't think it's practical to add this requirement for secure boot at this stage; the UEFI firmware will probably continue to just disable the time check — even if it's a local patch as it is at the moment. But I'm *trying* to eliminate those local patches, to make it easier to keep OpenSSL up to date. It occurs to me that UEFI firmware might be the *largest* deployment of OpenSSL, so it's unfortunate that the patches it needs are out-of-tree :) FWIW the Linux kernel also specifically avoids checking timestamps altogether when validating signed modules. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC][PATCH] Fixing OPENSSL_NO_STDIO
On Wed, 2015-07-22 at 16:02 +, Salz, Rich wrote: To what extent is the OPENSSL_NO_STDIO build expected to actually work? It seems fairly unloved. I have a a complete fix sitting in my queue for a few months now. Is that sitting in a visible git tree somewhere, and/or could you share, please? If I can move them towards fixes which are at least *destined* for upstream, that would be a step in the right direction... Thanks. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC][PATCH] Fixing OPENSSL_NO_STDIO
On Wed, 2015-07-22 at 16:13 +, Salz, Rich wrote: I'm willing to forward them to you, and if you want to review and rebase, etc., that would make it quicker. Please. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC][PATCH] Fixing OPENSSL_NO_STDIO
To what extent is the OPENSSL_NO_STDIO build expected to actually work? It seems fairly unloved. I have a a complete fix sitting in my queue for a few months now. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
Hi David, I think that both your proposals will add vulnerabilities. With your proposal I anticipate that many careless application developers will disable the date checking forever. As a result, consumers will be blaming openssl, not these developers. Current solution for kernels and other firmware without a reliable RTC is to issue certificates that are valid from 1969 to 2037. We will have a Y2037 problem similar to Y2000 but this is a wide problem, much wider than openssl can solve at the moment. Regards, Alex Gostrer On Wed, Jul 22, 2015 at 6:09 AM, Woodhouse, David via RT r...@openssl.org wrote: There are various circumstances in which it makes no sense to be checking the start and end times of a certificate's validity. When validating OS kernel drivers, or indeed when validating the OS kernel itself when the firmware loads it, we *really* don't want to have a built-in obsolescence date after which the system will no longer function. That would be a bad thing even if we *could* reliably trust the system's real time clock at this stage in the boot sequence. This patch gives us a way to disable the time checks entirely, by using X509_VERIFY_PARAM_set_time() with a time of -1. There is a slight risk here — if anyone was genuinely using the value of -1 to check if a certificate chain was indeed valid in the last second of 1969. I judge that risk to be negligible. And it certainly shouldn't be externally triggerable — if an attacker could influence the value passed to X509_VERIFY_PARAM_set_time() then all bets were off w.r.t. time-based checks anyway. If there are serious concerns, however, I can provide an alternative patch which adds an X509_V_FLAG_NO_CHECK_TIME flag for this purpose instead. I'm happy with anything except the existing version in the UEFI source tree that everyone is shipping, which just disables the time check if OPENSSL_SYS_UEFI is set¹. That one I *don't* like. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ¹ http://git.infradead.org/users/dwmw2/openssl.git/commitdiff/2fb12afc2ceb ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Wed, 2015-07-22 at 14:58 +, Victor Wagner via RT wrote: Isn't it better to check if certificate was valid at the time of signing? Is there a benefit to that which would make it worth the additional complexity? Typically compiler somehow puts compilation timestamp into compiled binaries. So, I think, this time should be used as argument to X509_VERIFY_PARAM_set_time instead of wall clock time. For the UEFI build we try to avoid all non-repeatable things like that being included in the binaries. I'm still worrying about how to approach the patch at the end of the list¹ which removes all those instances of __FILE__ and __LINE__... I have a vague recollection of there being a discussion on this list about that, fairly recently, and I need to go back and find it. Or, may be there is something like CMS signing attributes with signing time. Did I not send the patch which fixes the OPENSSL_NO_CMS build yet? :) -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ¹ http://git.infradead.org/users/dwmw2/openssl.git/commitdiff/b599f07d smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [RFC][PATCH] Fixing OPENSSL_NO_STDIO
To what extent is the OPENSSL_NO_STDIO build expected to actually work?
It seems fairly unloved.
The UEFI build (currently on 1.0.2) has a minimal patch¹ which fixes up
OPENSSL_NO_FP for their use case, which obviously it would be nice to
eliminate by merging upstream.
But since OPENSSL_NO_FP_API got subsumed into OPENSSL_NO_STDIO in
commit 4b618848f, the problem has got a lot more interesting. A
preliminary patch is below. There are a number of issues.
- Lots of places still need 'FILE' to be defined.
- Various (mis)uses of BUFSIZ
- GOST engine using printf()
- Don't even look at crypto/cryptlib.c
- Missing DECLARE_PEM_write_fp_const() macro for OPENSSL_NO_STDIO
- SRP_VBASE_init() requires file access
Is this the way it's supposed to be? Surely we can have file access
without a FILE *? Should BIO_new_file() be using a filedescriptor-based
method of opening the file, instead of just being unavailable for the
OPENSSL_NO_STDIO build? There are a number of users of it, which is why
I #defined it to return NULL instead of just failing.
Obviously I *can* just submit patches to fix it minimally so that the
UEFI build works. That doesn't seem like the correct thing to do
though.
diff --git a/Configure b/Configure
index 6cc05bd..6cc0e20 100755
--- a/Configure
+++ b/Configure
@@ -1088,7 +1088,7 @@ if (defined($disabled{md5}) || defined($disabled{sha})
if (defined($disabled{ec}) || defined($disabled{dsa})
-|| defined($disabled{dh}))
+|| defined($disabled{dh}) || defined($disabled{stdio}))
{
$disabled{gost} = forced;
}
diff --git a/apps/passwd.c b/apps/passwd.c
index dbae620..ce5c402 100644
--- a/apps/passwd.c
+++ b/apps/passwd.c
@@ -112,6 +112,10 @@ OPTIONS passwd_options[] = {
{NULL}
};
+#ifndef BUFSIZ
+#define BUFSIZ 256
+#endif
+
int passwd_main(int argc, char **argv)
{
BIO *in = NULL;
diff --git a/crypto/cryptlib.c b/crypto/cryptlib.c
index 6d050ff..dc99d11 100644
--- a/crypto/cryptlib.c
+++ b/crypto/cryptlib.c
@@ -116,7 +116,7 @@
#include internal/cryptlib.h
#include openssl/safestack.h
-
+#include stdio.h
#if defined(OPENSSL_SYS_WIN32)
static double SSLeay_MSVC5_hack = 0.0; /* and for VC1.5 */
#endif
diff --git a/crypto/des/read2pwd.c b/crypto/des/read2pwd.c
index 01e275f..7633139 100644
--- a/crypto/des/read2pwd.c
+++ b/crypto/des/read2pwd.c
@@ -114,6 +114,10 @@
#include openssl/ui.h
#include openssl/crypto.h
+#ifndef BUFSIZ
+#define BUFSIZ 256
+#endif
+
int DES_read_password(DES_cblock *key, const char *prompt, int verify)
{
int ok;
diff --git a/crypto/engine/eng_openssl.c b/crypto/engine/eng_openssl.c
index eaf0618..2e7ed31 100644
--- a/crypto/engine/eng_openssl.c
+++ b/crypto/engine/eng_openssl.c
@@ -89,7 +89,9 @@
* this is no longer automatic in ENGINE_load_builtin_engines().
*/
#define TEST_ENG_OPENSSL_RC4
+#ifndef OPENSSL_NO_STDIO
#define TEST_ENG_OPENSSL_PKEY
+#endif
/* #define TEST_ENG_OPENSSL_HMAC */
/* #define TEST_ENG_OPENSSL_HMAC_INIT */
/* #define TEST_ENG_OPENSSL_RC4_OTHERS */
diff --git a/crypto/lock.c b/crypto/lock.c
index d7d672d..2066b31 100644
--- a/crypto/lock.c
+++ b/crypto/lock.c
@@ -309,9 +309,7 @@ void CRYPTO_destroy_dynlockid(int i)
--pointer-references;
#ifdef REF_CHECK
if (pointer-references 0) {
-fprintf(stderr,
-CRYPTO_destroy_dynlockid, bad reference count\n);
-abort();
+OPENSSL_showfatal(CRYPTO_destroy_dynlockid, bad reference
count\n);
} else
#endif
if (pointer-references = 0) {
diff --git a/crypto/srp/srp_vfy.c b/crypto/srp/srp_vfy.c
index 39c89e8..a877f8d 100644
--- a/crypto/srp/srp_vfy.c
+++ b/crypto/srp/srp_vfy.c
@@ -349,6 +349,7 @@ static BIGNUM *SRP_gN_place_bn(STACK_OF(SRP_gN_cache)
*gN_cache, char *ch)
return NULL;
}
+#ifndef OPENSSL_NO_STDIO
/*
* this function parses verifier file. Format is:
* string(index):base64(N):base64(g):0
@@ -467,6 +468,7 @@ int SRP_VBASE_init(SRP_VBASE *vb, char *verifier_file)
return error_code;
}
+#endif
SRP_user_pwd *SRP_VBASE_get_by_user(SRP_VBASE *vb, char *username)
{
diff --git a/crypto/ui/ui_util.c b/crypto/ui/ui_util.c
index f65f80d..b18e2a2 100644
--- a/crypto/ui/ui_util.c
+++ b/crypto/ui/ui_util.c
@@ -56,6 +56,10 @@
#include string.h
#include ui_locl.h
+#ifndef BUFSIZ
+#define BUFSIZ 256
+#endif
+
int UI_UTIL_read_pw_string(char *buf, int length, const char *prompt,
int verify)
{
diff --git a/crypto/x509/by_dir.c b/crypto/x509/by_dir.c
index cc91db8..d4f 100644
--- a/crypto/x509/by_dir.c
+++ b/crypto/x509/by_dir.c
@@ -69,6 +69,8 @@
# include sys/stat.h
#endif
+#ifndef OPENSSL_NO_STDIO
+
#include openssl/lhash.h
#include openssl/x509.h
@@ -435,3 +437,5 @@ static int get_cert_by_subject(X509_LOOKUP *xl,
X509_LOOKUP_TYPE type,
BUF_MEM_free(b);
return (ok);
}
+
+#endif /* OPENSSL_NO_STDIO */
diff --git a/include/openssl/bio.h b/include/openssl/bio.h
index
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
The way this is supposed to work is by using a timestamp from a trusted timestamp server to show the certificate was valid at the time the code was signed. See the following text from the draft code signing baseline requirements from the CA/Browser forum: 8.2.1: ... With the exception of revocation checking for time-stamped and expired Certificates, Platforms are expected to validate Code Signatures in accordance with RFC 5280 when first encountered. Subsequent signature validation MAY ignore revocation, especially if rejecting the Code will cause the device to fail to boot. When a Platform encounters a Certificate that fails to validate due to revocation, the Platform should not permit the Code to execute. When a Platform encounters a Certificate that fails to validate for reasons other than revocation, the Platform should treat the Code as unsigned. Ordinarily, a Code Signature created by a Subscriber is only considered valid until expiration of the Certificate. However, the “Timestamp” method and the “Signing Service” methods permit Code to remain valid for longer periods of time. 1. Timestamp Method: In this method, the Subscriber signs the Code, appends its Code Signing Certificate and submits it to a Timestamp Authority to be time-stamped. The resulting package can be considered valid after expiration of the Code Signing Certificate and expiration of the Timestamp Authority certificate if the timestamp is dated prior to the Certificate’s expiration date and any applicable revocation date. (See Section 13.2.) 2. Signing Service Method: In this method, the Subscriber uses the service to sign compiled code, binary, file, app, or similar object. Alternatively, the service MAY sign a digest of the preceding objects. The resulting Code Signature is valid up to the expiration time of the Signing Service’s Code Signing Certificate and any applicable revocation date, whichever comes first. Signing Services MAY also timestamp signed objects. This is much better than simply ignoring all date validation. -Tim -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Woodhouse, David via RT Sent: Wednesday, July 22, 2015 9:10 AM Cc: openssl-dev@openssl.org Subject: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled There are various circumstances in which it makes no sense to be checking the start and end times of a certificate's validity. When validating OS kernel drivers, or indeed when validating the OS kernel itself when the firmware loads it, we *really* don't want to have a built-in obsolescence date after which the system will no longer function. That would be a bad thing even if we *could* reliably trust the system's real time clock at this stage in the boot sequence. This patch gives us a way to disable the time checks entirely, by using X509_VERIFY_PARAM_set_time() with a time of -1. There is a slight risk here — if anyone was genuinely using the value of -1 to check if a certificate chain was indeed valid in the last second of 1969. I judge that risk to be negligible. And it certainly shouldn't be externally triggerable — if an attacker could influence the value passed to X509_VERIFY_PARAM_set_time() then all bets were off w.r.t. time-based checks anyway. If there are serious concerns, however, I can provide an alternative patch which adds an X509_V_FLAG_NO_CHECK_TIME flag for this purpose instead. I'm happy with anything except the existing version in the UEFI source tree that everyone is shipping, which just disables the time check if OPENSSL_SYS_UEFI is set¹. That one I *don't* like. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ¹ http://scanmail.trustwave.com/?c=4062d=w5av1VNIDJq7CuEBC-sOxIBHFHbcisoH_n4fAJKpMgs=5u=http%3a%2f%2fgit%2einfradead%2eorg%2fusers%2fdwmw2%2fopenssl%2egit%2fcommitdiff%2f2fb12afc2ceb This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Wed, 2015-07-22 at 14:52 +, Tim Hollebeek wrote: The way this is supposed to work is by using a timestamp from a trusted timestamp server to show the certificate was valid at the time the code was signed. That would be great. Unfortunately, if the UEFI firmware were suddenly to start insisting upon that then a lot of operating systems would no longer boot. I don't think it's practical to add this requirement for secure boot at this stage; the UEFI firmware will probably continue to just disable the time check — even if it's a local patch as it is at the moment. But I'm *trying* to eliminate those local patches, to make it easier to keep OpenSSL up to date. It occurs to me that UEFI firmware might be the *largest* deployment of OpenSSL, so it's unfortunate that the patches it needs are out-of-tree :) FWIW the Linux kernel also specifically avoids checking timestamps altogether when validating signed modules. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Wed, 2015-07-22 at 14:58 +, Victor Wagner via RT wrote: Isn't it better to check if certificate was valid at the time of signing? Is there a benefit to that which would make it worth the additional complexity? Typically compiler somehow puts compilation timestamp into compiled binaries. So, I think, this time should be used as argument to X509_VERIFY_PARAM_set_time instead of wall clock time. For the UEFI build we try to avoid all non-repeatable things like that being included in the binaries. I'm still worrying about how to approach the patch at the end of the list¹ which removes all those instances of __FILE__ and __LINE__... I have a vague recollection of there being a discussion on this list about that, fairly recently, and I need to go back and find it. Or, may be there is something like CMS signing attributes with signing time. Did I not send the patch which fixes the OPENSSL_NO_CMS build yet? :) -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ¹ http://git.infradead.org/users/dwmw2/openssl.git/commitdiff/b599f07d smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Wed, Jul 22, 2015 at 03:36:40PM +, David Woodhouse via RT wrote: FWIW the Linux kernel also specifically avoids checking timestamps altogether when validating signed modules. You probably need a dedicated implementation of X509_verify_cert(). When dealing with data at rest (signed email, signed code, ...) certificate expiration needs to be understood in the context of time of signature, not time of verification. Ideally (this generally works for email), the verifier initially verifies the signed object before the expiration time of the certificate and then caches this fact in some manner, so that subsequent verification can ignore the certificate entirely, and just check the the object has not changed since initially verified. If caching results of initial verification is not an option, then perhaps disabling expiration checks is a last-resort option. There are ways (with care) to do this via the verify callback, which can be made to suppress *only* expiration errors and fail on all other errors. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3950] Standard mem* functions called with length 0 and invalid pointer arguments
fixed in master. not needed for 1.0.2 since that code uses inline coding, not calling the standard routines. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Wed, Jul 22, 2015 at 04:36:27PM +0100, David Woodhouse wrote: On Wed, 2015-07-22 at 14:52 +, Tim Hollebeek wrote: The way this is supposed to work is by using a timestamp from a trusted timestamp server to show the certificate was valid at the time the code was signed. That would be great. Unfortunately, if the UEFI firmware were suddenly to start insisting upon that then a lot of operating systems would no longer boot. Which operating systems would that be? As far as I know Windows 7 required this if you wanted to have your drivers stay valid for longer than 2 years and Windows 10 just always requires it. So I would hope that they actually do this for all of their own software. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Wed, Jul 22, 2015 at 03:36:40PM +, David Woodhouse via RT wrote: FWIW the Linux kernel also specifically avoids checking timestamps altogether when validating signed modules. What do you mean wit timestamps? The trusted timestamp, or the validity period? Any idea why they don't check it? They're not sure about the time or something at the moment it's checked? Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Wed, Jul 22, 2015 at 04:36:27PM +0100, David Woodhouse wrote: On Wed, 2015-07-22 at 14:52 +, Tim Hollebeek wrote: The way this is supposed to work is by using a timestamp from a trusted timestamp server to show the certificate was valid at the time the code was signed. That would be great. Unfortunately, if the UEFI firmware were suddenly to start insisting upon that then a lot of operating systems would no longer boot. Which operating systems would that be? As far as I know Windows 7 required this if you wanted to have your drivers stay valid for longer than 2 years and Windows 10 just always requires it. So I would hope that they actually do this for all of their own software. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3950] Standard mem* functions called with length 0 and invalid pointer arguments
On Wed, Jul 22, 2015 at 10:23:40AM +, Pascal Cuoq via RT wrote: Recently, GCC began to assume for optimization purposes that p and q are non-null pointers when memcpy(p, q, n); is invoked. I have to agree that p and q can't be NULL, even when n is 0. The standard seems to be rather clear about that. Clause 7.1.4 also allows compilers to assume that p and q are not pointers one past the end of an object: http://stackoverflow.com/questions/25390577/is-memcpya-1-b-1-0-defined-in-c11 It seems at least not everybody agrees on that, and it's non obvious to me who is correct. Can I suggest someone takes that question to the standard committee? OpenSSL's bignum implementation contains two invocations of standard functions that fail this property: https://github.com/openssl/openssl/blob/b39fc560612984e65ec30d7f37487303bf514fb3/crypto/bn/bn_add.c#L225 https://github.com/openssl/openssl/blob/b39fc560612984e65ec30d7f37487303bf514fb3/crypto/bn/bn_mont.c#L199 These two lines are actually reached with pointers one past and sizes of 0 during real executions. I'm unsure what the effect of it would be in case it's really undefined behaviour. I think the only thing gcc could assume is that the pointers aren't NULL, which they aren't. But that would be the first undefined behaviour, not the second. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3953] Bug: !RSA does not exclude aRSA
The ciphers documentation page (https://www.openssl.org/docs/apps/ciphers.html) says: kRSA, aRSA, RSA cipher suites using RSA key exchange, authentication or either respectively. That sounds like RSA should be a superset of kRSA and aRSA, but actually aRSA includes cipher suites not in RSA, as can be seen from: (bash)$ diff (openssl ciphers 'RSA' | sed -e 's/:/\n/g') (openssl ciphers 'aRSA'| sed -e 's/:/\n/g') As a consequence, !RSA allows some aRSA ciphers. I don't know whether this is a documentation problem or a software problem. I am using OpenSSL 1.0.1e-fips 11 Feb 2013 on Red Hat Enterprise Linux Workstation release 6.6 (Santiago). Thanks, --Paul ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Compilation error while ignoring no-ssl2 no-ssl3
Hi, To disable SSLv2 and SSLv3 while compilation used no-ssl2 and no-ssl3 option for windows platform. But getting the below link error. Without option no-ssl2 no-ssl3 I can compile successfully. Any pointers to resolve this issue? Thanks in advance. LINK : warning LNK4001: no object files specified; libraries used LINK : warning LNK4068: /MACHINE not specified; defaulting to IX86 LINK : warning LNK4001: no object files specified; libraries used SSLEAY32.def : error LNK2001: unresolved external symbol BIO_f_ssl SSLEAY32.def : error LNK2001: unresolved external symbol BIO_new_buffer_ssl_connec SSLEAY32.def : error LNK2001: unresolved external symbol BIO_new_ssl SSLEAY32.def : error LNK2001: unresolved external symbol BIO_new_ssl_connect SSLEAY32.def : error LNK2001: unresolved external symbol BIO_ssl_copy_session_id SSLEAY32.def : error LNK2001: unresolved external symbol BIO_ssl_shutdown SSLEAY32.def : error LNK2001: unresolved external symbol DTLSv1_client_method SSLEAY32.def : error LNK2001: unresolved external symbol DTLSv1_method SSLEAY32.def : error LNK2001: unresolved external symbol DTLSv1_server_method SSLEAY32.def : error LNK2001: unresolved external symbol ERR_load_SSL_strings SSLEAY32.def : error LNK2001: unresolved external symbol SSL_CIPHER_description SSLEAY32.def : error LNK2001: unresolved external symbol SSL_CIPHER_get_bits SSLEAY32.def : error LNK2001: unresolved external symbol SSL_CIPHER_get_name SSLEAY32.def : error LNK2001: unresolved external symbol SSL_CIPHER_get_version SSLEAY32.def : error LNK2001: unresolved external symbol SSL_COMP_add_compression_ SSLEAY32.def : error LNK2001: unresolved external symbol SSL_COMP_get_compression_ SSLEAY32.def : error LNK2001: unresolved external symbol SSL_COMP_get_name SSLEAY32.def : error LNK2001: unresolved external symbol SSL_CTX_add_client_CA SSLEAY32.def : error LNK2001: unresolved external symbol SSL_CTX_add_session SSLEAY32.def : error LNK2001: unresolved external symbol SSL_CTX_callback_ctrl SSLEAY32.def : error LNK2001: unresolved external symbol SSL_CTX_check_private_key Openssl Version: openssl-0.9.8zc Commands used: VCVARS32.BAT perl Configure VC-WIN32 no-idea shared no-ssl2 no-ssl3 --prefix=e:/openssl ms\do_masm nmake -f ms\ntdll.mak Thanks, Kannan Narayanasamy. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3950] Standard mem* functions called with length 0 and invalid pointer arguments
Recently, GCC began to assume for optimization purposes that p and q are
non-null pointers when
memcpy(p, q, n); is invoked.
This means that the if is eliminated completely when compiling the following
sequence of instructions:
memcpy(p, q, n);
if (!p) printf(good\n);
And this causes a problem for any programmer that would expect “good” to be
printed by the
following program:
#include string.h
void f(void *p, void *q, size_t n) {
memcpy(p, q, n);
if (!p) printf(good\n);
}
int main(void) {
f(0, 0, 0);
}
The clauses in the standard that allow GCC to “optimize” the program in this
way are, in C11, 7.24.1:2 and 7.1.4.
Clause 7.24.1:2 says:
“Where an argument declared as size_t n specifies the length of the array for a
function,
n can have the value zero on a call to that function. Unless explicitly stated
otherwise in the description
of a particular function in this subclause, pointer arguments on such a call
shall still have valid values,
as described in 7.1.4”
Clause 7.1.4 also allows compilers to assume that p and q are not pointers “one
past” the end of an object:
http://stackoverflow.com/questions/25390577/is-memcpya-1-b-1-0-defined-in-c11
Since you can expect GCC developers to take as much responsibility for the
vulnerabilities
introduced in previously working code when they add the optimization of
assuming that p and q
are not pointers “one past” than they did when they added the optimization of
assuming that p
and q are not null (i.e. none at all), it would be prudent never to call any
standard function
with pointers “one past”, even when these are functions that also take a length
and the length
is always 0 in these cases.
OpenSSL's bignum implementation contains two invocations of standard functions
that
fail this property:
https://github.com/openssl/openssl/blob/b39fc560612984e65ec30d7f37487303bf514fb3/crypto/bn/bn_add.c#L225
https://github.com/openssl/openssl/blob/b39fc560612984e65ec30d7f37487303bf514fb3/crypto/bn/bn_mont.c#L199
These two lines are actually reached with pointers “one past” and sizes of 0
during real executions.
The prudent thing to do would be to guard these lines so that the standard
function is not called
with a pointer “one past”, which can be done as simply as:
if (max - r-top) memset(rp[r-top], 0, sizeof(*rp) * (max - r-top));
if (dif) memcpy(rp, ap, sizeof(*rp) * dif);
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3674] Bug report - cannot compile 1.0.2 with no-cms
From: David Bar david@gmail.com
Subject: [PATCH] RT3674: Fix no-cms build failure
This fixes multiple problems with CMS-related code, including the
RFC2631 DH key derivation which depends on CMS, not being correctly
protected by #ifndef OPENSSL_NO_CMS.
---
Updated version of David Bar's patch, against OpenSSL git HEAD. I have
introduced a couple of switch statements for key derivation types, as
David suggested. And also I leave EVP_PKEY_DH_KDF_X9_42 defined in the
header file, but just returning failure when you try to *use* it.
(
This fix is also required for building OpenSSL in the UEFI environment.
We are starting to work on fixing up the patch which currently lives in
https://github.com/tianocore/edk2/tree/master/CryptoPkg/Library/Openssl
Lib
so that we can get the useful parts merged upstream.
To start with, we've just broken it down into individual changes, which
are (not cleaned up for submission yet) at
http://git.infradead.org/users/dwmw2/openssl.git/shortlog/refs/heads/OpenSSL_1_0_2-stable
)
crypto/dh/dh_kdf.c | 3 +++
crypto/dh/dh_pmeth.c | 30 +++---
crypto/ec/ec_ameth.c | 2 ++
crypto/rsa/rsa_ameth.c | 8
include/openssl/dh.h | 2 ++
5 files changed, 38 insertions(+), 7 deletions(-)
diff --git a/crypto/dh/dh_kdf.c b/crypto/dh/dh_kdf.c
index b812d82..3035d0b 100644
--- a/crypto/dh/dh_kdf.c
+++ b/crypto/dh/dh_kdf.c
@@ -51,6 +51,8 @@
*
*/
+#include openssl/opensslconf.h
+#ifndef OPENSSL_NO_CMS
#include string.h
#include openssl/dh.h
#include openssl/evp.h
@@ -184,3 +186,4 @@ int DH_KDF_X9_42(unsigned char *out, size_t outlen,
EVP_MD_CTX_cleanup(mctx);
return rv;
}
+#endif /* !OPENSSL_NO_CMS */
diff --git a/crypto/dh/dh_pmeth.c b/crypto/dh/dh_pmeth.c
index 763e42f..b070246 100644
--- a/crypto/dh/dh_pmeth.c
+++ b/crypto/dh/dh_pmeth.c
@@ -203,12 +203,20 @@ static int pkey_dh_ctrl(EVP_PKEY_CTX *ctx, int type, int
p1, void *p2)
return 1;
case EVP_PKEY_CTRL_DH_KDF_TYPE:
-if (p1 == -2)
+switch (p1) {
+case -2:
return dctx-kdf_type;
-if (p1 != EVP_PKEY_DH_KDF_NONE p1 != EVP_PKEY_DH_KDF_X9_42)
+
+#ifndef OPENSSL_NO_CMS
+case EVP_PKEY_DH_KDF_X9_42:
+#endif
+case EVP_PKEY_DH_KDF_NONE:
+dctx-kdf_type = p1;
+return 1;
+
+default:
return -2;
-dctx-kdf_type = p1;
-return 1;
+ }
case EVP_PKEY_CTRL_DH_KDF_MD:
dctx-kdf_md = p2;
@@ -437,7 +445,9 @@ static int pkey_dh_derive(EVP_PKEY_CTX *ctx, unsigned char
*key,
}
dh = ctx-pkey-pkey.dh;
dhpub = ctx-peerkey-pkey.dh-pub_key;
-if (dctx-kdf_type == EVP_PKEY_DH_KDF_NONE) {
+
+switch (dctx-kdf_type) {
+case EVP_PKEY_DH_KDF_NONE:
if (key == NULL) {
*keylen = DH_size(dh);
return 1;
@@ -447,7 +457,9 @@ static int pkey_dh_derive(EVP_PKEY_CTX *ctx, unsigned char
*key,
return ret;
*keylen = ret;
return 1;
-} else if (dctx-kdf_type == EVP_PKEY_DH_KDF_X9_42) {
+
+#ifndef OPENSSL_NO_CMS
+case EVP_PKEY_DH_KDF_X9_42: {
unsigned char *Z = NULL;
size_t Zlen = 0;
if (!dctx-kdf_outlen || !dctx-kdf_oid)
@@ -475,7 +487,11 @@ static int pkey_dh_derive(EVP_PKEY_CTX *ctx, unsigned char
*key,
OPENSSL_clear_free(Z, Zlen);
return ret;
}
-return 1;
+#endif /* !OPENSSL_NO_CMS */
+
+default:
+return 0;
+}
}
const EVP_PKEY_METHOD dh_pkey_meth = {
diff --git a/crypto/ec/ec_ameth.c b/crypto/ec/ec_ameth.c
index edb68d1..e2f3287 100644
--- a/crypto/ec/ec_ameth.c
+++ b/crypto/ec/ec_ameth.c
@@ -67,8 +67,10 @@
#include openssl/asn1t.h
#include internal/asn1_int.h
+#ifndef OPENSSL_NO_CMS
static int ecdh_cms_decrypt(CMS_RecipientInfo *ri);
static int ecdh_cms_encrypt(CMS_RecipientInfo *ri);
+#endif
static int eckey_param2type(int *pptype, void **ppval, EC_KEY *ec_key)
{
diff --git a/crypto/rsa/rsa_ameth.c b/crypto/rsa/rsa_ameth.c
index d409631..254b553 100644
--- a/crypto/rsa/rsa_ameth.c
+++ b/crypto/rsa/rsa_ameth.c
@@ -68,10 +68,12 @@
#endif
#include internal/asn1_int.h
+#ifndef OPENSSL_NO_CMS
static int rsa_cms_sign(CMS_SignerInfo *si);
static int rsa_cms_verify(CMS_SignerInfo *si);
static int rsa_cms_decrypt(CMS_RecipientInfo *ri);
static int rsa_cms_encrypt(CMS_RecipientInfo *ri);
+#endif
static int rsa_pub_encode(X509_PUBKEY *pk, const EVP_PKEY *pkey)
{
@@ -653,6 +655,7 @@ static int rsa_pss_to_ctx(EVP_MD_CTX *ctx, EVP_PKEY_CTX
*pkctx,
return rv;
}
+#ifndef OPENSSL_NO_CMS
static int rsa_cms_verify(CMS_SignerInfo *si)
{
int nid, nid2;
@@ -671,6 +674,7 @@ static int rsa_cms_verify(CMS_SignerInfo *si)
}
return 0;
}
+#endif
/*
* Customised RSA item verification routine. This is called when a signature
@@ -693,6 +697,7 @@ static int rsa_item_verify(EVP_MD_CTX *ctx, const
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
Maybe it is the time to introduce the 64-bit UNIX time? Anything else looks like a patch. Regards, Alex. On Wed, Jul 22, 2015 at 2:34 PM, David Woodhouse dw...@infradead.org wrote: On Wed, 2015-07-22 at 23:29 +0200, Kurt Roeckx wrote: On Wed, Jul 22, 2015 at 09:56:24PM +0100, David Woodhouse wrote: The more I look at this 'signed timestamp' scheme, the more pointless it seems in this situation. We basically don't *care* about the wall -clock time, *and* we don't really know it. If we're going to trust anyone to say was the time at which the signature was generated, then we might as well forget the whole nonsense about an expiry time and just trust that same third party to provide a signature... or not. The whole point of this signed timestamp is that the signature doesn't expire and that you don't have to care about the wall clock. ... which is much more simply achieved by just not caring about the validity times of the certificate in the first place. -- dwmw2 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Wed, 2015-07-22 at 22:42 +0200, Kurt Roeckx wrote: On Wed, Jul 22, 2015 at 03:36:40PM +, David Woodhouse via RT wrote: FWIW the Linux kernel also specifically avoids checking timestamps altogether when validating signed modules. What do you mean wit timestamps? The trusted timestamp, or the validity period? Any idea why they don't check it? They're not sure about the time or something at the moment it's checked? It's running on a computer. Of course they're not sure about the time. If after a CMOS battery failure you cannot boot the system in order to log into it and correct the time, because the firmware refuses to load the OS kernel or because the OS kernel refuses to load its disk driver, then there is something very wrong with the design. And if your system is designed to suddenly stop booting in 2037 for no better reason than the fact that *some* systems had bugs which made it seem simpler to set that as the expiry date for a cert even though we didn't really want it to expire *ever*, that's kind of broken too. The more I look at this 'signed timestamp' scheme, the more pointless it seems in this situation. We basically don't *care* about the wall -clock time, *and* we don't really know it. If we're going to trust anyone to say THIS was the time at which the signature was generated, then we might as well forget the whole nonsense about an expiry time and just trust that same third party to provide a signature... or not. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Wed, 2015-07-22 at 22:40 +0200, Kurt Roeckx wrote: On Wed, Jul 22, 2015 at 04:36:27PM +0100, David Woodhouse wrote: On Wed, 2015-07-22 at 14:52 +, Tim Hollebeek wrote: The way this is supposed to work is by using a timestamp from a trusted timestamp server to show the certificate was valid at the time the code was signed. That would be great. Unfortunately, if the UEFI firmware were suddenly to start insisting upon that then a lot of operating systems would no longer boot. Which operating systems would that be? As far as I know Windows 7 required this if you wanted to have your drivers stay valid for longer than 2 years and Windows 10 just always requires it. So I would hope that they actually do this for all of their own software. Perhaps they do, although the UEFI bootloader they use is a somewhat different beast. But there are plenty of other OS bootloeders which are signed for so-called secure boot, other than Microsoft's. And I would be utterly shocked if they all have trusted timestamps, given that the UEFI firmware in all current machines does not require such. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Wed, 2015-07-22 at 22:40 +0200, Kurt Roeckx wrote: On Wed, Jul 22, 2015 at 04:36:27PM +0100, David Woodhouse wrote: On Wed, 2015-07-22 at 14:52 +, Tim Hollebeek wrote: The way this is supposed to work is by using a timestamp from a trusted timestamp server to show the certificate was valid at the time the code was signed. That would be great. Unfortunately, if the UEFI firmware were suddenly to start insisting upon that then a lot of operating systems would no longer boot. Which operating systems would that be? As far as I know Windows 7 required this if you wanted to have your drivers stay valid for longer than 2 years and Windows 10 just always requires it. So I would hope that they actually do this for all of their own software. Perhaps they do, although the UEFI bootloader they use is a somewhat different beast. But there are plenty of other OS bootloeders which are signed for so-called secure boot, other than Microsoft's. And I would be utterly shocked if they all have trusted timestamps, given that the UEFI firmware in all current machines does not require such. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Wed, 2015-07-22 at 23:29 +0200, Kurt Roeckx wrote: On Wed, Jul 22, 2015 at 09:56:24PM +0100, David Woodhouse wrote: The more I look at this 'signed timestamp' scheme, the more pointless it seems in this situation. We basically don't *care* about the wall -clock time, *and* we don't really know it. If we're going to trust anyone to say was the time at which the signature was generated, then we might as well forget the whole nonsense about an expiry time and just trust that same third party to provide a signature... or not. The whole point of this signed timestamp is that the signature doesn't expire and that you don't have to care about the wall clock. ... which is much more simply achieved by just not caring about the validity times of the certificate in the first place. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Thu, 2015-07-23 at 00:29 +0200, Kurt Roeckx wrote: On Wed, Jul 22, 2015 at 10:34:53PM +0100, David Woodhouse wrote: On Wed, 2015-07-22 at 23:29 +0200, Kurt Roeckx wrote: On Wed, Jul 22, 2015 at 09:56:24PM +0100, David Woodhouse wrote: The whole point of this signed timestamp is that the signature doesn't expire and that you don't have to care about the wall clock. ... which is much more simply achieved by just not caring about the validity times of the certificate in the first place. In case of a timestamp you can reduce the check to verify that the timestamp was in the validity period of the certificate. Yes. You can. But it's still pointless complexity in a use case where *every* valid signature would need a corresponding timestamp to ensure its validity. I can kind of understand why we might want the timestamp scheme in circumstances where *some* signatures should be infinitely valid, and others not. But in the case where *all* signatures should be infinitely valid, it just seems entirely gratuitous. And retrofitting it into a model where the validity is *already* not being checked is a inviting a whole bunch of breakage for precisely zero benefit. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3953] Bug: !RSA does not exclude aRSA
On Wed, Jul 22, 2015 at 07:38:48PM +, Lynch, Paul[E] via RT wrote: The ciphers documentation page (https://www.openssl.org/docs/apps/ciphers.html) says: kRSA, aRSA, RSA cipher suites using RSA key exchange, authentication or either respectively. That sounds like RSA should be a superset of kRSA and aRSA, but actually aRSA includes cipher suites not in RSA, as can be seen from: I think the problem is that RSA does and instead of or, and ends up being the same as kRSA. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Wed, 2015-07-22 at 15:02 -0700, Alexander Gostrer wrote: Maybe it is the time to introduce the 64-bit UNIX time? Anything else looks like a patch. Theoretically, we can already encode notAfter values as a GeneralizedTime of up to 1231235959Z (i.e. Y10K) in an X.509 certificate. The limitation is purely an implementation issue — not only is it a fairly safe bet that a lot of software will crap itself on seeing a GeneralizedTime at all (since for dates before we MUST use UTCTime instead), but a lot of 32-bit implementations are known to break even for UTCTime values later than 2038. So certificates which do this are just not going to interoperate very well at all. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3953] Bug: !RSA does not exclude aRSA
On Wed, Jul 22, 2015 at 08:49:05PM +, Kurt Roeckx via RT wrote: On Wed, Jul 22, 2015 at 07:38:48PM +, Lynch, Paul[E] via RT wrote: The ciphers documentation page (https://www.openssl.org/docs/apps/ciphers.html) says: kRSA, aRSA, RSA cipher suites using RSA key exchange, authentication or either respectively. That sounds like RSA should be a superset of kRSA and aRSA, but actually aRSA includes cipher suites not in RSA, as can be seen from: I think the problem is that RSA does and instead of or, and ends up being the same as kRSA. Yes, one way or another the RSA cipherstring is just kRSA. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Wed, Jul 22, 2015 at 09:56:24PM +0100, David Woodhouse wrote: The more I look at this 'signed timestamp' scheme, the more pointless it seems in this situation. We basically don't *care* about the wall -clock time, *and* we don't really know it. If we're going to trust anyone to say THIS was the time at which the signature was generated, then we might as well forget the whole nonsense about an expiry time and just trust that same third party to provide a signature... or not. The whole point of this signed timestamp is that the signature doesn't expire and that you don't have to care about the wall clock. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Wed, Jul 22, 2015 at 10:34:53PM +0100, David Woodhouse wrote: On Wed, 2015-07-22 at 23:29 +0200, Kurt Roeckx wrote: On Wed, Jul 22, 2015 at 09:56:24PM +0100, David Woodhouse wrote: The whole point of this signed timestamp is that the signature doesn't expire and that you don't have to care about the wall clock. ... which is much more simply achieved by just not caring about the validity times of the certificate in the first place. In case of a timestamp you can reduce the check to verify that the timestamp was in the validity period of the certificate. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Wed, 22 Jul 2015 13:09:48 + Woodhouse, David via RT r...@openssl.org wrote: There are various circumstances in which it makes no sense to be checking the start and end times of a certificate's validity. When validating OS kernel drivers, or indeed when validating the OS kernel itself when the firmware loads it, we *really* don't want to have a built-in obsolescence date after which the system will no longer function. That would be a bad thing even if we *could* reliably trust the system's real time clock at this stage in the boot sequence. Isn't it better to check if certificate was valid at the time of signing? Typically compiler somehow puts compilation timestamp into compiled binaries. So, I think, this time should be used as argument to X509_VERIFY_PARAM_set_time instead of wall clock time. Or, may be there is something like CMS signing attributes with signing time. s ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
