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
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,
Magnus Hagander [EMAIL PROTECTED] 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.
Magnus Hagander [EMAIL PROTECTED] 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
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] 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
Magnus Hagander [EMAIL PROTECTED] 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
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] 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
Bruce Momjian [EMAIL PROTECTED] 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,
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
Tom Lane [EMAIL PROTECTED] 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
Dan Kaminsky [EMAIL PROTECTED] 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
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] 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
Tom Lane wrote:
Dan Kaminsky [EMAIL PROTECTED] 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
Dan Kaminsky wrote:
Tom Lane wrote:
Dan Kaminsky [EMAIL PROTECTED] 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
Magnus Hagander [EMAIL PROTECTED] 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
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] 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
Dan Kaminsky wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] 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
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] 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
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
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
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
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
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
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
Bruce Momjian wrote:
Tom Lane wrote:
Dan Kaminsky [EMAIL PROTECTED] 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
Alvaro Herrera [EMAIL PROTECTED] 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
Tom Lane wrote:
Dan Kaminsky [EMAIL PROTECTED] 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
The following bug has been logged online:
Bug reference: 4340
Logged by: Dan Kaminsky
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.3
Operating system: Any
Description:SECURITY: Is SSL Doing Anything?
Details:
Dan Kaminsky [EMAIL PROTECTED] 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
Tom Lane wrote:
Dan Kaminsky [EMAIL PROTECTED] 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
30 matches
Mail list logo
