Why does the Tor Browser Bundle ship with HTTPS Everywhere? Surely if you're connected through a Tor circuit, HTTPS provides no extra security?
Yes, the guy running the exit node can read the bytes that come in and out there. Tor anonymizes the origin of your traffic, and it makes sure to encrypt everything inside the Tor network, but it does not magically encrypt all traffic throughout the Internet.
This is why you should always use end-to-end encryption such as SSL for sensitive Internet connections.
```
Fortunately HTTPS adoption is much better now :)
It's HSTS what we need in 2018
Ive seen HSTS applied to things like Windows 10 updates, to prevent users from seeing what exactly your OS is sending to the mothership.
Ideally, we should be able to see exactly the content being exfiltrated, and choose to allow/disallow. But the moment we use tools like ettercap or mitmssl, it kills the session and we can't see the data.
HSTS seems more "self cutting" than useful at this juncture.
If anything, the vendors you mention should be applauded for taking that step towards a more secure distribution of updates. Not enforcing SSL makes malware injection through updates way way easier.
Debian introduced HTTPS repos a while back as an option, but not by default. Other distros already offer it.
Otherwise go ahead and disable DEP, ASLR, and other modern defense in depth and mitigations mechanisms used by Debian, of course, unless your OS is exploitable.
Now, if you're using Public Internet->Tor->Public Internet, then absolutely yes the last node CAN read the contents of your packets. In that case, you absolutely need appropriate encryption to hide the contents (sigh, not the metadata) of your packets.
If the target is using https, you can see if the signature changes (there are addons for this).
Digicert will sign .onion domains, though the hidden site must be willing to share their identity with Digicert. I would love to see LetsEncrypt sign .onion domains, assuming they are willing to connect back to a .onion to validate the server.
Perhaps the Tor team or an affiliate could set up a simplified CA and have a public CA cert restricted to .onion that folks could install as a work around to having browsers trust it by default.
https://cabforum.org/pipermail/public/2017-November/thread.h...
Since then Fotis Loukos and I have drafted a ballot, which I believe he plans to introduce soon after asking a few other organizations to look it over.
You can subscribe to the cabfpub mailing list without becoming an Interested Party or Member. Only Interested Parties or Members can post to the list, while only Members can introduce or vote on ballots.
(Edit: Strangely, the reason for this is seemingly not that they're worried that the general public will make crazy suggestions, but rather that the general public will make patented suggestions, without being willing to license them according to the Forum's patent policy, and thereby sneak patented technology into the standards.)
I thought about setting up boulder on tor, and start rolling it myself. But then again who'd trust me? This should be part of the Tor organization. I can't see my own system getting inertia, or put into TBB, or Firefox for that matter. It was hard enough for LE to be put in trusted CAs on machines.
To summarize, you are a dissident. I am a news reporter. You are giving me information about your government. Your life and the lives of your family members now depend 100% on the security of the Tor Proxy transport. Tor is a proxy transport and nothing more.
As a dissident, you have been trained by me to install addons that validate the signature of my HTTPS certs will not change. I also showed you how to do this using openssl s_client. When Tor is popped and routing you to your government hosts, you will see the SSL signature change. Per my instructions, you will cease all communication with me.
Without HTTPS, you are relying entirely on the transport for assurance of who you are talking to. This is neither appropriate nor acceptable for this type of communication.
PGP is not a mitigating control, because the handshake has completed and you are now downloading your state sponsored rootkit. It's too late by that point. The only thing we have to validate ID and allow or block application traffic is a certificate.
That's not the case, even with a SecureDrop setup, a Gov can compromise your SecureDrop machine and listen directly.
I can set up multiple canaries that they will have to pop and the fingerprint of one of those canaries is going to change or drop off the net.
I think you're misunderstanding something here, with onion services traffic is e2e encrypted and self-authenticated, as Matt explains:
> When you connect to an onion service, how do you know no one is MitM'ing you? Easy. It's impossible. The bad guy would have to be in your browser (more accurately: between the browser part of Tor Browser and the Tor process it runs in the background) or between the Tor process the onion service operator is running and the webserver it's pointing at. If you assume your Tor Browser hasn't been compromised, and you assume the onion service is being run intelligently, then a MitM attack is impossible. (And if the onion service isn't being run intelligently, can you really trust its operator to do HTTPS intelligently?) > > https://matt.traudt.xyz/posts/dont-https-your-o44SnkW2.html
My point is that is a single point of success. Any other web service I would cut some slack. In the case of Tor, it is marketed as a means by which dissidents may communicate safely. Putting peoples lives on a single point of success is not appropriate, especially when there are technical means to mitigate the risk.
you can stay anonymous while making sure anyone can read what you are sending.
you can send confidential messages while making sure anyone knows who you are.
you can also combine the two :)
That depends a lot on what you're sending. Tor stops people from identifying you based on your IP address, but you can still identify yourself by logging in on http://not-encrypted.com.