Re: CA certificate directory for a VPN client

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/01/18 08:39, Mikhail Zabaluev wrote:
> A question arose about a good choice of the default directory for
> trusted CA certificates over these proposed rpm PRs:
> 
> https://src.fedoraproject.org/rpms/strongswan/pull-request/6
> https://src.fedoraproject.org/rpms/strongswan/pull-request/7
> 
> An IKEv2 client from strongSwan package, charon-nm, needs to be
> configured with a directory name to load trusted X.509 CAs from. The
> CA certificates are used to authenticate VPN servers.
> 
> There are following considerations for the directory choice:
> 
> 1. It should be in /etc so that it can be configured on ostree machines.
> 2. There is a concern with using a subdirectory of
> /etc/pki/ca-trust/extracted : charon-nm has no regard for key usage
> flags, and there are indeed no standardized flags to authorize
> specifically the VPN usage. Trusting by default any CA that is used to
> validate TLS websites may be considered too permissive; small VPN
> operators typically use self-signed or private CA certificates.

If a single CA list for both TLS and VPNs was used, and a user added a
VPN's private CA to that shared list, it would technically enable the
VPN operator to issue false certificates, and TLS clients like Firefox
would then trust such false certificates. This side effect of installing
a VPN's private CA should be avoided.

Therefore I agree with you, the directory for VPN CAs should be
configured separately.

Are there any VPNs that use server certificates issued by web CAs? All
VPNs that I have seen personally used their own CA certificates.


> 3. It would be useful to have a shared CA certificate directory
> configured out of the box for various VPN clients, similarly to how
> /etc/pki/tls/certs can be shared by any applications using TLS.

If a user wants to connect to a specific VPN A, the user might also like
to avoid to connect to a service operated by an attacker that pretends
to be A. If most VPN CAs are private CAs, and haven't been audited in
similar ways as the Mozilla CA Certificate program is doing it, that
might be an argument for shipping an empty directory by default, and
requiring the user to manually install the CA certificate for only the
services they intend to connect to.


> I came up with /etc/pki/vpn, that is not currently populated in
> Fedora. Would there be a more appropriate choice, governed by PKI
> policies that I'm not aware of?

If the directory format expected by charon-nm might be different from
the input expect by other vpn clients, then it might make sense to
define a directory specifically for charon-nm. If you think it's
reusable, it might make sense to define the file format expected in that
directory. For TLS, because different tools require the list of CAs in
different format, we have chosen the approach that is documented in the
update-ca-trust(8) manual apge.

Does charon-nm want individual files? Does it expect specific filenames,
like the hashed filenames that openssl may use? Does it expect files in
PEM or DER format? Does it support files in which multiple certificates
are concatenated, or does it accept only one CA per file? These are
example attributes, that might cause the contents of the directory to
work only for the charon-nm tool, but not for others.

Kai
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/W64BLLOEGMI34AWO6ODUBDDBKEJOXJI5/




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux