On 04/12/2018 05:38, Nick Lamb wrote:
> On Tue, 4 Dec 2018 01:39:05 +0100
> Jakob Bohm via dev-security-policy
> <[email protected]> wrote:
>
>> A few clarifications below
>> Interesting. What is that hole?
>
> I had assumed that you weren't aware that you could just use these
> systems as designed. Your follow-up clarifies that you believe doing
> this is unsafe. I will endeavour to explain why you're mistaken.
>
Which systems?
> But also I specifically endorse _learning by doing_. Experiment for
> yourself with how easy it is to achieve auto-renewal with something like
> ACME, try to request renewals against a site that's configured for
> "stateless renewal" but with a new ("bad guy") key instead of your real
> ACME account keys.
>
I prefer not to experiment with live certificates. Anyway, this was
never intended to focus on the specifics of ACME, since OC issuance
isn't ACME anyway.
So returning to the typical, as-specified-in-the-BRs validation
challenges. Those generally either do not include the CSR in the
challenge, or do so in a manner that would involve active checking
rather than just trivial concatenation. These are the kind of
challenges that require the site owner to consider IF they are in a
certificate request process before responding.
>
>> It certainly needs the ability to change private keys (as reusing
>> private keys for new certificates is bad practice and shouldn't be
>> automated).
>
> In which good practice document can I read that private keys should be
> replaced earlier than their ordinary lifetime if new certificates are
> minted during that lifetime? Does this document explain how its authors
> imagine the new certificate introduces a novel risk?
>
> [ This seems like breakthrough work to me, it implies a previously
> unimagined weakness in, at least, RSA ]
>
Aligning key and certificate lifetime is generally good practice.
See for example NIST SP 1800-16B Prelim Draft 1, Section 5.1.4 which has
this to say:
"... It is possible to renew a certificate with the same public and
private keys (i.e., not rekeying during the renewal process).
However, this is only recommended when the private key is contained
with a hardware security module (HSM) validated to Federal Information
Processing Standards (FIPS) Publication 140-2 Level 2 or above"
And the operations I discuss are unlikely to purchase an expensive HSM
that isn't even future proof. (I have checked leading brands of end site
HSMs, and they barely go beyond current recommended key strengths).
> You must understand that bad guys can, if they wish, construct an
> unlimited number of new certificates corresponding to an existing key,
> silently. Does this too introduce an unacceptable risk ? If not, why is
> the risk introduced if a trusted third party mints one or more further
> certificates ?
>
> No, I think the problem here is with your imaginary "bad practice".
> You have muddled the lifetime of the certificate (which relates to the
> decay in assurance of subject information validated and to other
> considerations) with the lifetime of the keys, see below.
>
>> By definition, the strength of public keys, especially TLS RSA
>> signing keys used with PFS suites, involves a security tradeoff
>> between the time that attackers have to break/factor the public key
>> and the slowness of handling TLS connections with current generation
>> standard hardware and software.
>
> This is true.
>
>> The current WebPKI/BR tradeoff/compromise is set at 2048 bit keys
>> valid for about 24 months.
>
> Nope. The limit of 825 days (not "about 24 months") is for leaf
> certificate lifetime, not for keys. It's shorter than it once was not
> out of concern about bad guys breaking 2048-bit RSA but because of
> concern about algorithmic agility and the lifetime of subject
> information validation, mostly the former.
825 Days = 24 months plus ~94 days slop, in practice CAs map this two
payment for 2 years validity and some allowance for overlap during
changeover.
>
> Subscribers are _very_ strongly urged to choose shorter, not longer
> lifetimes, again not because we're worried about 2048-bit RSA (you will
> notice there's no exemption for 4096-bit keys) but because of agility
> and validation.
>
> But choosing new keys every time you get a new certificate is
> purely a mechanical convenience of scheduling, not a technical necessity
> - like a fellow who schedules an appointment at the barber each time he
> receives a telephone bill, the one thing has nothing to do with the
> other.
>
See above NIST quote.
>
>> It requires write access to the private keys, even if the operators
>> might not need to see those keys, many real world systems don't allow
>> granting "install new private key" permission without "see new
>> private key" permission and "choose arbitrary private key" permission.
>>
>> Also, many real world systems don't allow installing a new
>> certificate for an existing key without reinstalling the matching
>> private key, simply because that's the interface.
>>
>> Traditional military encryption systems are built without these
>> limitations, but civilian systems are often not.
>
> Nevertheless.
>
> I'm sure there's a system out there somewhere which requires you to
> provide certificates on a 3.5" floppy disk. But that doesn't mean
> issuing certificates can reasonably be said to require a 3.5" floppy
> disk, it's just those particular systems.
I am referring to the very real facts that:
- Many "config GUI only" systems request certificate import as PKCS#12
files or similar.
- Many open source TLS servers require supplying the private key as an
unencrypted PKCS#8 PEM key file, either appended to the PEM file with
the certificate chain or as a matching file with same file name.
Either of those require private key access to change the certificate
(for the parallel key file case, only if following the recommendation
to rekey on each renewal).
>
>> This is why good CAs send out reminder e-mails in advance. And why
>> one should avoid CAs that use that contact point for infinite spam
>> about new services.
>
> They do say that insanity consists of doing the same thing over and
> over and expecting different results.
>
The risk of forgetting to do the renewal (a self-inflicted risk that
occurs only at the time when this should have been in your calendar) is
substantially different than the risk of someone from the outside
suddenly demanding doing the procedure as a rush job at a completely
different time.
>> The scenario is "Bad guy requests new cert, CA properly challenges
>> good guy at good guy address, good guy responds positively without
>> reference to old good guy CSR, CA issues for bad guy CSR, bad guy
>> grabs new cert from anywhere and matches to bad guy private key,
>> bad guy does actual attack".
>
> You wrote this in response to me explaining exactly why this scenario
> won't work in ACME (or any system which wasn't designed by idiots -
> though having read their patent filings the commercial CAs on the whole
> may be taken as idiots to my understanding)
>
> I did make one error though, in using the word "signature" when this
> data is not a cryptographic signature, but rather a "JWK Thumbprint".
>
> When "good guy responds positively" that positive response includes
> a Thumbprint corresponding to their ACME public key. When they're
> requesting issuance this works fine because they use their ACME keys
> for their requests. But when a bad guy requests issuance it won't work
> because the bad guy does not know that ACME private account key. They
> can choose their own of course, but that won't match the Thumbprint on
> the "positive response" and so the request fails.
>
I also explained, that ACME wasn't the target, and any mitigations specific
to ACME are of little relevance.
>> This would only work if the existing CA challenge can be re-used or
>> there is no CA chosen challenge in the protocol. I have yet to look
>> at http-01 as it doesn't fit my own usage scenarios.
>
> Computers are programmable :D
And programs can have security bugs, which is a key part of the risk
discussed.
>
> Specifically in this case you:
>
> 1. Calculate your Thumbprint (off-line if appropriate) and make a note
> of it.
>
> 2. Write a "program" (actually one configuration line for popular web
> servers) to respond to all ACME challenges by playing back the random
> challenge text with the Thumbprint appended as described in the ACME
> protocol.
>
Again, this is only for your chosen ACME example, while I was referring
to traditional challenges closely matching what the BRs say should be
done.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://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
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
