[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

Tickets

Development
#1

T80

The Openssl s_client looks limited and can only do simple GET commands. It emulates a simple ssl clients and doesn’t allow tunneling through it. Debian freeze is a bummer and they likely won’t let exceptions through for curl.

Yet another option that can be added to the ticket is a SSL wrapping server. Titus is a minimalistic wrapper that is security minded. It was designed to isolate private keys of SSL connections to protect against heartbleed class of bugs. Curl couldn’t do that and its out of its scope anyway curl.haxx.se/mail/lib-2014-04/0109.html. Titus was featured in Red hat security blog and is available for Debian wheezy+ opsmate.com/titus/

T135

A solution is to make a list of whonix network facing libs then compare with alerts from Debian support package. Those that match can be called out in an alert. A whonixcheck module can handle it.

#2

Why not post this on the tracker?

#3

The forum is a good sorting area to avoid clutter. You can take what you like to the tracker and leave what you don’t.

Disclaimer I don’t know the guts of openssl and maybe it is possible but I don’t know how. Debian packagers may make an exception for curl but no way to know for sure without asking.

#4

I don’t think they make an exception so long after the freeze.

The Openssl s_client looks limited and can only do simple GET commands. It emulates a simple ssl clients and doesn't allow tunneling through it.
GET is sufficient. The open question is how to automate that tool. Make it somehow read from stdin. I failed using the usual way last time I tried.
Yet another option that can be added to the ticket is a SSL wrapping server. Titus is a minimalistic wrapper that is security minded. It was designed to isolate private keys of SSL connections to protect against heartbleed class of bugs
Does it support direct public key pinning?
Titus was featured in Red hat security blog and is available for Debian wheezy+ opsmate.com/titus/
Apparently not in Debian repository, which makes it very hard to use it.
T135

A solution is to make a list of whonix network facing libs then compare with alerts from Debian support package. Those that match can be called out in an alert. A whonixcheck module can handle it.


It’s also about self installed applications by the user.
#5

For the crypto pinning you can go down the python path.

I found a nice article on python crypto libraries, the differences between them and a section on pinning by creating your own CA and signing certs under it.
www.tomastouceda.com/2014/07/03/what-to-use-for-security-python-edition/

One of these crypto modules combined with Twisted-client and python-socksipy should be enough to make a curl alternative that does what you need in a memory safe way with the added bonus of PyPy. OONI’s Arturo was adding socks support to twisted a couple of years back. Socks support may be ready and you won’t need to use anything extra.

#6

T135

Then you will need to detect every network calling process and then run them against the support list.

A few ideas on how to do the first part


www.cyberciti.biz/faq/what-process-has-open-linux-port/

#7

Speaking of PyPy and seccomp.py, it would be interesting to see it used by Stem, Torbrowser-launcher and secure drop. Do other people in the Tor community know it exists?

#8

seccomp.py: very unlikely?
PyPy: unlikely?

Speaking of PyPy and seccomp.py, it would be interesting to see it used by Stem, Torbrowser-launcher and secure drop.
Sure.

See also:
https://www.whonix.org/forum/index.php/topic,663.msg6854.html#msg6854

#9

[quote=“mitm, post:6, topic:855”]T135

Then you will need to detect every network calling process and then run them against the support list.[/quote]
Sounds difficult.

[quote=“mitm, post:6, topic:855”]A few ideas on how to do the first part


www.cyberciti.biz/faq/what-process-has-open-linux-port/[/quote]
That supposes the binary is currently running and having a port opened or at least an open connection. Let’s suppose it’s about an rss reader, that fetches only some time, then it would only find that out by coincidence.

#10

Well its either that or making and maintaining a list of every Debian package that accesses the network. Its impossible because there are thousands of packages and you want to cover anything users might install from the repositories.

The monitoring daemon would be running constantly in the background so when a program occasionally accesses the network, it can detected.

Do you have any other ideas?

#11

When it makes a connection and is vulnerable, that could already be fatal.

Perhaps manually making head or tail of /usr/share/debian-security-support/security-support-ended and /usr/share/debian-security-support/security-support-limited and then baking it into whonixcheck as required.

#12

The support list is about software that won’t be maintained, not necessarily that a critical security bug exists.

Better to know at some point, than never, as it is the case now. Maintenance effort aside, its hard to figure out if some obscure program on that list uses the internet unless you test each one. An automated solution is more practical and accurate.

Running something like

netstat -antup
Monitor all (a) listening numeric (n) TCP (t) UDP (u) process §

Output redirected to file
Deduplicated with ask then grep -r REGEX result to compare and match with selection in Debian support list.

#13

A daemon won’t work here. Users can still install packages from stable even after months or even years they have been declared security unsupported. By the time they run for the first time, a Tor exit could already detect that (for example an rss client) and automatically mitm the request and exploit a known vulnerability. Just after that happened, the daemon would notice and report. By that time, the compromise could be already done.

#14

Its better to let it notify about all packages actually. Sometimes people could be using a document viewer or editor of some type to open untrusted files they grab off the internet. They may want to know about it and migrate to something else. Its best to provide all information to the user and let them make a choice than hiding important notifications from informed people to “protect” the less knowledgeable ones.

You can add a note to whonixcheck saying network facing programs deserve priority. Package names are self evident like pidgin.

#15

kde4libs in that list is pretty weird. Installing it debian-security-support default would report this. Then a zillion of users would ask in the forums about it. Even the harmless AppArmor warnings (https://www.whonix.org/wiki/Download#AppArmor_Warning_during_Boot) created loads of noise, even though documented.

How does the user benefit from knowing kde4libs is supposed to be used for trusted input only? check-support-status lists for kde4libs a bunch of libs that tells the user nothing.

#16

Then your curated list should cover local programs that are used to process untrusted data like any documents or files from outside. Thats important for all users.

How will your guidelines deal with dependencies of network facing software? Let’s say the database WordPress or mediawiki relies on. Even if its not directly visited by surfers its still is very much exposed to network attack.

I still recommend having an advanced raw view mode of the information for power users who are interested. As optional.

#17
I still recommend having an advanced raw view mode of the information for power users who are interested.
Who wants the raw data can use the raw `check-support-status`, no?
#18

Makes sense.

Any comments on the two other points in my last post?

#19

I don’t know yet.

Seems like a missing feature in the debian-security-support package:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776548

The right place to fix the limitations seems largely be the debian-security-support package.

#20

Updated ticket:
https://phabricator.whonix.org/T135

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]