Tor 0.3.0.9 is released (with security update for clients)

by nickm | June 29, 2017

Source code for a new Tor release (0.3.0.9) is now available on the website.

Tor 0.3.0.9 fixes a path selection bug that would allow a client to use a guard that was in the same network family as a chosen exit relay. This is a security regression; all clients running earlier versions of 0.3.0.x or 0.3.1.x should upgrade to 0.3.0.9 or 0.3.1.4-alpha when packages become available.  Packages should be available soon, along with a Tor Browser release early next week. 

One last reminder: Tor 0.2.4, 0.2.6, and 0.2.7 will no longer be supported after 1 August of this year.  Tor 0.2.8 will not be supported after 1 Jan of 2018.  Tor 0.2.5 will not be supported after 1 May of 2018.  If you need a release with long-term support, 0.2.9 is
what we recommend: we plan to support it until at least 1 Jan 2020.

This release also backports several other bugfixes from the 0.3.1.x series.

Changes in version 0.3.0.9 - 2017-06-29

  • Major bugfixes (path selection, security, backport from 0.3.1.4-alpha):    
    • When choosing which guard to use for a circuit, avoid the exit's family along with the exit itself. Previously, the new guard selection logic avoided the exit, but did not consider its family. Fixes bug 22753; bugfix on 0.3.0.1-alpha. Tracked as TROVE-2016- 006 and CVE-2017-0377.  
  • Major bugfixes (entry guards, backport from 0.3.1.1-alpha):  
    • Don't block bootstrapping when a primary bridge is offline and we can't get its descriptor. Fixes bug 22325; fixes one case of bug 21969; bugfix on 0.3.0.3-alpha.  

 

  • Major bugfixes (entry guards, backport from 0.3.1.4-alpha):    
    • When starting with an old consensus, do not add new entry guards unless the consensus is "reasonably live" (under 1 day old). Fixes one root cause of bug 22400; bugfix on 0.3.0.1-alpha.  
  • Minor features (geoip):    
    • Update geoip and geoip6 to the June 8 2017 Maxmind GeoLite2 Country database.  
  • Minor bugfixes (voting consistency, backport from 0.3.1.1-alpha):    
    • Reject version numbers with non-numeric prefixes (such as +, -, or whitespace). Disallowing whitespace prevents differential version parsing between POSIX-based and Windows platforms. Fixes bug 21507 and part of 21508; bugfix on 0.0.8pre1.  
  • Minor bugfixes (linux seccomp2 sandbox, backport from 0.3.1.4-alpha):    
    • Permit the fchmod system call, to avoid crashing on startup when starting with the seccomp2 sandbox and an unexpected set of permissions on the data directory or its contents. Fixes bug 22516; bugfix on 0.2.5.4-alpha.  
  • Minor bugfixes (defensive programming, backport from 0.3.1.4-alpha):  
    • Fix a memset() off the end of an array when packing cells. This bug should be harmless in practice, since the corrupted bytes are still in the same structure, and are always padding bytes, ignored, or immediately overwritten, depending on compiler behavior. Nevertheless, because the memset()'s purpose is to make sure that any other cell-handling bugs can't expose bytes to the network, we need to fix it. Fixes bug 22737; bugfix on 0.2.4.11-alpha. Fixes CID 1401591.  

Comments

Please note that the comment area below has been archived.

hunter2 (not verified) said:

June 29, 2017

Permalink

I would like some type of update process for which you may have the latest version of TBB, but a new version of Tor is released and you could choose to update Tor to the latest version within the current version of TBB, so you wouldn't have to wait X days or weeks in order to update to the latest version of TBB which has the latest version of Tor!

Just my 2 Lithuanian cents: If there's a version of Tor that has a serious bug for clients, they'll probably deploy a new release of the Tor Browser with the fix. But most of the time you don't need to always have a version more recent that the one that is bundled with your Tor Browser, so I don't think it would be worth the effort IMO.

A version release for one or more cosmetic or otherwise non-catastrophic bugs, is a violation of good SW process, as well as a waste of time and resources, including that of the user. Therefore zaps can be made available to the community for minor stuff, and releases reserved for level I and II faults, or when there have been enough zaps to warrant a major version push. It is, one may say, the unwritten rule of SW development, and just good sense.
luv

BUG or attack … (not verified) said:

June 29, 2017

Permalink

Since version 7.0 entry node (IP/Server) & country never changes! This behavior is still present in 7.0.1. All entry nodes are now only from US, UK, France, Netherlands & occasionally Germany. Previously (in 6.x and older) entry nodes from vastly more countries were used.

Description below (tested with a clean TOR Browser install):

A-TOR Browser
1-Entry NODE (eN)
2-Middle NODE (mN)
3-Exit NODE (xN)
B-Internet

Old behavior (6.x or older) New behavior (7.x)
New eN from a different country Same eN IP & from the same country
----------------------------------- -----------------------------------
New Identity
Restart Tor Browser
Close Tor browser, then start another session

New Tor Circuit does change the mN & xN in 7.x, just as it did in older versions.

The only way to change the eN IP/Server and geographic location/country is to do the following:
1- exit Tor Browser
2- navigate to folder TorBrowser/Data/Tor
3- delete all the cached-* & control_auth_cookie
4- start Tor Browser

After this the eN IP/Server changes to one from only a handful of five different countries (as listed above). But then again the eN IP will always be stuck no matter what is done, that is until I follow the four steps above & delete all the cached files.

Please fix this. I liked the old behavior (also seems more secure to me), where clicking New Identity or restarting the Tor Browser also changed the eN.

> Since version 7.0 entry node (IP/Server) & country never changes!

Tor has used a Guard (fixed entry node) for years.

> Please fix this. I liked the old behavior (also seems more secure to me), where clicking New Identity or restarting the Tor Browser also changed the eN.

It's not more secure, and is quite a bit worse by a long margin. And the old behavior that you describe, would have been a massive anonymity bug if it existed in the first place.

> BUG or attack

Bug confirmed! Tor never generates a new circuit or chooses a entry node when New Identity (Ctrl+Shift+U) is selected or the browser itself is relaunched.

> 3- delete all the cached-* & control_auth_cookie

Thank you Sir! Now I can at least change the entry node server/IP, but still confined to the same geographic region; all of the entry nodes I've gotten so far is in the UK.

I have been stuck with the same entry node the past few weeks and was quite worried that I have somehow messed up the settings. Glad to know it wasn't just me.

> Tor has used a Guard (fixed entry node) for years.

I am not (and I don't think the OP did either) disputing the fact that Tor uses the same entry node throughout a session, only that entry node never changes if New Identity is selected or if the browser itself is relaunched.

> Please read the relevant FAQ:
> https://www.torproject.org/docs/faq.html.en#EntryGuards

What does any of this have to do with New Identity (Ctrl+Shift+U) not generating a new circuit? All it does is change the middle and exit nodes, the same as New Tor Circuit for this site (Ctrl+Shift+L)?

If this is by design then why not get rid of the New Identity (Ctrl+Shift+U) menu option?

> It's not more secure, and is quite a bit worse by a long margin.

So changing the entry node every time Tor Browser starts or a session is started by clicking New Identity (Ctrl+Shift+U) is less secure?

Let's say 1.1.1.1 located in the UK, is my entry node. Now please explain how using this same server/IP as the entry node for a year or more is secure (as the entry node never changes)? Anyone able to trace you to this entry node (very easily done) will be able to collect a year worth of data passing through.

So now, how do I report this to a dev?

> If this is by design then why not get rid of the New Identity (Ctrl+Shift+U) menu option?

The New Identity button also discards the application-level browser stuff like cookies. It is essentially like restarting Tor Browser -- it flushes the browser state.

> Now please explain how using this same server/IP as the entry node for a year or more is secure

The very short version is at the FAQ entry people pointed you to:
https://www.torproject.org/docs/faq#EntryGuards

Here is the much longer version:
https://blog.torproject.org/blog/improving-tors-anonymity-changing-guar…

And in case that one doesn't convince you either, check out
https://petsymposium.org/2014/papers/Dingledine.pdf

buried alive (not verified) said:

June 30, 2017

Permalink

Torsocks, Torify...

Would it be so difficult to include one or both of these in TBB releases?

I'd also like to know how to configure WGET for use in TBB, whereas in Tails it's already setup.

For putting torsocks into tor browser, I think it's probably better to leave it as a separate tool. That's the unix way, after all, and also most people installing Tor Browser aren't going to ever notice it, and also there are fine torsocks packages for many platforms.

As for setting up your wget to use a socks proxy on port 9150, that sounds like a fine topic for a tor.stackexchange.com question (after you've checked to see if there is one already).

I <3 to bite myself (not verified) said:

July 03, 2017

Permalink

Searching stack exchange for anything requires the completion of a CAPTCHA, which never loads, because I refuse to allow JavaScript and I tighten the settings. Thanks anyway.

Anonymous (not verified) said:

June 30, 2017

Permalink

I fetched and upgraded tor from Tor's repository (hidden service) on Debian 9, stretch:

deb tor+http://sdscoq7snqtznauu.onion/torproject.org stretch main

and it's still version 0.2.9.11-1~deb9u1. Why not 3.0.x series? Or which version to be on apt's repositories is decided by Debian (not Tor Project), and they decide to still stick to 0.2.9??

Anonymous (not verified) said:

July 02, 2017

Permalink

Can we expect on update of the repository (to 0.3.x) soon or will it stick to 0.2.9.x forever?
Is there a way to install the latest stable version (0.3.0.9) with via package manager?
https://www.torproject.org/docs/debian only suggests 0.3.0.x-experimental, but I want 0.3.0.9 stable.

Download https://dist.torproject.org/tor-0.3.0.9.tar.gz
Extract the tar.gz
CD to the folder that you extracted the tar.gz to.
Use ./configure" command
Then use the "make" command
After that is finished use the "make install" command. And you now should have the latest version installed. You can get future versions from https://dist.torproject.org and you can also get the file signature there.

You get a bunch of great things from the deb package, like having it run as a separate user, having it drop its privileges properly, having logs plus log rotation, and having it set ulimit -n higher so if you configure it to be a relay it won't be broken.

If you want a Tor 0.3.0.x deb package, you can get it from:
https://www.torproject.org/docs/debian

Most people will be happier switching their deb repository, rather than doing the install manually from tarball.

Anonymous (not verified) said:

July 01, 2017

Permalink

Yep, exactly! Thank guys!

I can manually install the newest stable package (0.3.x) from the tarball if I want, can create the binary package (0.3.x_amd64.deb, for example) too. But as a "regular user", I still prefer to fetch and install/upgrade from the repositories for pretty some reasons, like:

+) Save time (quite a few minutes -- in normal cases, maybe more in unexpected situations)
+) Newest version may required [newer] libraries (especially when the program is pretty large, like hundreds of MB or GB). Upgrading the dependencies, however, may cause problems for other programs which still require the older versions of the libraries.
+) I would trust the Debian/TorProject guys on which version of Tor is the best to used, by using the one from the repository, unless I have very clear and specific reasons to pick a newer version.
+) etc.

Anonymous (not verified) said:

June 30, 2017

Permalink

Sorry for the off topic. When should I expect confirmation/rejection about the internship (bridge bw scanner)?

I don't know which Ubuntu PPA you mean, but I believe there are zero Ubuntu PPAs made by Tor people.

So if you want somebody to update their PPA, you should do something more direct than asking on here.

Looks like it fixes one issue, and it's not a security related issue?

I don't know what the Tor Browser folks are planning, but I wouldn't be surprised if the plan is to just wait until 52.3.

No, there is no Tor Browser update necessary for this issue. It's not clear yet whether we are affected by this problem. If so, we'll think about picking this up if we do a 7.0.3 before the usual security fix update which is planned for the first week in August.

Anonymous (not verified) said:

July 02, 2017

Permalink

What about Win32 expert bundle? And it is possible, finally, to build Win64 version in 2017?

The expert bundle should be available now. And, yes, we plan to have a 64bit Windows version for our alpha series at least in 2017. That included the whole browser and the expert bundle. So, stay tuned.

Tor Browser has nothing to do with systemd, so, no.

Tor isn't either, except if you are running a vulnerable systemd, in which case it's still the vulnerable systemd that is the problem. :)

Stay up to date with your system packages.

First, asking this question in a blog post about Tor is likely to never reach most Tor Browser people.

I'd suggest asking it on tor.stackexchange.com, where the answer will last longer.

In fact, I bet somebody already has, and can point to the answer here?

Anonymous (not verified) said:

July 04, 2017

Permalink

In fact, I bet somebody already has, and can point to the answer here?

Yes! Simple "LT" answer: Tor's design document explain this https://www.torproject.org/projects/torbrowser/design/#philosophy in the "5. No filters" section.

More compilcated answer: I should also mention that there's some disagreement between Tor people on this. See ticket 17569 for more discussion. One of the Tor Browser developers Edelstein said: "FWIW, I also like this idea. I think it will help improve privacy, security, performance, and usability."

Tails includes uBlock by default.

My 0.02 satoshis on this is that I'd like to see uBlock by default on the Tor Browser, this will improve performance, and besides that, some of the arguments made: 1) Mike Perry said that one of the reasons he didn't want to ship an ad-blocker was that it would give more incentive for Google to block Tor, but Google certainly does not block the Brave Browser, despite it blocking Google trackers, and using Tor with Google is already a big trouble, indicating that not blocking ads wont change the situation, 2) advertising made on sites to Tor users DOES NOT make sense, I'm from country X and I get an advertisement for a local product (apartment, yoga, ...) that is found only in country Y, they're just wasting money right? 3) Just because Tor Browser already provides strong protection against tracking does not mean other things that block trackers should'nt be added, the situation in the latter case will be much better than in the former.

Anyway, those were just my irrelevant 0.02 satoshis, I still think that they're doing the right choice by sticking to the Tor philosophy of providing true privacy by design without requiring fundamentally and intrinsically imperfect ways such as tracker blocking.

Another thing that is worth considering is adding an addon that bundle common CDN resources, such as Jquery ... sure Tor Browser already protects against them, but there will be a performance improvement. But that's another thing.

If you mean an ETA for the release of Tor 0.3.0.9, it was released when this blog post went up.

If you mean an ETA for a Tor Browser that includes this new Tor version, there is now one as of today (whew -- building Tor Browser is still way more effort than it ought to be).

Anonymous (not verified) said:

July 03, 2017

Permalink

!!!WARNING!!! Tor Browser and all VPN services seems blocked in Russia from today! !!!WARNING!!!

bb sweet anonymity.

Anonymous (not verified) said:

July 03, 2017

Permalink

I'm using Tor (client only) on Linux. According to man torrc, the options DisableAllSwap and Sandbox could enhance security of Tor, so they shouldn't harm security or anonymity in any way. Would you recommend me to enable them? Do these options have some drawbacks?

Feel free to set them! The Sandbox one might cause some surprise crashes, if Tor does something that the sandbox didn't expect (either accidentally, where a crash is bad, or maliciously, where a crash is good). The Sandbox feature is still experimental, so please experiment with it.

DisableAllSwap is probably also fine, except if you're running a relay and you don't have that much ram, in which case it will turn bad.

Let us know if you learn any lessons from trying them. :)

Anonymous (not verified) said:

July 04, 2017

Permalink

Which of two choices is more secure?
1. Using sandbox option in torrc
2. Creating restricted file structure in some directory and then running tor via command chroot pointing to this directory. Of course, chroot is called with option --userspec so after changing the root directory for tor process it drops privileges to a non-root user.

My 2 cents:

Actually, chroot was never intended to be security mechanism. It should be used to isolate non-malicious behavior, so you'll not damage main file system tree accidentally. It is in no way related to malicious behavior when application intentionally tries to get out of chroot. If you do have the last case, use either SELinux or virtual machines for forced isolation.

Anonymous (not verified) said:

July 04, 2017

Permalink

Thank you, Roger! I'll try these options.

The Sandbox one might cause some surprise crashes

The idea of crashes sounds suspicious. It wouldn't be good if core dump with all keys, chains, circuits and the list of visited sites is dumped somewhere on my hard drive, so it can be later found by forensic analysis...

DisableAllSwap is probably also fine, except if you're running a relay and you don't have that much ram, in which case it will turn bad.

I don't use swap on my hard drive anyway, so it shouldn't be a problem.

> The idea of crashes sounds suspicious.

What safe behavior is there, if the daemon is in a state where it is attempting system calls (or file system access) that aren't whitelisted. To be pedantic, the behavior in most cases is that the kernel will `SIGSYS` the daemon, with `SIGKILL` used in some cases.

> It wouldn't be good if core dump with all keys, chains, circuits and the list of visited sites is dumped somewhere on my hard drive, so it can be later found by forensic analysis...

Unless you configure it otherwise, the daemon does this: `prctl(PR_SET_DUMPABLE, 0);`

DisableAllSwap just calls mlockall(). It's totally pointless if you don't have a swap partition.

Anonymous (not verified) said:

July 05, 2017

Permalink

I don't know Linux internals so well. I'm using standard Debian jessie, and I never change preferences related to creation of core dumps. Am I right that core dumps in Debian are now disabled by default? At least, I never see core files on my system.

Anonymous (not verified) said:

July 04, 2017

Permalink

Let us know if you learn any lessons from trying them. :)

OK, my comment will be too minor, but still...

I don't map my real IP to my hostname, because... no any program on my PC needs it. It is configured as follows:

  1. # hostname<br />
  2. MYHOSTNAME<br />
  3. # cat /etc/hosts<br />
  4. 127.0.0.1       localhost<br />
  5. 127.0.1.1       MYHOSTNAME<br />
  6. # cat /etc/hostname<br />
  7. MYHOSTNAME

So, somehow MYHOSTNAME cannot be resolved, because 127.0.1.1 is not the IP on any of my network interfaces. Actually, man hostname tells that

  1. -i, --ip-address<br />
  2.   Display the network address(es) of the host name.<br />
  3.   Note that this works *only if the host  name can  be resolved.*<br />
  4.   Avoid using this option; use hostname --all-ip-addresses instead.

So, the situation when "the host name cannot be resolved" is treated as normal. Since Tor doesn't rely on any DNS system or hostnames, I expect that it doesn't need to mess up with my personal useless hostname. However, if sandbox is enabled, this error is printed:

  1. Jul 04 13:32:19.000 [notice] Tor 0.3.0.9 (git-xxxxxxxxxxxxxxxx) opening log file.<br />
  2. Jul 04 13:32:19.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.<br />
  3. Jul 04 13:32:19.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.<br />
  4. Jul 04 13:32:20.000 [notice] Bootstrapped 0%: Starting<br />
  5. Jul 04 13:32:21.000 [notice] Starting with guard context "default"<br />
  6. Jul 04 13:32:21.000 [notice] Bootstrapped 80%: Connecting to the Tor network<br />
  7. Jul 04 13:32:21.000 [notice] Opening Control listener on /var/run/tor/control<br />
  8. Jul 04 13:32:21.000 [notice] Bootstrapped 85%: Finishing handshake with first hop<br />
  9. Jul 04 13:32:22.000 [notice] Bootstrapped 90%: Establishing a Tor circuit<br />
  10. Jul 04 13:32:22.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.<br />
  11. Jul 04 13:32:22.000 [notice] Bootstrapped 100%: Done<br />
  12. Jul 04 13:34:20.000 [notice] New control connection opened.<br />
  13. Jul 04 13:34:21.000 [err] sandbox_getaddrinfo(): Bug: (Sandbox) failed to get address MYHOSTNAME! (on Tor 0.3.0.9)

Still, Tor works fine with this err. To avoid it I fixed my /etc/hosts to be

127.0.0.1 localhost MYHOSTNAME

which I think is also fine solution. Nevertheless, I cannot see why sandbox_getaddrinfo needs to be called by Tor.

Anonymous (not verified) said:

July 04, 2017

Permalink

Sorry, let me add this to my previous two comments.

The error with gethost address is observed only when I start tor-arm (immediately when tor-arm is started, with root permissions). NEWNYM command on ControlPort doesn't force Tor to produce this err. I mean, if tor-arm is not used, I cannot observe this tor log error (independently of the content of /etc/hosts and hostname).

If tor-arm is launched, the error in tor log is observed in all cases, including the case of original configuration (when hostname is resolved to fake 127.0.1.1) and full fix case (when hostname is mapped to my real IP in /etc/hosts). I don't know what tor-arm tweaks in tor process to force him to give this error...

HI EVERYBODY (not verified) said:

July 03, 2017

Permalink

One question, i have windows 64 bits, and always i had torborwser in 64bits, then since torbrowser 7 and 7.2 7.3
i have torbrowser 32bits, and i have afraid this is only with me,, then i ask. why not is verion 64bits???

Tor Browser has never been a 64bit application so far for Windows users. But we plan to provide it later this year in our alpha series. If everything works out as we hope it'll be available for stable users, too. Maybe already with Tor Browser 7.5 but latest with the switch to Tor Browser 8.

noEnglish (not verified) said:

July 04, 2017

Permalink

I found a bug
Option -> Privcay Tab -> Always use private browsing mode -> Keep until -> I close Tor Browser
Crash error

AnnA (not verified) said:

July 04, 2017

Permalink

Mac : For some 2-3 months Mac doesn't accept soft loaded from the net. One have to go through App Store, if it exists (Tor does not...), at costs...

Brandy (not verified) said:

July 04, 2017

Permalink

how do u set up bitcoin core to use tor?? before there was vidalia control panel but now the whole tor browser opens up... how u open tor without the torbrowser?? pls hlp

Anonymous (not verified) said:

July 04, 2017

Permalink

Sometimes I see concurrent simultaneous connections from my own IP to the same Guard node. So,

# netstat -apn | grep MY_IP

shows up to 4 different connections (they use different src ports and the same dst port) between my IP and my Guard node. Why tor needs to separate these TCP connections? Why one TCP connection between my IP and my Guard is not enough?

For what it is worth: We have blog posts specifically for Tor Browser releases. I guess your issue would fit in one of those pretty well. Just for the next time. :) To answer your question: I am not sure yet. Could you give me some steps to reproduce your problem? "not working without javascript" can mean many things...

Anonymous (not verified) said:

July 05, 2017

Permalink

""not working without javascript" can mean many things..."

Before, you can use the search form field on robtex without javascript on in TBB.
Now, without javascript the site is not able to work.
Before, you can choose between the old -good(-:- "answer" or the new
teeming design. Now you get nothing without javascript)-:.

Anonymous (not verified) said:

July 05, 2017

Permalink

It sounds like Tor faces the most serious problems in China. I'm wondering how Tor (Tor Browser) is working in China now: is it able to pass the Great Firewall, are Chinese able to use Tor and how difficult it is for them to use Tor from china, how effective does the Chinese Gov get in blocking Tor now (in comparison with in the past)??

(I post the questions here since the Tor Browser 7.0.2 post isn't allowed comments).

Anonymous (not verified) said:

July 05, 2017

Permalink

Thank you, pastly!

I thought the 7.0.2 release post doesn't allow comments :)

Anonymous (not verified) said:

July 05, 2017

Permalink

Could I restrict list of my Guard nodes by 1) excluding some countries or by 2) specifying the country I want to choose Guard from? I don't like the idea that most of Tor nodes are now located in Germany. It means that if your Guard is also in Germany, then very often all 3 nodes in the chain are from Germany. It sounds not good...

I know that there was discussion in tor project about path selection, like should different nodes correspond to different AS or not, and so on... But now, AFAIK, only nodes within 0.0.0.0/16 are excluded.

Another point is that Guard should be more trusted node than the others. I know that state adversary can use any hosting providers in the whole globe independently from its own country, but his abilities to monitor and analyze traffic are less restricted in its own country. E.g., in the case of NSA I wouldn't like the idea that my Guard is hosted in US. Moreover, in general, I don't think that it is good idea to choose Guard from your own country. As I understand, path selection should force adversary to make so many international collaborations between countries, that it makes the harm to anonymity mostly impractical.

Maybe I'm totally wrong, and my interaction with Guard selection cannot make things better.

Anonymous (not verified) said:

July 06, 2017

Permalink

Yes you can restrict your node selection.

I cannot see any simple way to restrict the choice of Guard nodes (except of manually specifying particular node I decide to choose). I don't want to use ExcludeNodes, because I'm OK with middleman nodes (and, probably, Exit nodes) from adversary countries.

Thirdtrytopost (not verified) said:

July 05, 2017

Permalink

Tails 3.01 uses TOR 0.3.0.9 but has a serious flaw. It leaks the http authentication to all web sites visited (a unique ID), so a user can easily be tracked.

Is this a flaw with Tails 3.01 or with TOR 0.3.0.9?

Well, it's not an issue with Tor, because Tor is just the underlying transport -- it does not understand or think about the bytes that it helps you send back and forth to websites.

So you should be looking at Tor Browser, which is also included in Tails.

But it sounds to me like you are misunderstanding something. http client auth is used at far fewer than "all" web sites, for starters.

Are you saying this because you actually found a bug? Or because you went to some "how safe am I" website and it told you to be scared of the phrase "http authentication"? If it's the former, please open a ticket at https://bugs.torproject.org/

joe (not verified) said:

July 16, 2017

Permalink

hi i cant connect to tor network i did what Ive done many times before with installing the tor program.
it seems like its about to connect but doesn't. can any one help

Anonymous (not verified) said:

July 27, 2017

Permalink

After upgrading from 0.2.9.xx to 0.3.0.xx (stable versions from torproject repo for debian) I noticed the following problem with tor client. If tor is not actively used during many hours, it fails to construct new circuits, but old circuits still can be used. I see from netstat that it has few new connections established, but getinfo circuits-status shows that no new circuits are constructed. Any application has connection timeout if I try to use it with tor. To fix the issue I have to restart my tor.

First time my "long live" old circuit was youtube. Next time it was XMPP connection. In both cases I had just one circuit. So, basically, I leave my tor running for night, but at morning it cannot make any new circuit. However, already established circuits continue to work. May it be some interference with ISP preferences? I don't know. But it looks like a tor problem, because according to netstat new connections are got established by tor.