Re: [tor-dev] Using Let's Encrypt for meek bridges

[David Fifield]

On Fri, Apr 08, 2016 at 05:28:45PM -0700, George Tankersley wrote:
> > I'm looking for ideas of good ways to handle TLS certificates and their
> > renewal for meek bridges. I want to use Let's Encrypt for this process,
> > and I hope that someone who knows Let's Encrypt well can contribute some
> > ideas.
> 
> > ideally not requiring new complicated code in meek-server itself
> 
> If you're OK with some amount of new code, there are Go client libraries that
> might be sufficiently flexible:
> 
> - https://github.com/xenolf/lego
> - https://ericchiang.github.io/go/tls/lets/encrypt/letsencrypt/2015/11/13/
> a-letsencrypt-client-for-go.html
> 
> I'll give this a try soon if you haven't already.

Thanks. You are welcome to try. I haven't done anything yet.

My ideal situation would be that I can run an acme client *outside* of
meek-server, the same way I can do for Apache. Something like this:
letsencrypt-auto certonly [some other arguments, maybe --webroot] 
meek.bamsoftware.com

Adding acme code to meek-server seems less desirable to me. I am trying
to keep the feature count low to keep the bug count low. meek-server is
under 500 lines and I wouldn't want to add more than, say, 200 lines for
acme support. It might have to write new certificate files to the
filesystem, which means worrying about privileges. It's possible,
though, that I don't properly understand how an acme library should work
and these concerns aren't appropriate.

My current inclination is to add an --acme-webroot option to
meek-server, and install a restricted http.Handler that allows serving
files from that directory. It will only serve files whose names are in
the specific format that acme requires. Maybe it can only serve files
whose creation time is recent, as an additional safeguard against
accidentally serving non-acme files.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [tor-relays] Private Tor Research Network

[Tim Wilson-Brown - teor]

> On 9 Apr 2016, at 04:21, Nicholas R. Parker (RIT Student)  
> wrote:
> 
> Hi all,
> 
> I've got an issue that I'm seeking help with. I'm with a small group out of 
> RIT that's trying to construct a private TOR network for research purposes, 
> but we've hit a bit of a snag.
> 
> I've worked with both liu fengyun's 
> (http://liufengyun.chaos-lab.com/prog/2015/01/09/private-tor-network.html) 
> and Ritter's write up (https://ritter.vg/blog-run_your_own_tor_network.html), 
> but when trying to set up authority directories the whole thing really falls 
> apart.

Depending on your research needs, you might find chutney helpful:
https://gitweb.torproject.org/chutney.git

chutney configures and launches a tor network on the local machine.
It's designed to quickly smoke-test tor's key functionality, so it has a lot of 
torrc options set that speed things up.

You should be able to get it to run using:
1. git clone https://git.torproject.org/chutney.git
2. git clone https://git.torproject.org/tor.git
3. cd tor
4. make test-network-all

You might find this useful to test your code changes, or to give you a set of 
starting configurations that you can then modify to your own needs (including 
putting various nodes on different IP addresses).

> Trying to edit the torrc file gives errors where it doesn't attempt to bind 
> to the correct ports and trying to set --dirserver or --datadirectory results 
> in errors that there isn't permission to access /var/lib/tor regardless of 
> the owner of the directory (we've tried leaving it as being owned by _tor, 
> tried changing ownership to root, etc) so we can't get the authority 
> directories off the ground.

At the high level of detail your provided, these sound like typical network 
daemon configuration issues.
Have you tried consulting a network daemon FAQ for your OS?

Typically, ports under 1024 shouldn't be used, because they often require root 
permissions or OS-specific capabilities.
Each tor authority has a configured IP and ports, and these need to be 
consistent in each authority, relay, and client's torrc.
Multiple tor instances on the same machine should not use the same ports - this 
includes default ports like SOCKSPort. (Set to 0 to disable).
Do you have any other services running on these machines?
Do you have old tor processes still running?

Typically, network daemons need to be run as the user that owns the directory 
(or, at the very least, the user needs permission to modify it).
Have you tried using a user / permissions FAQ for your OS to help you configure 
the user and permissions correctly?
Tor also has more specific requirements for security reasons, this protects the 
keys from other users on the system.

It's hard to give more advice without more specific details.
If this advice doesn't help, please copy and paste the configuration options 
you used, and the errors you got, and then tell us what you've tried to do to 
fix them.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Private Tor Research Network

[Nicholas R. Parker (RIT Student)]

Hi all,

I've got an issue that I'm seeking help with. I'm with a small group out of
RIT that's trying to construct a private TOR network for research purposes,
but we've hit a bit of a snag.

I've worked with both liu fengyun's (
http://liufengyun.chaos-lab.com/prog/2015/01/09/private-tor-network.html)
and Ritter's write up (https://ritter.vg/blog-run_your_own_tor_network.html),
but when trying to set up authority directories the whole thing really
falls apart.


Trying to edit the torrc file gives errors where it doesn't attempt to bind
to the correct ports and trying to set --dirserver or --datadirectory
results in errors that there isn't permission to access /var/lib/tor
regardless of the owner of the directory (we've tried leaving it as being
owned by _tor, tried changing ownership to root, etc) so we can't get the
authority directories off the ground.

I'd really appreciate any thoughts

Nicholas R. Parker
Rochester Institute of Technology
5thYear, BS/MS Computing Security
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Configuring Single Onion Services

[Virgil Griffith]

For whatever it's worth I never found the compile-time option for tor2web
mode to be offensive.

I remember Roger's original rebuttal against tor2web mode was, "Virgil, I'm
not going to make a 'Make Tor Go Faster Button' to be pressed by people who
don't know what they are doing."

I always thought the compile-time-flag or text warning was a good
compromise.

-V

On Friday, 8 April 2016, George Kadianakis  wrote:

> Tim Wilson-Brown - teor > writes:
>
> > [ text/plain ]
> > Hi All,
> >
> > I'm working on proposal 260's Rendezvous Single Onion Services in #17178.
> >
> > They are faster, because they have one hop between the service and the
> introduction and rendezvous points.
> > But this means that their location is easy to discover (non-anonymous).
> > So we want to come up with a design that makes it hard to configure a
> non-anonymous service by accident.
> >
> > Here's a cut-down version of an email I sent to tor-onions for feedback,
> for those who are on both lists:
> >
> > Nick's concern was that users could configure Single Onion Services
> without realising that it provides no server location anonymity.
> > I initially thought we could change the torrc option name to make this
> clear. ...
> > I now believe that trying to overload the name of a feature with
> warnings about its downsides was a mistake. …
> >
> > This would mean that Single Onion Service operators would include in
> their torrc:
> >
> > SingleOnionMode 1
> > HiddenServiceDir …
> > ...
> >
> > As a separate issue, I think there are two alternative designs that can
> prevent users from configuring the feature and then exposing their location
> unintentionally:
> >
> > Tor2WebMode requires users to add a compilation option:
> --enable-tor2web-mode
> > We could do this with Single Onion Services as well:
> --enable-single-onion-mode
> > If SingleOnionMode is configured without the compilation option, tor
> warns the user and refuses to start.
> > When it is configured, tor warns the user they're non-anonymous, then
> starts.
> > However, using a compilation option makes the feature harder to test.
> > And Tor2Web operators already don't like having to compile separate
> binaries.
> > It's likely Single Onion operators would feel similarly.
> >
> > Alternately, we could add a torrc option: NonAnonymousMode
> > If SingleOnionMode is configured without NonAnonymousMode, tor warns the
> user and refuses to start.
> > When it is configured, tor warns the user they're non-anonymous, then
> starts.
> >
> > I spoke with Nick on IRC and he's happy with either of these options.
> >
> > I'd like to proceed with the NonAnonymousMode torrc option, unless there
> are compelling reasons against that design.
> > I hope that this will allow us to get SingleOnionMode merged early in
> tor 0.2.9.
> >
>
> I think I like this approach more than complicating the torrc option name!
>
> Coming up with a warning message for people who forget to enable
> NonAnonymousMode seems easier than trying to fit that warning message in a
> torrc option name.
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Configuring Single Onion Services

[George Kadianakis]

Tim Wilson-Brown - teor  writes:

> [ text/plain ]
> Hi All,
>
> I'm working on proposal 260's Rendezvous Single Onion Services in #17178.
>
> They are faster, because they have one hop between the service and the 
> introduction and rendezvous points.
> But this means that their location is easy to discover (non-anonymous).
> So we want to come up with a design that makes it hard to configure a 
> non-anonymous service by accident.
>
> Here's a cut-down version of an email I sent to tor-onions for feedback, for 
> those who are on both lists:
>
> Nick's concern was that users could configure Single Onion Services without 
> realising that it provides no server location anonymity.
> I initially thought we could change the torrc option name to make this clear. 
> ...
> I now believe that trying to overload the name of a feature with warnings 
> about its downsides was a mistake. …
>
> This would mean that Single Onion Service operators would include in their 
> torrc:
>
> SingleOnionMode 1
> HiddenServiceDir …
> ...
>
> As a separate issue, I think there are two alternative designs that can 
> prevent users from configuring the feature and then exposing their location 
> unintentionally:
>
> Tor2WebMode requires users to add a compilation option: --enable-tor2web-mode
> We could do this with Single Onion Services as well: 
> --enable-single-onion-mode
> If SingleOnionMode is configured without the compilation option, tor warns 
> the user and refuses to start.
> When it is configured, tor warns the user they're non-anonymous, then starts.
> However, using a compilation option makes the feature harder to test.
> And Tor2Web operators already don't like having to compile separate binaries.
> It's likely Single Onion operators would feel similarly.
>
> Alternately, we could add a torrc option: NonAnonymousMode
> If SingleOnionMode is configured without NonAnonymousMode, tor warns the user 
> and refuses to start.
> When it is configured, tor warns the user they're non-anonymous, then starts.
>
> I spoke with Nick on IRC and he's happy with either of these options.
>
> I'd like to proceed with the NonAnonymousMode torrc option, unless there are 
> compelling reasons against that design.
> I hope that this will allow us to get SingleOnionMode merged early in tor 
> 0.2.9.
>

I think I like this approach more than complicating the torrc option name!

Coming up with a warning message for people who forget to enable
NonAnonymousMode seems easier than trying to fit that warning message in a
torrc option name.

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

Re: [tor-dev] Update on 259

[Ola Bini]

> 
> - Directory guards are 85% of total current guard bandwidth.
> - Guards with ORPorts on 80/443 are 42% of total current guard bandwidth.
> - Guards on IPv6 are 20% of total current guard bandwidth.
> - Guards both on 80/443 and on IPv6 are 8% of total current guard 
> bandwidth.

Useful info, thanks.
This tells us it's very unlikely that someone will not have any
dirguards, or dystopic guards or ipv6 guards. And if we make the
sample set size large enough, something like 50 guards - we are very
likely to have all capabilities.

> With the above probabilities, everytime you sample a guard you have 20%
> probability for it to be an IPv6 guard. To get 4 of them, you will first need
> to sample a lot of guards (like 20 or so, but some binomial distribution magic
> is required to get the exact probabilities) and add them to your sampled guard
> set. I wonder if that's worth it.
Maybe, maybe not. I don't think the problem of sampling until we have
enough to match the filter is a big problem actually.

> Maybe if we have a single guard that satisfies our filters in our sampled 
> guard
> list, we should use that guard instead of sampling for more? I don't exactly
> see value in sampling and exposing ourselves to additional guards if we have
> one that we like (and we might have even connected to in the past).
True, if we have one and that works - all fine with me. The problem is
that IF that guard doesn't work, we have no fallback mechanism to
sample more guards, so we will never correct for that circuit
building.

> Symmetrically, I'm also not sure what's the right thing to do if we have zero
> guards that satisfy our filters in our sampled guard set. Should we start
> sampling randomly till we hit a guard that satisfies us, or should we sample
> directly from the correct set (e.g. only from the set of IPv6 guards). I'm
> still not sure about this.
I'm much more in favor of sampling in general, rather than trying to
hit the specific thing. If we sample in general, we will not skew the
sampled set at least.

Cheers
-- 
 Ola Bini (https://olabini.se)

 "Yields falsehood when quined" yields falsehood when quined.


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] Update on 259

[George Kadianakis]

Ola Bini  writes:

> [ text/plain ]
> Hey,
>
>> > - OrPort vs DirPort
>> > ORPort is used for regular circuits, while DirPort is used when getting 
>> > directory information. We need to interpret reachable stuff
>> > differently depending on the purpose.
>> >
>>
>> I'm not actually sure what the comment means here.
> This was more for our own benefit. The OrPort vs DirPort distinction
> has been a bit complicated so far. The comment basically means, when
> we are looking up directory information, we should use the DirPort to
> decide reachability and so on instead, correct?
>
>> Ensuring a min percentage of dirguards in our sampled set could work. Then,
>> when we need a directory guard, we could filter the sampled set and only
>> examine guards that can do directory requests.
> Yeah, we talked about this yesterday and our current thinking is to
> have a sampled set that contains every kind of thing, and then we
> dynamically filter it based on config and so on during START.
>
>> Hm, are you talking about the guardlists here? What's the question?
>>
>> BTW, if we have the ability to do "ensure a min percentage of X in our 
>> sampled
>> set", couldn't we just ensure a min percentage of dystopic guards in our
>> sampled set?  And forget about the two separate guardlists?
>>
>> In this case we can have the percentage value be the actual portion of the
>> network that is dystopic guards. So if 20% of the total guard bandwidth is
>> dystopic, we could ensure that at least 20% of our sampled set is
>> dystopic".
> Well, the problem is really that the idea of dystopic doesn't
> necessarily make sense, since it's so dependent on the current network
> position of the client. Our current thinking is to do away with that
> concept as well. =)
>
>> > - DYSTOPIC - is there value in trying 80 and 443?
>> > Probably not.
>> >
>>
>> What does "trying" mean in this case?
> Falling back to guards with 80 and 443.
>
>> Restart pending guard selection algorithms on a SIGHUP? Plausible, but I 
>> don't
>> know how hard it would be to implement this.
> Well, the alternative is to just finish the running guard selections
> with the old settings, but use the new settings for new algorithm instances.
>
>> That's not very nice because the USED_GUARDS set that was created when
>> ClientsUseIPv6 or FascistFirewall were on will have reduced diversity. Then
>> even if we switch off those options, we are still stuck with reduced 
>> diversity.
>>
>> I'm not sure what's the right way to do this here!
>>
>> We could imagine having multiple USED_GUARDS sets, where we make a new set 
>> for
>> each possible filter. This might be worth considering, but I imagine there 
>> will
>> be technical difficulties. e.g. when a guard goes down, you need to update 
>> its
>> state in all the USED_GUARDS sets that it's in. Also, a person who toggles 
>> the
>> FascistFirewall option frequently, will end up using two different sets of
>> guards all the time which is suboptimal.
> Well, one thing you could do is hash the settings (and maybe also
> reachable ports) and use that as a key to differentiate the different
> USED_GUARDS. That would solve the problem, but might lead to a single
> client using lots of different guards in different locations. Might
> that be OK?
>
>> > - Can we make the lists smaller?
>> > Probably. Maybe a sampled set of 30 guards? Or 1.5%?
>> >
>>
>> Plausible. However, if we take the filtering approach but use a small sampled
>> guards list, it could happen that the list is not able to satisfy some of our
>> filtering restrictions.
>>
>> e.g. maybe in our 30 guards there are no IPv6 guards at all, and the user 
>> just
>>  turned on ClientUseIPv6. What to do now?
>>
>> This is important to understand, because currently there is no mechanism to 
>> add
>> stuff to the sampled guards list if a restriction cannot be satisfied. So 
>> what
>> will Tor do, if a user enables ClientsUseIPv6 _and_ FascistFirewall but there
>> are no IPv6+80/443 guards in our sampled guards list?
> Yeah, we talked about that yesterday. Our suggestion is to do
> something like this:
> - if the filtered/reduced sample-set contains less than X (5?) guards,
> expand SAMPLED guards using the regular process.
> - If SAMPLE guards reach SAMPLED_MAX (50?) size, we fail closed with
> an error saying something like "your current network settings make it
> impossible for us to safely choose an entry guard. If you really need
> to connect under these circumstances, consider explicitly setting the
> EntryGuards configuration option"

Hello,

just to give some perspective I wrote a small script that calculates the
bandwidth percentage of various types of guards. Here are the results:

- Directory guards are 85% of total current guard bandwidth.
- Guards with ORPorts on 80/443 are 42% of total current guard bandwidth.
- Guards on IPv6 are 20% of total current guard bandwidth.
- Guards both on 80/443 and on IPv6 are 8% of