SSL connection to DB server gone in 8.0?
"DatabaseConnection": { # Used to connect to an external database if DBType is non-empty "endpoint": "", # Database connection endpoint "database": "", # Name of database or Oracle SID "user": "", # User name to connect as "password": "", # Password to use }, Is this intentional to omit the ssl parameter here? Axel --- PGP-Key:29E99DD6 ☀ computing @ chaos claudius
Hi, "Endpoint" in this context means "twisted endpoint". Twisted endpoints provide an abstract (but not too abstract) means for doing things like listening and connecting, and include TLS support. https://twistedmatrix.com/documents/current/core/howto/endpoints.html An example (minimally specified) TLS endpoint: tls:example.com:443. Note: we tend to use UNIX domain sockets much more than TCP these days, and I don't believe I've ever tested TLS from CalendarServer to Postgres, but it should work if Postgres is configured correctly and you do the right stuff with certs, etc. To answer your question, I think the adoption of endpoints by CalendarServer was intended to reap the benefits of endpoints over the previous connection handling code, and omission of a separate TLS parameter is a side effect. -dre Sent from my iPhone
On Jun 2, 2016, at 8:48 AM, Axel Rau <Axel.Rau@chaos1.de> wrote:
"DatabaseConnection": { # Used to connect to an external database if DBType is non-empty "endpoint": "", # Database connection endpoint "database": "", # Name of database or Oracle SID "user": "", # User name to connect as "password": "", # Password to use }, Is this intentional to omit the ssl parameter here?
Axel --- PGP-Key:29E99DD6 ☀ computing @ chaos claudius
_______________________________________________ calendarserver-dev mailing list calendarserver-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-dev
Hi Andre, I come back to this.
Am 03.06.2016 um 03:48 schrieb Andre LaBranche <dre@apple.com>:
https://twistedmatrix.com/documents/current/core/howto/endpoints.html <https://twistedmatrix.com/documents/current/core/howto/endpoints.html>
An example (minimally specified) TLS endpoint: tls:example.com:443.
Note: we tend to use UNIX domain sockets much more than TCP these days, and I don't believe I've ever tested TLS from CalendarServer to Postgres, but it should work if Postgres is configured correctly and you do the right stuff with certs, etc.
If I try this: - - - <key>endpoint</key> <string>tls:db4.lrau.net</string> - - - I get: - - - File "/usr/local/lib/python2.7/site-packages/txdav/base/datastore/dbapiclient.py", line 308, in _connectorFor_pg8000 if params.unixsocket: AttributeError: 'DBAPIParameters' object has no attribute 'unixsocket' - - - In dbapiclient.py, I see: - - - if self.endpoint.startswith("unix:"): . . . elif self.endpoint.startswith("tcp:"): . . . self.user = user - - - Shall I report a bug for this? Axel --- PGP-Key:29E99DD6 ☀ computing @ chaos claudius
Hi,
On Jun 15, 2016, at 9:26 AM, Andre LaBranche <dre@apple.com> wrote:
On Jun 14, 2016, at 4:46 AM, Axel Rau <Axel.Rau@Chaos1.DE> wrote:
Shall I report a bug for this?
Yeah, looks like we don't accept tcps.
I tried the most naive thing I could think of, since I believe none of the parameters we pass down to pg8000 are TLS-aware - I think it's a negotiation that happens at connect time. Index: txdav/base/datastore/dbapiclient.py =================================================================== --- txdav/base/datastore/dbapiclient.py (revision 15694) +++ txdav/base/datastore/dbapiclient.py (working copy) @@ -218,7 +218,7 @@ else: self.port = None self.host = None - elif self.endpoint.startswith("tcp:"): + elif self.endpoint.startswith("tcp:") or self.endpoint.startswith("tcps:"): self.unixsocket = None self.host = self.endpoint[4:] if ":" in self.host: However in trying to test this, I realized that we don't build postgres with SSL support. When I added "--with-openssl" to the PG configure args (in bin/_build.sh), it blows up on me because my OS vendor totally doesn't ship openssl headers, and I'm not trying to solve that right now... but maybe I can get it going via Homebrew. In the mean time, feel free to try the above patch and let me know if it 'just works' :) -dre
Rebuilding PG with openssl support wasn't that hard. Turns out I already had openssl installed via brew, so just needed to define a couple env vars.
I tried the most naive thing I could think of,
... no it's not that simple. Also because that patch is bunk, as the string slice is off by one, so fails to capture the entire hostname when there is a tcps: prefix.
since I believe none of the parameters we pass down to pg8000 are TLS-aware
Yes, they are. The one called 'ssl' in pg8000/__init__.py which is a bool. After some reckless hacking, I got this to work, verified by the fact that my PG server is configured to allow only connections that use SSL. I'll clean this up and do some more testing before committing. -dre
Hi, Fixed in http://trac.calendarserver.org/changeset/15710/CalendarServer/trunk <http://trac.calendarserver.org/changeset/15710/CalendarServer/trunk> Because pg8000 has a separate kwarg to enable SSL, and because Twisted / endpoints don't have to do anything differently for an SSL connection via pg8000 to succeed, I went with a separate 'ssl' option for the DB config dict instead of adding support for a 'tcps' prefix. Although the pg8000 documentation doesn't state this explicitly, testing shows that enabling this option *requires <http://trac.calendarserver.org/changeset/15714/CalendarServer/trunk>* SSL, and does not merely use SSL if available. The connection will fail if SSL is not available. -dre
On Jun 24, 2016, at 3:50 PM, Andre LaBranche <dre@apple.com> wrote:
Rebuilding PG with openssl support wasn't that hard. Turns out I already had openssl installed via brew, so just needed to define a couple env vars.
I tried the most naive thing I could think of,
... no it's not that simple. Also because that patch is bunk, as the string slice is off by one, so fails to capture the entire hostname when there is a tcps: prefix.
since I believe none of the parameters we pass down to pg8000 are TLS-aware
Yes, they are. The one called 'ssl' in pg8000/__init__.py which is a bool.
After some reckless hacking, I got this to work, verified by the fact that my PG server is configured to allow only connections that use SSL. I'll clean this up and do some more testing before committing.
-dre _______________________________________________ calendarserver-dev mailing list calendarserver-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-dev
participants (3)
-
Andre LaBranche
-
Axel Rau
-
Axel Rau