On 2006.08.31 at 08:52:08 +0100, Gregory Stark wrote: > > "Victor B. Wagner" <[EMAIL PROTECTED]> 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. ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
