2nd revision of SSL patches
Another uberpatch for the SSL code.
The main improvements over the last revision include:
*) certs are fully validated - valid root certs must be available.
This is a hassle, but it means that you *can* trust the identity
of the server.
*) the client library can handle hardcoded root certificates, to
avoid the need to copy these files.
*) host name of server cert must resolve to IP address, or be a
recognized alias. This is more liberal than the previous
iteration.
*) the number of bytes transferred is tracked, and the session
key is periodically renegotiated.
*) basic cert generation scripts (mkcert.sh, pgkeygen.sh). The
configuration files have reasonable defaults for each type
of use.
Remaining issues are:
*) select() in legacy code?
*) encrypted private keys
*) session support (useful if auto-reconnection will be supported)
*) anonymous DH
*) fully implemented cert tools
Bear
Bear Giles writes:
*) certs are fully validated - valid root certs must be available.
This is a hassle, but it means that you *can* trust the identity
of the server.
I'm confused. We currently don't have SSL-based authentication, so why do
we have certificates at all?
*) the client library can handle hardcoded root certificates, to
avoid the need to copy these files.
Hardcoding is evil.
*) host name of server cert must resolve to IP address, or be a
recognized alias. This is more liberal than the previous
iteration.
Which is the standard/recommended practice?
*) the number of bytes transferred is tracked, and the session
key is periodically renegotiated.
Define "periodically".
*) basic cert generation scripts (mkcert.sh, pgkeygen.sh). The
configuration files have reasonable defaults for each type
of use.
Again, what are these certificate management tools for if we don't have
any need for certificates?
About the code:
* no // comments
* no fprintf(stderr, ...) in library functions
* read_SSL/write_SSL -- If you think these functions are misnamed, rename
them.
* Isn't there an automated way to generated error message from error codes
in OpenSSL?
--
Peter Eisentraut peter_e@gmx.net
OK, I have added tools.tar.gz to CVS under interfaces/ssl. Peter, you
seem to be saying we don't want these. Is that accurate?
---------------------------------------------------------------------------
Peter Eisentraut wrote:
Bear Giles writes:
*) certs are fully validated - valid root certs must be available.
This is a hassle, but it means that you *can* trust the identity
of the server.I'm confused. We currently don't have SSL-based authentication, so why do
we have certificates at all?*) the client library can handle hardcoded root certificates, to
avoid the need to copy these files.Hardcoding is evil.
*) host name of server cert must resolve to IP address, or be a
recognized alias. This is more liberal than the previous
iteration.Which is the standard/recommended practice?
*) the number of bytes transferred is tracked, and the session
key is periodically renegotiated.Define "periodically".
*) basic cert generation scripts (mkcert.sh, pgkeygen.sh). The
configuration files have reasonable defaults for each type
of use.Again, what are these certificate management tools for if we don't have
any need for certificates?About the code:
* no // comments
* no fprintf(stderr, ...) in library functions
* read_SSL/write_SSL -- If you think these functions are misnamed, rename
them.* Isn't there an automated way to generated error message from error codes
in OpenSSL?--
Peter Eisentraut peter_e@gmx.net---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Bruce Momjian writes:
OK, I have added tools.tar.gz to CVS under interfaces/ssl. Peter, you
seem to be saying we don't want these. Is that accurate?
I'd like to see some documentation before deciding what those do. Of
course dumping in code that no one knows what it's for is a questionable
strategy.
--
Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote:
Bruce Momjian writes:
OK, I have added tools.tar.gz to CVS under interfaces/ssl. Peter, you
seem to be saying we don't want these. Is that accurate?I'd like to see some documentation before deciding what those do. Of
course dumping in code that no one knows what it's for is a questionable
strategy.
I disagree. No one commented on the patch. It is in its own directory,
easily removed.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026