Delivery-Date: Sun, 04 Jan 2015 03:25:35 -0500
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,SPOOF_COM2OTH,
	T_DKIM_INVALID,URIBL_BLOCKED autolearn=no version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 6D2121E0A1F
	for <archiver@seul.org>; Sun,  4 Jan 2015 03:25:34 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 3316732D3F;
	Sun,  4 Jan 2015 08:25:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 4186E32CC7
 for <tor-talk@lists.torproject.org>; Sun,  4 Jan 2015 08:25:28 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id eAYHYXKRn7Js for <tor-talk@lists.torproject.org>;
 Sun,  4 Jan 2015 08:25:28 +0000 (UTC)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com
 [IPv6:2a00:1450:400c:c03::22b])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id EA0F332CA8
 for <tor-talk@lists.torproject.org>; Sun,  4 Jan 2015 08:25:27 +0000 (UTC)
Received: by mail-we0-f171.google.com with SMTP id u56so6346941wes.16
 for <tor-talk@lists.torproject.org>; Sun, 04 Jan 2015 00:25:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=user-agent:in-reply-to:references:mime-version
 :content-transfer-encoding:content-type:subject:from:date:to
 :message-id; bh=DUPd1dD8vEAmL3mktfL/lajiHSRv8Zv3CG8W/VTBvjI=;
 b=h8ZhN/MAUrKEvZHAQn6NHtz07LyJq7UkoIbwxPJcO2GWs/MdCZcA+I0WbeCaQdWchw
 iSW0maZicn5OGBAk4aU44rZabYOW+Ig6G/4xzc3Q2AbljoBVEjAkF6R8QYMyBmsaHAqw
 twnlVGriq4/mO4IFW6HILFdrhRnfGHWjxMltsXzRajFGNDPW55Jb6R+ry2ZRcPsFgDcY
 BktWsBLA2hhj1A1EQDjh1ZUU2EnyPZwBIggr3FpnMJSEKeEvmQZ91/pweqvfDdGYPrOD
 GVtmzBuv2QXfvinetSBmrlP35Pk/d75ujaL80ZnbuPgn2UHAXEvOHLIcrkl1DXOQxARR
 2OpQ==
X-Received: by 10.180.103.40 with SMTP id ft8mr13599391wib.68.1420359925114;
 Sun, 04 Jan 2015 00:25:25 -0800 (PST)
Received: from [10.232.53.250] (27-228.197-178.cust.bluewin.ch.
 [178.197.228.27])
 by mx.google.com with ESMTPSA id x16sm5211583wia.15.2015.01.04.00.25.23
 for <tor-talk@lists.torproject.org>
 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Sun, 04 Jan 2015 00:25:24 -0800 (PST)
User-Agent: K-9 Mail for Android
In-Reply-To: <54A8C4A6.3090804@jbcrawford.us>
References: <54A4A69B.4020803@riseup.net>
 <20150101132852.73822cef@localhost.localdomain> <54A4C6BF.3040207@riseup.net>
 <20150101143551.00c64c7e@localhost.localdomain>
 <218CCDA8-6BB7-4C1C-B806-A1CEAB42A1C0@riseup.net>
 <20150101170451.33e950e6@localhost.localdomain> <54A59E83.1080300@riseup.net>
 <20150102104622.3e5fb008@localhost.localdomain>
 <0BE4AC7A-4DA6-4F56-8B88-9C2B93E9FC7A@riseup.net>
 <CADop2NEx22J2qGspApv588uC8o32OmS8zzV5yyek_UxtMxZGiw@mail.gmail.com>
 <CAJaLD9+M8EErJ11LRGQYrYLOf+9+8dQL6RawC+3UY-ojLd=sWQ@mail.gmail.com>
 <54A607EB.1020505@riseup.net>
 <CADop2NE5tY_97XdYY=UWfd_xvbByPqd95LW4Z8G4Q+m44n-YZQ@mail.gmail.com>
 <54A72481.5020108@torservers.net> <54A72877.6090900@veloc1ty.de>
 <54A72FFA.7090305@sky-ip.org> <54A74EBD.5070407@jbcrawford.us>
 <20150103132326.04b88929@puckey.org> <54A8C4A6.3090804@jbcrawford.us>
MIME-Version: 1.0
From: Christoph Volonte <christoph.volonte@gmail.com>
Date: Sun, 04 Jan 2015 09:26:09 +0100
To: tor-talk@lists.torproject.org
Message-ID: <EE10664E-C5D4-42B4-AF0D-A61F099D2B38@gmail.com>
Subject: Re: [tor-talk] Giving Hidden Services some love
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Well is Tor then for the typicall user. That commes no in to my mind. Maybe im wrong...

Am 4. Januar 2015 05:42:14 MEZ, schrieb "Jesse B. Crawford" <jesse@jbcrawford.us>:
>On 2015-01-03 05:23, Matthew Puckey wrote:
>> <snip>
>>
>> Not sure I would use DNS as an example of reliable authentication. As
>> above though, do you think current or future users would be checking
>> who issed the certificate? I don't think the typical user would. In
>> that scenerio, I would hope the difficulty in creating a too similar
>> hidden service address would create enough difference for users to
>> notice; though I might well be wrong here. But I see your point. :)
>
>What I mean is that the situations where DNS is compromised (malicious
>DNS server, malicious local network operator, malicious third party
>pulling a trick on the local network, etc...), while completely
>possible
>and important to protect against, are far less common out there in the
>wild than phishers using similar-but-wrong domains (we've probably all
>seen a usbank.com.abunchofhexcharacters.numbers.cz before).
>
>I realized that I missed something earlier. When I refer to SSL
>certificates fixing this problem, I am referring to extended validation
>(EV) certificates that validate legal entity, not to the various
>cheaper
>certificates that only validate domain.
>
>EV certificates tie a service to a real-world entity, typically by the
>CA validating organizational documents (articles of incorporation,
>charter, etc) and validating that the person who submitted the request
>is an authorized agent of the organization. The certificates then
>include as part of the principal not only the domain name of the host
>but also the legal name of the operator.
>
>What this means to users is that they get a green box in their address
>bar with the legal entity name of the hidden service operator, which
>gives them easy-peasy confidence that they are communicating with the
>right party, as verified by a trusted third party.
>
>Now, two HUGE caveats:
>
>1) Facebook does not actually have an EV cert for their hidden service!
>they have an OV cert with O=Facebook, Inc. but for various (largely
>political but still largely valid) reasons Firefox does not trust the O
>field and considers OV certificates no better than DV [1]. So why does
>Facebook use SSL..? I don't know, perhaps they think that providing the
>O field is significant (I'd say that it isn't because browsers don't
>tell the user about it), or perhaps it's just for consistency with
>their
>open web presence.
>
>2) Don't think that I'm an advocate of the present CA infrastructure,
>it's a terrible approach to the problem. But it is the approach that we
>have right now. :)
>
>Overall, what should be done? Layering SSL on top of the hidden service
>system is not a good solution to the problem, but I'm also not
>comfortable with just saying "users should be smart enough to validate
>that they have the right address" and relying on the difficulty in
>producing a near-collision address (keep in mind that many "important"
>hidden services do not have a vanity address at all or have only
>generated an address with a small number of chosen characters).
>
>Probably the best solution is that hidden services that are attractive
>for phishing/misdirection (just about anyone doing business in bitcoin
>for example) should implement measures like showing secrets to the user
>to prove the service identity, and users should of course beware. But
>this solution requires service operator and user participation, making
>it far less than ideal.
>
>Hopefully I made my meaning more clear.
>
>jc
>--
>Jesse B. Crawford
>Student, Information Technology
>New Mexico Inst. of Mining & Technology
>
>https://jbcrawford.us // jesse@jbcrawford.us
>https://cs.nmt.edu/~jcrawford // jcrawford@cs.nmt.edu
>--
>tor-talk mailing list - tor-talk@lists.torproject.org
>To unsubscribe or change other settings go to
>https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

- --
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQJNBAEBCgA3BQJUqPkhMBxDaHJpc3RvcGggVm9sb250ZSA8Y2hyaXN0b3BoLnZv
bG9udGVAZ21haWwuY29tPgAKCRDJZ1TSvj0l9boEEACaWyMM0/CB/Lx52MJeik5i
oAPKc4bkkvJbK+xw0FKQ0MxQXLJzw61Lityb3E0FuvHgAsuVPBHXV7JDZd0SelTW
ptJNVaGUK5/d4dfMFU7ynvqGzzOO8ZlxW6GmGkyoAs3s9tD0QOf0ifCH9FhP/2qp
JWDCVUUNXT1OhaUEPEb9XxZ2LlJn7eQo4yrX2+ECpaygkATbL7AMCzPYnyM0LODP
fXREd2wZFDij5J00VFx3QhLmWax5laF3RPkeJLD1Oap0VjVcTNRTWvpV9Xlq+Ibg
uEL4LrR8LtYsGQ1tqMVtHcnYbduxNhhvRBCgyYpzq7LneiDH8rkyAEOJJjzVuIyT
x9ljB9SIIOouJZbgSkYST5m0CSMFsRXFjJ+jXcYXZx307dFhG4t5SMkGp6QyOcSy
Z0Gf1ClcMcdATxwX2zjXZ0mHhHYHMx9EUhrbcq1rfFuM0jg1tUcLXb/1S5nGTt7z
ApU7sCEBf9BSUIt+5U1U6TxWM7+SEygM65EWMgg8MBE0mSx5AiktqJBCDuji5TTJ
FAfX1mUhD5tALwmPK3vDIzUB3dZkcVILjwIHX2i67U0AHvuuX0qdoL+tQ19RfPDB
BXSjDk7HOpcWoZ3JG/6I3d3wd8pcdNGgMRyRx3AOsgZtFfkr6Y/xA4Dhy/MGTR8T
PdpTpZD1vqvFHFTUpkFwMw==
=Y9Hu
-----END PGP SIGNATURE-----

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

