Обсуждение: BUG #4340: SECURITY: Is SSL Doing Anything?
The following bug has been logged online: Bug reference: 4340 Logged by: Dan Kaminsky Email address: dan@doxpara.com PostgreSQL version: 7.3 Operating system: Any Description: SECURITY: Is SSL Doing Anything? Details: http://www.google.com/codesearch?hl=en&q=verify_cb+package:http://ring.atr.j p/archives/misc/db/postgresql-jp/7.3beta/postgresql-7.3b1.tar.gz+show:T2MIh9 GrfhE:LRGuIfOPoEk:-Eemn4ZpAKY&sa=N&cd=1&ct=rc&cs_p=http://ring.atr.jp/archiv es/misc/db/postgresql-jp/7.3beta/postgresql-7.3b1.tar.gz&cs_f=postgresql-7.3 b1/src/interfaces/libpq/fe-secure.c#l355 /* * Certificate verification callback * * This callback allows us to log intermediate problems during * verification, but there doesn't seem to be a clean way to get * our PGconn * structure. So we can't log anything! * * This callback also allows us to override the default acceptance * criteria (e.g., accepting self-signed or expired certs), but * for now we accept the default checks. */ static int verify_cb(int ok, X509_STORE_CTX *ctx) { return ok; } --- Clearly, this is handling self-signed certs. Great. But what I really want to know is, is verify_peer accepting a self-signed identity assertion? Because that'd be remote EoP.
"Dan Kaminsky" <dan@doxpara.com> writes:
> Clearly, this is handling self-signed certs. Great. But what I really want
> to know is, is verify_peer accepting a self-signed identity assertion?
> Because that'd be remote EoP.
I'm just guessing what you're driving at (unexplained acronyms aren't
a good way to communicate), but I think it's not a big problem. PG
doesn't rely on SSL for authentication, only for communications
security, so whether the remote cert is self-signed doesn't seem
like much of an issue. Anyway, you can adjust your list of trusted
CAs to determine whether you'll accept it or not.
regards, tom lane
Tom Lane wrote:
> "Dan Kaminsky" <dan@doxpara.com> writes:
>
>> Clearly, this is handling self-signed certs. Great. But what I really want
>> to know is, is verify_peer accepting a self-signed identity assertion?
>> Because that'd be remote EoP.
>>
>
> I'm just guessing what you're driving at (unexplained acronyms aren't
> a good way to communicate), but I think it's not a big problem. PG
> doesn't rely on SSL for authentication, only for communications
> security, so whether the remote cert is self-signed doesn't seem
> like much of an issue. Anyway, you can adjust your list of trusted
> CAs to determine whether you'll accept it or not.
>
> regards, tom lane
>
Heh Tom,
Thanks for replying so quickly. It's definitely appreciated.
Apologies, EoP = Escalation of Privilege. I've been up all night.
Lets talk about the verify_cb callback first: Suppose there's a
man-in-the-middle between the PG client and the PG server. Is some
secondary force going to apply some Trusted CA list?
Second, are you saying verify_peer doesn't do anything for
authentication? Are you sure about that? There's really little reason
otherwise for the call to exist.
--Dan
Dan Kaminsky <dan@doxpara.com> writes:
> Lets talk about the verify_cb callback first: Suppose there's a
> man-in-the-middle between the PG client and the PG server. Is some
> secondary force going to apply some Trusted CA list?
I'm not sure why we have verify_cb at all -- so far as I can see,
it just specifies the same behavior as OpenSSL's default. Are
you saying that OpenSSL's default verification behavior is broken?
> Second, are you saying verify_peer doesn't do anything for
> authentication? Are you sure about that? There's really little reason
> otherwise for the call to exist.
Er, we don't *have* a verify_peer callback.
regards, tom lane
Tom Lane wrote: > Dan Kaminsky <dan@doxpara.com> writes: > > Lets talk about the verify_cb callback first: Suppose there's a > > man-in-the-middle between the PG client and the PG server. Is some > > secondary force going to apply some Trusted CA list? > > I'm not sure why we have verify_cb at all -- so far as I can see, > it just specifies the same behavior as OpenSSL's default. Are > you saying that OpenSSL's default verification behavior is broken? verify_cb() is just a throwaway true parameter for the function, I assume. > > Second, are you saying verify_peer doesn't do anything for > > authentication? Are you sure about that? There's really little reason > > otherwise for the call to exist. > > Er, we don't *have* a verify_peer callback. Uh, the user reported running Postgres 7.3 and we have improved SSL quite a bit since then so perhaps an upgrade and reading the current docs would help the user. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Tom Lane wrote: > > Dan Kaminsky <dan@doxpara.com> writes: > > > Second, are you saying verify_peer doesn't do anything for > > > authentication? Are you sure about that? There's really little reason > > > otherwise for the call to exist. > > > > Er, we don't *have* a verify_peer callback. > > Uh, the user reported running Postgres 7.3 and we have improved SSL > quite a bit since then so perhaps an upgrade and reading the current > docs would help the user. The code is identical in HEAD, according to a quick read I did last week. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Tom Lane wrote:
>>> Er, we don't *have* a verify_peer callback.
>>
>> Uh, the user reported running Postgres 7.3 and we have improved SSL
>> quite a bit since then so perhaps an upgrade and reading the current
>> docs would help the user.
> The code is identical in HEAD, according to a quick read I did last
> week.
Actually, I had missed that the OP was looking at 7.3 rather than 8.3.
There was a "verify_peer()" in 7.3 but it was #ifdef'd out. The
question remains whether there's a reason to have it. It would be good
if the discussion were based on a non-obsolete PG version ...
regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > Actually, I had missed that the OP was looking at 7.3 rather than 8.3. > There was a "verify_peer()" in 7.3 but it was #ifdef'd out. The > question remains whether there's a reason to have it. It would be good > if the discussion were based on a non-obsolete PG version ... Well in theory SSL without at least one-way authentication is actually worthless. It's susceptible to man-in-the-middle attacks meaning someone can sniff all the contents or even inject into or take over connections. It is proof against passive attacks but active attacks are known in the field so that's cold comfort these days. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!
Dan Kaminsky <dan@doxpara.com> writes:
> My question has been: When you attempt to create an SSL connection to
> database.backend.com, do you actually validate that:
> 1) The subject name of the certificate you're connecting to is
> database.backend.com, and
> 2) At least the basic checks (expiration, chaining back to a valid root)
> occur?
[ shrug... ] We do whatever OpenSSL's default validation behavior is.
If that's inadequate you probably ought to be taking it up with them,
instead of trying to get downstream projects to fix it one at a time.
regards, tom lane
Gregory Stark wrote: > "Tom Lane" <tgl@sss.pgh.pa.us> writes: > > >> Actually, I had missed that the OP was looking at 7.3 rather than 8.3. >> There was a "verify_peer()" in 7.3 but it was #ifdef'd out. The >> question remains whether there's a reason to have it. It would be good >> if the discussion were based on a non-obsolete PG version ... >> > > Well in theory SSL without at least one-way authentication is actually > worthless. It's susceptible to man-in-the-middle attacks meaning someone can > sniff all the contents or even inject into or take over connections. It is > proof against passive attacks but active attacks are known in the field so > that's cold comfort these days. As the finder of recent DNS issues, I'm pretty aware of real world active attacks. My question has been: When you attempt to create an SSL connection to database.backend.com, do you actually validate that: 1) The subject name of the certificate you're connecting to is database.backend.com, and 2) At least the basic checks (expiration, chaining back to a valid root) occur? I've gotten some reasonable hints that #2 happen, but I don't know if #1 happens, and these comments make me worry. --Dan
Tom Lane wrote: > Dan Kaminsky <dan@doxpara.com> writes: > >> My question has been: When you attempt to create an SSL connection to >> database.backend.com, do you actually validate that: >> > > >> 1) The subject name of the certificate you're connecting to is >> database.backend.com, and >> 2) At least the basic checks (expiration, chaining back to a valid root) >> occur? >> > > [ shrug... ] We do whatever OpenSSL's default validation behavior is. > If that's inadequate you probably ought to be taking it up with them, > instead of trying to get downstream projects to fix it one at a time. > > regards, tom lane > Heh, you're the one making guarantees to your users. I'm just asking the exact nature of those guarantees. I agree that #2 is entirely under the control of OpenSSL -- but I'd like to know if #1 is being satisfied, i.e. OpenSSL knows you're looking to validate database.backend.com as opposed to "some cert that chains back", which is a worthless security assertion. --Dan
Dan Kaminsky wrote: > > > Tom Lane wrote: >> Dan Kaminsky <dan@doxpara.com> writes: >> >>> My question has been: When you attempt to create an SSL connection >>> to database.backend.com, do you actually validate that: >>> >> >> >>> 1) The subject name of the certificate you're connecting to is >>> database.backend.com, and >>> 2) At least the basic checks (expiration, chaining back to a valid >>> root) occur? >>> >> >> [ shrug... ] We do whatever OpenSSL's default validation behavior is. >> If that's inadequate you probably ought to be taking it up with them, >> instead of trying to get downstream projects to fix it one at a time. >> >> regards, tom lane >> > Heh, you're the one making guarantees to your users. I'm just asking > the exact nature of those guarantees. I agree that #2 is entirely under > the control of OpenSSL -- but I'd like to know if #1 is being satisfied, > i.e. OpenSSL knows you're looking to validate database.backend.com as > opposed to "some cert that chains back", which is a worthless security > assertion. We do not validate the name. It is stated in a comment at the top of f-secure.h that we do, but the code is all behind #ifdef NOT_USED. It would probably not be a bad idea to have that check enabled by default, but a way to turn it off. (I don't believe OpenSSL does this verification either, because AFAICS OpenSSL only ever sees the IP address of the server, and not the FQDN) We do, however, return the peer certificate information to the libpq client, that can verify this if it's considered necessary by the *application*. That said, claiming that the check of the chain up to a root certificate is wortheless is very far from correct. Used the proper way, and the way I most often see it deployed with PostgreSQL, makes it very worthy. Because people normally either bundle the server certificate itself with the application, in which case it will only ever connect to that server (self-signed cert). Or they have a dedicated CA for this purpose. Is it perfect? Far from. But it's certainly not worthless. //Magnus
Magnus Hagander <magnus@hagander.net> writes:
> (I don't believe OpenSSL does this verification either, because AFAICS
> OpenSSL only ever sees the IP address of the server, and not the FQDN)
In common usages libpq doesn't have the FQDN of the server either.
To impose such a requirement, we'd have to forbid naming the server
by IP address or via a domain-search-path abbreviation.
regards, tom lane
Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: >> (I don't believe OpenSSL does this verification either, because AFAICS >> OpenSSL only ever sees the IP address of the server, and not the FQDN) > > In common usages libpq doesn't have the FQDN of the server either. > To impose such a requirement, we'd have to forbid naming the server > by IP address or via a domain-search-path abbreviation. You could issue a certificate to an IP address, so you could match the textual representation of the IP in that case. Or you could require the FQDN for a SSL connection when this verification is enabled. A similar restriction already exists for Kerberos, for example. //Magnus
Dan Kaminsky wrote: > > > Tom Lane wrote: >> Magnus Hagander <magnus@hagander.net> writes: >> >>> (I don't believe OpenSSL does this verification either, because AFAICS >>> OpenSSL only ever sees the IP address of the server, and not the FQDN) >>> >> >> In common usages libpq doesn't have the FQDN of the server either. >> To impose such a requirement, we'd have to forbid naming the server >> by IP address or via a domain-search-path abbreviation. >> >> regards, tom lane >> > Well, right now, SSL does nothing for you, so you have to do something. > It's OK, SSL isn't doing a lot for a lot of people, but this is the > beginning of us calling people out on that. Do feel free to explain how it "does nothing" for you with properly set up certificates (see my previous email). (I'm still not saying it cannot be significantly improved, of course) > You can handle IP address and domain-search-path by having an option for > explicitly declaring the subject name to be expected at the other side > of the SSL connection. In other words, sever the DNS/FQDN link, and > just explicitly say "however I reach that host over there, I expect > database.backend.com". You can do this today. If you are willing to do it in the application, just verify the certificate DN and you're done. Yes, it would certainly be a lot better to do the validation earlier in the chain (if you're sending plaintext password, you'll end up sending the password before you do the validation. But I don't think you even can do that in current versions), and if it was slightly easier to do, but you can certainly validate the cert if you want to. //Magnus
Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: > >> (I don't believe OpenSSL does this verification either, because AFAICS >> OpenSSL only ever sees the IP address of the server, and not the FQDN) >> > > In common usages libpq doesn't have the FQDN of the server either. > To impose such a requirement, we'd have to forbid naming the server > by IP address or via a domain-search-path abbreviation. > > regards, tom lane > Well, right now, SSL does nothing for you, so you have to do something. It's OK, SSL isn't doing a lot for a lot of people, but this is the beginning of us calling people out on that. You can handle IP address and domain-search-path by having an option for explicitly declaring the subject name to be expected at the other side of the SSL connection. In other words, sever the DNS/FQDN link, and just explicitly say "however I reach that host over there, I expect database.backend.com". --Dan
Dan Kaminsky wrote: > >>> Well, right now, SSL does nothing for you, so you have to do >>> something. It's OK, SSL isn't doing a lot for a lot of people, but >>> this is the >>> beginning of us calling people out on that. >>> >> >> Do feel free to explain how it "does nothing" for you with properly set >> up certificates (see my previous email). (I'm still not saying it cannot >> be significantly improved, of course) >> >> > If the only roots set up are private roots, it works great. > > If there are generic roots (Verisign etc), or if no roots are checked at > all, it's useless. > > Pretty simple Good, then we're in agreement that far. (FWIW, I don't think I've ever seen a PostgreSQL server with a certificate off a global root. I've seen plenty off a corporate root though, which could in theory have similar issues - but at least you're in control of your own problem in that case) >>> You can handle IP address and domain-search-path by having an option for >>> explicitly declaring the subject name to be expected at the other side >>> of the SSL connection. In other words, sever the DNS/FQDN link, and >>> just explicitly say "however I reach that host over there, I expect >>> database.backend.com". >>> >> >> You can do this today. If you are willing to do it in the application, >> just verify the certificate DN and you're done. >> >> Yes, it would certainly be a lot better to do the validation earlier in >> the chain (if you're sending plaintext password, you'll end up sending >> the password before you do the validation. But I don't think you even >> can do that in current versions), and if it was slightly easier to do, >> but you can certainly validate the cert if you want to. >> >> //Magnus >> > See, I don't care *why* things are broken -- whether they're broken at > the application, at libpq, or at openssl, I'm asking the direct question > -- is SSL doing anything in common deployment, and if not, what needs to > be done to fix that? > > Background: After the DNS flaw was found, I started looking around to > see if SSL was a legitimate protection. Everywhere I looked, I found > issues. It's pretty embarrassing to find out that even SSL VPN's aren't > checking certs. So, yeah, I'm looking to see what level of protection > is out there. > > So, not caring *why* things are broken -- is it fair to say that libpq's > use of SSL didn't defend against the DNS bug, in any scenario except > where custom roots were set up? Yes, I think that's fair. You *can* do the verification yourself, but libpq will not do it for you. Only I will claim that the common deployment, as you refer to above, *is* with a custom root. PostgreSQL server are *very* seldom "published to the internet", and therefor tend not to use the global CA roots. //Magnus
>> Well, right now, SSL does nothing for you, so you have to do something. >> It's OK, SSL isn't doing a lot for a lot of people, but this is the >> beginning of us calling people out on that. >> > > Do feel free to explain how it "does nothing" for you with properly set > up certificates (see my previous email). (I'm still not saying it cannot > be significantly improved, of course) > > If the only roots set up are private roots, it works great. If there are generic roots (Verisign etc), or if no roots are checked at all, it's useless. Pretty simple. >> You can handle IP address and domain-search-path by having an option for >> explicitly declaring the subject name to be expected at the other side >> of the SSL connection. In other words, sever the DNS/FQDN link, and >> just explicitly say "however I reach that host over there, I expect >> database.backend.com". >> > > You can do this today. If you are willing to do it in the application, > just verify the certificate DN and you're done. > > Yes, it would certainly be a lot better to do the validation earlier in > the chain (if you're sending plaintext password, you'll end up sending > the password before you do the validation. But I don't think you even > can do that in current versions), and if it was slightly easier to do, > but you can certainly validate the cert if you want to. > > //Magnus > See, I don't care *why* things are broken -- whether they're broken at the application, at libpq, or at openssl, I'm asking the direct question -- is SSL doing anything in common deployment, and if not, what needs to be done to fix that? Background: After the DNS flaw was found, I started looking around to see if SSL was a legitimate protection. Everywhere I looked, I found issues. It's pretty embarrassing to find out that even SSL VPN's aren't checking certs. So, yeah, I'm looking to see what level of protection is out there. So, not caring *why* things are broken -- is it fair to say that libpq's use of SSL didn't defend against the DNS bug, in any scenario except where custom roots were set up? --Dan --Dan
On Tue, Aug 19, 2008 at 02:57:55PM -0400, Tom Lane wrote: > To impose such a requirement, we'd have to forbid naming the server > by IP address or via a domain-search-path abbreviation. If you ask me, the second idea at least is a good one anyway. In an SSL context, search paths are a terrible idea. (Frankly, they're a terrible idea outside that context also, but that ship sailed some time ago.) A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/
> Good, then we're in agreement that far. > > Cool! > (FWIW, I don't think I've ever seen a PostgreSQL server with a > certificate off a global root. I've seen plenty off a corporate root > though, which could in theory have similar issues - but at least you're > in control of your own problem in that case) > OK, now describe client behavior for me. Is the average client configured to accept: 1) No roots (but still works for some unknown reason) 2) Explicitly configured corporate roots 3) Explicitly configured corporate roots, AND global roots 4) Global roots (but still works for some unknown reason) Keep in mind that at least Debian distributes a ca-certificates package, and I can't imagine they're alone. > Yes, I think that's fair. You *can* do the verification yourself, but > libpq will not do it for you. > > Only I will claim that the common deployment, as you refer to above, > *is* with a custom root. PostgreSQL server are *very* seldom "published > to the internet", and therefor tend not to use the global CA roots. > So one of the nastier aspects of the DNS bug is that internal communication may get routed out to the Internet, because it's DNS that keeps things behind the firewall. If SSL is being used, the *presumption* is that there's a MITM we want to defend against.
Dan Kaminsky wrote: > >> Good, then we're in agreement that far. >> >> > Cool! >> (FWIW, I don't think I've ever seen a PostgreSQL server with a >> certificate off a global root. I've seen plenty off a corporate root >> though, which could in theory have similar issues - but at least you're >> in control of your own problem in that case) >> > OK, now describe client behavior for me. Is the average client > configured to accept: > > 1) No roots (but still works for some unknown reason) > 2) Explicitly configured corporate roots > 3) Explicitly configured corporate roots, AND global roots > 4) Global roots (but still works for some unknown reason) > > Keep in mind that at least Debian distributes a ca-certificates package, > and I can't imagine they're alone. My guess is you'll find both options 1 and 2 fairly often, and 3 and 4 very seldom. (Note that if you configure libpq for no roots, it will accept any certificate without verifying the chain) Unless, that is, some distribution (like debian) changes the default config there. I don't know enough about the specific distros to really comment on that. >> Yes, I think that's fair. You *can* do the verification yourself, but >> libpq will not do it for you. >> >> Only I will claim that the common deployment, as you refer to above, >> *is* with a custom root. PostgreSQL server are *very* seldom "published >> to the internet", and therefor tend not to use the global CA roots. >> > So one of the nastier aspects of the DNS bug is that internal > communication may get routed out to the Internet, because it's DNS that > keeps things behind the firewall. If SSL is being used, the > *presumption* is that there's a MITM we want to defend against. That's one of the things, yeah, agreed. I meant the internals part only as an argument for why you'll see most pg deployments not using global certs. OTOH, if your firewall lets your clients (or even worse - your webserver or so) connect out to arbitrary machines on the PostgreSQL port, it can easily be argued that you have a lot of homework to do elsewhere as well ;-) But that's just a mitigating factor, and not a solution. //Magnus
>> 1) No roots (but still works for some unknown reason) >> 2) Explicitly configured corporate roots >> 3) Explicitly configured corporate roots, AND global roots >> 4) Global roots (but still works for some unknown reason) >> >> Keep in mind that at least Debian distributes a ca-certificates package, >> and I can't imagine they're alone. >> > > My guess is you'll find both options 1 and 2 fairly often, and 3 and 4 > very seldom. > (Note that if you configure libpq for no roots, it will accept any > certificate without verifying the chain) > So, if you do nothing special, it's #1? Sounds like the path of least resistance is no security. Uh oh. > That's one of the things, yeah, agreed. I meant the internals part only > as an argument for why you'll see most pg deployments not using global > certs. > > OTOH, if your firewall lets your clients (or even worse - your webserver > or so) connect out to arbitrary machines on the PostgreSQL port, it can > easily be argued that you have a lot of homework to do elsewhere as well > ;-) But that's just a mitigating factor, and not a solution. > > It's hard enough to manage inbound firewall rules. Outbound? Fuggetaboutit :) --Dan
Dan Kaminsky wrote: > >> 1) No roots (but still works for some unknown reason) > >> 2) Explicitly configured corporate roots > >> 3) Explicitly configured corporate roots, AND global roots > >> 4) Global roots (but still works for some unknown reason) > So, if you do nothing special, it's #1? Sounds like the path of least > resistance is no security. Uh oh. Yeah, in the average, if not common case, a user interested in SSL use would probably just follow the recipe in the documentation for creating and installing a self-signed certificate with no certificate checking in the client. Which, as you correctly observe, is pretty much completely useless. Someone should probably redesign, reconfigure, and redocument this.
Peter Eisentraut wrote: > Dan Kaminsky wrote: >>>> 1) No roots (but still works for some unknown reason) >>>> 2) Explicitly configured corporate roots >>>> 3) Explicitly configured corporate roots, AND global roots >>>> 4) Global roots (but still works for some unknown reason) > >> So, if you do nothing special, it's #1? Sounds like the path of least >> resistance is no security. Uh oh. > > Yeah, in the average, if not common case, a user interested in SSL use would > probably just follow the recipe in the documentation for creating and > installing a self-signed certificate with no certificate checking in the > client. Which, as you correctly observe, is pretty much completely useless. > > Someone should probably redesign, reconfigure, and redocument this. Agreed. I'd like to suggest that for the "easy fix" (without supporting custom callbacks and whatever) we create a new connection parameter called "sslverifypeer". It can be set to "verifypeer", "verifycert" or "off". When set to "verifypeer", we will verify the peer name and the certificate. When "verifycert" we just verify the certificate, fail if we can't find a root certificate, but ignore the common name. "off" should be self-explaining. I'd set the default to "verifypeer" in 8.4 and up, but backpatch it with a default of "off". That way we don't break existing setups, but give users the ability to verify if if they want to. Comments? //Magnus
Magnus Hagander <magnus@hagander.net> writes:
> I'd set the default to "verifypeer" in 8.4 and up, but backpatch it with
> a default of "off". That way we don't break existing setups, but give
> users the ability to verify if if they want to.
This seems a bit large/invasive/new-feature-ish for a backpatch.
regards, tom lane
Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: >> I'd set the default to "verifypeer" in 8.4 and up, but backpatch it with >> a default of "off". That way we don't break existing setups, but give >> users the ability to verify if if they want to. > > This seems a bit large/invasive/new-feature-ish for a backpatch. I agree in principle, but I really didn't want to leave our "old" users in the cold, unable to actually use SSL to secure their systems.. The code is there, actually, it's just #ifdef NOT_USED :-) From a *long* time ago, and the commit message just says "silence compiler warnings", so I've not managed to figure out why... //Magnus
Magnus Hagander <magnus@hagander.net> writes:
> The code is there, actually, it's just #ifdef NOT_USED :-) From a *long*
> time ago, and the commit message just says "silence compiler warnings",
> so I've not managed to figure out why...
I think the commit you're looking for is this one:
2002-09-26 00:41 momjian
* doc/src/sgml/runtime.sgml, src/backend/libpq/be-secure.c,
src/interfaces/libpq/fe-secure.c: Allow SSL to work withouth
client-side certificate infrastructure.
so you'd probably need to root around in the archives from around then
to see why this was considered a good idea.
regards, tom lane
Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: >> The code is there, actually, it's just #ifdef NOT_USED :-) From a *long* >> time ago, and the commit message just says "silence compiler warnings", >> so I've not managed to figure out why... > > I think the commit you're looking for is this one: > > 2002-09-26 00:41 momjian > > * doc/src/sgml/runtime.sgml, src/backend/libpq/be-secure.c, > src/interfaces/libpq/fe-secure.c: Allow SSL to work withouth > client-side certificate infrastructure. > > so you'd probably need to root around in the archives from around then > to see why this was considered a good idea. No, that's not the one. It's the one after that one, at: http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-secure.c.diff?r1=1.14;r2=1.15 In general, that code needs a look-over, I think. There may be more changes required. //Magnus
Magnus Hagander <magnus@hagander.net> writes:
> Tom Lane wrote:
>> I think the commit you're looking for is this one:
>> 2002-09-26 00:41 momjian
> No, that's not the one. It's the one after that one, at:
No, that one is just fallout from having removed the *use* of the
function in the earlier patch.
regards, tom lane
Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: >> Tom Lane wrote: >>> I think the commit you're looking for is this one: >>> 2002-09-26 00:41 momjian > >> No, that's not the one. It's the one after that one, at: > > No, that one is just fallout from having removed the *use* of the > function in the earlier patch. Hmm. Bummer, that's right. Anyway. The code should be fairly usable I think, but we'll see that once there is some code to test... If the method I suggested seems good I'll work along that line, and we'll see when it's done if it's reasonable to backpatch it or not. If it seems the wrong track, I'm interested in suggestions on which direction we should be going in :-) //Magnus
Magnus Hagander <magnus@hagander.net> writes:
> In general, that code needs a look-over, I think. There may be more
> changes required.
Yeah, even assuming that it did what is wanted in the first place,
it's been #ifdef NOT_USED for an awfully long time. I'd suggest
looking for thread-safety and Windows-portability issues ...
regards, tom lane
Magnus Hagander wrote: > Tom Lane wrote: > > Magnus Hagander <magnus@hagander.net> writes: > >> The code is there, actually, it's just #ifdef NOT_USED :-) From a *long* > >> time ago, and the commit message just says "silence compiler warnings", > >> so I've not managed to figure out why... > > > > I think the commit you're looking for is this one: > > > > 2002-09-26 00:41 momjian > > > > * doc/src/sgml/runtime.sgml, src/backend/libpq/be-secure.c, > > src/interfaces/libpq/fe-secure.c: Allow SSL to work withouth > > client-side certificate infrastructure. > > > > so you'd probably need to root around in the archives from around then > > to see why this was considered a good idea. > > No, that's not the one. It's the one after that one, at: > > http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-secure.c.diff?r1=1.14;r2=1.15 > > In general, that code needs a look-over, I think. There may be more > changes required. I found the reason for the patch; the SSL guy at that time, "Bear", disappeared, and our code required SSL certificates at that point, so I removed the requrement: http://archives.postgresql.org/pgsql-hackers/2002-09/msg01522.php I will work with Magnus on cleaning this up. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> I found the reason for the patch; the SSL guy at that time, "Bear",
> disappeared, and our code required SSL certificates at that point, so I
> removed the requrement:
Hmm, according to that thread the code that got diked out "didn't work
according to Peter", but I can't find anything in Sept 2002
pgsql-hackers suggesting exactly what was wrong.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > I found the reason for the patch; the SSL guy at that time, "Bear", > > disappeared, and our code required SSL certificates at that point, so I > > removed the requrement: > > Hmm, according to that thread the code that got diked out "didn't work > according to Peter", but I can't find anything in Sept 2002 > pgsql-hackers suggesting exactly what was wrong. I looked back in hackers through June 2002 and found no mention of why it didn't work either. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +