[tor-dev] Always up-to-date HSTS preload list for Tor?

[Ivan Ristic]

Dear Tor developers,

My SSL Labs server test has a feature where it checks for preloaded HSTS
in Chrome, IE, Firefox, and Tor.

You can see it near the bottom of this report, for example (under "HSTS
Preloading"):

https://www.ssllabs.com/ssltest/analyze.html?d=scotthelme.co.uk=107.170.218.42

For Tor, I download the preload list from this URL:

https://gitweb.torproject.org/tor-browser.git/plain/security/manager/boot/src/nsSTSPreloadList.inc?h=tor-browser-38.2.1esr-5.0-2

That's the best I could find (when I originally implemented the
feature), and I now see that the version number has advanced since.

Which brings me to my question: is there a public URL that always
contains the latest preload list?

Thanks!

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

Re: [tor-dev] Revisiting Proposal 246: Merging Hidden Service Directories and Introduction Points

[George Kadianakis]

Tim Wilson-Brown - teor  writes:

> Hi,
>

Hi, thanks for the feedback.

> I also have concerns about proposal 246, I don't think its benefits are 
> compelling
> compared with the number of drawbacks.
>

To better understand the performance benefits of prop246, here are some
experimental graphs by Karsten that show how much time each hidden service
connection substep takes: http://ec2-54-92-231-52.compute-1.amazonaws.com/

As you can see the "fetch descriptor" step (which prop246 removes) is one of
the most lengthy ones.

> If we do want to skip the introduction point, proposal 252 (single onion 
> services)
> provides a way for onion services to do this on an opt-in basis. (However, it 
> doesn't
> allow onion services to skip the introduction point step and stay 
> location-hidden.)
>

Yeah, SOS is not suitable for all the threat models we are trying to cover.

> There's also nothing preventing us from making this change in future, by 
> modifying
> how hidden services select their introduction points. We could then teach 
> clients
> to use the HSDir as an introduction point if it's in the list.
>

Hm, maybe. But with increased migration and engineering costs.

>> On 14 Jan 2016, at 03:50, George Kadianakis  wrote:
>> 
>> Hello there,
>> ...
>> Here are some issues that make this proposal not an obvious pick:
>> 
>> 1) Security issues
>> ...
>>   - It was also pointed out that the HSDir algorithm does not take into
>> account the bandwidth of the nodes, making it easier to launch Sybil
>> attacks.  However, the rest of the the mailing list thread suggests
>> various ways to do bandwidth weighted hash ring selections [4], so this
>> might not be an important factor.
>
> As far as I recall, there was no guarantee that a large hidden service would
> not pick 6 low-bandwidth HSDirs/IPs for a day, with serious impact on the
> reachability of that hidden service for that period.
>
>> 3) Load balancing issue
>> ...
>>   - Another concern here is that hidden services would not be able to change
>> the number of their introduction points. This is not a big problem
>> currently, but it could become in the future if the network gets more
>> overloaded. As a partial solution to this, #17690 suggests making the
>> number of HSDirs a network-wide consensus parameter that could also be
>> used by proposal 246.
>
> It could also become a big problem for large hidden services which benefit 
> from
> 10 (or more) introduction points.
>
>> 2) Reachability issue
>> 
>>   A final issue here is that if the relay churn of the network increases, the
>>   introduction point hash ring might be changing rapidly and clients might 
>> get
>>   pointed to the wrong introduction points.
>> 
>>   However, this does not seem like a greater problem than what hidden 
>> services
>>   are facing with HSDir reachability currently. Is this right, or does 
>> prop246
>>   makes it worse?
>
> Proposal 246 makes it worse, because now both HSDirs and introductions depend
> on a potentially churning hash ring. If churn makes an introduction point
> unreachable, this increases the load on the other introduction points.
>

Isn't that also the case for HSDirs currently?

> Clients also cache descriptors from HSDirs, but they need an introduction 
> point
> to be up whenever they contact the hidden service.
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Comparing Stem, metrics-lib, and zoossh

[Karsten Loesing]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14/01/16 17:22, Damian Johnson wrote:
> Oh, forgot to talk about compression. You can run the stem script 
> against compressed tarballs but python didn't add lzma support
> until python 3.3...
> 
> https://stem.torproject.org/faq.html#how-do-i-read-tar-xz-descriptor-archives
>
>  I suppose we could run over bz2 or gz tarballs, or upgrade python.
> But can't say the compressed benchmark is overly important.

I just ran all the Stem measurements using Python 3, which now
includes xz tarballs.  The table below contains all results:

server-descriptors-2015-11.tar.xz:
 - metrics-lib: 0.334261 ms
 - Stem[**]: 0.63 ms (188%)

server-descriptors-2015-11.tar:
 - metrics-lib: 0.28543 ms
 - Stem: 1.02 ms (357%)
 - Stem[**]: 0.63 ms (221%)

server-descriptors-2015-11/:
 - metrics-lib: 0.682293 ms
 - Stem: 1.11 ms (163%)
 - Stem[**]: 1.03 ms (151%)
 - Zoossh: 0.458566 ms (67%)

extra-infos-2015-11.tar.xz:
 - metrics-lib: 0.274610 ms
 - Stem[**]: 0.46 ms (168%)

extra-infos-2015-11.tar:
 - metrics-lib: 0.2155 ms
 - Stem: 0.68 ms (316%)
 - Stem[**]: 0.42 ms (195%)

consensuses-2015-11.tar.xz:
 - metrics-lib: 255.760446 ms
 - Stem[**]: 913.12 ms (357%)

consensuses-2015-11.tar:
 - metrics-lib: 246.713092 ms
 - Stem: 1393.10 ms (565%)
 - Stem[**]: 876.09 ms (355%)

consensuses-2015-11/:
 - metrics-lib: 283.910864 ms
 - Stem: 1303.53 ms (459%)
 - Stem[**]: 873.45 ms (308%)
 - Zoossh: 83 ms (29%)

microdescs-2015-11.tar.xz[*]:
 - metrics-lib: 0.099397 ms
 - Stem[**]: 0.33 ms (332%)

microdescs-2015-11.tar[*]:
 - metrics-lib: 0.066566 ms
 - Stem: 0.66 ms (991%)
 - Stem[**]: 0.34 ms (511%)

[*] The microdescs* tarballs contain microdesc consensuses and
microdescriptors, but I only cared about the latter; what I did is
extract tarballs, delete microdesc consensuses, and re-create and
re-compress tarballs

[**] Run with Python 3.5.1

Is Python 3 really that much faster than Python 2?  Should we just
omit Python 2 results from this comparison?

All the best,
Karsten
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJWmPd6AAoJEJD5dJfVqbCrW2IIAL7KyVxDbLczXjtzgwLxFjzw
s9AjhRILb4cBUwr4N4bFAe6x2rXT5w0dEOweMqjcki7IQ4+/gcjok3PLvT6z6lUW
5pKHppU8OmaZItARvGRNlDxWt4E2SSP597GwTWr7rPwwjRRjXmqNPrWAUzq1eteB
S8os9M2whsEntfUF+aPmZbu2oNzJYdnOL/B139MA72nuo9d6no3CXyTFfvT4a9kV
K8vg1w54yDtyp15+uVGaJjfbQRJdPRmpjzkSntngnvSL098g1Rq7coRARMrIJ4BB
8+WjqtoU5IlnuMS3U/aC/FaXFWLz0vHoXci33ZP+kwmX4GywC1mC/QGbvinlkPk=
=WQF6
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Comparing Stem, metrics-lib, and zoossh

[Damian Johnson]

Yikes, thanks for getting these Karsten! I don't think we should omit
the earlier results since the python community is still very much
split between 2.7 and 3.x. I'll include both so users know they can
upgrade their interpreter to get a nice little speed boost.

Thanks!


On Fri, Jan 15, 2016 at 5:43 AM, Karsten Loesing  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 14/01/16 17:22, Damian Johnson wrote:
>> Oh, forgot to talk about compression. You can run the stem script
>> against compressed tarballs but python didn't add lzma support
>> until python 3.3...
>>
>> https://stem.torproject.org/faq.html#how-do-i-read-tar-xz-descriptor-archives
>>
>>  I suppose we could run over bz2 or gz tarballs, or upgrade python.
>> But can't say the compressed benchmark is overly important.
>
> I just ran all the Stem measurements using Python 3, which now
> includes xz tarballs.  The table below contains all results:
>
> server-descriptors-2015-11.tar.xz:
>  - metrics-lib: 0.334261 ms
>  - Stem[**]: 0.63 ms (188%)
>
> server-descriptors-2015-11.tar:
>  - metrics-lib: 0.28543 ms
>  - Stem: 1.02 ms (357%)
>  - Stem[**]: 0.63 ms (221%)
>
> server-descriptors-2015-11/:
>  - metrics-lib: 0.682293 ms
>  - Stem: 1.11 ms (163%)
>  - Stem[**]: 1.03 ms (151%)
>  - Zoossh: 0.458566 ms (67%)
>
> extra-infos-2015-11.tar.xz:
>  - metrics-lib: 0.274610 ms
>  - Stem[**]: 0.46 ms (168%)
>
> extra-infos-2015-11.tar:
>  - metrics-lib: 0.2155 ms
>  - Stem: 0.68 ms (316%)
>  - Stem[**]: 0.42 ms (195%)
>
> consensuses-2015-11.tar.xz:
>  - metrics-lib: 255.760446 ms
>  - Stem[**]: 913.12 ms (357%)
>
> consensuses-2015-11.tar:
>  - metrics-lib: 246.713092 ms
>  - Stem: 1393.10 ms (565%)
>  - Stem[**]: 876.09 ms (355%)
>
> consensuses-2015-11/:
>  - metrics-lib: 283.910864 ms
>  - Stem: 1303.53 ms (459%)
>  - Stem[**]: 873.45 ms (308%)
>  - Zoossh: 83 ms (29%)
>
> microdescs-2015-11.tar.xz[*]:
>  - metrics-lib: 0.099397 ms
>  - Stem[**]: 0.33 ms (332%)
>
> microdescs-2015-11.tar[*]:
>  - metrics-lib: 0.066566 ms
>  - Stem: 0.66 ms (991%)
>  - Stem[**]: 0.34 ms (511%)
>
> [*] The microdescs* tarballs contain microdesc consensuses and
> microdescriptors, but I only cared about the latter; what I did is
> extract tarballs, delete microdesc consensuses, and re-create and
> re-compress tarballs
>
> [**] Run with Python 3.5.1
>
> Is Python 3 really that much faster than Python 2?  Should we just
> omit Python 2 results from this comparison?
>
> All the best,
> Karsten
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
>
> iQEcBAEBAgAGBQJWmPd6AAoJEJD5dJfVqbCrW2IIAL7KyVxDbLczXjtzgwLxFjzw
> s9AjhRILb4cBUwr4N4bFAe6x2rXT5w0dEOweMqjcki7IQ4+/gcjok3PLvT6z6lUW
> 5pKHppU8OmaZItARvGRNlDxWt4E2SSP597GwTWr7rPwwjRRjXmqNPrWAUzq1eteB
> S8os9M2whsEntfUF+aPmZbu2oNzJYdnOL/B139MA72nuo9d6no3CXyTFfvT4a9kV
> K8vg1w54yDtyp15+uVGaJjfbQRJdPRmpjzkSntngnvSL098g1Rq7coRARMrIJ4BB
> 8+WjqtoU5IlnuMS3U/aC/FaXFWLz0vHoXci33ZP+kwmX4GywC1mC/QGbvinlkPk=
> =WQF6
> -END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Revisiting Proposal 246: Merging Hidden Service Directories and Introduction Points

[Mike Perry]

George Kadianakis:
> Hello there,
> 
> we recently finished implementing proposal 250 which is one of the first steps
> for the upcoming hidden service redesign [1]. The next steps are implementing
> proposal 224 and the other performance and security proposals [2].
> 
> On this note, one of the open design issues that we need to tackle next is
> whether we should do proposal 246 or not. Proposal 246 merges HSDirs and Intro
> Points into a single entity to simplify the protocol and improve its
> performance. The idea is that HSes will pick their intro points using the hash
> ring algorithm currently used for picking HSDirs. Clients will do the same and
> connect directly to the intro points instead of going through the HSDir step.
> 
> I suggest you read the proposal and the discussion thread to become better
> informed about this idea:
>  https://lists.torproject.org/pipermail/tor-dev/2015-July/009079.html
> 
> Proposal 246 changes the hidden service protocol substantially, which is why 
> we
> need to decide whether to do it soon. The next steps in our implementation 
> plan
> heavily depend on whether we will do proposal 246 or not.
> 
> Here are some issues that make this proposal not an obvious pick:
> 
> 1) Security issues
> 
>- Professor Hopper pointed out [3] that this proposal will double the 
> number
>  of introduction points of a hidden service (from the current 3 to 6).
>  Introduction points have slightly more attack vectors than HSDirs, so we
>  should not increase their number without analyzing further.

An additional related security issue is the traffic analysis benefits of
separating out hsdir, IP, and RP. Recall that the original onion routing
design did this on purpose (despite considerable performance drawback),
so that actual circuit-level traffic patterns from the hidden service
would be fully decoupled from their identity information.

If we were to merge hsdirs with intro points that have long-lived
circuits opened to them, we create additional point where an adversary
who sees/learns/knows the hs address can attempt to passively or
actively correlate traffic patterns with a malicious hidden service
guard. There will be much more traffic available at the intropoint for
such passive or active traffic analysis than there will be during a
simple hsdir fetch or post, which means that long-term traffic analysis
and related intersection/statistical disclosure attacks have much more
opportunity to succeed. Long-term traffic analysis is also much harder
to combat with padding.

Granted, even with prop 224, an adversary that knows a non-authenticated
hidden service address can decrypt the descriptor to learn the
introduction points, but to actually be in the position to perform
circuit-level traffic analysis on them requires another c/n multiplier,
making the full attack succeed with probability O((c/n)^3) (ie, the
adversary has to get in the guard, hsdir, and intropoint positions to be
fully successful).

I think this is reason enough to reject Proposal 246 for high security
onion services by itself, but the complications with onionbalance also
concern me, as well.


-- 
Mike Perry


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

Re: [tor-dev] Proposal: Load Balancing with Overhead Parameters

[Mike Perry]

Mike Perry:
> Tim Wilson-Brown - teor:
> > > On 13 Jan 2016, at 00:53, Mike Perry  wrote:
> > > 1. Overview
> > > 
> > > For padding overhead due to Proposals 251 and 254, and changes to hidden
> > > service path selection in Proposal 247, it will be useful to be able to
> > > specify a pair of parameters that represents the additional traffic
> > > present on Guard and Middle nodes due to these changes.
> > 
> > I don't know if it's worth noting that proposals 252 and 260 (the Single 
> > Onion
> > Services variants) will reduce traffic to guard and middle nodes, as they
> > remove the nodes between the hidden service and client-controlled endpoint
> > (rendezvous point in Rendezvous Single Onion Services, extend point in
> > Single Onion Services).
> > 
> > I think these will just be part of the overhead parameters?
> 
> Probably, though this will require us to have some estimation on the
> amount of network traffic using these services. Will they be broken out
> separately in the extra-info hidden service stats?
> 
> > > 2. Simplified Load Balancing Equations
> > > 
> > > Recall that the point of the load balancing equations in section 3.8.3
> > > of dir-spec.txt is to ensure that an equal amount of client traffic is
> > > distributed between Guards, Middles, Exits, and Guard+Exits, where each
> > > flag type can occupy one or more positions in a path. This allocation is
> > > accomplished by solving a system of equations for weights for flag
> > > position selection to ensure equal allocation of client traffic for each
> > > position in a circuit.
> > > 
> > > If we ignore overhead for the moment and treat Guard+Exit nodes as Exit
> > > nodes, then this allows the simplified system of equations to become:
> > > 
> > >  Wgg*G == M + Wme*E + Wmg*G# Guard position == middle position
> > >  Wgg*G == Wee*E# Guard position == equals exit position
> > >  Wmg*G + Wgg*G == G# Guard allocation weights sum to 1
> > >  Wme*E + Wee*E == E# Exit allocation weights sum to 1
> > 
> > I think this analysis assumes that all paths in the Tor network are 3-hop 
> > paths.
> 
> That is correct.
>  
> > What about the 4-hop paths created by circuit cannibalisation?
> > (We don't actually know what proportion of the Tor network has 3-hop vs 
> > 4-hop paths.)
> > 
> > Depending on whether an exit or internal circuit is cannibalised, they can 
> > look like:
> > G M E E
> > G M M E
> > 
> > Or, if cannibalised from an exit or internal circuit:
> > G M E M
> > G M M M
> > 
> > Again, I think these will just be part of the overhead parameters?
> 
> Ugh. This will be complicated to work out. Cannibalization rate is a
> function of how often you need to build a path, and have circuits
> available, but none with the right exit/endpoint at the time. This will
> be hard to predict accurately in the wild.
> 
> Cannibalization has been the bane of my existence every time I've made
> any performance or path selection change to Tor. It was an optimization
> introduced because TAP was believed to be too CPU-expensive to allow us
> to opt to build fresh circuits when we needed a different endpoint than
> was currently available in the open set, and so we needed to add the
> new required endpoint to an existing open circuit instead.
> 
> Now that we have ntor, I am wondering if we can just remove
> cannibalization. My guess is that without it, we will pay some up-front
> latency cost in terms of needing to build fresh full circuits in some
> (rare?) cases, but probably will have faster and higher capacity
> circuits for those cases once they are built (especially since the
> Circuit Build Timeout cutoff works better without factoring in
> cannibalization time, as well). Circuit build prediction should also
> reduce this cost over time, since it will ensure that we always have a
> circuit open to recently used endpoint types (either exit ports or
> hidserv-capable circs).
> 
> David Goulet supposedly has a simulator+test script to examine the
> impact of cannibalization. He said that he'd look into updating it for
> 0.2.7/master, but here's a graph of his results from 0.2.5:
> https://people.torproject.org/~dgoulet/hs/rp-025.png
> 
> Basically, that says that unless you make a whole lot of rendezvous
> connections, cannibalized circuits are slower. I'm not sure why their
> speed would be a function of quantity at all.. As I said, circuit
> prediction should reduce the need for cannibalization over time, but it
> shouldn't actually make the circuits that do get cannibalized any
> faster..
> 
> All told, I think in the interest of simplification and also better load
> balancing, we should still kill cannibalization for most cases. The one
> case where I think it may still be desired is in the connection to the
> hsdir, since it seems natural to just extend an existing circuit rather
> than build a whole new one there.
> 
> > And what about hidden service paths (paths that 

Re: [tor-dev] Revisiting Proposal 246: Merging Hidden Service Directories and Introduction Points

[Mike Perry]

It's me again. It looks like I'm still the Internet champion of
"Thinking once and posting twice".

Mike Perry:
> George Kadianakis:
> > Hello there,
> > 
> > we recently finished implementing proposal 250 which is one of the first 
> > steps
> > for the upcoming hidden service redesign [1]. The next steps are 
> > implementing
> > proposal 224 and the other performance and security proposals [2].
> > 
> > On this note, one of the open design issues that we need to tackle next is
> > whether we should do proposal 246 or not. Proposal 246 merges HSDirs and 
> > Intro
> > Points into a single entity to simplify the protocol and improve its
> > performance. The idea is that HSes will pick their intro points using the 
> > hash
> > ring algorithm currently used for picking HSDirs. Clients will do the same 
> > and
> > connect directly to the intro points instead of going through the HSDir 
> > step.
> > 
> > I suggest you read the proposal and the discussion thread to become better
> > informed about this idea:
> >  https://lists.torproject.org/pipermail/tor-dev/2015-July/009079.html
> > 
> > Proposal 246 changes the hidden service protocol substantially, which is 
> > why we
> > need to decide whether to do it soon. The next steps in our implementation 
> > plan
> > heavily depend on whether we will do proposal 246 or not.
> > 
> > Here are some issues that make this proposal not an obvious pick:
> > 
> > 1) Security issues
> > 
> >- Professor Hopper pointed out [3] that this proposal will double the 
> > number
> >  of introduction points of a hidden service (from the current 3 to 6).
> >  Introduction points have slightly more attack vectors than HSDirs, so 
> > we
> >  should not increase their number without analyzing further.
> 
> An additional related security issue is the traffic analysis benefits of
> separating out hsdir, IP, and RP. Recall that the original onion routing
> design did this on purpose (despite considerable performance drawback),
> so that actual circuit-level traffic patterns from the hidden service
> would be fully decoupled from their identity information.
> 
> If we were to merge hsdirs with intro points that have long-lived
> circuits opened to them, we create additional point where an adversary
> who sees/learns/knows the hs address can attempt to passively or
> actively correlate traffic patterns with a malicious hidden service
> guard. There will be much more traffic available at the intropoint for
> such passive or active traffic analysis than there will be during a
> simple hsdir fetch or post, which means that long-term traffic analysis
> and related intersection/statistical disclosure attacks have much more
> opportunity to succeed. Long-term traffic analysis is also much harder
> to combat with padding.
> 
> Granted, even with prop 224, an adversary that knows a non-authenticated
> hidden service address can decrypt the descriptor to learn the
> introduction points, but to actually be in the position to perform
> circuit-level traffic analysis on them requires another c/n multiplier,
> making the full attack succeed with probability O((c/n)^3) (ie, the
> adversary has to get in the guard, hsdir, and intropoint positions to be
> fully successful).

This paragraph is wrong. Of course, the adversary can just poll the
hsdir themselves actively to learn the current into points. It's still
O((c/n)^2). Embarrassing.

> I think this is reason enough to reject Proposal 246 for high security
> onion services by itself, but the complications with onionbalance also
> concern me, as well.

I think my traffic analysis concerns still stand, though. I'm especially
nervous about having the IP lifetimes fixed at the same lifespan as the
hsdirs. It would be better if we're able to shorten those as we better
understand the benefits of padding and the risks of traffic analysis
here.

One option might be leaving Prop 246 as an optional later optimization.
If we don't change the 224 crypto at all to optimize it for 246, we can
still save the same number of network round trips if clients know to
re-use their hsdir circ to perform the intro request if one of the
listed intro points happens to be the current hsdir. That way we save
the same number of round trips if we want, but don't lock ourselves in
to this path restriction and associated circuit lifespan issue? Sure,
we'd be doing a little bit of needless crypto, but the important thing
is we can still save the network round trips and circuit construction.


-- 
Mike Perry


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

[tor-dev] Fwd: Orbot 15.1.0-RC-1

[Nathan Freitas]

- Original message -
From: Nathan of Guardian 
To: guardian-...@lists.mayfirst.org
Subject: Orbot 15.1.0-RC-1
Date: Fri, 15 Jan 2016 15:34:20 -0500


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Orbot v15.1 is out as a release candidate. It includes Tor 0.2.7.6, a
very reliable VPN mode (full device or app-specific), a major update to
Orbot icon, and many more important improvements.

APK: https://guardianproject.info/releases/Orbot-v15.1.0-RC-1.apk
Sig: https://guardianproject.info/releases/Orbot-v15.1.0-RC-1.apk.asc
Code:
https://gitweb.torproject.org/orbot.git/commit/?id=f541e9ffe14a2719863327bf262b48de135ee0fd
Changelog:
https://gitweb.torproject.org/orbot.git/tree/CHANGELOG?id=f541e9ffe14a2719863327bf262b48de135ee0fd

/** 15.1.0-RC-1 / 15-January-2016 /
f541e9ffe14a2719863327bf262b48de135ee0fd **/

We updated the essentials
* 317405d update external versions of Tor 0.2.7.6 and OpenSSL 1.0.1q

We made the ability scan QR codes from bridges.torproject.org work
again!
* 8f7165c fixes for settings processing and QRCode scanning of bridges -
support new JSON array form bridges.torproject.org - only en
ab

We fixed the DNS leak bug in the VPN feature and improved the usability
overall (no Orbot restart required)
* 76b2171 update pdnsd and tun2socks to Android-16 add stpcpy function
not present before Android-21
* 39244a6 fix the ability to select per app VPN routing
* d839b15 fixes for VPN service UI to work on Android6
* 3691cca native binary asset building fixes move pdnsd exec to assets
* f369652 add code to kill pdnsd daemon when VPN is stopped
* f1fcec3 add support for PDNSD DNS Daemon for VPN DNS resolution Tor's
DNS port doesn't work well with the VPN mode, so we will use
PD
* 8d8fe0c updates to improve VPN support
* 699b60d add linancillary for badvpn tun2socks update for DNS

We added the controversial ability for the user to easily set their exit
country, with the default to the whole world
* 52acf68 move "World" string to resource
* 3b41365 allow country exit node select to persist
* b208178 add initial support for easy exit country selection

We now recommend Orfox over Orweb
* 51205b8 update for Orfox
* 0a5dd08 use a browser constant here, with the new constant being Orfox

We made some new graphics
* c54ab18 deleted these graphics
* 534c2fb update style, icons and graphics

We improve the build process, updated localizations and links to other
repos:
* 3240367 clean shouldn't clean assets, so we can easily builds for
multiple platforms
* 0081d00 remove Pluto Go building form this Makefile for now
* 2288210 update to OpenSSL's github mirror
* dfc5101 update tfx config
* eaf49da update store and app translations
* fe9119d update jenkins-build script
* 6dc8cf6 update makefile for new pluto builds
* 0261236 change this to "browser button"
* 3462cbd small updates to icon and strings
* bb7 update installer to get PLUTO binaries from assets
* 7d213e2 delete pluggable transport binaries here; build with Makefile
use the external/pluto project
* 6cf1201 update makefile to support PLUTO builds
* 871701e add link for new icon
* 6fb4f0c update binaries
* cd0bfd3 [Trivial] Fixed broken reference to Main Activity in 
WALKTHROUGH
* 0cde639 fix translations for common issues
* 2acdd29 update localizations for strings and app description

- - --
  Nathan of Guardian
  nat...@guardianproject.info
-BEGIN PGP SIGNATURE-
Version: Mailvelope v1.3.3
Comment: https://www.mailvelope.com

wsFcBAEBCAAQBQJWmVe+CRCoARg+abN6qQAAdksP/2REHo8U2M42/cBLD9Pd
wKnPxGTNMnLYsv0Nq7hJMwmMky/7BNopBW9T2pjIiLSxj3soNUdw7LJAgA57
ns0bI2BNqILcai/gK3j9tw1dOQdfvYmfKL4omZuJpGSOSotGW/F9nVnv8SBn
l8ddE0rU5FUyrJ3Si+QNgkCB4heij6oNOAFqrUb6YRQcUuu08tl18b3IGr1N
VfWk4504FjwJIKX1LiYLVHRL2Se49UGYOmeg+cZtKcVV/6zmcl66hsaAdqZD
+7IhcUivlGPU37v/IP3Af9hbpLIcW/eyW6Arf3kKD8Pv08mwg5gHQDblOcD0
j5Ai29Tig+75RHjmCdkIBnc4dhByGbNaiY49t12gBq2/m9zNwgqibmxozG3Y
gTecvL5rGxgYdOYby1Hd9ndSF7x5R2L/IREAbotsvph4TxUhHh2AAnumAU9a
YitErhaNE3vim6ywP8Il92WJ3gIDUlQimXAJuVmsOQcnXRLIq2LcJUW2IkfJ
1+D+Z4z1xJePDAOaguxK1WHb3TerG4y/CT7btQb2ibTf6u0pMgCYK7+bRf1S
pPlkzr6sh+DWkihom+rU+vrLsqAhuGfVydsVy3RS+n6ea+dEpqY92YGaFXxZ
XbwYrNOsBDD+rlzvKJr/51GgxmtGvVTfeh+P0bxClnIkwoyuDSH7MftONFeY
OxI3
=16US
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev