I think I found the topic you're paraphrasing which explains the limitations of HSTS:

Great research! Now this needs to be documented.

HSTS is a server side opt-in standard meaning it can fail silently if the user does not force a request to use SSL. So its useless by itself.

Could you work on this one please? @HulaHoop

add --remote-name so scurl can be used as wget replacement
https://github.com/Whonix/scurl/commit/9006429ff7f9f39ff4dc367848ff45b690957881

Could you work on this one please? @HulaHoop

Finally got back to Tariq.

No :)

Great! Anything else to do here?

https://www.whonix.org/w/index.php?title=Hidden_Services&diff=prev&oldid=28910

Talked to Tariq.

Roger mailed Tariq. Now waiting for Tariq's reply.

Not easy. Need to wait for reply from TPO.

add option to not modify firewall rules
https://github.com/leapcode/bitmask_client/issues/1021

vpnprocess.py error
https://github.com/leapcode/bitmask_client/issues/1020

Part 1 is now documented.

Mailed Roger.

https://www.whonix.org/w/index.php?title=Desktop&diff=prev&oldid=27954

This was done by @TNTBOMBOM:

Calling this a duplicate of T118.

run this from .bashrc

Calling this done.

Talked to Roger Dingledine in person of Tor at 33c3 ccc conference. The short summary is, Roger also doesn't know what the advisable trade-off for our [single-gw multiple-ws vs multiple-gw multiple-ws mapped 1:1](https://lists.torproject.org/pipermail/tor-dev/2016-December/011720.html) question is.

Let me know the title and place and I'll put something up.

sent:
https://lists.torproject.org/pipermail/tor-dev/2016-December/011720.html

Go for it.

I think we should post the long draft. I am not convinced, they are offended by longer mails / complexity. That wiki page shows, that we considered each of their sentences and made an effort to reflect on it before asking more questions.

Done. Feel free to discuss it further before posting if needed.

Is https://www.whonix.org/w/index.php?title=Dev%2FMultiple_Whonix-Workstations&type=revision&diff=26455&oldid=26415 in progress or done?

In T567#10844, @HulaHoop wrote:

Good in principle however I want to avoid confusion.

multi-gw multi-ws -> single-g/ws 1:1

single-gw with multi-ws while recommending against running multiple VMs for activities of different trust levels / pseudonyms at the same time

Is this the setup I describe where a single ws is rolledback between different activities? If yes then this should be better described.

Good in principle however I want to avoid confusion.

Draft ready. Please check/edit.

In T567#10795, @HulaHoop wrote:

OK. I'll think of something but its better if you post so he doesn't get impatient.

Before rushing such a major usability decreasing change, I want to make sure it is really well justified and we are not chasing a ghost.

Before rushing such a major usability decreasing change, I want to make
sure it is really well justified and we are not chasing a ghost.

I will post the new usage advice on the KVM page because some applies for a simple setup.

HulaHoop (HulaHoop):

HulaHoop added a comment.

For multi-gw setups it might be theoretically an option to have
them manually use the same Tor entry guard?

The solution is much simpler than you imagine. A user would simply
clone the original GW VM after its started and chosen its guard so
they have the same one.

For multi-gw setups it might be theoretically an option to have them manually use the same Tor entry guard?

HulaHoop (HulaHoop):

HulaHoop added a comment.

Nice. The Tor guys took notice.

ontopic: While DNS and HS desc caching is one of the things. The original reply implies there are still many other problems - some known and possibly some unknown unknowns. To be absolutely safe we should still recommend for multi-setup with gw snapshots as a catch-all. Inconvenient? yes but better safe than sorry.

> - Caching of DNS, HS descriptors, preemptive circuits, etc.
> - VMs can leak other VM's guards and even entire circuits
>   - easily without a control port filter
>   - perhaps some discovery attacks even with a filter

TASK DETAIL

https://phabricator.whonix.org/T567

EMAIL PREFERENCES

https://phabricator.whonix.org/settings/panel/emailpreferences/

To: HulaHoop
Cc: Patrick, WhonixQubes, entr0py, HulaHoop

Nice. The Tor guys took notice.

Posted:
https://trac.torproject.org/projects/tor/ticket/20555

Good write-up

stream isolation for DNS and hidden service descriptor cache

HulaHoop (HulaHoop):

HulaHoop added a comment.

Another reply:

https://lists.torproject.org/pipermail/tor-dev/2016-October/011613.html

Another reply:

In T567#10782, @HulaHoop wrote:

I would prefer if you post these questions on tor developer ML since you understand the topic better and it is an important thing we need to know.

I would prefer if you post these questions on tor developer ML since you understand the topic better and it is an important thing we need to know.

Thanks for the feedback!

The other option would be to present INFO every time a wrapped command is invoked, but that would probably be too intrusive for anyone other than occasional terminal users.

Could you please add all of these pros and cons to that wiki page? Or some /Dev page if too irrelevant for users?

HulaHoop (HulaHoop):

gateways cache DNS entries and descriptors of HS websites visited
which can give away that they were visited before (because of faster
site loading response) even if a single WS is used and is rolled back
to a clean snapshot.

Could you please add all of these pros and cons to that wiki page? Or
some /Dev page if too irrelevant for users?

Got an answer: https://lists.torproject.org/pipermail/tor-dev/2016-October/011591.html

Thanks, great!

https://lists.torproject.org/pipermail/tor-dev/2016-October/011590.html

Yes, that seems useful. Please also add the pros and cons we discussed
above.

I wonder how non-long lived, new connections would be trackable by malicious newnym patterns?

Interesting thought!

I thought of something else. Using a single Gateway can link activities of two different Workstations even if they are on separate internal networks because the malicious WS can send NEWNYMs in som pattern which causes the traffic coming from the other clean WS to change exits at will. So while the identity of the user is not unmasked the entire purpose of the setup (multiple unlinked identities) is defeated.

Ideally for usability after the user run into some torsocks warning message, a tooltip or konsole message would offer help. But I don't think terminals support that feature.

vailla Debian 8 same result. After reading about similar setups I think there is more needed to get this working:

https://github.com/Whonix/anon-meta-packages/commit/4385dbdd54f68b0855cbc20574b9faa2d2f8a83e

I'd replicate this setup using plain Debian first. Multi ws's that are
connected to one gw using multiple internal network interfaces. The ws's
should not be able to reach clearnet [no ip forwarding in Linux by
default] but you should be able to ping the gateway from the ws since no
Whonix stuff (no firewall) interferes.

Any ideas for what else I can try?

HulaHoop (HulaHoop):

Not worth the effort when an extra GW solves the problem and runs with very little resources.

The firewall works as expected according to xtrace. So we can conclude its something else. Probably too difficult to find out. Not worth the effort when an extra GW solves the problem and runs with very little resources.

Did not notice this answer before making my first answer.

HulaHoop (HulaHoop):

HulaHoop added a comment.

I didn't mean running everybody as a relay by default. That would be a bad idea because:

Oh I see. It is already documented. My bad. closing

I didn't mean running everybody as a relay by default. That would be a bad idea because:

0. Check with TPO if this is a good idea at all.

Hosting a (private) (obfuscated) bridge or (exit) relay

HulaHoop (HulaHoop):

HulaHoop added a comment.

I tried testing this by creating a second internal network connected ot the GW. And it does not seem to work though I'm sure with a bit of troubleshooting it will get there.

Some points:

- Its 50_user no .conf - the ending creates a second file.