Hi,
On 9 Jan 2018, at 08:09, Tortilla wrote:
>>> Yes, if the HS operator does not want to mask the HS location, then it
>>> is all good. For that purpose, I agree that the warning message should
>>> be changed.
>>
>> Indeed. I run some public resources (e.g.
>> So assuming I just want to run SSH on some port on an .onion on the
>> relay, what is the downside there? Just wondering if for that usecase,
>> SSH to login remotely on to the relay would still have any disadvantages
>> that I missed to consider
The relay is on clearnet in consensus, thus
On 2018-01-09 13:33, yl wrote:
On 08.01.2018 11:21, Florentin Rochet wrote:
Yes, if the HS operator does not want to mask the HS location, then it
is all good. For that purpose, I agree that the warning message should
be changed.
So assuming I just want to run SSH on some port on an .onion
On 08.01.2018 11:21, Florentin Rochet wrote:
>
> Yes, if the HS operator does not want to mask the HS location, then it
> is all good. For that purpose, I agree that the warning message should
> be changed.
So assuming I just want to run SSH on some port on an .onion on the
relay, what is the
On 2018-01-08 16:08, Roger Dingledine wrote:
On Mon, Jan 08, 2018 at 03:59:25PM -0700, Dave Warren wrote:
Even if Tor didn't supply any relay
statistics, a curious and enterprising individual could "explore" by seeing
what happens to a particular onion when one launches a DoS attack against
On 2018-01-08 19:54, Alain Wolf wrote:
I think the real issue here is once more the wording "hidden service"
for something which is, in your case, not intended to be hidden.
I believe thats why the term "Onion Service" was introduced.
Indeed. I use Onion Service when starting a conversation,
On 08.01.2018 23:59, Dave Warren wrote:
> On 2018-01-08 14:09, Tortilla wrote:
>>
>> On Mon, January 8, 2018 11:25 am, Dave Warren wrote:
>>> On 2018-01-08 03:21, Florentin Rochet wrote:
> Perhaps in the case that the HS operator is not trying to mask the HS
> location, the act of mixing
On 2018-01-08 14:09, Tortilla wrote:
On Mon, January 8, 2018 11:25 am, Dave Warren wrote:
On 2018-01-08 03:21, Florentin Rochet wrote:
Perhaps in the case that the HS operator is not trying to mask the HS
location, the act of mixing public relay traffic can be nothing but a
*help* to defeat
On Mon, January 8, 2018 11:25 am, Dave Warren wrote:
> On 2018-01-08 03:21, Florentin Rochet wrote:
>>> Perhaps in the case that the HS operator is not trying to mask the HS
>>> location, the act of mixing public relay traffic can be nothing but a
>>> *help* to defeat anyone trying to correlate
On Mon, January 8, 2018 2:21 am, Florentin Rochet wrote:
> Hey Tortilla,
>
> Sorry for the late reply:
>
> On 2018-01-05 21:13, Tortilla wrote:
>>> The issue is fixed by adding the above warning message: if you care
>>> about your hidden service's "hidden" property, do not run a relay on
>>> the
On 2018-01-08 03:21, Florentin Rochet wrote:
Perhaps in the case that the HS operator is not trying to mask the HS
location, the act of mixing public relay traffic can be nothing but a
*help* to defeat anyone trying to correlate traffic coming to the HS with
traffic emanating from any one
Hey Tortilla,
Sorry for the late reply:
On 2018-01-05 21:13, Tortilla wrote:
The issue is fixed by adding the above warning message: if you care
about your hidden service's "hidden" property, do not run a relay on the
same process.
Would you mind elaborating? As I read the tracker link, the
On Fri, January 5, 2018 12:31 pm, Roger Dingledine wrote:
> On Fri, Jan 05, 2018 at 03:08:48AM -, torti...@mantablue.com wrote:
>> Second, I had read in the past opinions stating:
>>
>> When operating a hidden service, running a relay helps mix traffic so
>> that
>> anyone observing traffic
On Fri, Jan 05, 2018 at 03:08:48AM -, torti...@mantablue.com wrote:
> Second, I had read in the past opinions stating:
>
> When operating a hidden service, running a relay helps mix traffic so that
> anyone observing traffic from the machine cannot easily run an analysis
> targeted at a
>> When operating a hidden service and a relay in one tor instance, tor
>> currently warns:
>>
>> [warn] Tor is currently configured as a relay and a hidden service.
>> That's
>> not very secure: you should probably run your hidden service in a
>> separate
>> Tor process, at least -- see
Hey,
On 2018-01-05 04:08, torti...@mantablue.com wrote:
When operating a hidden service and a relay in one tor instance, tor
currently warns:
[warn] Tor is currently configured as a relay and a hidden service. That's
not very secure: you should probably run your hidden service in a separate
It is safe to assume that both relays and select hidden services are
being scanned 24/7. When your host reboots (say, as a result of an
automatic OS update), both your relay and your hidden service become
unavailable at the same time, instantly revealing the IP of the hidden
service.
On Thu, Jan
When operating a hidden service and a relay in one tor instance, tor
currently warns:
[warn] Tor is currently configured as a relay and a hidden service. That's
not very secure: you should probably run your hidden service in a separate
Tor process, at least -- see https://trac.torproject.org/8742
18 matches
Mail list logo