Yes its better to reference intrigeri.
Change to “arrange for hosting a hidden Debian mirror for access by Whonix and any other anonymous OS that is interested”
If you don’t like it just take out any references to who will want to use it.
You might be interested to know that The Update Framework is know what putting out code for their securr update platform.
[quote=“mitm, post:42, topic:855”]You might be interested to know that The Update Framework is know what putting out code for their securr update platform.
https://github.com/theupdateframework[/quote]
I am aware of TUF and in contact with them. See,
A fantastic new development has happened in Tor 0.2.6. Alpha
I will go into what it means for different parts of Whonix and where to go from here. I’m putting it out there and you do what you like.
“Tor’s consensus lists Torbrowser updates”
Applicable to whonixcheck and tbb-updater.
The tbb version in the consensus can be checked by a similar variant of the Consensus based clock sanity check. Except this time you will be parsing the version number and hash of the most current tbb package.
Other great options stemming from this upstream ticket is to propose in the future the broadcast of version information for Tor IM Bundle when it debuts in the same way so tbb-updater and other managers can take advantage of this more reliable and secure way of learning about Tor based software.
If you go one step further and direct tbb-launcher to only download from Thomas’s hidden mirror, that solves the lack of SSL pinning of the Tor Projects’s site for this component. You won’t have to worry about serious breakage of tbb-updater ever again even when the Tor site’s self signrd certificate changes after pinning is implemented.
After looking through all the extra work you would need to mask Micah’s tbb-launcher to use its certificate, I conclude it’s much easier if you manually embed it into your code and maintain it that way.
If the above is implemented, the only part of whonix that will depend on the cert is the the request to check.torproject.org.
Worst case, that will be the only part breaking because of upstream lapses in cert maintaince but its not as bad as tbb-updater breaking down.
An unlikely solution without the Tor Project’s support is for them to deploy TUF repositories as an update method.
Even if it never happens, the comment above lays ground for a rock solid secure way to know about updates and downloading them.
[quote=“mitm, post:47, topic:855”]What will you do about the pure evil that is 32bit gpg key ids?
https://evil32.com[/quote]
I think there is no more action required. They’re used nowhere in Whonix’s code. All the signing keys that come with Whonix (Whonix ™ Source Code Introduction) are obtained using full fingerprints and verified using the web of trust. And if I know some software to use gpg, I check if they use gpg short key ids and do a short audit of their gpg usage. Also if those are not part of Whonix. I report it if necessary. (Example: apt-key adv command in dockerfile might be unsafe · Issue #4 · trezor/trezor-mcu · GitHub)
Awesome.
Any comments on my latest couple of posts? Are they rejected or still under consideration?
[quote=“mitm, post:44, topic:855”]A fantastic new development has happened in Tor 0.2.6. Alpha
“Tor’s consensus lists Torbrowser updates”
Applicable to whonixcheck and tbb-updater.
The tbb version in the consensus can be checked by a similar variant of the Consensus based clock sanity check. Except this time you will be parsing the version number and hash of the most current tbb package.[/quote]
Created ⚓ T161 use 'getinfo consensus/packages' rather than RecommendedTBBVersions for it.
Other great options stemming from this upstream ticket is to propose in the future the broadcast of version information for Tor IM Bundle when it debuts in the same way so tbb-updater and other managers can take advantage of this more reliable and secure way of learning about Tor based software.Suggested here: https://trac.torproject.org/projects/tor/ticket/14388#comment:2
If you go one step further and direct tbb-launcher to only download from Thomas's hidden mirror, that solves the lack of SSL pinning of the Tor Projects's site for this component. You won't have to worry about serious breakage of tbb-updater ever again even when the Tor site's self signrd certificate changes after pinning is implemented.Sadly, the internet [no one claims so] has no mechanism to securely feed mirrors. Mirrors themselves are updated using unauthenticated rsync. So downloading from a super secure mirror, while the mirror downloaded unauthenticated, makes no improvement. (Uploads the the master mirror are mostly rsync over ssh, I hope.) Yet another piece of missing security infrastructure on the internet that adds up to the huge backlog.
[quote=“mitm, post:45, topic:855”]After looking through all the extra work you would need to mask Micah’s tbb-launcher to use its certificate, I conclude it’s much easier if you manually embed it into your code and maintain it that way.
If the above is implemented, the only part of whonix that will depend on the cert is the the request to check.torproject.org.
Worst case, that will be the only part breaking because of upstream lapses in cert maintaince but its not as bad as tbb-updater breaking down.[/quote]
The torbrowser-launcher is also not necessarily fast updated.
Mirror security depends on the definition of security the threat model. Package authenticity is not mirror dependent of course because package signatures and the consensus update information take care of that. Even if the packages on the mirror have been rigged it will be discovered.
My suggestion for using a hidden mirror is for that extra bit of protection against traffic analysis and traffic tampering. Unless Thomas’s server is popped connecting to it is better than using something with no strong end to end authencation aka regular SSL.
You might be interested in following this feature coming to Tor. I don’t know how safe to have in Whonix’s model. It might fit projects like Ricochet IM to make it work better with Whonix.
Ephemeral Hidden Services via the Control Port
https://lists.torproject.org/pipermail/tor-dev/2015-February/008279.html
Adding hidden services through control socket
I don’t foresee security issues with it. Users could add a cpfpy snippet to add it to the whitelist.
The following is problematic with the cpfpy implementation.
* meejah suggested that ephemeral hidden services should have their lifetime tied to the originating control port connection. I think this is a good idea, but this would be the only control port command that does this sort of thing.
Because for now cpfpy throws commands at Tor and relays back Tor’s answer. It does not keep that control connection open. We discussed this in the cpfpy thread somewhere (Whonix Forum). (We discussed it in a different context: the current inability to register to ControlPort events/callbacks, but this is very similar.)
Will be some time until this lands in Tor stable and applications starting to use it. If we manage to add this feature to cpfpy, this feature could improve usability of hidden services, because then much fewer settings would be required to manually apply on the gateway.
T192
Sounds like a good workaround. There is a project Micah is working on to help Tor dependent packages to work in the VM model.
If it makes sense for what this ticket, you can collaborate on a single solution to avoid duplication of effort.
Sounds good.
The proposed repository naming scheme is confusing with stable-testing vs testing. Why not emulate Debian’s naming conventions and stability levels?
They would be easy to recognize for any regular Linux user as for what to expect when choosing.
Thanks for your feedback.
The two distributions don’t compare. Debian is a much bigger distribution. Much more maintainers with strong social ties. Dedicated release team and whatnot.
testing vs testers: Debian testing is used by a lot as rolling distribution replacement. “Real” Debian testers use Debian “unstable”. Few regular users do, but most Debian package maintainers run such a machine or VM somewhere, since they need it for development.
To be on par with Debian, the repository would need to be named “stable-proposed-updates”. Is that name any more clear?
proposed-updates:
https://www.debian.org/releases/proposed-updates.html
https://wiki.debian.org/StableProposedUpdates
Ever heard about that? Not very popular, no?
To make confusion perfect, there is also a separate Debian “StableUpdates” repository:
https://wiki.debian.org/StableUpdates
I had not heard about stable-proposed-updates before but the name makes things more clear.
‘IsolateDestAddr and IsolateDestPort’ discussion split: