[Ach] bettercrypto.org cert blocked in chrome 56

[sivmu]

Am 30.11.2016 um 01:11 schrieb Alice Wonder:
> On 11/29/2016 12:41 PM, sivmu wrote:
>>
>>
>> Am 29.11.2016 um 11:46 schrieb Alice Wonder:
>>
>>>> ...
>>>> 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.
>>
>> HPKP and its equivalent for smtp is not the same as DANE.
>>
>> DANE requires a lage set of dependencies, a gigantic infrastructure and
>> a still largely central administration of root keys.
>> HPKP on the other hand is simple and small.
> 
> DANE doesn't require a gigantic infrastructure. Your domain has a KSK
> (key signing key) that YOU have access to, and that key is where the DS
> record comes from that gets signed by an upstream (typically the Top
> Level Domain but it doesn't have to be)
> 
> Your DNS is then only vulnerable if a hacker either gets your private
> signing key, or creates a new signing key for your domain and tricks the
> TLD (or alternate signing root if you are using one) to sign the DS
> record for their signing key.
> 
> Creating a new signing key for your domain and getting it signed by the
> upstream is a very visible action and can be mitigated by using a second
> infrastructure in addition to ICANN such as the hypothetical EFF
> infrastructure I mentioned. That would require the fraudulent DS record
> be signed by two hierarchies.
> 
Lets play this out: "Hi, I'm Mr. Smith from (put three letter agency
here) and I demand that the provided certificated for man in the middle
operations are to be installed by you Mr. provider guy, by you Mr. DNS
root key administrator and by you EFF people. If anyone objects you will
be sentenced to many years of prison due to endangering national security"

We already know this card is being played even for minor cases and there
is no reason to believe it's not a valid scenario.

And DANE will do absolutely nothing to protect against it nor will any
other security mechanism that relies on central authorities.

>>
>> The difference in attack surface of these two technoogies is like
>> comparing the complexity of a nail to that of a plane.
> 
> Your analogy fails.
> 
> HPKP and TLSA do the exact same thing. They provide a mechanism by which
> the client the validate the fingerprint of the certificate.
> 
> HPKP does so in a very insecure way that can leave your site bricked for
> many users for a long period of time and makes it difficult to respond
> to situations where you must change both your primary and backup keys in
> a short period of time (such as firing a system admin who had access to
> both).
> 
> TLSA doesn't have those design flaws and is Validate On Every Use
> opposed to Blind Trust On First Use.
> 
> Blind Trust On First Use doesn't work well with server to server
> communication because now all your scripts that fetch resources from
> other resources have to create their own cache of keypins they trusted
> or else they are just Blind Trust On Every Use.
> 
> With Validate On Every Use your server to server communication scripts
> can validate on every use and the blind trust issue doesn't exist.
> 
> HPKP is just conceptually broken, it was not very well thought out.

Terje Elde has got it right. The issues HPKP has is there whether you
use it or not.

However there is an easy way to avoid it and this should probably in the
guide as well: when pinning your certificates you can include one whose
coresponding key is not on the machine but acts as the backup key, maybe
even offline.

Do not misunderstand me here. I like DANE just as well as HPKP but both
technologies serve somewhat different purposes. The work and fail at
different levels and using both will increase security significantly
while covering each other attack vectors.

I think that both DANE as well as HPKP should be advertised while
documenting thier shortcomings and workarounds.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20161130/23f49151/attachment.sig>