Re: [tor-dev] onion v2 deprecation plan?

[grarpamp]

> for v3 support, HSFETCH won't be ncessary...

N...

HSFETCH 

is an absolutely necessary control function now critical to operation of a
variety of onionland search / index / status / webhosting / research services,
and any other basic commandline checks that have zero wish to be
spawning heavy browser / wget / specific application apparatus or wasting
resources establishing TCP connections to the services themselves,
and for debugging tor client and network itself independant from
all such other tools, and helpful for "Why can't I connect" questions
from users, etc.

Further, a minimum request and result option semantics of
HSFETCH regarding the above were roughly specified previously...

HSFETCH  [fetch_mode] [output_each] [raw_desc]
[sync_here] [update_cache]
 as integrated with vN-DescId and SERVER= elements

General operation
- fetch mode: 0 default client resolution method, 1 force from network [3 only,
  do not recurse to cache], 2 force from cache [4 only, do not recurse
to network]
- source of the returned descriptor: network, or local cache
- network may have different data than cache so [update_cache] or not,
default yes
- result status of the fetch [a]: ok found, 404 not found, network
failure + why: reason
- status of the descriptor [a]: ok good, bad + why: crypto failed, expired,
  parsing data type, truncated, corrupt, etc
- decoding and printing out all fields of the returned descriptor,
  optionally also print the whole descriptor as received, regardless of any bad
  status, in hex [raw_desc] to further help debugging and other uses
For each HSDir by respective HSDir identifier [output_each=true]
- above result status of the fetch for each HSDir queried (typically six)
- above status of the descriptor from each responding HSDir
- above decoding and printing for each responding HSDir [output_each=verbose]

[a] These should be tagged 0 if all sources / HSDirs were ok, or 1 if an
ok descriptor was ultimately able to be returned to the fetch but some of
the sources / HSDirs had negatives thus pointing to further investigation,
or 2 if none were ok (and print the status if all six had same status, or
print "various" if they varied).

Since nodes may be performing other tasks in parallel, even over the
same onions, and due to various mandatory modes and sources being
selected, and network delays, it is very helpful and unambiguous if the
output is selectably synchronus to this command and console [sync_here],
thus leaving the HS_DESC / HS_DESC_CONTENT event streams doing their
thing if so enabled possibly on / for other control connections / monitors.
A command instance identifier should be added to be returned to match
up with respective event logstream (which would otherwise perhaps be
identified as "socks / tunnel / trans / dns / natd / etc" for those sources),
but that does not replace utility of [sync_here] for lesser capable
users or cases.

Future applications may (and perhaps already do) use HSDir descriptor
mechanism as their own datastore via HSPOST, for which similar
HSFETCH models would be useful, thus good to consider herein,
certainly as an extensible.

There were a tickets and emails somewhere on these concepts so
that they could be further and better implemented. Some elements
were committed, others remain :)

> It is the main reason it hasn't been done that is for a lack of use case. The
> HSFETCH for v3 is much more tricky in terms of engineering and interface thus
> we decided to implement it on the "need it basis".
>
> If OnionBalance actually needs it for v3, then we should try to get that on
> the roadmap.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] TBB + Privoxy

[Mark Smith]

On 4/29/18 10:15 AM, procmem wrote:
> Hi. We are trying to get Tor Browser to work with privoxy to allow users
> to optionally connect to other networks including I2P, Zeronet...
> 
> Here's what we tried:
> 
> * Disabling network.proxy.no_proxies_on
> 
> * Setting network.proxy.http_port to 8118 (privoxy’s port number)
> network.proxy.http 127.0.0.1
> network.proxy.http_port 8118
> network.proxy.ssl 127.0.0.1
> network.proxy.ssl_port 8118
> 
> * We know a transition to unix sockets for localhost comms is planned
> but not currently enforced. We have workarounds for that.
> 
> Can someone please tell me what's missing?
> 
> NB This is a separate copy of Tor Browser to prevent fingerprinting
> problems with normal surfing in general.

What error or incorrect behavior are you experiencing?

Do your preference changes seem to remain in effect? That is, are they
correct if you check them via about:config after your special Tor
Browser is up and running?

Have you disabled Tor Launcher? During browser startup, Torbutton asks
Tor Launcher which proxy settings to use and resets many of the
preferences you mentioned.

-- 
Mark Smith
Pearl Crescent
http://pearlcrescent.com/
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] onion v2 deprecation plan?

[teor]

> On 30 Apr 2018, at 23:55, David Goulet  wrote:
> 
>> On 28 Apr (09:34:09), teor wrote:
>> 
>> On 28 Apr 2018, at 04:48, Damian Johnson  wrote:
>> 
 OnionBalance requires STEM support for V3
>>> 
>>> Hi Alec, would you mind clarifying what you need from Stem? As far as
>>> I'm aware Stem supports v3 onion service creation...
>>> 
>>> https://trac.torproject.org/projects/tor/ticket/25124
>>> 
>>> See the 'version 3' note at the end of...
>>> 
>>> https://stem.torproject.org/api/control.html#stem.control.Controller.create_ephemeral_hidden_service
>>> 
>>> I'm unaware of the ball being in my court on any v3 Onion Service
>>> stuff. If there's something I should have on my radar then please let
>>> me know!
>> 
>> OnionBalance requires Stem support for v3 HSFETCH
>> But Stem requires Tor support for v3 HSFETCH
>> https://trac.torproject.org/projects/tor/ticket/25417
> 
> H I was told before the v3 control port work by Donnacha that for v3
> support, HSFETCH won't be ncessary...
> 
> It is the main reason it hasn't been done that is for a lack of use case. The
> HSFETCH for v3 is much more tricky in terms of engineering and interface thus
> we decided to implement it on the "need it basis".
> 
> If OnionBalance actually needs it for v3, then we should try to get that on
> the roadmap.

I didn't know there was any alternative to HSFETCH.

If OnionBalance can do without it, then we don't need it on the roadmap.

T
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] onion v2 deprecation plan?

[David Goulet]

On 28 Apr (09:34:09), teor wrote:
> 
> On 28 Apr 2018, at 04:48, Damian Johnson  wrote:
> 
> >> OnionBalance requires STEM support for V3
> > 
> > Hi Alec, would you mind clarifying what you need from Stem? As far as
> > I'm aware Stem supports v3 onion service creation...
> > 
> > https://trac.torproject.org/projects/tor/ticket/25124
> > 
> > See the 'version 3' note at the end of...
> > 
> > https://stem.torproject.org/api/control.html#stem.control.Controller.create_ephemeral_hidden_service
> > 
> > I'm unaware of the ball being in my court on any v3 Onion Service
> > stuff. If there's something I should have on my radar then please let
> > me know!
> 
> OnionBalance requires Stem support for v3 HSFETCH
> But Stem requires Tor support for v3 HSFETCH
> https://trac.torproject.org/projects/tor/ticket/25417

H I was told before the v3 control port work by Donnacha that for v3
support, HSFETCH won't be ncessary...

It is the main reason it hasn't been done that is for a lack of use case. The
HSFETCH for v3 is much more tricky in terms of engineering and interface thus
we decided to implement it on the "need it basis".

If OnionBalance actually needs it for v3, then we should try to get that on
the roadmap.

Cheers!
David

-- 
1dKuWYP7Si7mjurnrG6vfHiQfiibnDK5yH7HDBggBeM=


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: Tor bandwidth measurements document format

[juga]

Hi,

after teor's revision, second version pasted below.

Changes can be seen: in
https://github.com/juga0/torspec/commits/bandwidth-file-spec

Best,
juga

=

  Tor Bandwidth Measurements Document Format
juga
teor

1. Scope and preliminaries

  This document describes the format of Tor's bandwidth measurements
  document, version 1.0.0 and later.

  Since Tor version 0.2.4.12-alpha the directory
  authorities use the bandwidth measurements document called
  "V3BandwidthsFile" and produced by Torflow [1]
  (format described in README.spec.txt [2]).

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.

1.2. Acknowledgements

  The original bandwidth measurement scanner (Torflow) and format was
  created by mike. Teor suggested to write this specification while
  contributing on pastly's new bandwidth scanner implementation.

  This specification was revised after feedback from:

XXX

1.3 Outline

  The bandwidth measurements mentioned in sections 3.4.1 and 3.4.2
  of "Tor directory protocol" (dir-spec.txt) [3] are obtained
  by bandwidth authorities, which generate a file storing information
  on relays' measured bandwidth capacities.

1.4. Format Versions

   1.0.0 - The legacy fallback bandwidth measurements document format

   1.1.0 - Adds key_value lines to the header, format version,
   optional ones and section separator.

2. Format details

  Bandwidth measurements MUST contain the following sections:
  - Header (exactly once)
  - Relays measurements (zero or more times)

2.1. Definitions

  The following nonterminals are defined in dir-spec.txt, sections
  1.2., 2.1.1., 2.1.3.:

Int
SP (space)
NL (newline)
Keyword
ArgumentChar
fingerprint (hexdigest)
nickname

  Nonterminals defined in "Tor Directory List Format" (dir-list-spec.txt),
  section 2.2.1.:

version_number

  We define the following nonterminals:

value ::= ArgumentChar+
key_value ::= Keyword "=" value
line ::= ArgumentChar* NL
timestamp ::= Int
bandwidth ::= Int
relay_line ::= key_value (SP key_value)* NL

2.2. Header format

Some header lines MUST appear in specific positions, as documented below.
All other lines can appear in any order.

There MUST NOT be multiple key_value header lines with the same key.

It consists of:

  timestamp NL

[At start, exactly once.]

The Unix Epoch time in seconds when the file was created.

  "version=" version_number NL

[In second position, zero or one time.]

The specification document format version.
It uses semantic versioning [5].

This line has been added in version 1.1.0 of this specification.

Version 1.0.0 documents do not contain this line, and the
version_number is considered to be "1.0.0".

  "software=" value NL

[Zero or one time.]

The name of the software that created the document.

This line has been added in version 1.1.0 of this specification.

Version 1.0.0 documents do not contain this line, and the software is
considered to be "torflow".

  "software_version=" value NL

[Zero or one time.]

The version of the software that created the document.
The version may be a version_number, a git commit, or some other
version scheme.

This line has been added in version 1.1.0 of this specification.

  "scanner_started=" timestamp NL

[Zero or one time.]

The Unix Epoch time in seconds when the scanner that generates the
measurements document started.

This line has been added in version 1.1.0 of this specification.

  "earliest_measurement=" timestamp NL

[Zero or one time.]

The Unix Epoch time in seconds when the first relay measurement
was obtained.

This line has been added in version 1.1.0 of this specification.

  key_value NL

[Zero or more times.]

Future format versions may include additional key_value header lines.
Additional header lines will be accompanied by a minor version
increment.

Implementations MAY add additional header lines as needed. This
specification SHOULD be updated to avoid conflicting meanings for the
same header keys.

Parsers MUST NOT rely on the order of these additional lines.

Additional header lines MUST NOT use any keywords specified in the
relay measurements format.

If a header line does not conform to this format, the line SHOULD be
ignored by parsers.

  NL

[Zero or one time.]

The header ends.

This line has been added in version 1.1.0 of this specification.

For version 1.0.0 documents, the header ends when the first relay
measurement line is found conforming to the next section.

2.3. Relay measurements format

It consists of zero or 

Re: [tor-dev] HS v3 client authorization types

[Suphanat Chunhapanya]

Hi,

On 04/28/2018 03:59 AM, meejah wrote:
> Then, if the service client has a problem later they have
> to remember NOT copy-paste the whole config when asking for
> help... sounds like lots to go wrong :) and I don't think this can be
> solved by tinkering with the names/layout of torrc options,
> personally...


Agreed. I don't think putting a private key in torrc is a good idea.

Maybe we can put the private key in a separate file and put the path in
the torrc?

For example:
HidServAuth onion-address auth-type path-to-private-key-file

haxxpop



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] HS v3 client authorization types

[Suphanat Chunhapanya]

Hi,

On 04/28/2018 06:19 AM, teor wrote:
>> Or should we require the service to enable both for all clients?
>>
>> If you want to let the service be able to enable one while disable the
>> other, do you have any opinion on how to configure the torrc?
> 
> If someone doesn't understand client auth in detail, and just wants
> to be more secure, we should give them a single option that enables
> both kinds of client auth. (Security by default.)
> 
> OnionServiceClientAuthentication 1
> (Default: 0)
> 
> If someone knows they only want a particular client auth method,
> we should give them another option that contains a list of active
> client auth methods. (Describe what you have, not what you don't
> have, because negatives confuse humans.)
> 
> OnionServiceClientAuthenticationMethods intro
> (Default: descriptor, intro)


Do you have any opinion on specifying the client names in your
recommendation? and the list of client names in "descriptor" and "intro"
should be independent.

However, what i am currently think of is that we can use the existing
format.

HiddenServiceAuthorizeClient auth-type client-name,client-name,...

But instead of allowing only two auth-types "descriptor" and "intro", we
allow another type called "default" which includes both "descriptor" and
"intro"

So if I put an option:
HiddenServiceAuthorizeClient default client-name,client-name,...

It will be equivalent to two lines of:
HiddenServiceAuthorizeClient descriptor client-name,client-name,...
HiddenServiceAuthorizeClient intro client-name,client-name,...

And on the client side, if I put an option:
HidServAuth onion-address default x25519-private-key ed25519-private-key

It will be equivalent to two lines of:
HidServAuth onion-address descriptor x25519-private-key
HidServAuth onion-address intro ed25519-private-key


What do you all think?

Cheers,
haxxpop



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Closing old Trac Milestones

[Karsten Loesing]

On 2018-04-30 06:02, teor wrote:
> Hi,

Hi teor,

> Just following up on the old trac milestones.
> 
>> On 23 Apr 2018, at 14:31, teor  wrote:
>>
>> Hi,
>>
>> Tor's trac has a lot of milestones.
>> Sometimes users select the wrong one, because there are so many.
> 
> Does metrics want to close these milestones?
> 
>> ExoneraTor 1.0.0
>> Metrics 1.0.0
>> Metrics 2.0.0
>> Onionoo 1.14.0

Yes, I already closed some of them last week after seeing your message.
The remaining ones are still used.

Thanks for taking the initiative to get rid of old milestones!

All the best,
Karsten



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev