Delivery-Date: Mon, 06 Jul 2015 20:09:23 -0400
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=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	T_RP_MATCHES_RCVD autolearn=ham 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 595EC1E0B96;
	Mon,  6 Jul 2015 20:09:21 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 90AC535E7A;
	Tue,  7 Jul 2015 00:09:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 0D45535F42
 for <tor-talk@lists.torproject.org>; Tue,  7 Jul 2015 00:09:08 +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 j2fqJ_btJ5zR for <tor-talk@lists.torproject.org>;
 Tue,  7 Jul 2015 00:09:07 +0000 (UTC)
Received: from mailhost.cotse.com (mail.cotse.net [66.203.85.58])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id DE38C35E64
 for <tor-talk@lists.torproject.org>; Tue,  7 Jul 2015 00:09:07 +0000 (UTC)
Received: from out.packetderm.com (out.packetderm.com [66.203.85.62])
 by mailhost.cotse.com (8.14.8/8.14.5) with ESMTP id t67095lR050236
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO)
 for <tor-talk@lists.torproject.org>; Mon, 6 Jul 2015 20:09:05 -0400 (EDT)
 (envelope-from tortalk@couldbe.securecoffee.com)
Received: from localhost (localhost[127.0.0.1]) (authenticated bits=0)
 by smtp (5.7.4/5.7.4) with ESMTP id t67094uY087689
 for <tor-talk@lists.torproject.org>; Mon, 6 Jul 2015 20:09:04 -0400 (EDT)
 (envelope-from tortalk@couldbe.securecoffee.com)
Received: from HTTP by 127.0.0.1 with HTTP; Mon, 6 Jul 2015 20:09:04 -0400
Message-ID: <MTAwMDA0Mi5jb3VsZGJl.1436227744@quikprotect>
Date: Mon, 6 Jul 2015 20:09:04 -0400
From: "me" <tortalk@couldbe.securecoffee.com>
To: tor-talk@lists.torproject.org
MIME-Version: 1.0
Importance: Normal
Subject: [tor-talk] Hidden Service and exit circuit questions?
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>

I set up a test Stealth Authenticated Hidden Service Web Server.

I noticed examining the logs that the default behavior is for Tor to
establish several "exit circuits". Since the hidden service (HS) does not
need an exit node, I thought to try eliminating all exit circuits.

I added the following to the torrc:

   ExcludeExitNodes 255.0.0.0/1,1.0.0.0/1

Thinking that this excludes the entire Internet as an exit.

Based upon a brief test, it appears to work. I can still contact the HS and
there is no "exit circ" in the log, although it seemed to take longer for the
HS to become known.

This leads me to a couple of questions:

#1
Is excluding all exits a reasonable or good thing to do?

#2
Given that exit circuits are normally pre-established, is it theoretically
possible for an exit node to use its pre-established circuit with my HS to
establish a connect without having the HS encryption cookie, or even without
knowing the "onion" since the circuit already exists?



-- 
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

