Обсуждение: Fwd: [PATCHES] Preliminary GSSAPI Patches
OK, so posted. ;-) To clarify for the larger audience: without the plain "gss" mechanism, the "gss-np" mechanism provides exactly the same functionality as the existing krb5 mechanism. It will properly secure the initial connection, but will not do anything once the connection is established. If the Kerberos GSSAPI mechanism is used then it will follow exactly the same naming and file location conventions. What you gain is 1) it builds on Solaris 8+ with the built-in system Kerberos support (no separate Kerberos install needed), 2) the mechanism is portable to Java and native Windows clients, and 3) if you have a mechanism other than Kerberos available (e.g. SPKM, or SPNEGO/NTLM) in your GSSAPI then you could use it in place of Kerberos. I'm afraid that the politics at work that might have caused an adoption of a GSSAPI/JGSS Postgres Java client have changed, and they will be using MySQL instead. |-( Given what I've said here, I still feel obligated to provide Java mods, but your timeline will affect mine. Begin forwarded message: > From: Bruce Momjian <bruce@momjian.us> > Date: April 30, 2007 2:22:08 PM PDT > To: "Henry B. Hotz" <hotz@jpl.nasa.gov> > Subject: Re: [PATCHES] Preliminary GSSAPI Patches > > > Please post this info to the hackers list and we will deal with it. I > am thinking we might just keep this all for 8.4. > > ---------------------------------------------------------------------- > ----- > > Henry B. Hotz wrote: >> Thanks! >> >> As noted, the patch is incomplete w.r.t. the "gss" auth mech because >> it does not include code to actually encrypt the channel with the key >> derived from the auth mech. I confess I have so far been >> unsuccessful in inserting an additional layer of buffering to handle >> the block encryption. >> >> Would you like a new version of the patch with the incomplete >> functionality commented out (or otherwise removed)? >> >> Absent a volunteer to help, I think I should concentrate on getting >> the "gss-np" unprotected auth mech supported in the Java client. >> >> On Apr 26, 2007, at 4:09 PM, Bruce Momjian wrote: >> >>> >>> Your patch has been added to the PostgreSQL unapplied patches >>> list at: >>> >>> http://momjian.postgresql.org/cgi-bin/pgpatches >>> >>> It will be applied as soon as one of the PostgreSQL committers >>> reviews >>> and approves it. >>> >>> -------------------------------------------------------------------- >>> -- >>> ----- >>> >>> >>> Henry B. Hotz wrote: >>>> These patches have been reasonably tested (and cross-tested) on >>>> Solaris 9 (SPARC) and MacOS 10.4 (both G4 and Intel) with the >>>> native >>>> GSSAPI libraries. They implement the gss-np and (incompletely) the >>>> gss authentication methods. Unlike the current krb5 method gssapi >>>> has native support in Java and (with the SSPI) on Windows. >>>> >>>> I still have bugs in the security layer for the gss method. >>>> Hopefully will finish getting them ironed out today or tomorrow. >>>> >>>> Documentation is in the README.GSSAPI file. Make sure you get it >>>> created when you apply the patches. >>>> >>> >>> [ Attachment, skipping... ] >>> >>>> >>>> >>>> ------------------------------------------------------------------- >>>> -- >>>> --- >>>> The opinions expressed in this message are mine, >>>> not those of Caltech, JPL, NASA, or the US Government. >>>> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu >>>> >>>> >>>> >>>> ---------------------------(end of >>>> broadcast)--------------------------- >>>> TIP 7: You can help support the PostgreSQL project by donating at >>>> >>>> http://www.postgresql.org/about/donate >>> >>> -- >>> Bruce Momjian <bruce@momjian.us> http://momjian.us >>> EnterpriseDB http:// >>> www.enterprisedb.com >>> >>> + If your life is a hard drive, Christ can be your backup. + >> >> --------------------------------------------------------------------- >> --- >> The opinions expressed in this message are mine, >> not those of Caltech, JPL, NASA, or the US Government. >> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu >> > > -- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http:// > www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + ------------------------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
Excuse me for replying to myself, but maybe it would be clearer if I said this the other way around: The existing Kerberos support uses a C API that is not supported in Java or on Windows, and probably never will be. If we want to support Kerberos on *all* platforms (and if we want expandability to non-Kerberos, non-password authentication methods) then Postgres should use the GSSAPI instead. The submitted patches allow that. I tend to regard this as a comparable migration to the Kerb4 -> Kerb5 one. In time it should be a complete replacement. In time we will be able to rip out the existing Kerb5 code. On Apr 30, 2007, at 3:23 PM, Henry B. Hotz wrote: > OK, so posted. ;-) > > To clarify for the larger audience: without the plain "gss" > mechanism, the "gss-np" mechanism provides exactly the same > functionality as the existing krb5 mechanism. It will properly > secure the initial connection, but will not do anything once the > connection is established. If the Kerberos GSSAPI mechanism is > used then it will follow exactly the same naming and file location > conventions. > > What you gain is 1) it builds on Solaris 8+ with the built-in > system Kerberos support (no separate Kerberos install needed), 2) > the mechanism is portable to Java and native Windows clients, and > 3) if you have a mechanism other than Kerberos available (e.g. > SPKM, or SPNEGO/NTLM) in your GSSAPI then you could use it in place > of Kerberos. > > I'm afraid that the politics at work that might have caused an > adoption of a GSSAPI/JGSS Postgres Java client have changed, and > they will be using MySQL instead. |-( Given what I've said here, > I still feel obligated to provide Java mods, but your timeline will > affect mine. > > Begin forwarded message: > >> From: Bruce Momjian <bruce@momjian.us> >> Date: April 30, 2007 2:22:08 PM PDT >> To: "Henry B. Hotz" <hotz@jpl.nasa.gov> >> Subject: Re: [PATCHES] Preliminary GSSAPI Patches >> >> >> Please post this info to the hackers list and we will deal with >> it. I >> am thinking we might just keep this all for 8.4. >> >> --------------------------------------------------------------------- >> ------ >> >> Henry B. Hotz wrote: >>> Thanks! >>> >>> As noted, the patch is incomplete w.r.t. the "gss" auth mech because >>> it does not include code to actually encrypt the channel with the >>> key >>> derived from the auth mech. I confess I have so far been >>> unsuccessful in inserting an additional layer of buffering to handle >>> the block encryption. >>> >>> Would you like a new version of the patch with the incomplete >>> functionality commented out (or otherwise removed)? >>> >>> Absent a volunteer to help, I think I should concentrate on getting >>> the "gss-np" unprotected auth mech supported in the Java client. >>> >>> On Apr 26, 2007, at 4:09 PM, Bruce Momjian wrote: >>> >>>> >>>> Your patch has been added to the PostgreSQL unapplied patches >>>> list at: >>>> >>>> http://momjian.postgresql.org/cgi-bin/pgpatches >>>> >>>> It will be applied as soon as one of the PostgreSQL committers >>>> reviews >>>> and approves it. >>>> >>>> ------------------------------------------------------------------- >>>> --- >>>> ----- >>>> >>>> >>>> Henry B. Hotz wrote: >>>>> These patches have been reasonably tested (and cross-tested) on >>>>> Solaris 9 (SPARC) and MacOS 10.4 (both G4 and Intel) with the >>>>> native >>>>> GSSAPI libraries. They implement the gss-np and (incompletely) >>>>> the >>>>> gss authentication methods. Unlike the current krb5 method gssapi >>>>> has native support in Java and (with the SSPI) on Windows. >>>>> >>>>> I still have bugs in the security layer for the gss method. >>>>> Hopefully will finish getting them ironed out today or tomorrow. >>>>> >>>>> Documentation is in the README.GSSAPI file. Make sure you get it >>>>> created when you apply the patches. >>>>> >>>> >>>> [ Attachment, skipping... ] >>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------ >>>>> --- >>>>> --- >>>>> The opinions expressed in this message are mine, >>>>> not those of Caltech, JPL, NASA, or the US Government. >>>>> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu >>>>> >>>>> >>>>> >>>>> ---------------------------(end of >>>>> broadcast)--------------------------- >>>>> TIP 7: You can help support the PostgreSQL project by donating at >>>>> >>>>> http://www.postgresql.org/about/donate >>>> >>>> -- >>>> Bruce Momjian <bruce@momjian.us> http://momjian.us >>>> EnterpriseDB http:// >>>> www.enterprisedb.com >>>> >>>> + If your life is a hard drive, Christ can be your backup. + >>> >>> -------------------------------------------------------------------- >>> ---- >>> The opinions expressed in this message are mine, >>> not those of Caltech, JPL, NASA, or the US Government. >>> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu >>> >> >> -- >> Bruce Momjian <bruce@momjian.us> http://momjian.us >> EnterpriseDB http:// >> www.enterprisedb.com >> >> + If your life is a hard drive, Christ can be your backup. + > > > > ---------------------------------------------------------------------- > -- > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu > > > > ---------------------------(end of > broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq
"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:
> I tend to regard this as a comparable migration to the Kerb4 -> Kerb5
> one. In time it should be a complete replacement. In time we will
> be able to rip out the existing Kerb5 code.
Why "in time" and not immediately? Are there platforms that don't
support the GSSAPI interface? If so, how would we ever retire the
old code?
regards, tom lane
Don't you want to maintain some interoperability between 8.2 client/ server and 8.3 server/client at least? If you put my patches in 8.3, and they work as well as I hope, then "in time" could be as soon as 8.4, I suppose. To answer the question more directly: I do not know of any platform that supports the "native" Kerb5 API that doesn't also support GSSAPI for the simple reason that a Kerberos-only version of GSSAPI has been bundled with both the MIT and Heimdal distributions for as long as I can remember. On Apr 30, 2007, at 4:48 PM, Tom Lane wrote: > "Henry B. Hotz" <hotz@jpl.nasa.gov> writes: >> I tend to regard this as a comparable migration to the Kerb4 -> Kerb5 >> one. In time it should be a complete replacement. In time we will >> be able to rip out the existing Kerb5 code. > > Why "in time" and not immediately? Are there platforms that don't > support the GSSAPI interface? If so, how would we ever retire the > old code? > > regards, tom lane ------------------------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:
> Don't you want to maintain some interoperability between 8.2 client/
> server and 8.3 server/client at least?
Hm, you mean that what you called a C API change actually
break^H^H^H^H^Hchanges the on-the-wire protocol as well?
That sounds not very nice :-(
regards, tom lane
Yes, the wire protocol is different. Sorry. I can't help that. As I said, I'm not adding any new functionality yet, just lots of potential compatibility that isn't possible with the Kerberos API now used. While there's no significant new functionality yet, at least there's no regression either. On Apr 30, 2007, at 5:56 PM, Tom Lane wrote: > "Henry B. Hotz" <hotz@jpl.nasa.gov> writes: >> Don't you want to maintain some interoperability between 8.2 client/ >> server and 8.3 server/client at least? > > Hm, you mean that what you called a C API change actually > break^H^H^H^H^Hchanges the on-the-wire protocol as well? > That sounds not very nice :-( > > regards, tom lane ------------------------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
Tom Lane wrote: > "Henry B. Hotz" <hotz@jpl.nasa.gov> writes: >> Don't you want to maintain some interoperability between 8.2 client/ >> server and 8.3 server/client at least? > > Hm, you mean that what you called a C API change actually > break^H^H^H^H^Hchanges the on-the-wire protocol as well? > That sounds not very nice :-( It's a completely new authentication method, that just happens to use Kerberos underneath it. And it uses the API/wireprotocol that's recommended by the Kerberos folks. And in fact when talking to the MIT folks back when I found that security issue two years back it seems we're more or less the only ones other than sample apps taht use the "native api". Fact is that the way we do it now is not very "pretty". The GSSAPI way lets PostgreSQL handle sending/receiving and wrapping in whatever we want, whereas the current method we just pass in the socket. I think in a lot of ways it's just pure luck that it works reasonably well alongside OpenSSL for example. I think the correct path is to put it in GSSAPI and deprecate krb5 for at least one release, and then get rid of krb5 completely. Oh, and I do think putting in GSSAPI authentication only (and not encryption) is the way to go for now, since we can do encryption with OpenSSL. It'll make the changes localized to just the authentication. //Magnus
Henry B. Hotz wrote: > OK, so posted. ;-) <snip> >>> Would you like a new version of the patch with the incomplete >>> functionality commented out (or otherwise removed)? Yes please :-) I was going to try to do one of those myself, but since you already know your way around the code, please do it. And please go for removing it alltogether instead of just commenting it out - it's in the list archives and can be referred to there if/when we want to add it back in. I'd also vote for changing the name of the "non encrypted" version to just "gss" instead of "gss-np". //Magnus
On May 1, 2007, at 1:16 AM, Magnus Hagander wrote: > Henry B. Hotz wrote: >> OK, so posted. ;-) > > <snip> > >>>> Would you like a new version of the patch with the incomplete >>>> functionality commented out (or otherwise removed)? > > Yes please :-) I was going to try to do one of those myself, but since > you already know your way around the code, please do it. And please go > for removing it alltogether instead of just commenting it out - > it's in > the list archives and can be referred to there if/when we want to > add it > back in. I can do that. Could I ask you, or someone else, to look at what needs to happen to configure? The way you capture `krb5-config --libs gssapi` into a variable is completely different in BSD and GNU make, and I don't know how to deal with that. (The configure logic for mod_auth_kerb suffers from that problem, too.) The README.GSSAPI file in the patch has reasonable notes, and it should be pretty simple otherwise. > I'd also vote for changing the name of the "non encrypted" version to > just "gss" instead of "gss-np". I happen to disagree on this point. There are a whole class of attacks that become possible if the encryption from the original authentication exchange isn't used for the on-going channel encryption/integrity. They may be impossible in practice, but how many cans of worms do you want to deal with when you recommend a "secure" configuration to an average admin? I would rather not hide the distinction by changing the name that way. Also, if I *do* get the buffering disentangled and create a working "gss" mechanism, what would I call it if the name is already taken? At that point it would become the recommended mechanism unless high- volume performance made it impractical. ------------------------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
Magnus, > I'd also vote for changing the name of the "non encrypted" version to > just "gss" instead of "gss-np". I don't. We'll want to support GSS encryption once we have the code, so we should leave the namespace open to address that. > Oh, and I do think putting in GSSAPI authentication only (and not > encryption) is the way to go for now, since we can do encryption with > OpenSSL. It'll make the changes localized to just the authentication. For now, yes. In the long run, we want to provide users with other methods of encrypted connections than the rather flaky and not-available-on-every-platform OpenSSL. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
Henry B. Hotz wrote: > > On May 1, 2007, at 1:16 AM, Magnus Hagander wrote: > >> Henry B. Hotz wrote: >> >>>>> Would you like a new version of the patch with the incomplete >>>>> functionality commented out (or otherwise removed)? >> >> Yes please :-) I was going to try to do one of those myself, but since >> you already know your way around the code, please do it. And please go >> for removing it alltogether instead of just commenting it out - it's in >> the list archives and can be referred to there if/when we want to add it >> back in. > > I can do that. Thanks! > Could I ask you, or someone else, to look at what needs to happen to > configure? The way you capture `krb5-config --libs gssapi` into a > variable is completely different in BSD and GNU make, and I don't know > how to deal with that. (The configure logic for mod_auth_kerb suffers > from that problem, too.) The README.GSSAPI file in the patch has > reasonable notes, and it should be pretty simple otherwise. I'll leave the autoconf-fu to someone else if possible, but I can look at it later if nobody does (will look at the rest too). The docs need to be moved from README into the proper docs as well, but I can take care of that once the code is settled. >> I'd also vote for changing the name of the "non encrypted" version to >> just "gss" instead of "gss-np". > > I happen to disagree on this point. There are a whole class of attacks > that become possible if the encryption from the original authentication > exchange isn't used for the on-going channel encryption/integrity. They > may be impossible in practice, but how many cans of worms do you want to > deal with when you recommend a "secure" configuration to an average > admin? I would rather not hide the distinction by changing the name > that way. > > Also, if I *do* get the buffering disentangled and create a working > "gss" mechanism, what would I call it if the name is already taken? At > that point it would become the recommended mechanism unless high-volume > performance made it impractical. I would call them "gss" and "gss-sec". Or possibly "gss-enc". I think that's a lot more clear than "gss-np" (something ending with -sec is a giveaway) But I won't fight for it, it's not that important to me :-) (And whether it's recommended or not depends on the environment - there are a cases where it's just unnecessary to add it. Say if you're employing ipsec across your network, adding a second layer of encryption will just make things slower for no gain - and it makes things more complex. Even if you're not talking high volume.) //Magnus
Josh Berkus wrote: > Magnus, > >> I'd also vote for changing the name of the "non encrypted" version to >> just "gss" instead of "gss-np". > > I don't. We'll want to support GSS encryption once we have the code, so we > should leave the namespace open to address that. I agree that we should do this, I'm just suggesting different names, namely "gss" and "gss-sec". >> Oh, and I do think putting in GSSAPI authentication only (and not >> encryption) is the way to go for now, since we can do encryption with >> OpenSSL. It'll make the changes localized to just the authentication. > > For now, yes. In the long run, we want to provide users with other methods > of encrypted connections than the rather flaky and > not-available-on-every-platform OpenSSL. Certainly. I'm talking short-term when I say that. When we eventually do -sec, it might be worthwhile to consider that in the context of the GnuTLS patches that were thrown around earlier - maybe something can be done for both of them, so we don't get a hugely expanded codebase. //Magnus
Josh Berkus wrote: > Magnus, > >> I'd also vote for changing the name of the "non encrypted" version to >> just "gss" instead of "gss-np". > > I don't. We'll want to support GSS encryption once we have the code, so we > should leave the namespace open to address that. > >> Oh, and I do think putting in GSSAPI authentication only (and not >> encryption) is the way to go for now, since we can do encryption with >> OpenSSL. It'll make the changes localized to just the authentication. > > For now, yes. In the long run, we want to provide users with other methods > of encrypted connections than the rather flaky and > not-available-on-every-platform OpenSSL. I'm curious - on what platform is OpenSSL NOT available ? Stefan
Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> Josh Berkus wrote:
>> For now, yes. In the long run, we want to provide users with other methods
>> of encrypted connections than the rather flaky and
>> not-available-on-every-platform OpenSSL.
> I'm curious - on what platform is OpenSSL NOT available ?
And even more curious to see you defend that offhanded bashing of OpenSSL,
a tool a whole lot of people (including me) depend on all day every day.
If Postgres had the market penetration of OpenSSL, our lives would be a
lot different. Have you got even a shred of evidence that GSSAPI is
more stable than OpenSSL?
regards, tom lane
Magnus Hagander <magnus@hagander.net> writes:
> I would call them "gss" and "gss-sec". Or possibly "gss-enc". I think
> that's a lot more clear than "gss-np" (something ending with -sec is a
> giveaway)
+1
regards, tom lane
Tom, > And even more curious to see you defend that offhanded bashing of > OpenSSL, a tool a whole lot of people (including me) depend on all day > every day. If Postgres had the market penetration of OpenSSL, our lives > would be a lot different. Have you got even a shred of evidence that > GSSAPI is more stable than OpenSSL? Short answer: Existing Kerberos libs with GSSAPI may have the same issues; I don't know. What I was speaking in favor of was having several encryption mechanisms available so that at least one of them would be available on the user's system at installation time. For that matter, I think we should support Gnu-TLS if someone offers us a patch. Long Answer: I've been dealing with OpenSSL binary incompatibility issues for the last few Solaris builds and it's made me very unhappy with the upgrade/versioning/linking of OpenSSL, and explained a lot of issues I've had around using OpenSSL with PostgreSQL and Apache previously. That is, 0.9.8 isn't always backwards compatible to 0.9.7 or 0.9.6, making applications built against one version of OpenSSL not necessarily portable or easily upgraded, and causing a lot of installation-related pain. (yes, I know this describes PostgreSQL as well. People complain about it all the time to us, and they're right) When you combine that with the platform providers (like Novell, Sun and RH) treating OpenSSL as if there were no upgrade issues (even though there are), or being version-specific but not providing packages for other versions, you end up with a situation where a lot of users can't actually use OpenSSL on their system without ripping out a bunch of libraries and replacing them with compatible versions. I've had this issue on SuSE, Solaris, and OSX at different times. The OpenSSL team appears to be is very aware of these issues, which is why Richard Levitte started the OpenTLS project (www.opentls.org) as a successor to OpenSSL, where the issues are apparently insoluable 9http://marc.info/?l=openssl-dev&m=113042556401979&w=2). OpenSSL has also added a stronger EVP_API and some versioning of symbols in the most recent release, but that won't help most of our users for a while until 0.9.6 and 0.9.7 dissapear from userspace. Also, last I checked OpenSSL didn't ship with Windows and Kerberos encryption did. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
On May 1, 2007, at 1:33 PM, Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: >> I would call them "gss" and "gss-sec". Or possibly "gss-enc". I think >> that's a lot more clear than "gss-np" (something ending with -sec >> is a >> giveaway) > > +1 If we settle on gss-np and gss-sec is that a good compromise? ------------------------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
Josh Berkus wrote: > Tom, > >> And even more curious to see you defend that offhanded bashing of >> OpenSSL, a tool a whole lot of people (including me) depend on all day >> every day. If Postgres had the market penetration of OpenSSL, our lives >> would be a lot different. Have you got even a shred of evidence that >> GSSAPI is more stable than OpenSSL? > > Short answer: > Existing Kerberos libs with GSSAPI may have the same issues; I don't know. > What I was speaking in favor of was having several encryption mechanisms > available so that at least one of them would be available on the user's > system at installation time. For that matter, I think we should support > Gnu-TLS if someone offers us a patch. IIRC we had a gnutls patch offered, but rejected. > Also, last I checked OpenSSL didn't ship with Windows and Kerberos > encryption did. How long ago did you check? I've been using OpenSSL on windows for many years. Actually, it was supported just fine on Windows back when it was added to PostgreSQL *at least*. //Magnus
Henry B. Hotz wrote: > > On May 1, 2007, at 1:33 PM, Tom Lane wrote: > >> Magnus Hagander <magnus@hagander.net> writes: >>> I would call them "gss" and "gss-sec". Or possibly "gss-enc". I think >>> that's a lot more clear than "gss-np" (something ending with -sec is a >>> giveaway) >> >> +1 > > If we settle on gss-np and gss-sec is that a good compromise? I still think the "-np" part is unclear - it's not "easily guessable without reading the documentation", unless you're already familiar with it. //Magnus
On May 1, 2007, at 2:30 PM, Magnus Hagander wrote: > Henry B. Hotz wrote: >> >> On May 1, 2007, at 1:33 PM, Tom Lane wrote: >> >>> Magnus Hagander <magnus@hagander.net> writes: >>>> I would call them "gss" and "gss-sec". Or possibly "gss-enc". I >>>> think >>>> that's a lot more clear than "gss-np" (something ending with - >>>> sec is a >>>> giveaway) >>> >>> +1 >> >> If we settle on gss-np and gss-sec is that a good compromise? > > I still think the "-np" part is unclear - it's not "easily guessable > without reading the documentation", unless you're already familiar > with it. > > //Magnus gss-noprot and gss-prot gss-noenc and gss-enc ?? ------------------------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
Henry B. Hotz wrote: >>>>> I would call them "gss" and "gss-sec". Or possibly "gss-enc". I think >>>>> that's a lot more clear than "gss-np" (something ending with -sec is a >>>>> giveaway) >>>> >>>> +1 >>> >>> If we settle on gss-np and gss-sec is that a good compromise? >> >> I still think the "-np" part is unclear - it's not "easily guessable >> without reading the documentation", unless you're already familiar >> with it. >> >> //Magnus > > gss-noprot and gss-prot > > gss-noenc and gss-enc Those I like better. I still think it's unnecessary, but I won't object to those :-) //Magnus
On May 1, 2007, at 1:32 PM, Tom Lane wrote: > Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes: >> Josh Berkus wrote: >>> For now, yes. In the long run, we want to provide users with >>> other methods >>> of encrypted connections than the rather flaky and >>> not-available-on-every-platform OpenSSL. > >> I'm curious - on what platform is OpenSSL NOT available ? > > And even more curious to see you defend that offhanded bashing of > OpenSSL, > a tool a whole lot of people (including me) depend on all day every > day. > If Postgres had the market penetration of OpenSSL, our lives would > be a > lot different. Have you got even a shred of evidence that GSSAPI is > more stable than OpenSSL? > > regards, tom lane Windows? I don't do Windows, so I'm guessing. If you accept that Microsoft's SSPI is a flavor of GSSAPI, then GSSAPI is more widely supported and probably more stable on Windows machines than OpenSSL is. ------------------------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
Josh Berkus <josh@agliodbs.com> writes:
> Long Answer:
> I've been dealing with OpenSSL binary incompatibility issues for the last
> few Solaris builds and it's made me very unhappy with the
> upgrade/versioning/linking of OpenSSL, and explained a lot of issues I've
> had around using OpenSSL with PostgreSQL and Apache previously. That is,
> 0.9.8 isn't always backwards compatible to 0.9.7 or 0.9.6, making
> applications built against one version of OpenSSL not necessarily portable
> or easily upgraded, and causing a lot of installation-related pain.
> (yes, I know this describes PostgreSQL as well. People complain about it
> all the time to us, and they're right)
Indeed, but I dunno why you think things will be all magically better
in GSSAPI-land. What I foresee as more likely is that we'll just be
opening up another front in the versioning war.
regards, tom lane
>> Short answer: >> Existing Kerberos libs with GSSAPI may have the same issues; I don't know. >> What I was speaking in favor of was having several encryption mechanisms >> available so that at least one of them would be available on the user's >> system at installation time. For that matter, I think we should support >> Gnu-TLS if someone offers us a patch. > > IIRC we had a gnutls patch offered, but rejected. That is correct. THere is a very long thread on it here: http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php > > >> Also, last I checked OpenSSL didn't ship with Windows and Kerberos >> encryption did. > > How long ago did you check? I've been using OpenSSL on windows for many > years. Actually, it was supported just fine on Windows back when it was > added to PostgreSQL *at least*. > > //Magnus > > ---------------------------(end of broadcast)--------------------------- > TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/
"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:
> Windows? I don't do Windows, so I'm guessing.
> If you accept that Microsoft's SSPI is a flavor of GSSAPI, then
> GSSAPI is more widely supported and probably more stable on Windows
> machines than OpenSSL is.
I can't speak to the situation on Windows either; if OpenSSL isn't
commonly used on Windows that may be a sufficient reason for supporting
GSSAPI too. I'm just unconvinced by any argument that suggests we'll
replace our SSL support with it.
regards, tom lane
Tom, Josh, Magnus. > I can't speak to the situation on Windows either; if OpenSSL isn't > commonly used on Windows that may be a sufficient reason for supporting > GSSAPI too. I'm just unconvinced by any argument that suggests we'll > replace our SSL support with it. I can't imagine we will either. I think we should offer users choices, within reason. > IIRC we had a gnutls patch offered, but rejected. Darn, this happened while I was offline. I would have supported it. I still think it's a good idea, pending patch quality. > > Also, last I checked OpenSSL didn't ship with Windows and Kerberos > > encryption did. > > How long ago did you check? I've been using OpenSSL on windows for many > years. Actually, it was supported just fine on Windows back when it was > added to PostgreSQL *at least*. I didn't say *available for download*, I said *ship with*. That is, does a Windows Vista Pro box from the factory come with OpenSSL on it? It does come with Microsoft SSPI, although I don't know compatibility issues. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
>>> Also, last I checked OpenSSL didn't ship with Windows and Kerberos >>> encryption did. >> How long ago did you check? I've been using OpenSSL on windows for many >> years. Actually, it was supported just fine on Windows back when it was >> added to PostgreSQL *at least*. > > I didn't say *available for download*, I said *ship with*. That is, does a > Windows Vista Pro box from the factory come with OpenSSL on it? It does > come with Microsoft SSPI, although I don't know compatibility issues. No, of course not. Microsoft OSes don't ship with *any* third party software. So yeah, didn't get what you meant, and you do have a point there. Provided the SSPI stuff actually does gssapi encryption - but I'll trust the people who say it does. I've only ever used the authentication parts myself. //Magnus
On May 1, 2007, at 3:11 PM, Magnus Hagander wrote: >>>> Also, last I checked OpenSSL didn't ship with Windows and Kerberos >>>> encryption did. >>> How long ago did you check? I've been using OpenSSL on windows >>> for many >>> years. Actually, it was supported just fine on Windows back when >>> it was >>> added to PostgreSQL *at least*. >> >> I didn't say *available for download*, I said *ship with*. That >> is, does a >> Windows Vista Pro box from the factory come with OpenSSL on it? >> It does >> come with Microsoft SSPI, although I don't know compatibility issues. > > No, of course not. Microsoft OSes don't ship with *any* third party > software. So yeah, didn't get what you meant, and you do have a point > there. Provided the SSPI stuff actually does gssapi encryption - but > I'll trust the people who say it does. I've only ever used the > authentication parts myself. The SSPI has encryption and integrity functions, just like the GSSAPI. I don't remember Jeffrey Altman's interop example code well enough to say if he demonstrates that they interoperate as well. Spending 5 seconds looking at it, the SSPI appears to make a distinction between message and stream encryption that the GSSAPI does not make, so there is at least some profiling needed to identify what's common. I suspect that interoperability was intended. If we find bugs and tell the right people Microsoft might even fix them someday. As to the question of GSSAPI vs SSL, I would never argue we don't want both. Part of what made the GSSAPI encryption mods difficult was my intent to insert them "above" the SSL encryption/buffering layer. That way you could double-encrypt the channel. Since GSSAPI and SSL are (probably, not necessarily) referenced to completely different ID infrastructure there are scenarios where that's beneficial. (The other thing that made it hard is that I needed to make changes in different places in the FE and the BE versions of libpq in order to get the same effect.) ------------------------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
Magnus Hagander wrote: >>>> Also, last I checked OpenSSL didn't ship with Windows and Kerberos >>>> encryption did. >>> How long ago did you check? I've been using OpenSSL on windows for many >>> years. Actually, it was supported just fine on Windows back when it was >>> added to PostgreSQL *at least*. >> I didn't say *available for download*, I said *ship with*. That is, does a >> Windows Vista Pro box from the factory come with OpenSSL on it? It does >> come with Microsoft SSPI, although I don't know compatibility issues. > > No, of course not. Microsoft OSes don't ship with *any* third party > software. So yeah, didn't get what you meant, and you do have a point > there. Provided the SSPI stuff actually does gssapi encryption - but > I'll trust the people who say it does. I've only ever used the > authentication parts myself. I think it's largely irrelevant though - I can't see us shipping a non-ssl enabled build now (thats not to say we wouldn't add SSPI support of course). /D
On Tue, May 01, 2007 at 04:26:13PM -0700, Henry B. Hotz wrote: > > On May 1, 2007, at 3:11 PM, Magnus Hagander wrote: > > >>>>Also, last I checked OpenSSL didn't ship with Windows and Kerberos > >>>>encryption did. > >>>How long ago did you check? I've been using OpenSSL on windows > >>>for many > >>>years. Actually, it was supported just fine on Windows back when > >>>it was > >>>added to PostgreSQL *at least*. > >> > >>I didn't say *available for download*, I said *ship with*. That > >>is, does a > >>Windows Vista Pro box from the factory come with OpenSSL on it? > >>It does > >>come with Microsoft SSPI, although I don't know compatibility issues. > > > >No, of course not. Microsoft OSes don't ship with *any* third party > >software. So yeah, didn't get what you meant, and you do have a point > >there. Provided the SSPI stuff actually does gssapi encryption - but > >I'll trust the people who say it does. I've only ever used the > >authentication parts myself. > > The SSPI has encryption and integrity functions, just like the > GSSAPI. I don't remember Jeffrey Altman's interop example code well > enough to say if he demonstrates that they interoperate as well. > Spending 5 seconds looking at it, the SSPI appears to make a > distinction between message and stream encryption that the GSSAPI > does not make, so there is at least some profiling needed to identify > what's common. I suspect that interoperability was intended. If we > find bugs and tell the right people Microsoft might even fix them > someday. Ok. Well, that's for later. > As to the question of GSSAPI vs SSL, I would never argue we don't > want both. > > Part of what made the GSSAPI encryption mods difficult was my intent > to insert them "above" the SSL encryption/buffering layer. That way > you could double-encrypt the channel. Since GSSAPI and SSL are > (probably, not necessarily) referenced to completely different ID > infrastructure there are scenarios where that's beneficial. We might want to consider restructuring how SSL works when we do, that might make it easier. The way it is now with #ifdefs all around can lead to a horrible mess if there are too many different things to choose from. Something like "transport filters" or whatever might be a way to do it. I recall having looked at that at some point, but it was too long ago to remember any details.. //Magnus
On May 2, 2007, at 3:11 AM, Magnus Hagander wrote: >> As to the question of GSSAPI vs SSL, I would never argue we don't >> want both. >> >> Part of what made the GSSAPI encryption mods difficult was my intent >> to insert them "above" the SSL encryption/buffering layer. That way >> you could double-encrypt the channel. Since GSSAPI and SSL are >> (probably, not necessarily) referenced to completely different ID >> infrastructure there are scenarios where that's beneficial. > > We might want to consider restructuring how SSL works when we do, that > might make it easier. The way it is now with #ifdefs all around can > lead to > a horrible mess if there are too many different things to choose from. > Something like "transport filters" or whatever might be a way to do > it. I > recall having looked at that at some point, but it was too long ago to > remember any details.. > > //Magnus If someone wants to make it easier, that would be nice, I'm not up for it, I don't think. ------------------------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu