Daniel Varela Santoalla <dvs@arrakis.es> writes:
> The problem appeared when using DBBalancer with PostgreSQL and PHP installed
> from Debian packages, as a tcpdump capture identified a StartUp packet like
> this:
> 00 00 01 28 04 d2 16 2f ...
> According to the protocol specification the first four bytes are the length
> of the packet (ok), but the next four should be the protocol version....
This is an SSL negotiation request --- look for NEGOTIATE_SSL_CODE
in the sources.
> What I would like to know, since the lack of documentation (at least I
> couldn't find any) of previous versions of the protocol is:
The people who did the SSL feature did a spectacularly poor job of
documenting it. AFAICT, the rest of that packet is a wasted bunch of
zeroes, and the next thing that happens is that the postmaster sends
back a one-byte OK-to-use-SSL-or-not response; if OK, the next step
is to engage in an SSL connection dialog, then send the real StartUp
packet under protection of SSL. But no, there's not a word of
documentation about it except some comments in the source code.
Unless your balancer can cope with a stream of data that it cannot make
any sense of, my guess is that you'll have a hard time doing anything
useful with SSL-encrypted connections. You might be best off to reject
them out of hand (send back a 1-byte response 'N', then wait for the
non-encrypted StartUpPacket). Or perhaps run separate SSL sessions on
your incoming and outgoing datastreams.
regards, tom lane