Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Robert Haas]

On Thu, Oct 19, 2017 at 1:15 AM, Satyanarayana Narlapuram
 wrote:
> Tom, Robert, Microsoft is interested in supporting windows SChannel for 
> Postgres. Please let know how we can help taking this forward. We would love 
> contributing to this either by enhancing the original patch provided by 
> Heikki, or test the changes on Windows.

That would be great!  I think the first thing to do would be look over
Heikki's comments about what was left to be done and maybe try to do
some of those things.  And then test the result.  :-)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Satyanarayana Narlapuram]

Tom, Robert, Microsoft is interested in supporting windows SChannel for 
Postgres. Please let know how we can help taking this forward. We would love 
contributing to this either by enhancing the original patch provided by Heikki, 
or test the changes on Windows.

Thanks,
Satya

-Original Message-
From: pgsql-hackers-ow...@postgresql.org 
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
Sent: Wednesday, October 18, 2017 11:51 AM
To: Robert Haas <robertmh...@gmail.com>
Cc: hlinnaka <hlinn...@iki.fi>; Jeff Janes <jeff.ja...@gmail.com>; Andreas 
Karlsson <andr...@proxel.se>; Martijn van Oosterhout <klep...@svana.org>; 
Magnus Hagander <mag...@hagander.net>; PostgreSQL-development 
<pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

Robert Haas <robertmh...@gmail.com> writes:
> Heikki, do you have any plans to work more on this?
> Or does anyone else?

FWIW, I have some interest in the Apple Secure Transport patch that is in the 
CF queue, and will probably pick that up at some point if no one beats me to it 
(but it's not real high on my to-do list).
I won't be touching the Windows version though.  I suspect that the folk who 
might be competent to review the Windows code may have correspondingly little 
interest in the macOS patch.  This is a bit of a problem, since it would be 
good for someone to look at both of them, with an eye to whether there are any 
places in our SSL abstraction API that ought to be rethought now that we have 
actual non-OpenSSL implementations to compare to.

regards, tom lane


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make 
changes to your subscription:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.postgresql.org%2Fmailpref%2Fpgsql-hackers=02%7C01%7CSatyanarayana.Narlapuram%40microsoft.com%7C99f781c4865e46f8e69408d5165965f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636439495588088189=4I%2FYNAtDb63%2BGbSIgh6XVmfKZlbq1YewZ2mkAJkQVKE%3D=0


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Robert Haas]

On Wed, Oct 18, 2017 at 2:50 PM, Tom Lane  wrote:
> Robert Haas  writes:
>> Heikki, do you have any plans to work more on this?
>> Or does anyone else?
>
> FWIW, I have some interest in the Apple Secure Transport patch that
> is in the CF queue, and will probably pick that up at some point if
> no one beats me to it (but it's not real high on my to-do list).
> I won't be touching the Windows version though.  I suspect that the
> folk who might be competent to review the Windows code may have
> correspondingly little interest in the macOS patch.  This is a bit
> of a problem, since it would be good for someone to look at both of
> them, with an eye to whether there are any places in our SSL abstraction
> API that ought to be rethought now that we have actual non-OpenSSL
> implementations to compare to.

Well, the best way to handle that might be to get some of this stuff
done before we get too much later into the release cycle, so that
there's time to tinker with it before the release goes out the door
(or is deep in beta).  However, if nobody's working on this and the
other patch is someplace far down your to-do list, then I guess that
isn't going to happen.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Tom Lane]

Robert Haas  writes:
> Heikki, do you have any plans to work more on this?
> Or does anyone else?

FWIW, I have some interest in the Apple Secure Transport patch that
is in the CF queue, and will probably pick that up at some point if
no one beats me to it (but it's not real high on my to-do list).
I won't be touching the Windows version though.  I suspect that the
folk who might be competent to review the Windows code may have
correspondingly little interest in the macOS patch.  This is a bit
of a problem, since it would be good for someone to look at both of
them, with an eye to whether there are any places in our SSL abstraction
API that ought to be rethought now that we have actual non-OpenSSL
implementations to compare to.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Robert Haas]

On Tue, Aug 12, 2014 at 1:52 PM, Heikki Linnakangas
 wrote:
> On 08/06/2014 08:37 PM, Jeff Janes wrote:
>>
>> But now it looks like 0002 needs a rebase
>
> I've committed the refactoring patch, and here's a rebased and improved
> version of the Windows SChannel implementation over that.
>
> Server-side support is now implemented too, but it's all very crude and
> work-in-progress. CRLs are not supported, intermediary CAs are not
> supported, and probably many other bells and whistles are missing too. But
> the basics work, including cert authentication. Consider this a Proof of
> Concept.

Heikki, do you have any plans to work more on this?

Or does anyone else?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Jeff Janes]

On Tue, Aug 12, 2014 at 10:52 AM, Heikki Linnakangas 
hlinnakan...@vmware.com wrote:

 On 08/06/2014 08:37 PM, Jeff Janes wrote:

 But now it looks like 0002 needs a rebase


 I've committed the refactoring patch, and here's a rebased and improved
 version of the Windows SChannel implementation over that.


On MinGW, I get the following error when compiling with options
--host=x86_64-w64-mingw32 --without-zlib:

be-secure.c: In function 'secure_open_server':
be-secure.c:106:2: error: 'Port' has no member named 'peer_cn'
be-secure.c:106:2: error: 'Port' has no member named 'peer_cn'
make[3]: *** [be-secure.o] Error 1
make[2]: *** [libpq-recursive] Error 2
make[1]: *** [all-backend-recurse] Error 2
make: *** [all-src-recurse] Error 2

Should the ereport DEBUG2 be inside the #ifdef USE_SSL?

Thanks,

Jeff

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Heikki Linnakangas]

On 08/15/2014 08:16 PM, Jeff Janes wrote:

On Tue, Aug 12, 2014 at 10:52 AM, Heikki Linnakangas 
hlinnakan...@vmware.com wrote:


On 08/06/2014 08:37 PM, Jeff Janes wrote:


But now it looks like 0002 needs a rebase


I've committed the refactoring patch, and here's a rebased and improved
version of the Windows SChannel implementation over that.


On MinGW, I get the following error when compiling with options
--host=x86_64-w64-mingw32 --without-zlib:

be-secure.c: In function 'secure_open_server':
be-secure.c:106:2: error: 'Port' has no member named 'peer_cn'
be-secure.c:106:2: error: 'Port' has no member named 'peer_cn'
make[3]: *** [be-secure.o] Error 1
make[2]: *** [libpq-recursive] Error 2
make[1]: *** [all-backend-recurse] Error 2
make: *** [all-src-recurse] Error 2

Should the ereport DEBUG2 be inside the #ifdef USE_SSL?


Yeah.

I've been thinking though, perhaps we should always have the ssl_in_use, 
peer_cn and peer_cert_valid members in the Port struct. If not compiled 
with USE_SSL, they would just always be false/NULL. Then we wouldn't 
need #ifdefs around all the places that check hose fields either.


- Heikki



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Tom Lane]

Heikki Linnakangas hlinnakan...@vmware.com writes:
 On 08/15/2014 08:16 PM, Jeff Janes wrote:
 Should the ereport DEBUG2 be inside the #ifdef USE_SSL?

 Yeah.

 I've been thinking though, perhaps we should always have the ssl_in_use, 
 peer_cn and peer_cert_valid members in the Port struct. If not compiled 
 with USE_SSL, they would just always be false/NULL. Then we wouldn't 
 need #ifdefs around all the places that check hose fields either.

+1.  This would also make it less risky for add-on code to touch the Port
struct.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Robert Haas]

On Tue, Aug 12, 2014 at 1:52 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
 This isn't a showstopper, but needs some thought. As the patch stands, it
 uses a single key container called PostgreSQL server key container, and
 makes no attempt to delete the keys after they're no longer used. That
 works, but it leaves the key lying on the system.

What about using something like 'PostgreSQL ' || system_identifier?

Would it make sense to have pg_ctl unregister delete the key
container, or do we need a separate facility for that?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Heikki Linnakangas]

On 08/06/2014 08:37 PM, Jeff Janes wrote:

But now it looks like 0002 needs a rebase


I've committed the refactoring patch, and here's a rebased and improved 
version of the Windows SChannel implementation over that.


Server-side support is now implemented too, but it's all very crude and 
work-in-progress. CRLs are not supported, intermediary CAs are not 
supported, and probably many other bells and whistles are missing too. 
But the basics work, including cert authentication. Consider this a 
Proof of Concept.


One issue came up with managing private keys: In the server, it's 
necessary to import the private key into a permanent key container 
that's managed by the Windows Crypto API. That can be done 
programmatically (as I do in the patch), but the keys are permanently 
stored in the system (in the user's profile). They will be left behind 
even if you completely delete the data directory. That's not the end of 
the world, but it would be nicer if we could use some kind of a 
temporary key container that only lives in memory, but the Crypto API 
doesn't seem to have such a concept. You can acquire an ephemeral 
context by passing the CRYPT_VERIFYCONTEXT flag to CryptAcquireContext 
function, and that's exactly what I'm doing in the client, but that 
method doesn't seem to work when acting as an SSL server.


Also, the key container needs to be given a name, or we can use the 
default container, but either way all the keys are shared among all 
applications that use the same container. We'll have to figure out how 
to set that up so that there are no conflicts, if you try to use the 
same server certificate for two PostgreSQL instances running on the same 
host (useful while developing/testing replication).


This isn't a showstopper, but needs some thought. As the patch stands, 
it uses a single key container called PostgreSQL server key container, 
and makes no attempt to delete the keys after they're no longer used. 
That works, but it leaves the key lying on the system.


- Heikki

diff --git a/configure b/configure
index 0f435b5..d00290a 100755
--- a/configure
+++ b/configure
@@ -707,6 +707,7 @@ XML2_CONFIG
 UUID_EXTRA_OBJS
 with_uuid
 with_selinux
+with_winschannel
 with_openssl
 krb_srvtab
 with_python
@@ -823,6 +824,7 @@ with_pam
 with_ldap
 with_bonjour
 with_openssl
+with_winschannel
 with_selinux
 with_readline
 with_libedit_preferred
@@ -1509,6 +1511,7 @@ Optional Packages:
   --with-ldap build with LDAP support
   --with-bonjour  build with Bonjour support
   --with-openssl  build with OpenSSL support
+  --with-winschannel  build with Windows SChannel support
   --with-selinux  build with SELinux support
   --without-readline  do not use GNU Readline nor BSD Libedit for editing
   --with-libedit-preferred
@@ -5514,6 +5517,46 @@ $as_echo $with_openssl 6; }
 
 
 #
+# Windows SChannel
+#
+{ $as_echo $as_me:${as_lineno-$LINENO}: checking whether to build with native Windows SSL support 5
+$as_echo_n checking whether to build with native Windows SSL support...  6; }
+
+
+
+# Check whether --with-winschannel was given.
+if test ${with_winschannel+set} = set; then :
+  withval=$with_winschannel;
+  case $withval in
+yes)
+
+$as_echo #define USE_WINDOWS_SCHANNEL 1 confdefs.h
+
+  ;;
+no)
+  :
+  ;;
+*)
+  as_fn_error $? no argument expected for --with-winschannel option $LINENO 5
+  ;;
+  esac
+
+else
+  with_winschannel=no
+
+fi
+
+
+{ $as_echo $as_me:${as_lineno-$LINENO}: result: $with_winschannel 5
+$as_echo $with_winschannel 6; }
+
+
+if test $with_openssl = yes -a $with_winschannel = yes ; then
+  as_fn_error $? 
+*** Cannot select both OpenSSL and Windows SChannel. $LINENO 5
+fi
+
+#
 # SELinux
 #
 { $as_echo $as_me:${as_lineno-$LINENO}: checking whether to build with SELinux support 5
diff --git a/configure.in b/configure.in
index f8a4507..132fb0a 100644
--- a/configure.in
+++ b/configure.in
@@ -662,6 +662,20 @@ AC_MSG_RESULT([$with_openssl])
 AC_SUBST(with_openssl)
 
 #
+# Windows SChannel
+#
+AC_MSG_CHECKING([whether to build with native Windows SSL support])
+PGAC_ARG_BOOL(with, winschannel, no, [build with Windows SChannel support],
+  [AC_DEFINE([USE_WINDOWS_SCHANNEL], 1, [Define to build with Windows SChannel support. (--with-winschannel)])])
+AC_MSG_RESULT([$with_winschannel])
+AC_SUBST(with_winschannel)
+
+if test $with_openssl = yes -a $with_winschannel = yes ; then
+  AC_MSG_ERROR([
+*** Cannot select both OpenSSL and Windows SChannel.])
+fi
+
+#
 # SELinux
 #
 AC_MSG_CHECKING([whether to build with SELinux support])
diff --git a/src/backend/libpq/Makefile b/src/backend/libpq/Makefile
index 8be0572..88d0b8b 100644
--- a/src/backend/libpq/Makefile
+++ b/src/backend/libpq/Makefile
@@ -21,4 +21,8 @@ ifeq ($(with_openssl),yes)
 OBJS += be-secure-openssl.o
 endif
 
+ifeq ($(with_winschannel),yes)
+OBJS += be-secure-winschannel.o
+endif
+
 include $(top_srcdir)/src/backend/common.mk
diff 

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Jeff Janes]

On Fri, Aug 1, 2014 at 10:58 AM, Heikki Linnakangas hlinnakan...@vmware.com
 wrote:

 On 07/08/2014 08:11 PM, Jeff Janes wrote:

 Is there some recipe for testing the 0002 patch?  Can it be tested on an
 MinGW environment, or does it need to use the MicroSoft supplied
 compilers?


 I used MSVC. It ought to work with MinGW, I think, although you might need
 to tweak the Makefiles to make it compile. Certainly we should eventually
 make it work, before committing. If you try it out, let me know how it goes.


I couldn't it to work when I tried it long time ago, but I didn't record
the error and it may have been a failure to use the correct arguments to
the configure.  I think it was taking a path through all the #ifdef that
resulted in a function never getting defined.

But now it looks like 0002 needs a rebase

Cheers,

Jeff

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Heikki Linnakangas]

On 07/11/2014 08:39 PM, Alvaro Herrera wrote:

Heikki Linnakangas wrote:


I did again the refactoring you did back in 2006, patch attached.
One thing I did differently: I moved the raw, non-encrypted,
read/write functions to separate functions: pqsecure_raw_read and
pqsecure_raw_write. Those functions encapsulate the SIGPIPE
handling. The OpenSSL code implements a custom BIO, which calls to
pqsecure_raw_read/write to do the low-level I/O.  Similarly in the
server-side, there are be_tls_raw_read and pg_tls_raw_write
functions, which do the
prepare_for_client_read()/client_read_ended() dance, so that the SSL
implementation doesn't need to know about that.


I'm skimming over this patch (0001).  There are some issues:

* You duplicated the long comment under the IDENTIFICATION tag that was
   in be-secure.c; it's now both in that file and also in
   be-secure-openssl.c.  I think it should be removed from be-secure.c.
   Also, the hardcoded DH params are duplicated in be-secure.c, but they
   belong in -openssl.c only now.


Hmm. Once we add other SSL implementations, shouldn't they share the 
hardcoded DH parameters? That would warrant keeping them in be-secure.c.



* There is some mixup regarding USE_SSL and USE_OPENSSL in be-secure.c.
   I think anything that's OpenSSL-specific should be in
   be-secure-openssl.c only; any new SSL implementation will need to
   implement all those functions.  For instance, be_tls_init().


Agreed.


   I imagine that if we select any SSL implementation, USE_SSL would get
   defined, and each SSL implementation would additionally define its own
   symbol.


Yeah, that was the idea.


* ssl_renegotiation_limit is also duplicated.  But removing this one is
   probably not going to be as easy as deleting a line from be-secure.c,
   because guc.c depends on that one.  I think that variable should be
   defined in be-secure.c (i.e. delete it from -openssl) and make sure
   that all SSL implementations enforce it on their own somehow.


Agreed.


The DISABLE_SIGPIPE thingy looks wrong in pqsecure_write.  I think it
should be like this:

ssize_t
pqsecure_write(PGconn *conn, const void *ptr, size_t len)
{
ssize_t n;

#ifdef USE_SSL
if (conn-ssl_in_use)
{
DECLARE_SIGPIPE_INFO(spinfo);

DISABLE_SIGPIPE(conn, spinfo, return -1);

n = pgtls_write(conn, ptr, len);

RESTORE_SIGPIPE(spinfo);
}
else
#endif   /* USE_OPENSSL */
{
n = pqsecure_raw_write(conn, ptr, len);
}

return n;
}

You are missing the restore call, and I moved the declaration inside the
ssl_in_use block since otherwise it's not useful.  The other path is
fine since pqsecure_raw_write disables and restores the flag by itself.
Also, you're missing DECLARE/DISABLE/RESTORE in the ssl_in_use block in
pqsecure_read.  (The original code does not have that code in the
non-SSL path.  I assume, without checking, that that's okay.)  I also
assume without checking that all SSL implementations would be fine with
this SIGPIPE handling.

Another thing that seems wrong is the REMEMBER_EPIPE stuff.  The
fe-secure-openssl.c code should be setting the flag, but AFAICS only the
non-SSL code is doing it.


I think you're missing a change to the way fe-secure-openssl.c now uses 
the OpenSSL library: it defines custom read/write functions, 
my_sock_read and my_sock_write, which in turn call 
pqsecure_raw_read/write. So all the actual I/O now goes through 
pqsecure_raw_read/write. I believe it's therefore enough to put do the 
REMEMBER_EPIPE in pqsecure_raw_write. Come to think of it, 
pqsecure_write() shouldn't be doing any SIGPIGE stuff at all anymore.


- Heikki



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Heikki Linnakangas]

On 07/08/2014 08:11 PM, Jeff Janes wrote:

Is there some recipe for testing the 0002 patch?  Can it be tested on an
MinGW environment, or does it need to use the MicroSoft supplied compilers?


I used MSVC. It ought to work with MinGW, I think, although you might 
need to tweak the Makefiles to make it compile. Certainly we should 
eventually make it work, before committing. If you try it out, let me 
know how it goes.


- Heikki



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Alvaro Herrera]

Heikki Linnakangas wrote:

 I did again the refactoring you did back in 2006, patch attached.
 One thing I did differently: I moved the raw, non-encrypted,
 read/write functions to separate functions: pqsecure_raw_read and
 pqsecure_raw_write. Those functions encapsulate the SIGPIPE
 handling. The OpenSSL code implements a custom BIO, which calls to
 pqsecure_raw_read/write to do the low-level I/O.  Similarly in the
 server-side, there are be_tls_raw_read and pg_tls_raw_write
 functions, which do the
 prepare_for_client_read()/client_read_ended() dance, so that the SSL
 implementation doesn't need to know about that.

I'm skimming over this patch (0001).  There are some issues:

* You duplicated the long comment under the IDENTIFICATION tag that was
  in be-secure.c; it's now both in that file and also in
  be-secure-openssl.c.  I think it should be removed from be-secure.c.
  Also, the hardcoded DH params are duplicated in be-secure.c, but they
  belong in -openssl.c only now.

* There is some mixup regarding USE_SSL and USE_OPENSSL in be-secure.c.
  I think anything that's OpenSSL-specific should be in
  be-secure-openssl.c only; any new SSL implementation will need to
  implement all those functions.  For instance, be_tls_init().
  I imagine that if we select any SSL implementation, USE_SSL would get
  defined, and each SSL implementation would additionally define its own
  symbol.  Unless the idea is to get rid of USE_OPENSSL completely, and
  use only the Makefile bit to decide which implementation to use?  If
  so, then USE_OPENSSL as a preprocessor symbol is useless ...

* ssl_renegotiation_limit is also duplicated.  But removing this one is
  probably not going to be as easy as deleting a line from be-secure.c,
  because guc.c depends on that one.  I think that variable should be
  defined in be-secure.c (i.e. delete it from -openssl) and make sure
  that all SSL implementations enforce it on their own somehow.

The DISABLE_SIGPIPE thingy looks wrong in pqsecure_write.  I think it
should be like this:

ssize_t
pqsecure_write(PGconn *conn, const void *ptr, size_t len)
{
ssize_t n;

#ifdef USE_SSL
if (conn-ssl_in_use)
{
DECLARE_SIGPIPE_INFO(spinfo);

DISABLE_SIGPIPE(conn, spinfo, return -1);

n = pgtls_write(conn, ptr, len);

RESTORE_SIGPIPE(spinfo);
}
else 
#endif   /* USE_OPENSSL */
{
n = pqsecure_raw_write(conn, ptr, len);
}

return n;
}

You are missing the restore call, and I moved the declaration inside the
ssl_in_use block since otherwise it's not useful.  The other path is
fine since pqsecure_raw_write disables and restores the flag by itself.
Also, you're missing DECLARE/DISABLE/RESTORE in the ssl_in_use block in
pqsecure_read.  (The original code does not have that code in the
non-SSL path.  I assume, without checking, that that's okay.)  I also
assume without checking that all SSL implementations would be fine with
this SIGPIPE handling.

Another thing that seems wrong is the REMEMBER_EPIPE stuff.  The
fe-secure-openssl.c code should be setting the flag, but AFAICS only the
non-SSL code is doing it.


Thanks for working on this -- I'm sure many distributors will be happy
to be able to enable other, less license-broken TLS implementations.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training  Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Jeff Janes]

On Thu, Jun 26, 2014 at 4:26 PM, Andreas Karlsson andr...@proxel.se wrote:

 On 06/24/2014 03:20 AM, Jeff Janes wrote:

 I've tried your 0001 patch, reflecting this refactoring, on Linux and it
 caused 'make check' to hang at 'starting postmaster'.


 I found the bug in the code, and I have attached the a patch which you can
 apply on top of the patch. The regression tests pass now on my Debian
 machine.


Your fix works for me as well.  Thanks.

Is there some recipe for testing the 0002 patch?  Can it be tested on an
MinGW environment, or does it need to use the MicroSoft supplied compilers?

Thanks,

Jeff

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Andreas Karlsson]

On 06/24/2014 03:20 AM, Jeff Janes wrote:

I've tried your 0001 patch, reflecting this refactoring, on Linux and it
caused 'make check' to hang at 'starting postmaster'.


I found the bug in the code, and I have attached the a patch which you 
can apply on top of the patch. The regression tests pass now on my 
Debian machine.


One thing I noticed when trying to find the bug is that be-secure.c 
still includes some OpenSSL headers. Those should be removed since they 
have already been moved to be-secure-openssl.c.


--
Andreas Karlsson
diff --git a/src/backend/libpq/be-secure.c b/src/backend/libpq/be-secure.c
index 6d943cf..11f67c4 100644
--- a/src/backend/libpq/be-secure.c
+++ b/src/backend/libpq/be-secure.c
@@ -280,7 +280,7 @@ secure_write(Port *port, void *ptr, size_t len)
 	}
 	else
 #endif
-		n = secure_raw_read(port, ptr, len);
+		n = secure_raw_write(port, ptr, len);
 
 	return n;
 }

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Magnus Hagander]

On Monday, June 9, 2014, Heikki Linnakangas hlinnakan...@vmware.com wrote:

 Hi,

 I've been looking at Windows' native SSL implementatation, the SChannel
 API. It would be nice to support that as a replacement for OpenSSL on
 Windows. Currently, we bundle the OpenSSL library in the PostgreSQL,
 installers, which is annoying because whenever OpenSSL puts out a new
 release that fixes vulnerabilities, we need to do a security release of
 PostgreSQL on Windows. I was reminded of this recently wrt. psqlODBC, which
 bundles libpq and openssl as well. It's particularly annoying for psqlODBC
 and other client applications, as people typically update it less
 diligently than their servers.

 I think that we should keep the user-visible behavior the same, i.e. the
 libpq connection options, locations of the certificate files etc. would all
 be the same regardless of which SSL implementation is used. Using Windows
 SChannel API might make it possible to integrate better with Windows' own
 certificate store etc. but I don't really know much about that stuff, so
 for starters I'd like to just use it as a drop-in replacement for OpenSSL.

 Thoughts? While we're at it, we'll probably want to refactor things so
 that it's easy to support other SSL implementations too, like gnutls.


It's a project that many have started, and nobody has finished :) I'm
definitely interested in working on such a things, but I've been unable to
carve out enough time recently.

One problem is as you say, that we're exposing openssl too much. For one
thing, we *cannot* keep the current interface, because it returns OpenSSL
internal datastructures. Those functions will need to be deprecated and
replaced with something else.

Also, my memory says that SChannel doesn't support the key file format that
we use now, which makes a much bigger break with the supported platforms.
That may have changed of course - have you researched that part?

The main other entries I've been looking at are NSS and gnutls, both of
which can speak our current file formats. I think the right thing is to
start with those and thereby make it more pluggable, and only after that
tackle schannel. But I do think it would be good to have them all.

It's also a question of if we can accept supporting a different set of
libraries on the server vs on the client. It's really on the client that
it's a bigger problem, but in the end I think we want to have symmetrical
support. But it might be worth doing just the client side initially, and
then move to the server. I think in general, the client side is actually
likely to be *harder* than the server side..



-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Heikki Linnakangas]

On 06/09/2014 02:53 PM, Magnus Hagander wrote:

Also, my memory says that SChannel doesn't support the key file format that
we use now, which makes a much bigger break with the supported platforms.
That may have changed of course - have you researched that part?


A quick web search turned up a few discussion forums threads with a 
recipe for this (e.g 
https://stackoverflow.com/questions/1231178/load-an-x509-pem-file-into-windows-cryptoapi). 
There's no direct read this file function, but there are low-level 
functions that can decode the file format once it's read into memory. So 
it seems possible to make it work.



It's also a question of if we can accept supporting a different set of
libraries on the server vs on the client. It's really on the client that
it's a bigger problem, but in the end I think we want to have symmetrical
support. But it might be worth doing just the client side initially, and
then move to the server. I think in general, the client side is actually
likely to be *harder* than the server side..


Once we've modified the client to support multiple libraries, it's 
probably not much extra effort to do the same to the server. I wouldn't 
like to support different libraries in client and server, if only 
because it would be more complicated to have separate ./configure 
options for client and server.


- Heikki


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Andres Freund]

On 2014-06-09 13:53:15 +0200, Magnus Hagander wrote:
 The main other entries I've been looking at are NSS and gnutls, both of
 which can speak our current file formats. I think the right thing is to
 start with those and thereby make it more pluggable, and only after that
 tackle schannel. But I do think it would be good to have them all.

I think NSS makes a great deal of sense - the advantages of supporting
gnutls are much less clear to me. Maybe it's little enough additional
code that that doesn't matter much, but we imo shouldn't focus on it.

Greetings,

Andres Freund

-- 
 Andres Freund http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training  Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Marko Kreen]

On Mon, Jun 09, 2014 at 02:45:08PM +0300, Heikki Linnakangas wrote:
 Thoughts? While we're at it, we'll probably want to refactor things
 so that it's easy to support other SSL implementations too, like
 gnutls.

One project that is proud to support several SSL implementations
is curl: http://curl.haxx.se/

Git: https://github.com/bagder/curl.git
Implementations: https://github.com/bagder/curl/tree/master/lib/vtls

List from vtls.c:

- OpenSSL
- GnuTLS
- NSS
- QsoSSL
- GSKit
- PolarSSL
- CyaSSL
- Schannel SSPI
- SecureTransport (Darwin)

We cannot reuse the code directly, but seems it's usable for
reference for various gotchas that need to be solved.

-- 
marko



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Andreas Karlsson]

On 06/09/2014 01:45 PM, Heikki Linnakangas wrote:

Thoughts? While we're at it, we'll probably want to refactor things so
that it's easy to support other SSL implementations too, like gnutls.


There was a patch set for this from Martijn van Oosterhout which was 
quite complete.


http://www.postgresql.org/message-id/20060504134807.gk4...@svana.org

I am interested in dropping the dependency on OpenSSL, if only to fix 
the situation with Debian, libreadline and OpenSSL[1].


Notes

1. They now compile against libedit and change to using libreadline at 
runtime. This does not work perfectly though since libreadline supports 
some features which libedit does not which can only be checked for at 
compile time.


Andreas




--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Magnus Hagander]

On Mon, Jun 9, 2014 at 3:19 PM, Andreas Karlsson andr...@proxel.se wrote:

 On 06/09/2014 01:45 PM, Heikki Linnakangas wrote:

 Thoughts? While we're at it, we'll probably want to refactor things so
 that it's easy to support other SSL implementations too, like gnutls.


 There was a patch set for this from Martijn van Oosterhout which was quite
 complete.

 http://www.postgresql.org/message-id/20060504134807.gk4...@svana.org


A lot has, unfortunately, changed since 2006. It might be a good
startingpoint. But also actively starting from the point of let's try to
support multiple libraries rather than let's try to support gnutls is
probably also important.


I am interested in dropping the dependency on OpenSSL, if only to fix the
 situation with Debian, libreadline and OpenSSL[1].


That's one of the many reasons, yes :)


At some point we should design a new API, so that we can deprecate the old
one. Even if we don't hve the code ready, we need to get rid of PQgetssl(),
and replace it with something else. I'm thinking probably a functoin that
returns both a void pointer and an enum that tells you which library is
actually in use. And a boolean just saying ssl on/off, because that's
what a lot of clients are interested in and they don't care aobut more than
that.

Obviously, we also have to do something about PQinitOpenSSL().

Unfortunately, I think it's too late to do that for 9.4 - otherwise it
would've been good to have a whole cycle of deprecation on it...

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Magnus Hagander]

On Mon, Jun 9, 2014 at 3:02 PM, Marko Kreen mark...@gmail.com wrote:

 On Mon, Jun 09, 2014 at 02:45:08PM +0300, Heikki Linnakangas wrote:
  Thoughts? While we're at it, we'll probably want to refactor things
  so that it's easy to support other SSL implementations too, like
  gnutls.

 One project that is proud to support several SSL implementations
 is curl: http://curl.haxx.se/

 Git: https://github.com/bagder/curl.git
 Implementations: https://github.com/bagder/curl/tree/master/lib/vtls

 List from vtls.c:

 - OpenSSL
 - GnuTLS
 - NSS
 - QsoSSL
 - GSKit
 - PolarSSL
 - CyaSSL
 - Schannel SSPI
 - SecureTransport (Darwin)

 We cannot reuse the code directly, but seems it's usable for
 reference for various gotchas that need to be solved.


I did actually talk to Daniel at some point about turning that into a
generalized library, and/or getting him interested in helping out with it.
I can't remember where that ended up - I'll see if I can poke his interest
:)

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Tom Lane]

Heikki Linnakangas hlinnakan...@vmware.com writes:
 I've been looking at Windows' native SSL implementatation, the SChannel 
 API. It would be nice to support that as a replacement for OpenSSL on 
 Windows. Currently, we bundle the OpenSSL library in the PostgreSQL, 
 installers, which is annoying because whenever OpenSSL puts out a new 
 release that fixes vulnerabilities, we need to do a security release of 
 PostgreSQL on Windows.

Does SChannel have a better security track record than OpenSSL?  Or is
the point here just that we can define it as not our problem when a
vulnerability surfaces?

I'm doubtful that we can ignore security issues affecting PG just because
somebody else is responsible for shipping the fix, and thus am concerned
that if we support N different SSL libraries, we will need to keep track
of N sets of vulnerabilities instead of just one.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Andres Freund]

Hi,

On 2014-06-09 10:18:40 -0400, Tom Lane wrote:
 Does SChannel have a better security track record than OpenSSL?  Or is
 the point here just that we can define it as not our problem when a
 vulnerability surfaces?

Well, it's patched as part of the OS - so no new PG binaries have to be
released when it's buggy.

 I'm doubtful that we can ignore security issues affecting PG just because
 somebody else is responsible for shipping the fix, and thus am concerned
 that if we support N different SSL libraries, we will need to keep track
 of N sets of vulnerabilities instead of just one.

In most of the cases where such a issue exists it'll primarily affect
binary distributions that include the ssl library - and those will only
pick one anyway.

Greetings,

Andres Freund

-- 
 Andres Freund http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training  Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[MauMau]

From: Heikki Linnakangas hlinnakan...@vmware.com
Thoughts? While we're at it, we'll probably want to refactor things so 
that it's easy to support other SSL implementations too, like gnutls.


That may be good because it provides users with choices.  But I wonder if it 
is worth the complexity and maintainability of PostgreSQL code.


* Are SChannel and other libraries more secure than OpenSSL?  IIRC, recently 
I read in the news that GnuTLS had a vulnerability.  OpenSSL is probably the 
most widely used library, and many people are getting more interested in its 
quality.  I expect the quality will improve thanks to the help from The 
Linux foundation and other organizations/researchers.


* Do other libraries get support from commercial vendor product support? 
For example, Safenet Inc., the famous HSM (hardware security module) vendor, 
supports OpenSSL to access the private key stored in its HSM product.  Intel 
offered AES-NI implementation code to OpenSSL community.  I guess OpenSSL 
will continue to be the most functional and obtain the widest adoption and 
support.


Regards
MauMau



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Martijn van Oosterhout]

On Mon, Jun 09, 2014 at 03:35:23PM +0200, Magnus Hagander wrote:
 On Mon, Jun 9, 2014 at 3:19 PM, Andreas Karlsson andr...@proxel.se wrote:
 
  On 06/09/2014 01:45 PM, Heikki Linnakangas wrote:
  There was a patch set for this from Martijn van Oosterhout which was quite
  complete.
 
  http://www.postgresql.org/message-id/20060504134807.gk4...@svana.org

Wow, blast from the past.

 A lot has, unfortunately, changed since 2006. It might be a good
 startingpoint. But also actively starting from the point of let's try to
 support multiple libraries rather than let's try to support gnutls is
 probably also important.

The patch did provide an API. The idea was that there were a number of
functions which would need to be defined to support an SSL library.
Each library would then have a wrapper which wrapped the library and
based on the results of configure it compiled the right file into the
backend.

These functions were:

extern void pgtls_initialize(void);
extern void pgtls_destroy(void);
extern int pgtls_open_server(Port *);
extern void pgtls_close(Port *);
extern ssize_t pgtls_read(Port *port, void *ptr, size_t len);
extern ssize_t pgtls_write(Port *port, void *ptr, size_t len);

Which should be easy enough to support for any library. These days
you'd need to add support for verifying certificates, but I don't think
that that would be difficult (unless the actual certificate formats are
different).

No switching after compile time, that would just lead to useless
overhead.

 At some point we should design a new API, so that we can deprecate the old
 one. Even if we don't hve the code ready, we need to get rid of PQgetssl(),
 and replace it with something else. I'm thinking probably a functoin that
 returns both a void pointer and an enum that tells you which library is
 actually in use. And a boolean just saying ssl on/off, because that's
 what a lot of clients are interested in and they don't care aobut more than
 that.
 
 Obviously, we also have to do something about PQinitOpenSSL().

Yeah, I think this was one of the more controversial parts. Support in
the backend was primarily moving code around and renaming functions,
fairly straightforward.  Even error handling was not so hard (I found
the gnutls handling of errors much easier than openssl).

One tricky part is that programs like to use libpq for the
authentication, and then they hijack the connection using PGgetssl(). 
The way I dealt with this is defining a new state passthrough where
the caller would get a few function pointers to read/write/check the
connection.  Then the callers would not need to know what library libpq
was compiled with.  And libpq would know the connection was hijacked
and refuse to act anymore.  I don't think everyone was pleased with
this, but no real alternative was presented (other than requiring
people hijacking the connection to do the hard work).

For information about which library was in use there was PQgettlsinfo()
which returned a PGresult with information about the library and
connection.  I beleive since then new functions have been added to
libpq to retrive info about certificates, so that might need a rethink
also.

Basically, I think these last two points are the hard parts to get
agreement (assuming there's agreement to do anything at all about the
problem) and without nailing those down first whoever picks this up
will be in for a lot of work.

Have a nice day,
-- 
Martijn van Oosterhout   klep...@svana.org   http://svana.org/kleptog/
 He who writes carelessly confesses thereby at the very outset that he does
 not attach much importance to his own thoughts.
   -- Arthur Schopenhauer


signature.asc
Description: Digital signature

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Heikki Linnakangas]

On 06/09/2014 05:22 PM, Andres Freund wrote:

Hi,

On 2014-06-09 10:18:40 -0400, Tom Lane wrote:

Does SChannel have a better security track record than OpenSSL?  Or is
the point here just that we can define it as not our problem when a
vulnerability surfaces?


Well, it's patched as part of the OS - so no new PG binaries have to be
released when it's buggy.


Right. I have no idea what SChannel's track record is, but when there's 
a vulnerability in the native SSL implementation in Windows, you better 
upgrade anyway, regardless of PostgreSQL. So when we rely on that, we 
don't put any extra burden on users. And we won't need to release new 
binaries just to update the DLL included in it.


- Heikki


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Robert Haas]

On Mon, Jun 9, 2014 at 10:40 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
 Right. I have no idea what SChannel's track record is, but when there's a
 vulnerability in the native SSL implementation in Windows, you better
 upgrade anyway, regardless of PostgreSQL. So when we rely on that, we don't
 put any extra burden on users. And we won't need to release new binaries
 just to update the DLL included in it.

Right, heartily agreed.  It wouldn't surprise me if there are lots of
Windows machines out there that have 4 or 5 copies of OpenSSL on them,
each provided by a different installer for some other piece of
software that happens to depend on OpenSSL.  When OpenSSL then has a
security vulnerability, you're not safe until all of the people who
produce those installers produce new versions and you upgrade to all
of those new versions.  In practice, I'm sure that an enormous amount
slips through the cracks here.  Relying on something that is part of
the OS and updated by the OS vendor seems like less work for both
packagers (who have to prepare the updates) and users (who have to
apply them).  Of course there may be cases where the OS implementation
sucks badly or otherwise can't be relied upon, and then we'll just
have to live with shipping copies of things.  But avoiding it sounds
better, if someone's volunteering to do the work

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Magnus Hagander]

On Mon, Jun 9, 2014 at 4:39 PM, Martijn van Oosterhout klep...@svana.org
wrote:

 On Mon, Jun 09, 2014 at 03:35:23PM +0200, Magnus Hagander wrote:
  On Mon, Jun 9, 2014 at 3:19 PM, Andreas Karlsson andr...@proxel.se
 wrote:
 
   On 06/09/2014 01:45 PM, Heikki Linnakangas wrote:
   There was a patch set for this from Martijn van Oosterhout which was
 quite
   complete.
  
   http://www.postgresql.org/message-id/20060504134807.gk4...@svana.org

 Wow, blast from the past.


That's fun, itsn't it? :)


 A lot has, unfortunately, changed since 2006. It might be a good
  startingpoint. But also actively starting from the point of let's try to
  support multiple libraries rather than let's try to support gnutls is
  probably also important.

 The patch did provide an API. The idea was that there were a number of
 functions which would need to be defined to support an SSL library.
 Each library would then have a wrapper which wrapped the library and
 based on the results of configure it compiled the right file into the
 backend.

 These functions were:

 extern void pgtls_initialize(void);
 extern void pgtls_destroy(void);
 extern int pgtls_open_server(Port *);
 extern void pgtls_close(Port *);
 extern ssize_t pgtls_read(Port *port, void *ptr, size_t len);
 extern ssize_t pgtls_write(Port *port, void *ptr, size_t len);

 Which should be easy enough to support for any library. These days
 you'd need to add support for verifying certificates, but I don't think
 that that would be difficult (unless the actual certificate formats are
 different).


The two difficult points I think are the async support (libpq) and the
windows socket emulation support (backend). Do those really work there? In
particular the win32 stuff - though I guess that's less critical since we
can actually do hackish things there, unlike in libpq. But the example
there is that we can't have the library use recv()/send(), instead having
it work through our own functions.



 No switching after compile time, that would just lead to useless
 overhead.


Yes, I absolutely think we don't need to support 1 library at runtime.


 At some point we should design a new API, so that we can deprecate the old
  one. Even if we don't hve the code ready, we need to get rid of
 PQgetssl(),
  and replace it with something else. I'm thinking probably a functoin that
  returns both a void pointer and an enum that tells you which library is
  actually in use. And a boolean just saying ssl on/off, because that's
  what a lot of clients are interested in and they don't care aobut more
 than
  that.
 
  Obviously, we also have to do something about PQinitOpenSSL().

 Yeah, I think this was one of the more controversial parts. Support in
 the backend was primarily moving code around and renaming functions,
 fairly straightforward.  Even error handling was not so hard (I found
 the gnutls handling of errors much easier than openssl).


Yeah, the backend is easier, but also less important from the original
reason. For the patching reason, it's of course just as important.


One tricky part is that programs like to use libpq for the
 authentication, and then they hijack the connection using PGgetssl().


Is there *anybody* other than odbc that does that? Do we actually need a
published API for that, or just a hack for pgodbc?



 The way I dealt with this is defining a new state passthrough where
 the caller would get a few function pointers to read/write/check the
 connection.  Then the callers would not need to know what library libpq
 was compiled with.  And libpq would know the connection was hijacked
 and refuse to act anymore.  I don't think everyone was pleased with
 this, but no real alternative was presented (other than requiring
 people hijacking the connection to do the hard work).

 For information about which library was in use there was PQgettlsinfo()
 which returned a PGresult with information about the library and
 connection.  I beleive since then new functions have been added to
 libpq to retrive info about certificates, so that might need a rethink
 also.


Not really, no. we return the OpenSSL structure and have the client use
that one directly. That's quite horrible already :)


Basically, I think these last two points are the hard parts to get
 agreement (assuming there's agreement to do anything at all about the
 problem) and without nailing those down first whoever picks this up
 will be in for a lot of work.


Agreed.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Martijn van Oosterhout]

On Mon, Jun 09, 2014 at 11:39:17PM +0900, MauMau wrote:
 From: Heikki Linnakangas hlinnakan...@vmware.com
 Thoughts? While we're at it, we'll probably want to refactor
 things so that it's easy to support other SSL implementations too,
 like gnutls.
 
 That may be good because it provides users with choices.  But I
 wonder if it is worth the complexity and maintainability of
 PostgreSQL code.

The complexity is very low. SSL is a standard protocol and so all
libraries offer the same functionality. Were not really doing anything
complex.

 * Are SChannel and other libraries more secure than OpenSSL?  IIRC,
 recently I read in the news that GnuTLS had a vulnerability.
 OpenSSL is probably the most widely used library, and many people
 are getting more interested in its quality.  I expect the quality
 will improve thanks to the help from The Linux foundation and other
 organizations/researchers.

Does that matter? What's wrong with letting people choose. OpenVPN
these days supports multiple SSL libraries, because PolarSSL (for
example) has been vetted for a higher security level than OpenSSL.

 * Do other libraries get support from commercial vendor product
 support? For example, Safenet Inc., the famous HSM (hardware
 security module) vendor, supports OpenSSL to access the private key
 stored in its HSM product.  Intel offered AES-NI implementation code
 to OpenSSL community.  I guess OpenSSL will continue to be the most
 functional and obtain the widest adoption and support.

And the crappiest license. I think it's silly for PostgreSQL dictate
what SSL library users must use, when there are so many possibilities. 
We also support libedit for, in my opinion, worse reasons.

Have a nice day,
-- 
Martijn van Oosterhout   klep...@svana.org   http://svana.org/kleptog/
 He who writes carelessly confesses thereby at the very outset that he does
 not attach much importance to his own thoughts.
   -- Arthur Schopenhauer


signature.asc
Description: Digital signature

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Heikki Linnakangas]

On 06/09/2014 06:03 PM, Magnus Hagander wrote:

One tricky part is that programs like to use libpq for the

authentication, and then they hijack the connection using PGgetssl().


Is there*anybody*  other than odbc that does that? Do we actually need a
published API for that, or just a hack for pgodbc?


I wish psqlODBC would stop doing that. It's kind of cool that it 
supports compiling without libpq, but it's really quite a mess. I think 
we should modify psqlODBC to use the libpq API like most people do.


- Heikki


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

[Magnus Hagander]

On Mon, Jun 9, 2014 at 7:45 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:

 On 06/09/2014 06:03 PM, Magnus Hagander wrote:

 One tricky part is that programs like to use libpq for the

 authentication, and then they hijack the connection using PGgetssl().
 

 Is there*anybody*  other than odbc that does that? Do we actually need a

 published API for that, or just a hack for pgodbc?


 I wish psqlODBC would stop doing that. It's kind of cool that it supports
 compiling without libpq, but it's really quite a mess. I think we should
 modify psqlODBC to use the libpq API like most people do.


This was, I believe, done at one point, and then reverted. I think that was
because libpq didn't actually have all the features required either for the
current or for planned featues of the ODBC driver. That situation might be
very different now though, there's more functionality available in libpq..

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/