Re: Old backend/frontend protocol versions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Old backend/frontend protocol versions
Date
Msg-id 10573.1004378388@sss.pgh.pa.us
Whole thread Raw
In response to Old backend/frontend protocol versions  (Daniel Varela Santoalla <dvs@arrakis.es>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: HISTORY file
Next
From: David Ford
Date:
Subject: Re: [patch] helps fe-connect.c handle -EINTR more gracefully