[Ach] bettercrypto.org cert blocked in chrome 56

[Alice Wonder]

On 11/29/2016 02:16 AM, sivmu wrote:
>
>
> Am 29.11.2016 um 00:37 schrieb Alice Wonder:
>> On 11/28/2016 03:04 PM, sivmu wrote:
>>>
>>>
>>> Am 28.11.2016 um 23:23 schrieb Alice Wonder:
>>>> On 11/28/2016 02:12 PM, Raoul Bhatia wrote:
>>>>> I've successfully transitioned existing StartSSL certificates + HPKP /
>>>>> HSTS to letsencrypt.sh (via the Debian package).
>>>>>
>>>>> I know I am not the first to do such a thing, but maybe you'd like to
>>>>> have some quick pointers to get this resolved ASAP.
>>>>>
>>>>> Raoul
>>>>>
>>>>> PS. The most important thing is to initially tell letsencrypt.sh to
>>>>> reuse an existing private key for requesting new certs.
>>>>
>>>> And that is exactly why I never use HPKP - it does not give the system
>>>> administrator any flexibility when a new cert / key is needed.
>>>>
>>>> In theory there should be a backup key already with a pin to take care
>>>> of cases where the private key is compromised, but as soon as you have
>>>> to use it you are vulnerable to bricking the site for some users if that
>>>> key needs to be revoked.
>>>>
>>>> It also gives no flexibility whatsoever when you have to fire a system
>>>> administrator who may have had access to private keys. Normally in that
>>>> situation you generate new keys, but with HPKP you are stuck keeping the
>>>> old keys active until the new keys have had their pins in the header
>>>> longer than the TTL.
>>>>
>>>
>>> This issue can be solved by using sort life spans for certificates/keys
>>> like lets encrypt does. At least it reduces the drawbacks
>>
>> No it doesn't solve the problem, the certificate lifespan has nothing to
>> do with the private key.
>>
>>>
>>>
>>>> Why people like HPKP so much is a real mystery to me.
>>>>
>>>
>>> Because HPKP recreates some level of trust in a (almost) compleately
>>> broken and highly flawed system?
>>
>> It's a broken solution that only somewhat works for one very specific
>> application of x509 certificates.
>>
>> A better solution (DANE) exists, is not limited to HTTPS, and doesn't
>> prevent you from deploying freshly generated private keys in an emergency.
>>
>
> DANE has its onw drawbacks, and also provides only an alternative cert
> autority system (the DNS root) which has the same or at least simular
> problems the the existing one. It provides additional security yes, but
> it is not nearlz as resistant to elaborated attacks then HPKP.
> Expeciallz government level adversaries only need very little effort to
> break the common ssl cert system and the DNS cert system, while they
> won't be able to break HPKP because it lacks the central autorieties.

With DNSSEC you don't have to rely upon the ICANN root. You can have 
your DS records signed by alternate, and for the few TLDs that don't yet 
support DNSSEC an alternate root is the only way.

At some point I will be encouraging the EFF to provide such a service, 
so that people who use DNSSEC can submit their DS records both to their 
TLD and to EFF so that DNSSEC clients can check both.

That way to compromise a TLSA record, the attacker would have to access 
to both the signing key from the TLD and from the EFF.

The EFF could use the existing let's encrypt infrastructure to validate 
a domain owner before signing DS records submitted to them.

>
> A simular solution will be available for smtp soon as well.

It already exists with DANE and is in use on several large e-mail 
services (e.g. Comcast here in the United States) - though I think other 
than custom code, Postfix is the only MTA that supports it.