Tor onion services for KDE websites
Open, NormalPublic

Description

This would allow KDE sites to be reached without reaching the tor network. While onion services can be used to conceal the network location of the machine providing the service, this is not the goal here. Instead, we use onion services because they provide end-to-end integrity and confidentiality, and they authenticate the onion service end point.

For instance, when users connect to the onion service running at http://sejnfjrq6szgca7v.onion/ (Debian's onion service), using a Tor-enabled browser such as the Tor Browser, they can be certain that their connection to the Debian website cannot be read or modified by third parties, and that the website that they are visiting is indeed the Debian website. In a sense, this is similar to what using HTTPS provides. However, crucially, onion services do not rely on third-party certification authorities (CAs). Instead, the onion service name cryptographically authenticates its cryptographic key.

A lot of people mistakenly believe that Tor Onion Networking is "all about anonymity" - which is incorrect, since it also includes:

  • extra privacy
  • identity/surety of to whom you are connected
  • freedom from oversight/network surveillance
  • anti-blocking, and...
  • enhanced integrity/tamperproofing

...none of which are the same as "anonymity", but all of which are valuable qualities to add to communications.

Links:
https://github.com/alecmuffett/eotk
https://www.torproject.org/docs/onion-services
https://bits.debian.org/2016/08/debian-and-tor-services-available-as-onion-services.html

lavender created this task.May 23 2018, 3:35 PM
lavender added a parent task: T7050: Privacy Software.

What's the status on this?

Restricted Application added a subscriber: sysadmin. · View Herald TranscriptJun 15 2019, 9:05 PM

This would allow KDE sites to be reached without reaching the tor network.

Without leaving the Tor network you mean.


I think there is no harm in doing this but I also think there is hardly any benefit.
The advantages of this are nearly completly theoretical: Connecting through Tor to any KDE webpage using HTTPS will have nearly all the benefits of KDE running their own onion service. You cited the only advantage Peter Palfrader of Debian stated for their decision to do this:

onion services do not rely on third-party certification authorities

The point is: As long as we trust the certification authorities (which have been doing a good job aside from smaller mishaps) there is no gain at all.

I wrote a seminar paper and held a presentation about the Darknet so if there are any more questions concerning Tor and/or this task I can probably help.

bcooksley closed this task as Wontfix.Jun 15 2019, 11:03 PM
bcooksley claimed this task.
bcooksley added a subscriber: bcooksley.

Myself and another Sysadmin have discussed this issue.

In our case providing access to our services directly over .onion addresses is simply not practical, due to the sheer number of subdomains we operate (see https://cgit.kde.org/sysadmin/dns.git/tree/zones/kde.org.zone for a list of most of them, due to other domains being used it isn't everything though)

Additionally, it's very common for our sites to refer to other sites within the KDE.org family of websites, including for things such as CSS, Javascript, Videos and other resources needed for displaying the page (we serve these resources from a CDN in many cases to optimise page loads and site performance). Accessing our sites over Tor would therefore be extremely leaky (from a pure .onion access perspective)

Based on the comments by Felix above in combination with the below we don't think it's worth pursuing providing native .onion access to our websites at this stage as there is no real benefit, but there is a large cost (both in terms of on-going Sysadmin time to support the infrastructural side and for people contributing to our websites who need to maintain/work with code to handle the CDN differences, as well as the initial effort to figure out how to handle things such as our CDN services in a .onion context)

Would have liked to hear some of the discussion as this has been sitting here with no discussion for more than a year. I think there must be some misconceptions because you can have subdomains on onion services (for example facebook has subdomains on their onion service) and as for referring to kde.org I think a simple regex can fix that pretty easily (the same thing that is done to http:// links). Users of tor browser can and will prevent third-party connections if that is what they are worried about, there's a very nice security slider where you can set that.

Felix' comment did not address any point in the bullet list, only waved them away as theoretical (which they are not):

  • extra privacy
  • identity/surety of to whom you are connected
  • freedom from oversight/network surveillance
  • anti-blocking, and...
  • enhanced integrity/tamperproofing

I'm a tor community member and I can answer questions about this and the implementation. I can get the KDE sysadmins in touch with the people who wrote the toolkit, or the ones who implemented them at various organizations. But I find it kind of unsettling when someone claims to be an authority because they did a presentation on 'darknets' (which none of the people who work/contribute to tor call it, in fact it's not a term looked at with fondness in those circles) and spreads what can charitably be called dangerous misinformation such as that Certificate Authorities only had 'small mishaps' and that they are trustworthy when one of our goals is to improve privacy and security.

ognarb added a subscriber: ognarb.Mon, Jun 24, 3:29 PM

@lavender The biggest problem, is that kde.org link to neon.kde.org for example, and we would need to fix all these hardcoded links. Is there a way to fix that without tons of work?

lavender added a comment.EditedMon, Jun 24, 3:39 PM

Yes, https://github.com/alecmuffett/eotk was made to make all of this easy

felixernst added a comment.EditedMon, Jun 24, 7:23 PM

So I'll first address the personal attacks by @lavender and then go back to subject.

someone claims to be an authority because they did a presentation on 'darknets' (which none of the people who work/contribute to tor call it, in fact it's not a term looked at with fondness in those circles) and spreads what can charitably be called dangerous misinformation such as that Certificate Authorities only had 'small mishaps' and that they are trustworthy when one of our goals is to improve privacy and security.

First of all: I wasn't claiming anything. On the contrary I was completly transparent where my knowledge stems from. But I'll be even more transparent here: I held the presentation in front of the vice president of the University of Würzburg Phuoc Tran-Gia who questioned me about this subject afterwards and would later offer me a small time job at his institute. I got a 1.3 for my presentation in combination with my seminar paper which you failed to mention. You can read it right here (in German):

I am aware of the meaning of the term Darknet and its connection to Tor. I used the buzz word as the title.
It's an insult to me that you are claiming that I am spreading misinformation. Maybe addressing your concerns (which I would have also done if you had asked in a more appropriate manner) will prove this. So let's get to it:

Felix' comment did not address any point in the bullet list, only waved them away as theoretical (which they are not):

  • extra privacy
  • identity/surety of to whom you are connected
  • freedom from oversight/network surveillance
  • anti-blocking, and...
  • enhanced integrity/tamperproofing

I did address them here:

Connecting through Tor to any KDE webpage using HTTPS will have nearly all the benefits of KDE running their own onion service.

The bullet points you cited from https://github.com/alecmuffett/eotk are mostly advantages of Tor not of running your own onion service. This means that one already profits of those advantages when connecting to KDE using HTTPS and a Tor Browser. I say "mostly" because the second one

  • identity/surety of to whom you are connected

overlaps with the only advantage Peter Palfrader stated specifically for the Debian people running an onion service themselves which I already addressed in my last comment.
Bullet point four

  • anti-blocking, and...

can be understood as an argument in favor of running your own onion service as well. But the advantage in this case is only theoretical because there is no reason to believe that KDE webpages will be disallowed from being hosted which can be circumvented by running one's own onion service. Note that the blocking of KDE in certain countries (if such exists) can already be circumvented right now by using the Tor Browser.

dangerous misinformation such as that Certificate Authorities only had 'small mishaps' and that they are trustworthy when one of our goals is to improve privacy and security.

My conclusion on this matter is and was:

I think there is no harm in doing this but I also think there is hardly any benefit.
The advantages of this are nearly completly theoretical.

I'll elaborate a bit: I am pretty sure there are better ways to improve privacy and security with less effort. Distrusting Certificate Authorities shouldn't be our most pressing concern. This task only deals with privacy when connecting to KDE webpages which is only a small portion of online communication for most users of KDE software. It also only holds a value for people that use Tor.

I would not consider myself a security expert, my opinion is not set in stone on this and it wasn't and isn't on me to make a decision on this after all. I trust the Sysadmins to make the right call and I believe they would have noticed if my statements on this matter would have been wrong.
That being said I don't think I am quite able to judge the workload that this task entails accurately.

I hope we only have pleasant conversations in the future @lavender.

You seem to have some misconceptions about tor and onion services and the properties you get with each of them. I would be glad to clear them up.

Certificate authorities do not provide the same guarantees as onion services. Onion services are end-to-end encrypted and authenticated they can't be intercepted for example by Raytheon Forcepoint or BlueCoat.

I think there's a kind of cognitive dissonance in saying you see no reason why KDE infrastructure might be targeted while our goals are to reach out to more people (which means more potential targets) and provide better security and privacy. Or saying that it is only theoretical because all threats are theoretical until it happens and the point of security is to make sure it doesn't get there, or to make it as difficult as possible. With how the geopolitical climate is it would not be too strange to see superpowers attempt to control free open source technology sadly.

And I would love to hear your better ways to improve privacy and security as I've done most of the editing on the goal for the past year and haven't seen much of anything happen at all. :)

I would have hoped for an apology at this point but it seems like you didn't mind belittling me. Instead you go right ahead and write another passive aggressive comment belittling me again. I try to argue about the subject matter and you ignore my arguments.

You seem to have some misconceptions about tor and onion services and the properties you get with each of them. I would be glad to clear them up.

If you would be able to identify any misconceptions on my part I'd hope you would have already pointed them out to me. Actually it is obvious to me that you don't understand the subject matter at all. I already had some of the evidence for this written out but then I noticed that it is mostly off topic and there is no point arguing with someone who ignores arguments.

Good thing this task was closed by the Sysadmins for now. If anyone considers reopening this task I will consider contributing to this discussion again. Furthermore if anyone besides @lavender has any more questions on this or wants to talk about the unspecific concerns lavender raised I'd be happy to discuss them as it is a pretty fascinating topic.

lavender added a comment.EditedTue, Jun 25, 8:46 AM

Why are you acting like this? This is the Dunning-Kruger effect in action.

You made one school presentation and now you're telling others that they don't know what that are talking about. Don't you think this is a bit silly? Should I post my CV?

You keep saying you want to argue but from the first comment you made you disregarded what I said as theoretical. And now you do it again simply claiming "I don't know what I am talking about".

I mentioned a specific property that onion services give you that CA do not: end-to-end encryption and authentication. Do you know what this means? Is this theoretical to you?

It's very difficult to have a technical discussion when someone's ego gets in the way.

Why are you happy the issue was closed based on misconceptions?

And again I would love to hear your better ways to improve privacy and security as I've done most of the editing on the goal for the past year and haven't seen much of anything happen at all. :)

@lavendar and @felixernst please both of you stop these personal remarks here on Phabricator. This is a place where we can calmly discuss technical issues and think together about how to best solve them. Please make all your future comments about how to make our websites secure in a practical way.

Valorie, for the KDE Community Working Group

lavender reopened this task as Open.Wed, Jun 26, 10:47 AM
lavender triaged this task as Normal priority.
lavender added a comment.EditedWed, Jun 26, 10:53 AM

I agree, I think it's unhelpful that an issue that was open and stood there for more than a year was closed based on misinformation. I would like to have a discussion without dismissing the concerns and insights of others, especially when one might have a misguided sense of being an authority on a subject. It gets in the way of a constructive discussion. I was trying to say that it got personal for no reason and that now the conversation isn't about how to set up onion services and the benefits that it might offer or clearing up the misconceptions about subdomains for example.

I think it's very against the spirit of community to walk into an issue claim to be an authority because you did one school project and try to hi-jack it and say you will answer the questions now and that the person that started it has no idea what they are talking about and that you are glad it was closed based on a misconception. It just breaks cooperation.

ognarb removed a subscriber: ognarb.Thu, Jun 27, 10:34 AM
bcooksley removed bcooksley as the assignee of this task.Sat, Jun 29, 12:04 PM
bcooksley removed projects: Sysadmin, Websites.
bcooksley removed subscribers: bcooksley, sysadmin.

Removing Sysadmin from this.

We don't have the bandwidth to support this, both in terms of implementation and long term maintenance.

In addition to the Gitlab migration, we still have the future of Identity to deal with and other system upgrades (to finish our switch to Ubuntu 18.04 from 16.04, which is well underway) in addition to our usual maintenance (for Drupal, Wordpress, Jenkins and other software we run) and regular routine requests (of which several are pending on responses from community members currently).

Which one of those tasks are part of our goals though? Why is this such a "top-down" decision filed with technical misconceptions @bcooksley?

lavender added a comment.EditedSat, Jun 29, 1:00 PM

This really leaves a bad taste in my mouth for contributing more, when KDE announced privacy as a goal I put a lot of time into editing the goal, creating the tasks and providing as much contribution as I could in an area where I think I have some knowledge worth sharing.

After waiting a year the decision just comes from above with no discussion based on false information and you remove sysadmin and websites? You might as well delete the task because what else is possible now? I guess nothing will ever change, because the technical bandwidth has been reached and no discussion on solutions is possible. It's just top down decisions.

Funnily enough these are the same attitudes and arguments that were used against people asking for https a decade ago. I remember I opened a task on ubuntu for it and they said it's not important, fast forward a few years suddenly everyone wants to say they support https and that they support privacy, when I think it's more precise to say they support good marketing.

@valorie how should this be approached from a community perspective?

https://bugzilla.mozilla.org/show_bug.cgi?id=1567114

Yet another case of wide scale MITM facilitated by CAs but I guess KDE's sysadmins don't care about users in Kazakhstan.