Tor releases the Future of Darknet - Users still unsure about safety - Development Security Downloads Education | Andmp

This blog is mainly focused on Development, coding,technology and Security. Detailed analysis on most discussed topics on web plus Downloads and PDFs.Books and materials.

Breaking

ad

Post Top Ad

Saturday, 4 November 2017

Tor releases the Future of Darknet - Users still unsure about safety

Early this september Tor had released an official notification on its Official Blog.
 The alpha family(series) of it's VERSIONS rolled out had to be rolled back , not really that backwards but I noticed a major bug report on Tor on Hackerone that paid the Bug hunter a whopping bounty amount of 3000$ , that tops Tor's bounty slab and no wonders it was Tor's biggest blow , hit or whatever terms you might like to express it in.
  Keeping the story short , a bit of an insider one , this bounty, as per my communications with Hackerone and it's user turned out that this flaw had remote links to Tor's most famous ,among it's developers and hidden service operating pros , its STEM API.Consequently VERSIONS 7.0.8  ,see Tor 0.3.2.3-alpha is released, with small bugfixes had to be rolled back,revamped and fixed as soon as possible.
   Insider reports on the same flavoured, Tor has major loopholes in it's Security Protocol .Hops and Proxies went awry in the newer alpha releases forcing it's parent , Tor to withdraw , triage and release fixes and patches on existing ones while also revealing conspicuous erronities,oddities and security exceptions behind the back of the Guardian(Project).

Read this excerpts to understand the matter in detail _-

Tor 0.3.2.3-alpha is the third release in the 0.3.2 series. It fixes numerous small bugs in earlier versions of 0.3.2.x, and adds a new directory authority, Bastet.
You can download the source from the usual place on the website. Binary packages should be available soon, with an alpha Tor Browser likely some time in November.
Remember: This is an alpha release, and it's likely to have more bugs than usual. We hope that people will try it out to find and report bugs, though.

Changes In Version 0.3.2.3-Alpha - 2017-10-27

  • Directory authority changes:
    • Add "Bastet" as a ninth directory authority to the default list. Closes ticket 23910.
    • The directory authority "Longclaw" has changed its IP address. Closes ticket 23592.
  • Minor features (bridge):
    • Bridge relays can now set the BridgeDistribution config option to add a "bridge-distribution-request" line to their bridge descriptor, which tells BridgeDB how they'd like their bridge address to be given out. (Note that as of Oct 2017, BridgeDB does not yet implement this feature.) As a side benefit, this feature provides a way to distinguish bridge descriptors from non-bridge descriptors. Implements tickets 18329.

  • Minor features (client, entry guards):
    • Improve log messages when missing descriptors for primary guards. Resolves ticket 23670.
  • Minor features (geoip):
    • Update geoip and geoip6 to the October 4 2017 Maxmind GeoLite2 Country database.
  • Minor bugfixes (bridge):
    • Overwrite the bridge address earlier in the process of retrieving its descriptor, to make sure we reach it on the configured address. Fixes bug 20532; bugfix on 0.2.0.10-alpha.
  • Minor bugfixes (documentation):
    • Document better how to read gcov, and what our gcov postprocessing scripts do. Fixes bug 23739; bugfix on 0.2.9.1-alpha.
  • Minor bugfixes (entry guards):
    • Tor now updates its guard state when it reads a consensus regardless of whether it's missing descriptors. That makes tor use its primary guards to fetch descriptors in some edge cases where it would previously have used fallback directories. Fixes bug 23862; bugfix on 0.3.0.1-alpha.
  • Minor bugfixes (onion service client):
    • When handling multiple SOCKS request for the same .onion address, only fetch the service descriptor once.
    • When a descriptor fetch fails with a non-recoverable error, close all pending SOCKS requests for that .onion. Fixes bug 23653; bugfix on 0.3.2.1-alpha.
  • Minor bugfixes (onion service):
    • Always regenerate missing onion service public key files. Prior to this, if the public key was deleted from disk, it wouldn't get recreated. Fixes bug 23748; bugfix on 0.3.2.2-alpha. Patch from "cathugger".
    • Make sure that we have a usable ed25519 key when the intro point relay supports ed25519 link authentication. Fixes bug 24002; bugfix on 0.3.2.1-alpha.
  • Minor bugfixes (onion service, v2):
    • When reloading configured onion services, copy all information from the old service object. Previously, some data was omitted, causing delays in descriptor upload, and other bugs. Fixes bug 23790; bugfix on 0.2.1.9-alpha.
  • Minor bugfixes (memory safety, defensive programming):
    • Clear the target address when node_get_prim_orport() returns early. Fixes bug 23874; bugfix on 0.2.8.2-alpha.
  • Minor bugfixes (relay):
    • Avoid a BUG warning when receiving a dubious CREATE cell while an option transition is in progress. Fixes bug 23952; bugfix on 0.3.2.1-alpha.
  • Minor bugfixes (testing):
    • Adjust the GitLab CI configuration to more closely match that of Travis CI. Fixes bug 23757; bugfix on 0.3.2.2-alpha.
    • Prevent scripts/test/coverage from attempting to move gcov output to the root directory. Fixes bug 23741; bugfix on 0.2.5.1-alpha.
    • When running unit tests as root, skip a test that would fail because it expects a permissions error. This affects some continuous integration setups. Fixes bug 23758; bugfix on 0.3.2.2-alpha.
    • Stop unconditionally mirroring the tor repository in GitLab CI. This prevented developers from enabling GitLab CI on master. Fixes bug 23755; bugfix on 0.3.2.2-alpha.
    • Fix the onion service v3 descriptor decoding fuzzing to use the latest decoding API correctly. Fixes bug 21509; bugfix on 0.3.2.1-alpha.
  • Minor bugfixes (warnings):
    • When we get an HTTP request on a SOCKS port, tell the user about the new HTTPTunnelPort option. Previously, we would give a "Tor is not an HTTP Proxy" message, which stopped being true when HTTPTunnelPort was introduced. Fixes bug 23678; bugfix on 0.3.2.1-alpha.
Most of the bugs disclosed in the official reports' summary on their blog focuses on API based or Developer integrative exceptions that had been left in the base VERSIONS of the release .They are basically for Linux and Mac but Windows mostly was left untouched , not in focus for development .
       Mozilla Firefox too had it's own story of buggy instances ,often bad gateway error surfaced due to circuit jump TIMING prolongation,many a times breaking the flow through the relay nodes .
     Failure in establishing Database connection, if you have received this sort of an error from a hidden service,  and many such minor errors .
        The new version aims at improving its SOCKS proxy protocols and updating it's cipher suite to SHA3 and more modular versions of cryptographic algorithmic signatures .
       But , by far I have been noticing network and connection failures in he newer versions [Windows 10] of Tor .
   Have no idea what might have caused it because I being a heavy user of Tor and using it since '14 such issues hardly were there , even the Vidal is Control Panel now gives us the GUI controller feeling , it was a lot more easier to use , handle and create hidden services using Vidal is but Tor chose to discontinue it for unknown security reasons that were left irrationally reasoned .
Users have given a bitter response to Tor's post regarding it's alpha release  -
Check these excerpts of comments on Tor's blog post that reveal the amount of  suspicions and security concerns .


September 18, 2017
Permalink
Have you made some performances tests to compare curve to rsa? I bet the CPU consumption difference is significant.

September 18, 2017
Permalink
Woohoo! Finally something stable enough to have fun with V3 onion services :)
By the way an important question: how does making Tor fully multithreaded (many people and relays use 4 cores and even more including mobile users) fit in your future plans?

September 19, 2017
Permalink
When will they add measurements against traffic correlation attacks?

September 19, 2017
Permalink
KIST question: are there any changes for clients or this exclusively on the relay side code?


September 19, 2017
Permalink
congratulations
- what 's new about quantum resistance ?
- will the next TBB be update with all these new improvements ?

Regarding the TBB question: yes, the upcoming alpha will contain this new tor alpha release with all its improvements and new features.

September 19, 2017
Permalink
(experimental)
- does "KIST" work or is it a proof of concept ?
- SHA3 ! 25519 ! _ fantastic _
- does it mean that in a near future the onions site must be set with a 56 length ?
- could i set my o.s & my kernel with some of these features (e.g. TCP buffers) ?
-------------------------------------------------------------------------------------------------------------
- https-everywhere runs well with tor but is still broken on firefox.
- is it true that the relays are running with a google dns ?

> does "KIST" work or is it a proof of concept ?
KIST works and is in 0.3.2.1-alpha.
> does it mean that in a near future the onions site must be set with a 56 length
Legacy ("v2") are still the default type. Still the 16-char length addresses you're familiar with.
Legacy ("v2") onion services will still work for the foreseeable future, and will remain the default until this new codebase gets tested and hardened. Service operators who want to experiment with the new system can use the 'HiddenServiceVersion 3' torrc directive along with the regular onion service configuration options.
> could i set my o.s & my kernel with some of these features (e.g. TCP buffers)
Yes you can tweak low level stuff like that. But that's not what KIST does, it isn't how KIST works, and doesn't really have anything to do with Tor.
> is it true that the relays are running with a google dns
DNS only matters for exit relays.
The way DNS queries are resolved is up to the individual exit relay operator. SOME exit relays operators choose to use Google's public DNS service. Many don't.

September 19, 2017
Permalink
Does it exist yet a library, a cypher, an algorithm, a 'savoir-faire' for implementing quantum resistance on line ?
Is it so irrelevant or outside the scoop ?
KIST counts & dispatches (at least the result lol) but how-to be certain that data recollected are true ?
The more you add the more the count is false : it is the famous mathematics law of errors.
Is it not dangerous to built a system from scratch without a board/box dedicated ?
should not it be better if the relays & the users should use the same 'special Tor box/board' ?
Could tor be implemented in a ssd manufactured as a ram (a fake ddr but a real micro-harddisk) [or as an electronic component that i should insert in the mother card] that the user could set/update from a special program ?
The new laws , almost applied everywhere , say that even an usb-flash can be seized as soon as police can see it. Masked as a ddr_mini ssd, the user could plug it and be maybe more anonymized. I should prefer buy this 'special ssdram/ddr' than a tor box _ mini computer _ router _ .
Could it be in the kernel running like an ime friendly user element ? Should it be possible if ime should become opened to implemented tor inside the kernel as a function in the hands of the user ? Should not it be a monster doing the opposite (privacy/anonymity) that it should do : a layer against this invasive & destructive "insane curiosity" ?
Could nova file system improve the usage of tor ?

September 20, 2017
Permalink
Added new GETINFO targets "ip-to-country/{ipv4,ipv6}-available", so controllers can tell whether the geoip databases are loaded. Closes ticket 23237.
I'm sorry for my stupid question, but I need to use tor's geoIP in my scripts to decide which country each particular Tor node belongs to. I now use geoiplookup tool to map IP to country, but that relies on its own DB. I would like to use Tor's DB for GeoIP. How I can do that? Does this option gives me the result I need directly?

Sorry again, I understood answer to my question. Indeed, this option does exactly what I want! Now I use getinfo ip-to-country/X.X.X.X in my scripts, and it works fine. Thanks a lot for this improvement!

Improvement? Browser status bars getting throttled to death waiting for bizarre chained Url's? How does that relate to improvement? You have not got lost at jpg4.us.

September 20, 2017
Permalink
Any compile manual here? baniry is too late, always release with the TBB, but TBB release time is too long.

You'll have the next alpha with 0.3.2.1-alpha next week we are about to start building Tor Browser with it.

September 22, 2017
Permalink
So the new hidden services don't actually have any improvement that makes it harder to locate them.

So the new hidden services don't actually have any improvement that makes it harder to locate them.
My guess is that you have no idea on how important "Improved directory protocol, leaking much less information to directory servers" is, where the HSDir wont be able to gather and discover new onion services than before.

OP is right, harvesting is presence and has nothing to do with locating the known... attackers can still drop sybils as guards, start modulating their own test traffic to hs, eventually they get a pattern hit through guard to the onions IP.... game over.

September 23, 2017
Permalink
Since this mornig, saturday 23th september, TOR is very unstable and quit about each 10 minutes… I reload et I'm quite for another 10 minutes. I'm in France, I use Tor browser on Macintosh. When reloaded, TOR works fine, but there this problem anytime (almost 20 times today).
Has anybody experienced this problem ?


My problem, since saturday 23th is continuing. Approximately every ten minutes (more or less), a small window informs me that TOR has unexpectedly left.
This small window has two buttons, exit and restart. I click on "restart" and everything works normally again.
I use the last version of Tor browser on Mac OS X, Tor 7.0.5.


September 23, 2017
Permalink
I think that they have implemented guard pinning, layering, and rotation periods that make it harder for an attacker to move up the proxy chain to achieve a direct connection to the HS.
This basically means that the HSs' guards are themselves guarded by two layers of guards. Each layer having a different rotation period. Im unsure what the client side protections are aside from making end to end correlation more difficult.
It would be nice if the devs would elaborate on the new protections the new HS design affords its users on both ends. A thorough blog addressing this would be great. A video would be ideal.

No the vanguard proposal hasn't been implemented yet and it's a very difficult engineering undertaking.

September 29, 2017
Permalink
>SHA3
NSA-backed
>ECC
>NSA-backed
ooook....


October 10, 2017
Permalink
How to use Tor as a tunneled HTTP proxy? I added the HTTPTunnelPort statement in my torrc file to open a HTTP listen port. However, when I tried to use the proxy to visit some hidden services, "Saying: HTTP/1.0 405 Method Not Allowed" appeared in the notice log. It seemed that I can not use Tor as a HTTP proxy.


The response recieved from Tors user base . (Above)

No comments:

Post a Comment

Your Opinion is Our First Priority

Post Bottom Ad

Pages