* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > These no real way around this. The only real option would be moving to
> > a home directory but that would require knowing the username the server
> > is running under...
>
> And the problem would still exist, with even less chance of solution,
> for TCP connections which are probably the majority of real-world usage.
> If you're concerned about this sort of attack I think it has to be
> solved in the protocol, not by reliance on socket placement.
>
> I'm not sure whether our current SSL support does a good job of this
> --- I think it only tries to check whether the server presents a
> valid certificate, not which cert it is. Possibly Kerberos does more,
> but I dunno a thing about that...
With AP_OPTS_MUTUAL_REQUIRED (which we and most other Kerberos
client/server setups use), the user and the server authenticate to each
other. The server has to prove it has access to the same key the KDC
has on file for the server, and the client has to do the same. We
really should support the various options for SSL checking. Options to
define trusted CAs, checking CN against what the IP address of the
server resolves to, mapping of DN to username (perhaps regexp based),
explicitly certificate -> username mapping, etc...
Of course, it'd be nice to get SASL support and move to GSSAPI instead
of the Kerberos API... :)
Thanks,
Stephen
