[messaging] The Trouble with Certificate Transparency

[Emre Yuce]

> Date: Thu, 25 Sep 2014 12:32:11 +0100
> From: Ben Laurie <ben at links.org>
> To: Tao Effect <contact at taoeffect.com>
> Cc: messaging <messaging at moderncrypto.org>
> Subject: Re: [messaging] The Trouble with Certificate Transparency
> Message-ID:
> 	<CAG5KPzzeWGZtqwPemB+HBG=7PPdpiT-T_Yz+DfpCBYsAD2+c9A at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 24 September 2014 22:15, Tao Effect <contact at taoeffect.com> wrote:
>> On Sep 24, 2014, at 12:55 PM, elijah <elijah at riseup.net> wrote:
>>
>> On 09/24/2014 11:08 AM, Tao Effect wrote:
>>
>> I've finally taken the time to explain via diagrams and many words how
>> undetected MITM attacks can happen with Certificate Transparency.
>>
>>
>> It strikes me that you are not allowing for any distinction between a
>> MiTM attack that happens once, and a MiTM attack that is only successful
>> if it can be carried off from the moment a computer first contacts the
>> internet (and carried on forever if the attacker doesn't want to be
>> detected). What scenario do you have in mind where the latter is
>> possible?
>>
>>
>> Well, I'm primarily focusing on MITM attacks that happen more than once,
>> and
>> are undetected, but not in the sense that you've presented it (MITM
>> attack
>> 24/7 from beginning of time).
>>
>> A 24/7 MITM attack from birth to death simply goes undetected in all
>> systems, and it's probably impossible to do anything about that.
>>
>> However, the issue with CT is as I pointed out several months ago back
>> in
>> May, that detection depends on successful gossip.
>>
>> Sure, it's possible, if the gossip succeeds, that proof of failure (not
>> misbehavior) has occurred. The problem here is:
>>
>> 1. Gossip could be blocked.
>
> Blocking our proposed mechanism == blocking all TLS. So, it could be,
> but it would be kind obvious...

@Ben: 2 questions:
- What happens if a client is allowed to talk to a just one specific log
server? I mean in the case that it tries other log servers and the
connection is blocked.

- Is it defined somewhere what happens when there is a contradiction in
the logs?

@Greg: Is a similar case valid for DNSchain when DNS queries are
blocked/manipulated or just a few pre-defined DNS servers are allowed to
be used?

Best wishes,
Emre

>
>> 2. If Gossip isn't blocked, and you're able to prove failure... so what?
>> What then? The RFC is rather silent on this.
>>
>> The blockchain, on the other hand, doesn't have problem #2.
>>
>> Even if MITM suddenly starts blocking all new blocks and only showing
>> blocks
>> it creates, the node has a giant store of accurate data that the MITM
>> cannot
>> modify. Not so with CT.
>
> Why not? If clients want to download the whole log, they can.
>
>> Also, if browsers contain auditors, why can't these auditors be
>> pre-seeded with the hash of different logs at the time the browser was
>> compiled?
>>
>>
>> Sorry, what is this referring to? The post acknowledges that browsers
>> have
>> public keys of logs.
>
> If the browser has some known hash for a log, then it can detect a
> forked log (because there cannot be a consistency proof for the fork's
> hash).
>
>>
>> Kind regards,
>> Greg
>>
>> --
>> Please do not email me anything that you are not comfortable also
>> sharing
>> with the NSA.
>>
>>
>>
>> -elijah
>>
>> _______________________________________________
>> Messaging mailing list
>> Messaging at moderncrypto.org
>> https://moderncrypto.org/mailman/listinfo/messaging
>>
>>
>>
>> _______________________________________________
>> Messaging mailing list
>> Messaging at moderncrypto.org
>> https://moderncrypto.org/mailman/listinfo/messaging
>>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
>
> ------------------------------
>
> End of Messaging Digest, Vol 143, Issue 1
> *****************************************
>