Delivery-Date: Mon, 17 Nov 2014 13:19:23 -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=-4.8 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	RCVD_IN_DNSWL_MED,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 D1D871E0CA5;
	Mon, 17 Nov 2014 13:19:19 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id EBBC83190A;
	Mon, 17 Nov 2014 18:19:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 961E331908
 for <tor-talk@lists.torproject.org>; Mon, 17 Nov 2014 18:19:12 +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 D4KZ75THStq7 for <tor-talk@lists.torproject.org>;
 Mon, 17 Nov 2014 18:19:12 +0000 (UTC)
Received: from continuum.iocl.org (continuum.iocl.org [217.140.74.2])
 by eugeni.torproject.org (Postfix) with ESMTP id 6F8DE30D23
 for <tor-talk@lists.torproject.org>; Mon, 17 Nov 2014 18:19:11 +0000 (UTC)
Received: (from krey@localhost)
 by continuum.iocl.org (8.11.3/8.9.3) id sAHIJ7t30630;
 Mon, 17 Nov 2014 19:19:07 +0100
Date: Mon, 17 Nov 2014 19:19:07 +0100
From: Andreas Krey <a.krey@gmx.de>
To: tor-talk@lists.torproject.org
Message-ID: <20141117181907.GF10175@inner.h.apk.li>
References: <L8D.DP3D.gRavit6TQI.1KQYwu@seznam.cz>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <L8D.DP3D.gRavit6TQI.1KQYwu@seznam.cz>
User-Agent: Mutt/1.4.2.1i
X-message-flag: What did you expect to see here?
Subject: Re: [tor-talk] Hiden service and session integrity
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On Mon, 17 Nov 2014 18:22:00 +0000, NTPT wrote:
...
> web application "foo" use a classical session to maitain state of the use=
r. =

> Classically user BAR have=A0 IP address and cookie is assigned in the log=
in =

> process. If the right cookie from the right ip address comes for user BAR=
, =

> server accepts future request
> =

> But how it can work thru TOR ?

Your server always sees requests from 127.0.0.1 and everything works. ;-)
(The server only ever sees the addresse from where the hidden service
node is; obviously it can't see the actual client IP.)

> what about scenario that an attacker =

> determine my exit point and somehow stole my authentication cookie and th=
en =


The model of using the IP address (among others) to distinguish users is
broken anyway - mobile users may change addresses occasionally, and
the other way round multiple users (esp. mobile again) can appear
from the same address thanks to the marvels of NAT.

> he can use .exit pseudodomain to route his traffic thru the same exit poi=
nt=A0
>  (ie gain same ip address as a legitimate client ) ? =


You were talking about hidden services in the subject; what you discuss
here is your regular web service being accessed via tor. If we're
talking about the latter you should (as always) offer the service
on https, not http, and the question of stealing the login cookie
becomes academic.

If you're not using https, you're simply careless towards any user
of your service as the cookie is transferred in plaintext - any
open WLAN allows to sniff, as well as any rogue exit node operator
can intercept any login cookie that passes its node in HTTP.

If you're actually offering a hidden service the traffic is
encrypted end-to-end even for plain http: URLs.

> And is it possible (and how ? ) to run end to end encrypted (ssl) web =

> traffic via tor network ?

By enterin https://someurl in the tor browser. I'm sure there
is a pretty picture somewhere but I don't know it.

Andreas

-- =

"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
-- =

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

