Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s98rj-0003iD-2t for pgsql-hackers@arkaria.postgresql.org; Mon, 20 May 2024 19:40:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1s98ri-004eBj-5K for pgsql-hackers@arkaria.postgresql.org; Mon, 20 May 2024 19:40:10 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s98rh-004eBb-Qm for pgsql-hackers@lists.postgresql.org; Mon, 20 May 2024 19:40:09 +0000 Received: from mail-qv1-xf30.google.com ([2607:f8b0:4864:20::f30]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s98rZ-001AWu-Kl for pgsql-hackers@lists.postgresql.org; Mon, 20 May 2024 19:40:07 +0000 Received: by mail-qv1-xf30.google.com with SMTP id 6a1803df08f44-6ab6d1cf304so4194466d6.0 for ; Mon, 20 May 2024 12:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1716234000; x=1716838800; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HuH4ZJ45A2F+NhtCg9Wro3pQvB7xHZ3zF4yCiNW1Fes=; b=NY9M0U74w8Eq3AL5YdFz7SAMSa50OPuIxFTPtIhrnKC+yE8VlKbOwpfbmkvcOuHFgR nYhZXpKVH3RJblyowWH5rBUg+IlppjYhHokFvEdC2G4hz8tMvlYUUYCrE/lrznh+bGU+ B5ukl4oEDcagYn++eCHP7kHnszPSXhIA+cM9iV26iz8eLA+z0NbwG29DKb+4XUII35X8 E24TGxlPF1/tLPHoSGTctKSBsf69LYxhipY0PrVRr/jClf6m96hzrbud65hxRlyByopv XSY4XpqMvA4MoBt4Y2Z/tooOohDQS5AppAV/4iUYx70Q3y1rg07yhBEZZhqGauwiAhRU S3tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716234000; x=1716838800; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HuH4ZJ45A2F+NhtCg9Wro3pQvB7xHZ3zF4yCiNW1Fes=; b=h4cvfaWM8RM7VSVX8u787q/kCQCZRDUMP/HdImH4avPmbeUkgr6ajqM2hoqC+/SS8L oR6o7NWg71Wm3uZcYTg+zJWgX6wgKwu/M2OGReINvP5lH1bIVgUUjHNblBzalLEvKoCU QIoH2mQ+f4OVmj4Kuk6OapjC2E0jfMjzqp1UNlHM+nIkXCMQkaJhlnA7niXG5EiM2lXM 0OEh6naJ68JMz+bfKGDB9sGiCDElem0LOaiIsJVWg9YeN2UlARgMe43KGjp18JlGZ3oR oC0/SqocZCO2KaHCxNTTx9VQzdQUX3rjIRbAtYCTbcNhC/ERUevz9hQAcwWsUe8+K2Pq t7Nw== X-Forwarded-Encrypted: i=1; AJvYcCUGrVdlwYxmgay6TU5ZDCqOE41DiGyfkqRjHIkPbLYR2jrP1UVu+e+gHo+db7Blk7nd2CiL4MYhXYwRqjklzN4Nhj8mNg4xkuMkRziPPIrj/I5A X-Gm-Message-State: AOJu0YyymTtK4dh5xjv80GCSChSN9Uk7oCsqkNJ57bxyInbMVnHqkCdR K5WvtYdHjSjJXsSanMvUEOwLjCGVpfTsG6/LjAD2T0qGLCO3UY1cnd4fpNvmCiGbLl0lPLv99QU /wq1CIUU8+QhgGLKhxezWBcEuGBa3jZgBkA0l X-Google-Smtp-Source: AGHT+IFxopxqE9Bw4KGh375vN7Fb+FHNGx/I5LUPlfqebk5bi6/ff1F5MYie5X/sFowicjlhQ6Pv48ribraWcYwiEtU= X-Received: by 2002:a05:6214:3283:b0:69b:5d39:f556 with SMTP id 6a1803df08f44-6a16819ebe1mr333875236d6.1.1716234000626; Mon, 20 May 2024 12:40:00 -0700 (PDT) MIME-Version: 1.0 References: <874AA52D-1ACF-4FAE-95B0-9FC72A7DC83D@yandex-team.ru> In-Reply-To: <874AA52D-1ACF-4FAE-95B0-9FC72A7DC83D@yandex-team.ru> From: Jacob Champion Date: Mon, 20 May 2024 12:39:49 -0700 Message-ID: Subject: Re: libpq compression (part 3) To: "Andrey M. Borodin" Cc: Robert Haas , Jelte Fennema-Nio , Jacob Burroughs , PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, May 20, 2024 at 11:05=E2=80=AFAM Andrey M. Borodin wrote: > > So, the data would be compressed first, with framing around that, and > > then transport encryption would happen afterwards. I don't see how > > that would leak your password, but I have a feeling that might be a > > sign that I'm about to learn some unpleasant truths. > > Compression defeats encryption. That's why it's not in TLS anymore. > The thing is compression codecs use data self correlation. And if you mix= secret data with user's data, user might guess how correlated they are. I'm slow on the draw, but I hacked up a sample client to generate traffic against the compression-enabled server, to try to illustrate. If my client sends an LDAP password of "hello", followed by the query `SELECT 'world'`, as part of the same gzip stream, I get two encrypted packets on the wire: lengths 42 and 49 bytes. If the client instead sends the query `SELECT 'hello'`, I get lengths 42 and 46. We lost three bytes, and there's only been one packet on the stream before the query; if the observer controlled the query, it's pretty obvious that the self-similarity has to have come from the PasswordMessage. Rinse and repeat. That doesn't cover the case where the password itself is low-entropy, either. "hellohellohellohello" at least has length, but once you compress it that collapses. So an attacker can passively monitor for shorter password packets and know which user to target first. --Jacob