Bruce Momjian wrote:
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 can specify 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 between client and server.
A fact that the above misses, is that symmetric key encryption is
actually quite cheap. It is asymmetric key encryption that is expensive.
If you look up information on SSL accelerators, you will find claims
that the initial SSL authentication negotiation is 1000X as expensive as
the actual data encryption for a running session, and that SSL web
services are usually limited by their ability to negotiate NEW sessions.
In other words, as well intentioned and accurate as the claim you make
above, it may be irrelevant in many real world scenarios. If you are
going to go through all the expensive processing of having
authentication enabled, you may as well have encryption enabled too.
Cheers,
mark
--
Mark Mielke <[EMAIL PROTECTED]>
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
