Tomasz Ostrowski wrote:
> On Sun, 23 Dec 2007, Tom Lane wrote:
>
> > ISTM we have these action items:
> > 1. Improve the code so that SSL authentication can be used across a
> > Unix-socket connection (we can disable encryption though).
>
> I've just realised that there's a problem with SSL with disabled
> encryption on a unix socket / localhost connections for cpu-saving.
> Any local user using this attack would be able to eavesdrop
> everything comming through a socket.
>
> If an attacker just acts as a tunnel, highjacking a unix-socket and
> talking to a server using any other interface (or the other way
> around), then he would not be able to modify information flow, but he
> would be able to read and save everything going to and from a server.
> It is again not obvious as normally local connections are not
> susceptible to eavesdropping. And could go unnoticed for a long time
> as everything would just work normally.
>
> So I think no cpu-saving by turning off encryption should be done.
>
> And this would all not help for a denial-of-service attack.
Good point. I have added the last two sentences to the documentation
paragraph to highlight this issue:
<productname>OpenSSL</productname> supports a wide range of ciphers and authentication algorithms, of varying
strength. While a list of ciphers can be specified in the <productname>OpenSSL</productname> configuration file, you
canspecify ciphers specifically for use by the database server by modifying <xref linkend="guc-ssl-ciphers"> in
<filename>postgresql.conf</>. It is possible to have authentication without the overhead of encryption by using
<literal>NULL-SHA</>or <literal>NULL-MD5</> ciphers. However, a man-in-the-middle could read and pass communications
betweenclient and server.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
