Re: CA certificate directory for a VPN client

2018-06-12 Thread Mikhail Zabaluev
Hi Kai,

2018-06-12 16:55 GMT+03:00 Kai Engert :
>
> 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.

A public VPN service provider might conceivably use a certificate
issued by a well-known public CA to spare the clients the hassle of
installing custom CA certificates.

> > 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.

Accordingly to the documentation and my brief analysis of the code,
charon-nm can load both PEM or DER. It tries to load all files present
in the configured directory as CA certificates, using OpenSSL
functions to parse the formats.
It supports concatenated certificate bundles at least in PEM format; I
verified that it works with the bundle file in
/etc/pki/ca-trust/extracted/openssl. So I think the directory can be
shared between charon-nm and other VPN clients using standard PKI
formats.

Best regards,
  Mikhail
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org/message/RVEHEBDYZBESZM2FAR57L4JIKT5XA2QP/


Re: CA certificate directory for a VPN client

2018-06-12 Thread Kai Engert
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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org/message/W64BLLOEGMI34AWO6ODUBDDBKEJOXJI5/