Restrict login/access based on TLS client certificate?

[pccw]

Hello,

Is it possible to check the login user against a TLS client
certificate?  The intention is to ensure that a certificate only
allows a login to the account mentioned in the certificate, or that
all access is denied if a login to a different account can not be
prevented.

Potential mechanisms like:

    AllowUser %{env:TLS_CLIENT_S_DN_CN}

    <IfUser %{env:TLS_CLIENT_S_DN_CN}>

don't seem to work. (Maybe because the evaluation takes place before
the TLS information is available?)

A similar question was asked more than two years ago:

    http://forums.proftpd.org/smf/index.php/topic,1972.0.html

It seems that at the time coding was required. Have there been any
developments since then that allow this functionality?

Regards and thanks,

Peter Wagemans

[castaglia]

There have been no developments for this kind of feature, no -- it's not something that comes up often.

The previous post requested a slightly different functionality than I think you want.  If I understand correctly, you're looking for ACLs based on client-presented certificate; the previous post was asking about mapping client-present certificate to user accounts.

Would you expect to restrict just login access, or would you want something more granular, similar to <Limit>?  Would the blacklist (or whitelist?) of certs be stored in a single file (and thus in PEM format), in a directory, or retrieved from LDAP/SQL?

[pccw]

> Would you expect to restrict just login access, or would you want
> something more granular, similar to <Limit>? 

A certificate should provide access only to the account associated
with the certificate and not to other accounts. For example, Bob
should not be able to ftp files from Alice if he knows her password
but doesn't have access to her certificate private key.

If the account name is the same as the common name in the client
certificates, a general deny in combination with

AllowUser %{env:TLS_CLIENT_S_DN_CN}

would allow access only to that account. [But this construction
doesn't appear to work.]

In general the account might not be identical to a component of the
certificate subject distinguished name, so a mapping or query
(SQL/LDAP) might then be required to find the account that belongs to
the certificate.



I haven't looked at the code to figure out why the above AllowUser
doesn't work. I first built a configuration that used

AllowUser %{env:ALLOWLIST}

with ALLOWLIST set to the CN from the certificate (with SetEnv) and
that worked. When I replaced ALLOWLIST by TLS_CLIENT_S_DN_CN access
was refused, but a LogFormat with %{TLS_CLIENT_S_DN_CN}e shows that
this variable is set to the correct value, at least at the time of
logging. So my suspicion is that the evaluation of
%{env:TLS_CLIENT_S_DN_CN} for the AllowUser directive takes places
before the TLS engine has set it.

> Would the blacklist (or whitelist?) of certs be stored in a single
> file (and thus in PEM format), in a directory, or retrieved from
> LDAP/SQL?

I'm not sure a certificate list is helpful. The cert has been verified
by the TLS engine, so the content is trusted information. You need a
way to map the certificate or information extracted from it (like
%{env:TLS_CLIENT_S_DN_CN}) to a user account and use that account in
existing directives for access control.

[castaglia]

I do not assume that there is necessarily a relation between a certificate and an account; a client can present the same certificate and send USER/PASS for different accounts, or a client can send USER/PASS for the same account using different certificates.  So requesting access control by certificate is a different request than certificate-to-account mappings.

I am finding it hard to understand exactly what functionality you are requesting; it would help if you could describe in terms that do not assume changes to proftpd (i.e. please do not use AllowUser or mod_ifsession examples when describing the functionality you are trying to achieve).  Feature requests couched in terms of suggested implementations are not as clear as feature requests described such that no specific implementation is assumed.

[pccw]

> I do not assume that there is necessarily a relation between a
> certificate and an account

Yes, of course. But that is the functional requirement: the relation
is that the client certificate should identify the account(s) it has
access to. An ftp session that uses that client certificate may only
have access to (the data of) those accounts. That client certificate
may not be used to access (the data of) other accounts.

In other words, a client certificate strongly identifies somebody (or
some organisation) and you don't want this person to access other
people's data (even if they guessed or otherwise obtained their
password).

> please do not use AllowUser or mod_ifsession examples when
> describing the functionality you are trying to achieve).

The given examples specify exactly what I was trying to achieve for my
relation between certificate and account: each account has one
certificate and the account name is equal to the subject common name,
so if the directive

AllowUser %{env:TLS_CLIENT_S_DN_CN}

would work then my one-to-one restriction between certificate and
account would have been realised.


In the general case, there could be other ways to define a relation
between a certificate and the account(s) it has access to, for example

 1. mapping (similar to RewriteMap) or query LDAP or SQL database

    1.a. map certificate or information extracted from the certificate
    (e.g., distinguished name) to allowed account(s).

    1.b. map account to allowed certificate(s)

 2. store certificate(s) or subject distinguished name(s) under the
    home directory (similar to .tlslogin or the SSH authorized_keys
    file but with different functionality).

Disadvantage of mapping from/to a complete certificate is the renewal
process. A mapping in terms of (components of) the subject
distinguished name is probably stable over renewals, the certificates
themselves are not.

[lec]

I do agree with this request: requesting a client certificate for strong authentication is a very good feature, but falling back to user/password (like with the AllowDotLogin option) break the security.
I have seen a AllowUidLogin option in mod_gnutls but the doc does not specify if we are still falling back to user/password if the client cert login fails (no user with this UID).

[lec]

Actually I just found that we maybe can do it with AllowDotLogin but it would require a code change in mod_tls.c and use the PR_AUTH_FL_REQUIRED parameter in the auth table definition to make this authentication no longer optional but mandatory.
Does anyone knows if this would really work ?
As mentioned, not ideal as cert must be deployed on servers, but still better than nothing....