On Tue, 7 Jan 2003, Tom Lane wrote:
> Bruno Wolff III <bruno@wolff.to> writes:
> > Can't you use a "reject" hostssl line in hba.conf to keep SSL connections
> > from working for particular IP addresses? Does the client not fall back
> > in this case?
>
> I think it won't --- the fallback is only at the initial attempt to open
> the connection, not if the startup packet is rejected.
That's right.
> A more global question is whether the overhead of SSL is really large
> enough to justify any concern about avoiding it. I have never measured
> it, but even a local LAN is a lot slower than modern CPUs. It doesn't
> seem to me to be a foregone conclusion that we need to worry about
> providing a way to avoid it.
Not at all. SSL has significant overhead. Here's a quick test that runs
three SELECT queries returning about 50,000 rows:
bash-2.05$ time ./timeit
real 0m10.527s
user 0m5.290s
sys 0m0.420s
bash-2.05$ time ./timeit nossl=1
real 0m6.947s
user 0m1.720s
sys 0m0.350s
This is with a client and server on separate machines on the same local
network, each with 2+ GB RAM and Xeon 2.4 GHz processors (dual, though
that's not relevant). The slowdown will be worse with slower CPUs, of
course.
I can't imagine why I'd want to tolerate wasting CPU on both ends of the
connection and slowing down data transfer, when my original purpose in
moving the database off the app server box was to increase capacity.
I will of course continue using my working patched versions of PostgreSQL
that allow me the flexibility of deciding on client and server whether I
will talk via SSL or not. My question is whether the mainline PostgreSQL
software will give users the same flexibility. I'll finish up my SSLMODE
patch and submit it, and it's up to you all from there.
Jon
