Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gtDmj-00073z-5k for pgsql-hackers@arkaria.postgresql.org; Mon, 11 Feb 2019 15:46:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gtDmh-0002X3-VD for pgsql-hackers@arkaria.postgresql.org; Mon, 11 Feb 2019 15:46:15 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gtDmh-0002Wv-Fn for pgsql-hackers@lists.postgresql.org; Mon, 11 Feb 2019 15:46:15 +0000 Received: from mail-qk1-x744.google.com ([2607:f8b0:4864:20::744]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gtDmd-0005Zv-7V for pgsql-hackers@postgresql.org; Mon, 11 Feb 2019 15:46:14 +0000 Received: by mail-qk1-x744.google.com with SMTP id m9so6683364qkl.4 for ; Mon, 11 Feb 2019 07:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=D4tSO3Vwk9M2+cd+Ao0lhiyCGnvJOeZe24oppkD/5oM=; b=h6xmtFASi1tzwQMyeYaFCP6v/+hu9re7MrWm5kBCqg51z9zXr3GH307SNmCAhD3T64 lup3lSTXVYFADOOHQruKtvUoZ7pnzjKnBXAR901iD79CYCDk9d/ikeQD96Yb1OGAdj3m Mj9yjH4EKnM49nGUivybisUV6ITecoE4+vEz4F+Qyx6vH6YvCqheQaKUnyHFs51qHoZX RKryuVtBq1bEMj6Xet7e/5PTpT2+2CdJuxC/ZW0AVWYI1SpCndNao2IQuCDM/VHHIiLU cBtkpJ9J6sNPD1ZU7RjtCQXyHUqPpN5lMBnsWsOqPXtIsoB2Lyjc+MEnmkpMdVuRFJDE Mc1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=D4tSO3Vwk9M2+cd+Ao0lhiyCGnvJOeZe24oppkD/5oM=; b=uHP0kCqdPUAAZNgvCgC14YKVumeZ0xndTR30fjZLqazzQpB3VXZyG9VA8GHm6ANOL9 SO28M+mH42RceEoNMaKpH6bHa5C7iZAAWr1CIleXcLpEEoalm7nornPK/j9vtfAltoZH kgIUtJXE3tspmVQgVzR3eLwAOcTdvMgeAFwkvuGkBS4bj2i5vN50SNsbgJIxIb3CGwfp XGfjwaEOK4JZaUQhE19a2SmmGuXKFsuH8nOm4WURvpdGAYw5qlrq+zCQWigVMzYaeZ7Q 063U+qK1xRpEJ5mdP3Ahj/eIgyIuH489O/UJy0/nwHMkGkRpDmDjQPc26M6Z45XeKLr5 pm+w== X-Gm-Message-State: AHQUAuakxbD2Oad09J8lMYg1Xgg9SsUXoMsFFsDd/6mtfG4tBURUZdLf KjG7mSWupZLmhkZLJ5E1n+OsN+hO+84= X-Google-Smtp-Source: AHgI3Iap2g/bfRhEeLrJVAsHhsri+qcpYu0LzBmr8rrrRKupQGCeTIrjalgRP6CMsyYpN0Qr3EmVzA== X-Received: by 2002:a37:7e45:: with SMTP id z66mr25936239qkc.23.1549899970415; Mon, 11 Feb 2019 07:46:10 -0800 (PST) Received: from nimloth.alvh.no-ip.org ([190.121.29.3]) by smtp.gmail.com with ESMTPSA id w20sm9583327qki.35.2019.02.11.07.46.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 11 Feb 2019 07:46:09 -0800 (PST) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id EDDF7124686; Mon, 11 Feb 2019 12:46:07 -0300 (-03) Date: Mon, 11 Feb 2019 12:46:07 -0300 From: Alvaro Herrera To: Andreas Karlsson Cc: Andres Freund , Konstantin Knizhnik , PostgreSQL Hackers Subject: Re: libpq compression Message-ID: <20190211154607.GA7297@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8d210267-a2fa-662f-b167-0e5991d45dd7@proxel.se> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Feb-11, Andreas Karlsson wrote: > Imagine the following query which uses the session ID from the cookie to > check if the logged in user has access to a file. > > SELECT may_download_file(session_id => $1, path => $2); > > When the query with its parameters is compressed the compressed size will > depend on the similarity between the session ID and the requested path > (assuming Zstd works similar to DEFLATE), so by tricking the web browser > into making requests with specifically crafted paths while monitoring the > traffic between the web server and the database the compressed request size > can be use to hone in the session ID and steal people's login sessions, just > like the CRIME attack[1]. I would have said that you'd never let the attacker eavesdrop into the traffic between webserver and DB, but then that's precisely the scenario you'd use SSL for, so I suppose that even though this attack is probably just a theoretical risk at this point, it should definitely be considered. Now, does this mean that we should forbid libpq compression completely? I'm not sure -- maybe it's still usable if you encapsulate that traffic so that the attackers cannot get at it, and there's no reason to deprive those users of the usefulness of the feature. But then we need documentation warnings pointing out the risks. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services