Thread: 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
Attachment
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? > > http://archives.postgresql.org > -- 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
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. -- 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