Horton
Menu

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Remove RADIUS support.

  1. Time to drop RADIUS support?

    Thomas Munro <thomas.munro@gmail.com> — 2026-01-23T10:22:45Z

    Hi,

A bit over a year ago, I wrote about a RADIUS vulnerability and a
recommended mitigation[1].  I was grateful for the reviews, but I lost
steam on those patches because:

1.  Our implementation seems to have accidental (?) resilience because
it has a short hard-coded timeout.  The RADIUS/UDP Considered
Harmful[0] people used 47 servers to get "2% of the successful runs to
finish before 240s and 16% before 300s", but we time out after 3
seconds.  Assuming perfect scaling, maybe they could use 4700 servers
to get a 16% chance of success in 3s... or maybe I have the maths
wrong but it's fairly extreme anyway...

2.  It seems increasingly likely that there are no users, since
RADIUS/UDP without the mitigation spews warnings from FreeRADIUS, and
Microsoft RADIUS's 2024 update (KB5040456) recommended requiring it
(though you didn't have to accept IIUC).  I'm pretty sure we'd have
heard about it from users if there were any.

3.  That mitigation would help, but in the end it's still leaky
obfuscation of credentials + MD5-based technology that is being
formally deprecated with a mandated replacement[2], and de facto has
been for a long time.

The real recommendation of the paper was "don't use RADIUS/UDP at
all", and I don't want to expend energy writing a RADIUS/TLS client
for a hypothetical user, so I think we should just delete it all, and
stick a deprecation notice in the release branch documentation, as
attached.  That'd also mean our Windows select() and non-thread-safe
UDP kludges can be VACUUMed.

AFAICS you can already do RADIUS better with PAM using a module
maintained by the FreeRADIUS project (see below for quick and dirty
demo).  That way it's not our problem, follows the standards etc.  The
only issue I can think of with that is that Windows and OpenBSD
probably don't have PAM. But then, recall that we are talking about
approximately zero users so I think we can still hit 100% of them this
way?



=== Example of RADIUS via PAM ===

Tell PAM how to authenticate for service postgresql in /etc/pam.d/postgresql:
#%PAM-1.0
auth required pam_radius.so require_message_authenticator
account required pam_permit.so

Tell pam_radius.so how to talk to RADIUS server in /etc/radius.conf:
# Server[:port] SharedSecret Timeout Retries
127.0.0.1 shared_secret 3 3

Tell PostgreSQL to use PAM service postgresql in pg_hba.conf:
host all all 127.0.0.1/32 pam pamservice=postgresql

=== Setting up a test server to try it out ===

Tell FreeRADIUS how to be a RADIUS server in /tmp/radiusd/radiusd.conf:
/tmp/radiusd/radiusd.conf
client default {
  ipaddr = "127.0.0.1"
  secret = "shared_secret"
}
modules {
  files {
    filename = "/tmp/radiusd/users.txt"
  }
  pap {
  }
}
server default {
  listen {
    type   = "auth"
    ipv4addr = "127.0.0.1"
    port = "1812"
  }
  authenticate {
    Auth-Type PAP {
      pap
    }
  }
  authorize {
    files
    pap
  }
}
log {
  destination = "files"
  localstatedir = "/tmp/radiusd"
  logdir = "/tmp/radiusd"
  file = "/tmp/radiusd/radiusd.log"
}
pidfile = "/tmp/radiusd/radiusd.pid"

Tell FreeRADIUS the passwords in /tmp/radiusd/users.txt:
testuser Cleartext-Password := "xxx"

Then run it in the foreground with "radiusd -d /tmp/radiusd -f".  If
you leave out "require_message_authenticator" from
/etc/pam.d/postgresql then you'll get log messages just like when
PostgreSQL speaks RADIUS natively:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
BlastRADIUS check: Received packet without Message-Authenticator.
Setting "require_message_authenticator = false" for client default
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
UPGRADE THE CLIENT AS YOUR NETWORK IS VULNERABLE TO THE BLASTRADIUS ATTACK.
Once the client is upgraded, set "require_message_authenticator =
true" for  client default
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Both client and server should ideally be set to require
Message-Authenticator.  Presumably with more coffee and man pages you
could also configure it to use RADIUS/TLS instead of RADIUS/UDP, etc.

[0] https://www.usenix.org/conference/usenixsecurity24/presentation/goldberg
[1] https://www.postgresql.org/message-id/flat/CA%2BhUKGLRSPTOC_ygx4_sJjWeKOkOpWGCBCJiRq8cPNuMisuzgw%40mail.gmail.com
[2] https://datatracker.ietf.org/doc/draft-ietf-radext-deprecating-radius/

  2. Re: Time to drop RADIUS support?

    Michael Banck <mbanck@gmx.net> — 2026-01-23T10:43:22Z

    Hi,

On Fri, Jan 23, 2026 at 11:22:45PM +1300, Thomas Munro wrote:
> The real recommendation of the paper was "don't use RADIUS/UDP at
> all", and I don't want to expend energy writing a RADIUS/TLS client
> for a hypothetical user, so I think we should just delete it all, and
> stick a deprecation notice in the release branch documentation, as
> attached.

So you are saying we add a deprecation notice in the back branches and
drop it in V19? If this is a severe security issue then maybe we can
just remove it everywhere (ugh), or if not, I think it probably warrants
at least one release cycle of deprecation. Do we have a formal
deprecation timeline policy nowadays?


Michael

  3. Re: Time to drop RADIUS support?

    Álvaro Herrera <alvherre@kurilemu.de> — 2026-01-23T14:53:13Z

    On 2026-Jan-23, Michael Banck wrote:

> So you are saying we add a deprecation notice in the back branches and
> drop it in V19? If this is a severe security issue then maybe we can
> just remove it everywhere (ugh), or if not, I think it probably warrants
> at least one release cycle of deprecation. Do we have a formal
> deprecation timeline policy nowadays?

I don't think we do.

Would it work to add a WARNING (or something) to all back branches to
ask users to write here, so that we can confirm in the next few months
whether the protocol is completely unused or not?  If we do find users,
then we could try to think of workarounds[*], but otherwise we'd just
remove it for pg19 (or pg20 at the latest) and not waste any more time
on it.

I don't think removing it entirely from all back branches is a good
idea, without first making sure that there are no users.

[*] or even just a way to document a migration to PAM-based Radius.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"I'm impressed how quickly you are fixing this obscure issue. I came from 
MS SQL and it would be hard for me to put into words how much of a better job
you all are doing on [PostgreSQL]."
 Steve Midgley, http://archives.postgresql.org/pgsql-sql/2008-08/msg00000.php

  4. Re: Time to drop RADIUS support?

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-01-23T16:30:07Z

    =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
> Would it work to add a WARNING (or something) to all back branches to
> ask users to write here, so that we can confirm in the next few months
> whether the protocol is completely unused or not?  If we do find users,
> then we could try to think of workarounds[*], but otherwise we'd just
> remove it for pg19 (or pg20 at the latest) and not waste any more time
> on it.

I don't think that'd prove a lot.  Affected users (if any) wouldn't
necessarily be quick to adopt the latest minor releases.  They're
probably not even up-to-date on their RADIUS server, or they'd have
noticed it spewing complaints.

> I don't think removing it entirely from all back branches is a good
> idea, without first making sure that there are no users.

Agreed, we can't pull it from the back branches.  But I'm in favor of
pulling it from HEAD if we document how to use PAM-based RADIUS
instead.  I agree with Thomas' argument that the cost-benefit ratio
of fixing our implementation would be poor.

			regards, tom lane

  5. Re: Time to drop RADIUS support?

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-01-23T17:50:40Z

    On Fri, Jan 23, 2026 at 8:30 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > I don't think removing it entirely from all back branches is a good
> > idea, without first making sure that there are no users.
>
> Agreed, we can't pull it from the back branches.  But I'm in favor of
> pulling it from HEAD if we document how to use PAM-based RADIUS
> instead.  I agree with Thomas' argument that the cost-benefit ratio
> of fixing our implementation would be poor.

+1.

I still think a WARNING in the back branches would be a kindness, to
let people know that they need to move.

--Jacob

  6. Re: Time to drop RADIUS support?

    Thomas Munro <thomas.munro@gmail.com> — 2026-01-24T23:14:19Z

    On Sat, Jan 24, 2026 at 6:50 AM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> On Fri, Jan 23, 2026 at 8:30 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > I don't think removing it entirely from all back branches is a good
> > > idea, without first making sure that there are no users.
> >
> > Agreed, we can't pull it from the back branches.  But I'm in favor of
> > pulling it from HEAD if we document how to use PAM-based RADIUS
> > instead.  I agree with Thomas' argument that the cost-benefit ratio
> > of fixing our implementation would be poor.
>
> +1.

Great, it sounds like we have a plan.  I think the wiki might be a
good place for that documentation.  The details are likely to change,
and I wouldn't want to have to maintain that information in-tree, so I
created some PAM how-to documentation at
https://wiki.postgresql.org/wiki/RADIUS after testing on Debian and
FreeBSD.  We could point to that from the 19 release notes and in the
deprecation notice added to the documentation for 14-18, calling it
"community-maintained guidance on migration to supported
configurations".  Do we need to keep any trace of this in the 19 docs,
and if so, where?  A new tombstone section?

  7. Re: Time to drop RADIUS support?

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-01-25T01:02:44Z

    Thomas Munro <thomas.munro@gmail.com> writes:
> Great, it sounds like we have a plan.  I think the wiki might be a
> good place for that documentation.  The details are likely to change,
> and I wouldn't want to have to maintain that information in-tree, so I
> created some PAM how-to documentation at
> https://wiki.postgresql.org/wiki/RADIUS after testing on Debian and
> FreeBSD.

Ok ...

> We could point to that from the 19 release notes and in the
> deprecation notice added to the documentation for 14-18, calling it
> "community-maintained guidance on migration to supported
> configurations".  Do we need to keep any trace of this in the 19 docs,
> and if so, where?  A new tombstone section?

I think we don't want
https://www.postgresql.org/docs/current/auth-radius.html
to become 404, so I'd advocate keeping a short section with that
SGML ID that says we no longer support RADIUS directly and
gives a pointer to the wiki page.  It probably doesn't belong
exactly where it is today in the TOC, though, but shoved off
in a corner somewhere.

			regards, tom lane

  8. Re: Time to drop RADIUS support?

    Aleksander Alekseev <aleksander@tigerdata.com> — 2026-01-26T13:06:35Z

    Hi,

> 3.  That mitigation would help, but in the end it's still leaky
> obfuscation of credentials + MD5-based technology that is being
> formally deprecated with a mandated replacement[2], and de facto has
> been for a long time.
>
> The real recommendation of the paper was "don't use RADIUS/UDP at
> all", and I don't want to expend energy writing a RADIUS/TLS client
> for a hypothetical user, so I think we should just delete it all, and
> stick a deprecation notice in the release branch documentation, as
> attached.  That'd also mean our Windows select() and non-thread-safe
> UDP kludges can be VACUUMed.

All things considered, it sounds perfectly reasonable. +1.

-- 
Best regards,
Aleksander Alekseev

  9. Re: Time to drop RADIUS support?

    Thomas Munro <thomas.munro@gmail.com> — 2026-04-08T10:47:53Z

    On Sun, Jan 25, 2026 at 2:02 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I think we don't want
> https://www.postgresql.org/docs/current/auth-radius.html
> to become 404, so I'd advocate keeping a short section with that
> SGML ID that says we no longer support RADIUS directly and
> gives a pointer to the wiki page.  It probably doesn't belong
> exactly where it is today in the TOC, though, but shoved off
> in a corner somewhere.

TIL that there is an appendix for that very purpose.  So, done.