View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007944 | GNUnet | transport service | public | 2023-09-25 16:01 | 2023-09-26 09:54 |
| Reporter | Shamar | Assigned To | schanzen | ||
| Priority | urgent | Severity | major | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Summary | 0007944: Do NOT include QUIC transport in GNUnet | ||||
| Description | I've recently learned that Google is financing a GSoC to get QUIC included into GNUnet. This is obviously a trojan attack to the project in several ways: - QUIC is designed to enable users' communications' tracking at transport level https://arxiv.org/abs/2101.11871 - QUIC is VERY hard to implement correctly as proved by the several zero days easily identified in production ready servers by researcher in December 2022: https://link.springer.com/article/10.1007/s10207-022-00630-6 - QUIC protocol evolution is controlled by Google which is the most powerful global surveillance firm on this planet the future evolution of the protocol will force GNUnet to either use its scarce resources to update the transport OR get further money from Google to do so, deepening the influence this firm will get on the project - Even if QUIC is just one among several transports supported by GNUnet, in the long run Google might be able to sell it as a "privacy preserving and secure protocol" to enough people that it will be actually enabled in GNUnet, exposing unaware users to its privacy issues. Furthermore on a political level, taking grants from Google means to legitimate its business model, based on people surveillance and large scale individual manipulation. GNUnet home page, right now, is sponsoring Google, open-washing and ethic-washing it: people who do not know QUIC, will think "Looks! Google helps GNUnet! They really care about people privacy!", all while Google is inoculating it's Privacy Sandbox and Toxic APIs to unaware people that still use Chromium browsers. So please, refuse Google's tips and completely remove QUIC from supported transport. | ||||
| Tags | No tags attached. | ||||
|
|
Your points are partially incorrect: - GSoC does not fund GNUnet. It funds students to work on open source projects. GNU was accepted to be a host of projects as a whole. And our code will always be Free Software. - Your first paper looks at GQUIC/IQUIC and HTTPS. What is currently colloqually referred to as "QUIC" is "IETF QUIC", i.e. RFC9000. It uses TLS. Which makes it similar to the HTTPS in that paper. - In your other paper (https://link.springer.com/article/10.1007/s10207-022-00630-6) you can actually find the above distinction: " To respond to this issue, Google introduced the from-the-ground-up designed QUIC [2] in 2012 (referred to as gQUIC in the following), which is a fully encrypted, multiplexed, and low-latency transport protocol over UDP, targeting mainly at improving the performance of HTTPS traffic. In May 2021, IETF standardized QUIC in RFC 9000 [3] (referred to as IETF QUIC or simply QUIC in the following), and also specified in RFC 9001 [4] the way TLS 1.3 will act as a security component of QUIC. Notably, HTTP/3 [5] connections are realized only over QUIC. " - Implementation zero days are inevitable with new software. GNUnet likely has some as well, considering the size of the codebase. - Finally, but importantly, you misrepresent the security properties that we require of our transport systems. GNUnet is using its own end-to-end encryption. Peers authenticate each other on top of the transport channel. With CADET, there is an axolotl-stlye encryption session established. GNUnet also has TCP and UDP communicators in addition to QUIC with a simple, opportunistic key exchange. And it also supports TLS1.3-over-QUIC. Just like it could support TLS1.3-over-TCP. The reason for choice of transport is not security. It is to blend into other traffic (QUIC) or at least to be indistinguishable from random bytes transferred (TCP/UDP). In fact, you could argue that QUIC is currently doing a better job in this regard, because the TCP and UDP protocol is easily identified as GNUnet. Whis a QUIC connection is stilla QUIC connection. If you worry so much about QUIC itself, I challenge you to write a HTTPS transport (without zero days, of course). In conclusion, we will certainly not remove a standardized transport for the above reasons for now. Reducing the diversity of supported protocols only hurts this component. |
|
|
The problem is that my points are correct enough. > GSoC does not fund GNUnet. It funds students to work on open source projects. I know how GSoC works, but how this is relevant? Aren't the student contributor of the project anyway? > And our code will always be Free Software. The license is irrelevant here: we are talking about political issues and user privacy. > Your first paper looks at GQUIC/IQUIC and HTTPS. What is currently colloqually referred to as "QUIC" is "IETF QUIC", i.e. RFC9000. Did you even read the paper? The "IQUIC" there refers to the one documented in RFC 9000 (follow note 3 on page 2 https://arxiv.org/pdf/2101.11871.pdf ). > Which makes it similar to the HTTPS in that paper. In fact the paper concludes: "We demonstrate that GQUIC and IQUIC, especially GQUIC, are more vulnerable to WFP attacks than HTTPS in the early traffic scenario" > Finally, but importantly, you misrepresent the security properties that we require of our transport systems. GNUnet is using its own end-to-end encryption. ... Maybe I'm missing something here, but how can GNUnet E2E encryption and authentication prevent an attack that targets the early connection stage in the underlying protocol? Moreover, the fact that there are alternatives doesn't prevent the issue. > QUIC is currently doing a better job in this regard, because the TCP and UDP protocol is easily identified as GNUnet. Fair point: under certain threat models this might enable GNUnet censorship, but given the properties of GNUnet, most powerful attacker will prefer to fingerprint users' connections instead of brutally (and visibly) block them. > In conclusion, we will certainly not remove a standardized transport for the above reasons for now. Reducing the diversity of supported protocols only hurts this component. Well, this might be looks like a legitimate (if ill-informed) technical decision, but I wonder why you didn't address the political aspects of my issue. Isn't "open-washing" the most dangerous surveillance capitalist out there bad enough for GNUnet political mission? If so, maybe I was fooled by the documentation: """ GNUnet is not merely a technical project, but also a political mission: like the GNU project as a whole, we are writing software to achieve political goals with a focus on the human right of informational self-determination. Putting users in control of their computing has been the core driver of the GNU project. With GNUnet we are focusing on informational self-determination for collaborative computing and communication over networks. The Internet is shaped as much by code and protocols as it is by its associated political processes (IETF, ICANN, IEEE, etc.). Similarly its flaws are not limited to the protocol design. Thus, technical excellence by itself will not suffice to create a better network. We also need to build a community that is wise, humble and has a sense of humor to achieve our goal to create a technical foundation for a society we would like to live in. """ If GNUnet is fine with Google spreading its control over the Internet, please remove the outdated part here: https://docs.gnunet.org/latest/about.html |
|
|
If you worry about the underlying protocols and technologies on which GNUnet runs I have bad news for you: It is running on router( software) backbones and all kinds of stacks that we have no control over. Never mind security. What do you mean by "how can GNUnet E2E encryption and authentication prevent an attack that targets the early connection stage in the underlying protocol". If that was not possible, how can you design a secure protocol over bluetooth, ethernet, wifi? You can, of course, because the security is built on the layers on top. The transport layer for gnunet is what the transport layer is in the ISO/OSI model. Just that. We can use the protocols that the "classical" Internet uses for transport (TCP, UDP). But we can run over others, like HTTPS or HTTP or ad-hoc WiFi. And if we exclude all transport channel provides that somebody politically deems questionable, but are technically perfectly sound transports, then I have to strongly disagree that this is getting us anywhere and we basically have to start with launching our own satellites into space. |
|
|
> If you worry about the underlying protocols and technologies on which GNUnet runs I have bad news for you: It is running on router( software) backbones and all kinds of stacks that we have no control over. Never mind security. Do you know any backbone that declares a "political mission" to "achieve political goals with a focus on the human right of informational self-determination"? In fact, I didn't open this issue to them, but to GNUnet. > What do you mean by "how can GNUnet E2E encryption and authentication prevent an attack that targets the early connection stage in the underlying protocol". > If that was not possible, how can you design a secure protocol over bluetooth, ethernet, wifi? The key words in that question are "early connection stage": if you had read the first paper, you'd know that the vulnerability that enables the fingerprinting attack effective occurs during the QUIC handshake, BEFORE GNUnet payload is even taken into account. Given that: how will GNUnet avoid the attack on user privacy that will occur BEFORE its payload can be handled by the peers? It's a honest question: if you have a solution about this, please share the relevant documentation. > The transport layer for gnunet is what the transport layer is in the ISO/OSI model. Just that. We can use the protocols that the "classical" Internet uses for transport (TCP, UDP). But we can run over others, like HTTPS or HTTP or ad-hoc WiFi. So what? > And if we exclude all transport channel provides that somebody politically deems questionable, but are technically perfectly sound transports, First QUIC is not "technically perfectly sound": attached you find an extensive survey of the several security and privacy issues known to day. Second, we are not talking about somebody "politically questionable". We are talking about an organization whose business model is founded on people surveillance. I mean: Google is the most powerful surveillance capitalist: its interests are in direct contrast with the (declared) GNUnet goals! |
|
|
Again, you do not seem to understand what a transport is for. There is nothing to fingerprint. There is no application layer protocol running directly on top of the transport layer in gnunet. You have objections to a company that developed a technology that now has a specification developed inside the IETF. GNUnet runs on top of transports that are expected to be insecure channels. Period. It does not matter what kind of privacy and security issues quic has because we DO NOT CONSIDER IT A SECURE CHANNEL. As such I am starting to consider this post a troll post. Please take your discussion to gnunet-developers@gnunet.org if you want to talk about ideologically purging any trace of a capitalist company out of our software stack. We can discuss then on what will be left with apart from sticks and stones. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-09-25 16:01 | Shamar | New Issue | |
| 2023-09-25 17:32 | schanzen | Note Added: 0020553 | |
| 2023-09-25 21:06 | Shamar | Note Added: 0020556 | |
| 2023-09-25 21:21 | schanzen | Note Added: 0020557 | |
| 2023-09-26 08:02 | Shamar | Note Added: 0020558 | |
| 2023-09-26 08:02 | Shamar | File Added: A_Survey_on_the_Security_Issues_of_QUIC.pdf | |
| 2023-09-26 09:54 | schanzen | Note Added: 0020559 | |
| 2023-09-26 09:54 | schanzen | Assigned To | => schanzen |
| 2023-09-26 09:54 | schanzen | Status | new => closed |
| 2023-09-26 09:54 | schanzen | Resolution | open => fixed |
