<div dir="ltr">Hi David,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Alex Gostrer</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 22, 2015 at 6:09 AM, Woodhouse, David via RT <span dir="ltr"><<a href="mailto:rt@openssl.org" target="_blank">rt@openssl.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There are various circumstances in which it makes no sense to be<br>
checking the start and end times of a certificate's validity.<br>
<br>
When validating OS kernel drivers, or indeed when validating the OS<br>
kernel itself when the firmware loads it, we *really* don't want to<br>
have a built-in obsolescence date after which the system will no longer<br>
function. That would be a bad thing even if we *could* reliably trust<br>
the system's real time clock at this stage in the boot sequence.<br>
<br>
This patch gives us a way to disable the time checks entirely, by using<br>
X509_VERIFY_PARAM_set_time() with a time of -1.<br>
<br>
There is a slight risk here — if anyone was genuinely using the value<br>
of -1 to check if a certificate chain was indeed valid in the last<br>
second of 1969. I judge that risk to be negligible. And it certainly<br>
shouldn't be externally triggerable — if an attacker could influence<br>
the value passed to X509_VERIFY_PARAM_set_time() then all bets were off<br>
w.r.t. time-based checks anyway.<br>
<br>
If there are serious concerns, however, I can provide an alternative<br>
patch which adds an X509_V_FLAG_NO_CHECK_TIME flag for this purpose<br>
instead.<br>
<br>
I'm happy with anything except the existing version in the UEFI source<br>
tree that everyone is shipping, which just disables the time check if<br>
OPENSSL_SYS_UEFI is set¹. That one I *don't* like.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
David Woodhouse Open Source Technology Centre<br>
<a href="mailto:David.Woodhouse@intel.com">David.Woodhouse@intel.com</a> Intel Corporation<br>
<br>
¹ <a href="http://git.infradead.org/users/dwmw2/openssl.git/commitdiff/2fb12afc2ceb" rel="noreferrer" target="_blank">http://git.infradead.org/users/dwmw2/openssl.git/commitdiff/2fb12afc2ceb</a><br>
</font></span><br>_______________________________________________<br>
openssl-bugs-mod mailing list<br>
<a href="mailto:openssl-bugs-mod@openssl.org">openssl-bugs-mod@openssl.org</a><br>
<a href="https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod</a><br>_______________________________________________<br>
openssl-dev mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br>
<br></blockquote></div><br></div>