Just a note, it all depends on your threat model. Be careful that most of the 
solutions you explained have each very different implications:
1) Most website with a login do have https. If they are hidden services they do 
not need it as traffic does not go through an exit node. If none of the above 
apply you could still use a VPN or a tunnel on top of tor but you will loose 
some anonimity

2) Which type of files are you talking about? If we are not talking about 
executables (i hope not) then Qubes do have disposable vms which should prevent 
an attacker from accessing sensitive files or gaining persistance. Also even 
for attacking the disposable vm the attacker would need an exploit for a reader 
software (evince, libreoffice etc).

3) Not using tor in order to download files prevent only man in the middles 
attack coming from the tor network, your provider, your neighbors, your dns 
server etc may still tricks you the same way.

As a general rule, mixing any of your tor activities with your non tor 
activities do break the very purpose of tor, especially if you use the same 
accounts in and out. My suggestion is to first try to understand what the 
purpose of tor is and against which type of adversary you need protection and 
then make your choices on that basis.

Giulio

On April 4, 2018 1:23:56 AM GMT+02:00, "js...@riseup.net" <js...@riseup.net> 
wrote:
>Hi everyone,
>
>I've been thinking about ways i can increase security when using tor in
>a whonix vm, and i had a few questions about the security risks of
>browsing/downloading files over http.
>
>I've looked up some info about it and i know it presents a security
>risk, but i don't really know what i'm talking about so i thought i'd
>ask you guys. Please let me know if i'm wrong about anything here
>(which
>is likely!) Sorry this is so long!
>
>Anyways, let's say i want to use a site that doesn't use https (http
>only) that i can do 3 things on:
>
>1. general browsing/reading content
>2. download small files
>3. log into an account, which is required to download large files
>
>I'm browsing the site in a relatively unsecure vm that i don't
>necessarily care much about, but i'll probably want to move some of the
>files to another vm to use elsewhere, or to a usb stick to transfer to
>another machine.
>
>If i use the site over tor, the exit node operator can read all the
>unencrypted traffic, and possibly maliciously modify files downloaded,
>which is why it's recommended to always use https when possible over
>tor. Qubes helps with this since i can do all my browsing on the site
>in
>a separate vm, but there's still a security risk especially if i
>transfer files elsewhere.
>
>It seems to me that i basically have 4 options:
>
>1. Do everything over tor, including downloading files and logging into
>the account. This is bad because the exit node operator can see my
>username/password, and i don't think there's any way of really reducing
>the risk from this.
>
>2. Browse the site and download small files (without logging in) over
>tor, but use a non-tor VM to log into the account to download larger
>files. This is better than option 1 because exit node operators never
>see me log into the account, but still presents a security risk because
>they can maliciously modify files i download.
>
>It seems to me that exit node operators doing something like this
>(modifying files downloaded over http to compromise my vm) is something
>that would have to be done manually, in real time, but please let me
>know if i'm wrong about that! I also don't know how likely this is to
>actually happen.
>
>But it seems to me that a way to reduce the risk here is to use the
>"get
>a new tor circuit" option right before downloading the file. That way
>the new exit node operator would have not much warning/time to do
>something bad before i download the file. Would that help?
>
>3. Do general browsing in tor, but download all files outside of tor.
>This is better than option 2 from a security standpoint because i'm not
>downloading files in a risky way over tor that will then be transfered
>elsewhere, and if the vm i'm browsing the site in using tor gets
>compromised, i don't really care. But it's a pain to have to switch to
>a
>non-tor vm every time to download a file (and i know it's recommended
>not to have tor and non-tor connections to the same site at the same
>time).
>
>4. Do everything on the site outside of tor because the site doesn't
>support https. This is best from a security perspective, but worst from
>a privacy/anonymity perspective because i can't use tor to browse the
>site.
>
>If i really wanted to only use https over tor, i could enable the
>"block
>http connections" option in https everywhere, but couldn't this
>increase
>fingerprintability of browser since most tor users don't block http
>connections? The same reason it's recommended not to use additional
>browser plugins in tor browser.
>
>What do you guys think is the best way to go about it? Am i wrong about
>anything here or missing something?
>
>I know this may be too long to read, sorry!
>
>-Jackie
>
>-- 
>You received this message because you are subscribed to the Google
>Groups "qubes-users" group.
>To unsubscribe from this group and stop receiving emails from it, send
>an email to qubes-users+unsubscr...@googlegroups.com.
>To post to this group, send email to qubes-users@googlegroups.com.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/qubes-users/3d12c7d6-4b38-4356-9f80-fa749db2280b%40riseup.net.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7EA01E86-E96F-4790-9547-E5A0C2CDF49C%40anche.no.
For more options, visit https://groups.google.com/d/optout.

Reply via email to