- État À investiguer
- Pourcentage achevé
- Type Anomalie
- Catégorie Services locaux → Serveur VPN
-
Assignée à
mbizon - Système d'exploitation Tous
- Sévérité Moyenne
- Priorité Très Basse
- Basée sur la version 3.5.2
- Due pour la version Non décidée
-
Échéance
Non décidée
-
Votes
1
- Raptor039 (12/12/2018)
- Privée
Ouverte par TheGreenBowVPN - 02/07/2018
Dernière modification par mbizon - 04/09/2020
FS#22745 - Serveur OpenVPN: génération des certificats serveur et serveur CA
Bonjour,
Je viens de recréer la configuration serveur OpenVPN d’une Freebox Revolution.
En utilisant le client VPN TheGreenBow, je constate que les 2 certificats serveur et serveur CA sont bien différents, mais ils utilisent la même clef publique.
Ils ont aussi la même valeur pour le champ “Subject key identifier”.
Est-ce volontaire ? ou est-ce une erreur, ou mauvaise manip de ma part ?
Si c’est volontaire, ce n’est pas conforme. D’après la RFC 5280 paragraphe 4.2.1.2, le champ “Subject key identifier” est bien censé être unique pour chaque certificat, et il est effectivement calculé à partir du champ “subjectPublicKey”.
Je peux faire d’autres manips, ou donner plus d’information si besoin.
Avec mon ancienne configuration Serveur OpenVpn de la Freebox je n’avais pas constaté ce problème. Un utilisateur Freebox 4k + Client TheGreenBox nous a remonté aussi ce problème, que j’arrive donc maintenant à reproduire.
Merci,
Frederic Gloannec
TheGreenBow VPN.
Chargement...
Activer les raccourcis clavier
- Alt + ⇧ Shift + l Se connecter/Se déconnecter
- Alt + ⇧ Shift + a Ouvrir une tâche
- Alt + ⇧ Shift + m Mes recherches
- Alt + ⇧ Shift + t Rechercher par ID de tâche
Liste des tâches
- o Ouvrir la tâche sélectionnée
- j Déplacer le curseur vers le bas
- k Déplacer le curseur vers le haut
Détails de la tâche
- n Tâche suivante
- p Tâche précédente
- Alt + ⇧ Shift + e ↵ Enter Modifier cette tâche
- Alt + ⇧ Shift + w Surveiller
- Alt + ⇧ Shift + y Fermer cette tâche
Édition de la tâche
- Alt + ⇧ Shift + s Enregistrer la tâche
Je constate la même chose, mais sachant que c'est la même clé qui est utilisée pour le CA et le serveur, le comportement actuel est plus logique. On a changé la version d'openssl donc c'est peut être la raison pour laquelle c'est maintenant identique.
Quant à la conformité, je rajoute un bémol, seul le cert CA a la "basic constraint CA" à true, donc si vous utilisez le SKI pour créer le path de validation, le cert serveur ne devrait pas être présent dans la chaîne et donc rentrer en collision avec la CA.
Bonjour,
Merci pour votre réponse.
Normalement OpenSSL offre juste un ensemble de commandes qui permettent la création des certificats, mais ne doit pas imposer que les clef publiques de 2 certificats différents soient les mêmes.
Dans le cas de la Freebox, comme le certificat serveur CA ne sert que pour le certificat serveur d'une Freebox en particulier, un risque de sécurité est sans doute faible.
Dans le cas où un certificat CA sert à générer de multiples certificats (pour les users et/ou les passerelles) alors c'est un peu gênant si l'un des certificats se retrouve avec la même clef publique que son propre CA.
Est-ce que ce fonctionnement de la Freebox sur la génération des certificats sera revu dans une prochaine version ?
Merci,
Frédéric Gloannec
TheGreenBow VPN.
Il serait judicieux de changer le comportement actuel afin de corriger le problème.
Du neuf en 4.2.3 ?
@mbizon, ça devrait évoluer avec ça non ?
OpenVPN 2.5.0 (2020-10-27) :
- https://openvpn.net/
- https://github.com/OpenVPN/openvpn/releases
Email d'annonce de la sortie d'OpenVPN 2.5.0 :
- https://sourceforge.net/p/openvpn/mailman/message/37138737/
OpenVPN 2.5 is a new major release with many new features:
- Client-specific tls-crypt keys (–tls-crypt-v2)
- Added support for using the ChaCha20-Poly1305 cipher in the OpenVPN data channel
- Improved Data channel cipher negotiation
- Removal of BF-CBC support in default configuration
- Asynchronous (deferred) authentication support for auth-pam plugin
- Deferred client-connect
- Faster connection setup
- Netlink support
- Wintun support
- IPv6-only operation
- Improved Windows 10 detection
- Linux VRF support
- TLS 1.3 support
- Support setting DHCP search domain
- Handle setting of tun/tap interface MTU on Windows
- HMAC based auth-token support
- VLAN support
- Support building of .msi installers for Windows
- Allow unicode search string in –cryptoapicert option (Windows)
- Support IPv4 configs with /31 netmasks now
- New option –block-ipv6 to reject all IPv6 packets (ICMPv6)
- MSI installer (Windows)
- The MSI installer now bundles EasyRSA 3, a modern take on OpenVPN CA management
Overview of changes in OpenVPN v2.5:
- https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn25
Rappel pour la 2.4.x (il manque toujours des options dans Freebox OS) :
Overview of changes in OpenVPN v2.4:
- https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn24
OpenVPN 2.5.1 (2021-02-24) :
- https://openvpn.net/
- https://github.com/OpenVPN/openvpn/releases
- https://sourceforge.net/p/openvpn/mailman/message/37226597/
[Openvpn-announce] OpenVPN 2.5.1 released From: Samuli Seppänen <samuli@op...> - 2021-02-24 13:50:33 The OpenVPN community project team is proud to release OpenVPN 2.5.1. It includes several bug fixes and improvements as well as updated OpenSSL and OpenVPN GUI for Windows. Source code and Windows installers can be downloaded from our download page: <https://openvpn.net/community-downloads/>; Debian and Ubuntu packages are available in the official apt repositories: <https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos>; On Red Hat derivatives we recommend using the Fedora Copr repository. <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-release/>; --- Overview of changes since OpenVPN 2.4 Faster connections Connections setup is now much faster Crypto specific changes ChaCha20-Poly1305 cipher in the OpenVPN data channel Requires OpenSSL 1.1.0 or newer) Improved TLS 1.3 support when using OpenSSL 1.1.1 or newer Client-specific tls-crypt keys (--tls-crypt-v2) Improved Data channel cipher negotiation Removal of BF-CBC support in default configuration (see below for possible incompatibilities) Server-side improvements HMAC based auth-token support for seamless reconnects to standalone servers or a group of servers. Asynchronous (deferred) authentication support for auth-pam plugin Asynchronous (deferred) support for client-connect scripts and plugins Network-related changes Support IPv4 configs with /31 netmasks now 802.1q VLAN support on TAP servers IPv6-only tunnels New option --block-ipv6 to reject all IPv6 packets (ICMPv6) Linux-specific features VRF support Netlink integration (OpenVPN no longer needs to execute ifconfig/route or ip commands) Windows-specific features Wintun driver support, a faster alternative to tap-windows6 Setting tun/tap interface MTU Setting DHCP search domain Allow unicode search string in --cryptoapicert option EasyRSA3, a modern take on OpenVPN CA management MSI installer --- Important notices BF-CBC cipher is no longer the default Cipher handling for the data channel cipher has been significantly changed between OpenVPN 2.3/2.4 and v2.5, most notably there are no "default cipher BF-CBC" anymore because it is no longer considered a reasonable default. BF-CBC is still available, but it needs to be explicitly configured now. For connections between OpenVPN 2.4 and v2.5 clients and servers, both ends will be able to negotiate a better cipher than BF-CBC. By default they will select one of the AES-GCM ciphers, but this can be influenced using the --data-ciphers setting. Connections between OpenVPN 2.3 and v2.5 that have no --cipher setting in the config (= defaulting to BF-CBC and not being negotiation-capable) must be updated. Unless BF-CBC is included in --data-ciphers or there is a "--cipher BF-CBC" in the OpenVPN 2.5 config, a v2.5 client or server will refuse to talk to a v2.3 server or client, because it has no common data channel cipher and negotiating a cipher is not possible. Generally, we recommend upgrading such setups to OpenVPN 2.4 or v2.5. If upgrading is not possible we recommend adding data-ciphers AES-256-GCM:AES-128-GCM:AES-128-CBC (for v2.5+) or cipher AES-128-CBC (v2.4.x and older) to the configuration of all clients and servers. If you really need to use an unsupported OpenVPN 2.3 (or even older) release and need to stay on BF-CBC (not recommended), the OpenVPN 2.5 based client will need a config file change to re-enable BF-CBC. But be warned that BF-CBC and other related weak ciphers will be removed in coming OpenVPN major releases. For full details see the Data channel cipher negotiation section on the man page. Connectivity to some VPN service provider may break Connecting with an OpenVPN 2.5 client to at least one commercial VPN service that implemented their own cipher negotiation method that always reports back that it is using BF-CBC to the client is broken in v2.5. This has always caused warning about mismatch ciphers. We have been in contact with some service providers and they are looking into it. This is not something the OpenVPN community can fix. If your commercial VPN does not work with a v2.5 client, complain to the VPN service provider. More details on these new features as well as a list of deprecated features and user-visible changes are available in Changes.rst: <https://github.com/OpenVPN/openvpn/blob/release/2.5/Changes.rst>; ---Freebox OS 4.3.1 a OpenVPN 2.5.0, est-ce qu'il y a une amélioration ?
Thank you very much. You did an excellent job. I enjoyed reading your blog. Slope Unblocked is an entertaining game that puts your reflexes and reactions to the test.