On 02/23/16 20:28, krishna e bera wrote:
> On 02/22/2016 04:03 PM, Guido Witmond wrote:
>
>> If either the blogger or responder wishes to send a private message,
>> they can use the others' persons public key after validating there is no
>> MitM. Message transport goes through the site. After a few round trips
>> of messages, there is certainty there is no MitM.
>
> The website http://eccentric-authentication.org/ says:
>> With the use of DNSSEC and a validation service to check that each
>> certificate is issued only once we can prevent Man-in-the-Middle
>> attacks
>
> Could you explain how you validate that there is no MitM, and why a few
> round trips would make this certain? Do we not have to trust the
> validation service not to issue more than one certificate? I.e., the
> website or validation service can be the MitM.
>
Hi krishna e bera,
Good question.
Regrettable, I don't have an answer. I can solve the MitM problem in
certain cases but not in general.
Thank you for challenging me with the question. Below is the writeup to
the partial solution and the description of the general problem with
MitMing. And I have a new challenge.
First there is a difference between the issuer of client certificates
and the validation service. These are different entities. And these must
be run by different groups to prevent collusion between them.
The site runs its own CA. It signs both the server and client certificates.
Users choose their nickname @ sitename.tld as CN and supply a fresh
public key to be signed by the site's CA. This nickname is the user's
human readable identity. The CA must sign each CN only once. That is,
there may not be two certificates bearing the same CN. If there is one
occurrence of a duplicate, the site loses its trustworthiness and the
user agents should report that to the user and not connect there any more.
The sites existence depends on it not to get caught signing duplicate
CNs. The rest of this post is about detecting a duplicate.
Users are encouraged to post their certificate containing the CN and the
public key to the verification service after acquiring the certificate.
The verification service registers each certificate, that is: {CN,
public key} tuple that it gets offered. If it detects two or more of the
same CN with different public keys, it raises an alarm.
When users post public messages to sites, they sign it using their
private key. The signature gets posted along the message (hidden using CSS).
A user who posts a message should verify that it gets posted correctly
by the site, ie, with the user's signature, not a duplicate or a whole
new identity.
When readers are browsing around a site, the user agent verifies some of
the certificates at random at the verification service. The user agent
sends the certificate to the validation service and receives all
certificates on file bearing the CN. There should always be one. If
there are multiple, it's proof of misconduct.
But suppose a site does create a duplicate certificate of user A and
shows it to user B. Assume that certificate 'a' and 'b' have been
submitted to the verification service.
User A posts a message at the site. A -> m,Sa(m) -> site
The site creates a duplicate certificate c, with a public key that
matches a site controlled private key but it bears the users' A CN.
So B expects: m, Sa(m), but instead gets: site -> m, Sc(m)
If B would check the verification service it would learn of the two
certificates bearing the same CN. Busted.
But B doesn't check the verification service and wants to send a private
message to A and hands it of at the site for delivery.
B -> Ec(m, Sb(m)), Sb( Ec(m, Sb(m)) ) -> site
That is: sign(encrypt(sign(message)))
The site decrypts the message and re-encrypts using A's public key a. It
could encrypt the inner signed message, but it can't recreate the outer
signature, as the site lacks the private key of b.
If the site would create a duplicate for b, that would be detected by A
who does check at the verification service.
So the site/CA cannot create duplicate certificates bearing the same CN
as these will be detected quickly. That was the amount of badness I
imagined at first.
The site has to create a new identity D with a fresh CN to be able to
sign(encrypt(sign(message))) for A.
Site -> Ea(m, Sd(m), Sd( Ea(m, Sd(m)) ) -> A
A believes he got a message from D while B believes he's talking to A
because he didn't check it.
The site could have forgone the dangerous step of creating a duplicate
certificate for A and create a fresh identity in the first place. That
won't trigger duplicate detection. Then A believes he's talking to D and
B believes he's talking to C.
And that is one weakness for which I haven't gotten a solution yet: a
hostile site scraping content from other sites - or even it's own - and
luring others to initiate private messages that are relayed to the
original writer by the hostile site, completely MitM'ed.
They can only detect this attack by mismatches in the content. For
example, B mentions to A "I saw your message at site Y" while A has
published it at site X.
So my challenge is: how to detect or prevent this attack.
Regards, Guido Witmond.
Attachment:
signature.asc
Description: OpenPGP digital signature
-- tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk