Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp4422969ioa; Wed, 27 Apr 2022 03:38:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw8k3h++O7nlQBnGJGUl+0nPykKA86K1RY7AEsNr2f8hQxj32uL9qC7Y37tlC+vJXGWH+hv X-Received: by 2002:a17:90b:4a0f:b0:1d2:bf83:163b with SMTP id kk15-20020a17090b4a0f00b001d2bf83163bmr43446296pjb.6.1651055895518; Wed, 27 Apr 2022 03:38:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651055895; cv=none; d=google.com; s=arc-20160816; b=FQakG0oreTWeOkHeKfJHku9eFuNdTTHbhhgAvgS4iEsKF5XEuVzytSmVpq8MRIkvq3 7sKtqbYueKINZonemo3qhVJeNlaUX3SMcZf7ydIV+kDHcTIb+WQ+VufBAH9Nkyy838O3 PBOXzcEiEHv4vMhcaaJhwk1OmBHjtvqbMqS437q4cyeCoVX666l2QdaZxbsF85HX0jxw bjAFoBnvAFP4MhcBhIXm7mdc34pIHR3uY5SKKVZrBgjooZw8PHRaXJkQYXWgXLhBEBiI y+iuoRmo6HmxRRMUWgWsxllOMZZp9Bch5Ndi38wvc/Za+o3HE72Pk0JdFFzs9iTOTZ18 b/KQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from; bh=0/wlDnQWr8vkN7HQgB9GKyzLDZdKgeVj0RG8C6aNUoQ=; b=wbTARd0q7t7eY9gybbPG+lRt2soLZcwvCFGSmAFsmj2HIaeFVTSEKZx+6v6+JylPAQ OLxndO3ypOcHn9cxCGd3+WDdXokLiY08DCSNbGlr1Y9FfcHDLTJClTZKkOANEN1meqL+ SUrga9aOrHzkQlGQQJvu6z4E/1JG+9+E47+L/SgYHFd6IxGvJVs6aNA4s1tdRaADCPGc dV9sr66IegA6iBNCT2w4K9eNy1SqErPqYZWE7PxYWHYlDmlH3KxYE/ZfL2fx0R73n4Ff SbXvYFax1zok5gzgocoy6WtnNGsleokZspoBknyFKWq+SO1NJDt0PgaTkssFYGv/angu upZg== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id nl16-20020a17090b385000b001d97cb4fb82si1655874pjb.43.2022.04.27.03.38.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Apr 2022 03:38:15 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 44B7B3CE9AC; Wed, 27 Apr 2022 02:49:15 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358385AbiD0G4V (ORCPT + 99 others); Wed, 27 Apr 2022 02:56:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232250AbiD0G4Q (ORCPT ); Wed, 27 Apr 2022 02:56:16 -0400 Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0F2D750B16; Tue, 26 Apr 2022 23:53:04 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 23R6qn0D002124; Wed, 27 Apr 2022 08:52:49 +0200 From: Willy Tarreau To: netdev@vger.kernel.org Cc: David Miller , Jakub Kicinski , Eric Dumazet , Moshe Kol , Yossi Gilad , Amit Klein , linux-kernel@vger.kernel.org, Willy Tarreau Subject: [PATCH net 0/7] insufficient TCP source port randomness Date: Wed, 27 Apr 2022 08:52:26 +0200 Message-Id: <20220427065233.2075-1-w@1wt.eu> X-Mailer: git-send-email 2.17.5 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, In a not-yet published paper, Moshe Kol, Amit Klein, and Yossi Gilad report being able to accurately identify a client by forcing it to emit only 40 times more connections than the number of entries in the table_perturb[] table, which is indexed by hashing the connection tuple. The current 2^8 setting allows them to perform that attack with only 10k connections, which is not hard to achieve in a few seconds. Eric, Amit and I have been working on this for a few weeks now imagining, testing and eliminating a number of approaches that Amit and his team were still able to break or that were found to be too risky or too expensive, and ended up with the simple improvements in this series that resists to the attack, doesn't degrade the performance, and preserves a reliable port selection algorithm to avoid connection failures, including the odd/even port selection preference that allows bind() to always find a port quickly even under strong connect() stress. The approach relies on several factors: - resalting the hash secret that's used to choose the table_perturb[] entry every 10 seconds to eliminate slow attacks and force the attacker to forget everything that was learned after this delay. This already eliminates most of the problem because if a client stays silent for more than 10 seconds there's no link between the previous and the next patterns, and 10s isn't yet frequent enough to cause too frequent repetition of a same port that may induce a connection failure ; - adding small random increments to the source port. Previously, a random 0 or 1 was added every 16 ports. Now a random 0 to 7 is added after each port. This means that with the default 32768-60999 range, a worst case rollover happens after 1764 connections, and an average of 3137. This doesn't stop statistical attacks but requires significantly more iterations of the same attack to confirm a guess. - increasing the table_perturb[] size from 2^8 to 2^16, which Amit says will require 2.6 million connections to be attacked with the changes above, making it pointless to get a fingerprint that will only last 10 seconds. Due to the size, the table was made dynamic. - a few minor improvements on the bits used from the hash, to eliminate some unfortunate correlations that may possibly have been exploited to design future attack models. These changes were tested under the most extreme conditions, up to 1.1 million connections per second to one and a few targets, showing no performance regression, and only 2 connection failures within 13 billion, which is less than 2^-32 and perfectly within usual values. The series is split into small reviewable changes and was already reviewed by Amit and Eric. Regards, Willy --- Eric Dumazet (1): tcp: resalt the secret every 10 seconds Willy Tarreau (6): secure_seq: return the full 64-bit of the siphash tcp: use different parts of the port_offset for index and offset tcp: add small random increments to the source port tcp: dynamically allocate the perturb table used by source ports tcp: increase source port perturb table to 2^16 tcp: drop the hash_32() part from the index calculation include/net/inet_hashtables.h | 2 +- include/net/secure_seq.h | 2 +- net/core/secure_seq.c | 14 ++++++++---- net/ipv4/inet_hashtables.c | 40 ++++++++++++++++++++++------------- 4 files changed, 37 insertions(+), 21 deletions(-) -- 2.17.5