Re: [PATCHES] Backend SSL configuration enhancement

On 2006.08.31 at 08:52:08 +0100, Gregory Stark wrote:

>
> "Victor B. Wagner" <vitus(at)cryptocom(dot)ru> writes:
>
> > One example which can be tested with stock OpenSSL without national
> > cryptography modules is - usage of NULL ciphers. They are not enabled by
> > default, but use of them provides cryptographically strong
> > authentication with client certificates and data consistency checking
> > with MAC algorithm, but avoids overhead of encryption.
> >
> > Consider situation when data are public anyway, but data modification
> > should be properly authorized.
>
> I'm not sure that's a particularly good use case. There are attacks in the
> wild that hijack existing TCP connections. If you only authenticate
> connections and then even with the MAC checks I think you would have a chance
> of being able to take over the connection.

If you are hijacking TCP connection, you have no way to get shared
secret, negotiated between client and server during SSL handshake. So,
you have no way to generate correct MAC.

> That said it doesn't mean there aren't valid use cases. If for example you
> wanted to do some initial data load without encryption but didn't want to have
> to reconfigure your network to allow connections on different ports.

This is not a case for PostgreSQL, which uses same port for SSL and
non-SSL connection. Initial handshake with client certificates is much
stronger point when comparing SSL with NULL ciphers with non-SSL
connection. Also, SSL, even without client certificates, guarantees
that you are connecting to the right server. So, using SSL with NULL
cipher at least prevents clients from getting wrong data from malicious
server due to DNS spoofing attack.

Although I don't think that it is widespread attack scenario.

Point made by Stefan is much better - it is very probably that somewhen
in the future vulnerability in the some cipher would be discovered.

If cipher list is configurable, DBA would be able to quickly fix the
problem by editing configuration file, instead of recompiling PostgreSQL
or OpenSSL.

If this is mathematical vulnerability in the algorithm, rather than
implementation bug, there would be even no need to upgrade OpenSSL. All
that OpenSSL developers can do - mark this cipher as weak according to
newly discovered strength.

Note that current PostgreSQL cipherlist already contains such a hack:

It contains !MD5 element, because MD5 digest algorithm was broken about
year ago, and PostgreSQL expected to work with versions of OpenSSL which
still consider it strong.