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.
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.
You're thinking of HPKP and other certificate and key-pinning implementations. HSTS only enforces HTTPS, it does not prevent the usage of things like mitmproxy with custom roots added to your trust store.
The use of HSTS is a way to suggest to your clients that they use SSL for that domain - for all requests within a time span (which could be "forever").
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.
Debian, and most other distributions as well, verifies its updates for ages and doesn't need SSL to do that. There are some arguments for using HTTPS anyway, but preventing malware injection isn't one (unless your package manager is exploitable).
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.
If you're connecting to a clearnet site, you probably need HTTPS _more_ than on a standard connection - you _explicitly_ have a node between you and the site that you don't necessarily trust (see, e.g., https://nakedsecurity.sophos.com/2015/06/25/can-you-trust-to...).
This is the biggest misconception about Tor. Tor provides anonymity, but any node (EDIT: any exit node) can read what you're sending if it's not encrypted. You need both.
That's definitely not true if your endpoint you're talking to is an *.onion . A connection to an Onion is encrypted to the destination. That also means if you were running, say NodeRed with authentication, sending credentials "over the clear" (no SSL cert, because stupidity) it's not actually sent over the clear. It's encrypted to the public key relating to your onion address.
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.
I would still prefer https on a .onion. If tor itself is popped, then traffic can be routed or mirrored to another host. This has happened in a PoC and was fixed in a security update in one of the alpha releases. There are additional fixes required for HS that are coming.
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.
The CA/B Forum rules only allow EV certificates for .onion, so even if Let's Encrypt wanted they couldn't give out .onion certificates without getting that changed first.
Oh right, that is a good point. I suppose Digicert is the only option for now then.
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.
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.)
Indeed, I too would love to have SSL certs for .onions and not have to bend over with an Extended Payment... Err, Verification check.
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.
Those are interesting preferences and perspectives. I will set up a site to counter them from my perspective and experiences.
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.
Exactly, they have to pop my machine too. They can't just take control of the traffic in the middle, which absolutely can be done in Tor with enough gov controlled guard nodes, as the arms race of patching has proven.
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.
> They can't just take control of the traffic in the middle, which absolutely can be done in Tor with enough gov controlled guard nodes, as the arms race of patching has proven.
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
I think where we are having a disconnect is that what Matt posted works when Tor is working as expected. Software has bugs. Tor has not been an exception to this. I watch their change logs for alpha and there are often bugs that affect this overall concept. They are patched quickly, but Tor nodes are not forced to update, nor is there a safe way for them to do so.
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.
If you connect to a clearnet website, the clearnet website is fetched by the exit node. If it's not HTTPS, the exit node can change the website however it wants.
> you can stay anonymous while making sure anyone can read what you are sending.
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.
