MiM SSL-strip performed on tor exit-node / http:// only), why not blacklisted?

Using the Tor onion is frowned upon, because the frequent abuse of the anonymizing router service.
Users of such services will come under scrutiny and will find themselves often on gubberment blacklists or their meta-data analyzed.

Never have a tor exit-node yourself, if you wanna stay out of trouble.
Don’t do the crime, if you cannot do the time.

This exit-node was suspicious to say the least, again not blacklisted at BlutMagie: http://www.blutmagie.de/
Just what is seen blacklisted is a Kaspersky Lab node
inetnum: 37.221.171.232 - 37.221.171.239
netname: Kaspersky_Lab_Romania
descr: Kaspersky Lab Research TOR exit node
Kaspersky is not a promotor of the use of Tor, but outside that rather indifferent.

The exitnode IP to be blocked :
Czech Republic 94.23.173.249
The specific tor exit node in Roubaix seems indeed suspicious, like reported with force attacks via SSH: http://blackhat.directory/ip/94.23.173.249

French mail hackers active: http://botscout.com/ipcheck.htm?ip=94.23.173.249

Also other brute force attacks on Word Press and Magento CMS.
OVH SAS abuse taking place: hxtps://www.abuseipdb.com/check/94.23.173.249

IP should be blocked for MiM exit-node attacks (SSL-stripping), also Tor had problems with version 3.0 handling protection particular nodes. 8)

Whenever you have the need to use Tor or tails, follow the security instructions from experts, and be aware not to run javascript
and to use end-to-end encryption, still your anonymity and security cannot be fully guaranteed against for instance the snooping of certain state actors (three letter security services).

polonus (volunteer website security analyst and website error-hunter)

Why we have such a situation in the first place?
Well because Internet was developed without security, without session awareness or whatever other security implementations.

That is why we now keep patching and patching.

Security by design is more real, but you have to leave this “out-of-the-box and one-click-solution” thinking.

The browser should check a HSTS registration every time the browser opens up a website (so do not start from a read-only medium).

Read: http://www.radicalresearch.co.uk/lab/hstssupercookies/

Tor project writes

HSTS and HPKP supercookies

An extreme (but not impossible) attack to mount is the creation of HSTS supercookies. Since HSTS effectively stores one bit of information per domain name, an adversary in possession of numerous domains can use them to construct cookies based on stored HSTS state.

HPKP provides a mechanism for user tracking across domains as well. It allows abusing the requirement to provide a backup pin and the option to report a pin validation failure. In a tracking scenario every user gets a unique SHA-256 value serving as backup pin. This value is sent back after (deliberate) pin validation failures working in fact as a cookie.

Design Goal: HSTS and HPKP MUST be isolated to the URL bar domain.

Implementation Status: Currently, HSTS and HPKP state is both cleared by New Identity, but we don’t defend against the creation and usage of any of these supercookies between New Identity invocations.

Big Data analysis is going on and drag-net surveillance is coming everywhere.
This kind of protection may be needed and will be all there is left one day!

Even facebook has such a node, protecting facebook users against particular states/regimes,
that frown on their citizens using facebook: https://www.facebookcorewwwi.onion/

Think of threats with keyboard privacy (profiling through your typing sequences on the keyboard)
and other devious ways of further profiling and analyzing everything you do online.

Do not get startled when you see this for instance: https://amiunique.org

Info credits go to: Bitwiper, 'HSTS’Wiper, Neb Poorten. Thanks, folks. :wink:

polonus (volunteer website security analyst and website error-hunter)

To add this forum onto HSTS in Google Chrome, go to open “chrome://net-internals/#hsts

But be aware that Chrome also likes to added entries whenever you request a site over https.
This can be cleared from chrome://net-internals#hsts excluding the global Google maintained list

Example for this forum domain.

Added you get

Query domain

Input a domain name to query the current HSTS set:

Domain:
https://forum.avast.com/index.php
Query
Found:
static_sts_domain:
static_upgrade_mode: UNKNOWN
static_sts_include_subdomains:
static_sts_observed:
static_pkp_domain:
static_pkp_include_subdomains:
static_pkp_observed:
static_spki_hashes:
dynamic_sts_domain: https://forum.avast.com/index.php
dynamic_upgrade_mode: STRICT
dynamic_sts_include_subdomains: false
dynamic_sts_observed: 1499604675.150495
dynamic_pkp_domain:
dynamic_pkp_include_subdomains:
dynamic_pkp_observed:
dynamic_spki_hashes:

Info credits: Bitwiper & lauferek.

polonus (volunteer website security analyst and website error-hunter)

More reports on that IP:
Source of abuse, e.g. spam mailers, forum spam, and spam on tor exit node.
Consider:
https://www.stopforumspam.com/ipcheck/94.23.173.249
Report fraud via IP: https://www.maxmind.com/en/high-risk-ip-sample/94.23.173.249
Bulk spambot address: https://cleantalk.org/blacklists/94.23.173.249
Blacklisted by 20 websites: https://www.ip-finder.me/94.23.173.249/
Blocked spam tor exit node: https://www.webiron.com/abuse_feed/94.23.173.249
Interesting bulk list here: https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=94.23.173.249&port=80

So “look before you leap, folks!”

pol