Re: DEFCON Talk - Lost and Found Certificates

[Michael Casadevall via dev-security-policy]

On 08/19/2018 12:56 PM, Eric Mill via dev-security-policy wrote:
> On Thu, Aug 16, 2018 at 6:52 PM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> It seems that my response to this presentation has brought out the crowd
>> of people who are constantly looking to reduce the usefulness of
>> certificates to anyone but the largest mega-corporations.
>>
>> To summarize my problem with this:
>>
>>   - While some large IT operations (and a minority of small ones) run
>>    fully automated setups that can trivially handle replacing
>>    certificates many times per year, many other certificate holders treat
>>    certificate replacement as a rare event that involves a lot of manual
>>    labor.  Shortening the maximum duration of certificates down to Let's
>>    encrypt levels will be a massive burden in terms of wasted man-hours
>>    accumulated over millions (billions?) of organizations having to do 4
>>    times a year what they used to do every two or five years.
>>
> 
> The trend is away from manual replacement, not towards it -- and that's
> true for individual people, for large enterprises, and for smaller
> companies in between. For individuals and smaller enterprises, this
> manifests mostly in the increasing outsourcing of certificate management to
> third parties (e.g. SquareSpace, CloudFlare, AWS Certificate Manager,
> etc.).
> 

In my limited experience, this trend is *because* of Let's Encrypt
getting them to do it four times a year. A lot of my freelance work has
been automated certificate rollovers due to cost, and usually some
fiddling every X months when a domain fails to validate and the
certificate fails to issue. For a lot of places, the time spent having
someone automating it offsets the annual cost of having to fork up for a
certificate (or getting management to approve an expense)

It should be also noted that I've seen quite a few organizations decide
the cost of automation is too difficult or the systems using the
certificates are too fragile and rather pay for longer lasting
certificates.

> For larger enterprises, the same outsourcing is also present and is
> mitigating manual rotation burdens, but some are also investing in their
> own systems for automation inside their environments. I've seen several
> spring up in enterprise environments I'm close to in the last few years in
> order to handle the increasing pressure to secure connections by default
> even when the certificate volume is high.
>> Reducing certificate lifetimes to 13 months, in addition to addressing
the> real security issue identified by the Lost and Found Certificates
> presentation, is likely to further these trends, which would be a positive
> development both for user security and enterprise agility.
> 
>   - While infinitely wealthy organizations can afford getting separate
>>    certificates for each DNS name, and while lowest-security (DV)
>>    certificates are now available for zero dollars in the US, SANs remain
>>    significant in case of high security validation (OV, EV) that costs
>>    real money and effort, both to pay the CA and to provide evidence of
>>    human and organizational genuineness, such as showing government IDs,
>>    obtaining certified copies of registration statements, answering
>>    validation phone calls to CEOs at strange hours etc.
>
SANs are also important in DV certificates unless we're talking about
wildcards. Lets Encrypt certificates use the first domain as the CN, and
then all the subdomains as SANs. Given that wildcard certificates can be
undesirable, there are more than a few valid reasons to have SANs, even
in cases where everything is within one domain.

My largest problem with long lived certificates is that expiration is
essentially the only effective mechanism of removing old certificates
from circulation. Revocation at best is iffy, and down right broken
depending on who you ask between Chrome's CRLSets, OCSP Soft Fail, etc.

If we could fix revocation so it could work effectively, longer lived
certificates would be less of a risk factor.
Michael
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy