Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

+1, c’est le cas sur mon synology sous DSM 3.0, je pense qu’ils ne tarderons pas a y passer.
Après, a force de rajouter des fonctionnalités, faudrait pas que ca devienne une charette...

+1, et un bon exemple de ce que devrait être le freebox server, c’est bien les synology...qui d’ailleurs partage pour certains le même SoC...

Ah oui et vite, j’ai vu un commentaire de clôture qui m’a juste fait dresser le poil et avoir une sueur froide !!!!!

laisser passer des identifiants en texte clair sur un réseau public, est une honte, dans mon métier ça va meme au pénal !!!!!! quand je lis une raison de la préférence de laisser en clair... ça me fait peur très peur.

SURTOUT SURTOUT n’utilisez pas l’option de control à distance tant que ce n’est pas chiffré ou chiffrable. j’irai presque jusqu’à parier que d’ici un jour ou deux ou voit des tuto partout pour chopper des ID (le tuto est faisable en 5 minutes top chrono, c’est le temps qu’ils nous à fallu cet aprem pour tester la manie au bureau, mon métier m’autorise à faire ces manips)

et surtout par pitié passez cette tache en CRITIQUE / HAUTE

Surtout qu’openssl est déjà installé sur la box, et il doit bien deja y avoir une CA qui traine chez free non qui pourrait nous valider les CSR faite pour l’interface.

HS
Nicolas, mon message de demande de réouverture est passé un peu vite, il manque la fin, dsl. suis dispo pour en discuter si besoin.
/HS

pour ceux qui vérifieront le certificat, pas de possibilité de se faire voler les identifiants ou la session par un man in the middle.

Le certificat autosigné va très bien pour ceux qui vérifient le certificat avant d’accepter la connection ...

un serveur openvpn sur la freebox server permettrait de sécuriser les connections http et ftp. Comme pour le serveur ftp accessible depuis l’extérieur, c’est déjà possible, en hébergeant un serveur openvpn sur le réseau interne mais il faut forcément une machine qui tourne 24/7, hors c’est exactement le cas de la freebox server ...

HS : à quand le client nzbget ipv6 compliant

   à quand la possibilité de définir un cookie pour les sites de direct download et/ou possibilité d'utiliser ses identifiants (comptes premium)

Surtout qu’openssl est deja installé dessus. generation de la paire de clé, hop extraction de la clé du CA et integration du certificat de la CA dans ses propres machines. allez hop qu’il vienne le MIM je l’attends de pied ferme.

Ah oui faudrait aussi ajouter une entrée permettant de mettre le certificat dans l’apache (je crois) qui tourne sur la freeteuse.

En une demie journée c’est torché !!

de toute facon vu le rollback de la MAJ maintenant on s’en tape. mais y a pas intérêt à voire revenir le contrôle à distance d’une interface d’admin non chiffrée !

Est il nécessaire de rappeler que le défaut de sécurisation de sa connexion internet est un délit depuis une certain HADOPI ? Et qu’au niveau légal il n’y a pas une obligation de résultat (certes) mais il est écrit clairement “obligation de moyen” sur le texte que j’ai sous les yeux, surtout pour un fournisseur d’accès.

heu on va faire les choses par étape hein ^^

d’abord on gère la PKI, après on voit pour l’openvpn (qui à dit opensawn ? ^^)

+1 Cette tache devrait être CRITIQUE / HAUTE !
L’accès depuis l’extérieur c’est du suicide tant que le https n’est pas dispo.

Tout a fait, ne serait-ce qu’un certificat autosigné serait deja un progres
Bon courage ! B.

oh que oui ;)
up !

Oh yeah. Indispensable. On est quand même en 2011, un minimum de sécurité ne fait pas de mal, et c’est pas comme si ajouter un certificat auto-signé sur la box était très compliqué...

Tout à fait d’accord, l’accès à l’interface de gestion en http est très risquée !
Étant donné que les certificats SSL sont loin d’être gratuits, un certificat auto-signé sur le boîtier serveur ferait très bien l’affaire en effet.

+1

En écoutant le trafic réseau, n’importe qui de mon entreprise pourrait récupérer mon mot de passe, en clair !

L’accès à l’interface rend possible la modification des serveurs de noms et donc potentiellement une attaque simple sur les machines du réseau. L’authentification du client doit donc être effectuée de manière sure. Depuis que l’accès à distance est possible, la sévérité de cette tâche devrait être augmentée.

Si les contraintes pour mette en place un mécanisme de connexion sécurisée sur la box sont trop importantes, je pense qu’il est envisageable de mettre en place un reverse proxy https accessible depuis l’interface de gestion du site de free.

https://addons.mozilla.org/en-US/firefox/addon/enigform/ peut être une solution d’authentification ...

+1

Sinon pour éviter l’avertissement provoqué par l’utilisation d’un certificat auto-signé, il faudrait laisser le choix de l’utilisation du https en l’informant qu’il va rencontrer ce genre de message d’avertissement la 1ère fois.

Hello tout le monde !
J’ai un peu réfléchi et j’ai une autre solution potentielle a proposer..
Vous connaissez surement StartSSL (www.startssl.com), une des seules autorités de certification a proposer des certificats S/MIME et WEB/SSL de classe1 gratuitement (29 dollars de frais pour une révocation et pas de wildcards en classe1).
Cela fonctionnerai très bien puisque tout le monde ayant une Freebox révolution en degroupage total a une IP fixe.
Il serait peut être possible a Free de nous laisser uploader sur la Freebox notre certificat et notre clé via l’interface locale et qu’un script se lance automatiquement pour les installer ? Problème résolu !
L’autre solution serait aussi que free devienne elle même une autorité de certification et nous fournisse directement les certificats Apres les personnes ayant une IP dynamique : =S pour eux ...
Je ne sait pas... Qu’en pensez vous ?
Benjamin.

On s’en fout que le certificat soit signé par une autorité reconnu, le plus important c’est que les données soient cryptées.

... d’un coté c’est vrai que tu as raison... de l’autre coté, a long terme, ce serait préférable car les gens qui n’y connaissent rien pourraient tres bien accepter des certificats auto-signé par n’importe-qui... Tu peux très bien faire des attaques type Man-In-The-Middle ce qui est plus difficile a faire faire au gens quand ton certificat est signé par une autorité reconnue non ?

Tu as raison sur le long terme. Mais il est préférable d’avoir une connexion sécurisée avec un certificat auto signé par free qu’une connexion en clair avec le login/password qui passe en clair sur toute la chaine du réseau entre ton navigateur et ta freebox.

Une solution simple pour éviter d’avoir a accepter les certifs auto-signes a chaque fois serait d’ajouter free dans la liste des Autorités de confiance. De plus en cas d’attaque on aurait une alerte car le certificat serait erroné par rapport a celui fourni par free.

Mais SVP Free donnez nous une connexion https a la place de la connexion en claire.

+1 - n’importe quel certificat autosigné ou reconnu sera une bonne avancée pour un problème important !

+1 C’est vraiment indispensable

+1 inacceptable. la freebox se veut le hub de la maison mais il ne le sera jamais sans être blindée vers extérieur. HTTPS ou FTPS avec un certificat CA Free ADSL sont nécessaires.

+1.

C’est une évidence technologique qui aurait du être implémentée dès le début.

+1
https pour un accès distant, ca serait quand meme mieux...

+1 ;)

Ici, nous implorons tous, depuis de nombreux mois, nos développeurs vénérés de FREE,
pour leur demander de bien vouloir implémenter l’accès sécurisé authentifié “HTTPS” afin que, nous, FREENAUTES, nous puissions administrer nos FREEBOX,
à distance, et ce, de manière sécurisée.

MERCI d’avance

de toute façon, l’accès extérieur ne marche qu’un coup sur deux...
il serait bien de dépoussiérer le serveur web de cette box, ou de proposer la même interface mais depuis le site free.fr dans mon compte, au moins avec ça, on serait enfin en mesure d’en tirer quelque chose.

je rappelle que l’interface de gestion du site free.fr est naze, ça requiert un reboot du serveur alors que l’on y accede depuis n’importe ou, quel est l’intérêt d’un tel fonctionnement ? si on est obligé d’etre en local, il y a l’interface de gestion de la box qui est bien mieux pour ça, en supposant que n’importe quel Man In The Middle ne puisse capter le mot de passe !

Petite news:
Maxim Bizon (responsable développement freebox) m’a répondu que le HTTPS arrivera très bientôt. Dans le prochain firmware surement !!

Cool

Vivement le prochain firmware alors.

Je viens d 'avoir une autre idée. Il faudrait créer (ou utiliser s'il en existe déjà) un VPN entre les infrastructures de free et nos freebox. Cela permettrait d'accéder à l'interface d'administration de nos freebox server (http://mafreebox.freebox.fr/login.php) depuis l'interface abonnés (https://subscribe.free.fr/login/) qui dispose déjà de son certificat SSL (https). Avec cette solution, on a plus besoin d'accéder directement à nos propres freebox server. On passerait plutôt par le serveur web sécurisé de free pour rebondir sur nos freebox server. Il n'y a donc pas besoin de multiplier les certificats à installer sur toutes les freebox servers ! En y réfléchissant, c'est plus ou moins ce qui doit déjà être en place pour la programmation des enregistrements à distance. L'interface web agit directement sur notre freebox (via VPN ?).

Nouveau firmware, toujours pas de ssl... Il m'a fallu 5min pour encrypter en ssl l'accès à la partie site web de mon nas avec lighttpd, je refuse de croire que ce soit si compliqué à faire sur la freebox. Je ne pense pas que le certificat non reconnu pose de problème, seuls les utilisateurs avancés accèdent à l'administration à distance de toutes façons. L'idée du VPN est peut-être à creuser, mais quitte à passer par là, il est peut-être plus simple d'en faire tourner un chez soi, sur la box ou ailleurs, et de s'y connecter pour accéder à la box "localement".

Si ajout (indispensable et irréel qu'il ne soit pas toujours dispo) du HTTPS, le fait de pouvoir fournir son propre certificat serait pas mal.

On attend toujours le SSL avec impatience. Merci.

Toujours pas de HTTPS malgré la mise à jour récente. Vu les nouvelles capacités de la partie NAS il me semble que c'est plus que nécessaire. Vite Free

J'y ai cru, vouloir faire de la Freebox un NAS impliquait obligatoirement un accès sécurisé, mais apparemment non. Encore si on avait accès à un shell pour le faire nous-même. Bien, ne pas utiliser les nouvelles fonctions à distance, check.

Pour moi, le premier problème de mettre en place un HTTPS est la validation du certificat et je comprends que cela puisse bloquer Free car un utilisateur noobs va cocher "connexion securisée" et ensuite se fera jeter par son browser comme quoi le certificat n'est pas signé. Ce qui n'est pas un prob pour un power user qui a possède un certificat valide avec un reverse DNS correcte.

Il n'empêche que la fonctionnalité est simple à mettre en place, et pourrait être désactivée par défaut. Je comprends parfaitement qu'il ne soit pas possible pour Free de demander un certificat authentique pour chacun de ses abonnés. Seulement cela ne devrait pas léser ceux qui en possèdent un (même self-signed comme c'est mon cas) et ont conscience que balancer leur mot de passe en non crypté est une invitation à tous les hackers de la planète. L'utilisateur noob n'ira pas forcémment activer le ssl, et s'il l'active, il est toujours possible de le prévenir que le certificat généré est self-signed et que s'il n'en fournit pas un qui soit autenthique son browser va se plaindre.

" Je comprends parfaitement qu'il ne soit pas possible pour Free de demander un certificat authentique pour chacun de ses abonnés. " Pourquoi "chacun de ses abonnés"? Il suffit d'un seul certificat TLS! Il n'y a qu'un seul FQDN!!! " il est toujours possible de le prévenir que le certificat généré est self-signed " C'est vraiment la solution de dernier recours : - si le certificat est invérifiable, la connexion TLS ne protège PAS contre l'attaque MITM; - il ne faut PAS habituer les utilisateurs à accepter des certificats invérifiables sur le Web.

Je ne suis pas encore un guru des certificats, quel est donc cet unique FQDN, mafreebox.freebox.fr? Corrigez moi si je me trompe, mais celà ne marcherait qu'en LAN, le but recherché est d'accéder à la box à distance par l'IP publique. De plus, s'il on veut un certificat qui fonctionne aussi bien sous Linux et Windoze, en LAN et à distance, il est nécessaire de jouer avec les SAN (Subject Alternative Name) et mettre l'IP locale et publique en type DNS et en type IP (j'ai du tricher comme ça pour que mon certificat soit reconnu comme valable pour mes 2 IPs sur mes différents OS). Et effectivement, un certificat invérifiable n'est pas mieux que pas de certificat, seulement prévenir l'utilisateur des risques potentiels est loin d'être un encouragement à les ignorer, et encore une fois, ce n'est pas parce que le grand public est imperméable à ce genre de chose que les adeptes doivent s'abaisser à leur niveau. D'aileurs, de toutes les box internet, il me semble que la Freebox Revolution est la plus orientée power user, alors pourquoi trainer les pieds sur une question de sécurité aussi importante?

> quel est donc cet unique FQDN, mafreebox.freebox.fr? OUI > celà ne marcherait qu'en LAN OUI Je pensais qu'on parlait du LAN. > mettre l'IP locale et publique en type DNS et en type IP Une IP dans un certificat? Je pense que ce n'est pas kascher!

> un certificat invérifiable n'est pas mieux que pas de certificat Un certificat auto-signé est vérifiable, il faut juste l'ajouter à la liste de confiance. Il apporte le même niveau de sécurité qu'un certificat signé par une autorité reconnue de base par ton navigateur. > Une IP dans un certificat? C'est possible, http://tools.ietf.org/html/rfc2818#section-3.1 > In some cases, the URI is specified as an IP address rather than a > hostname. In this case, the iPAddress subjectAltName must be present > in the certificate and must exactly match the IP in the URI. Il y a aucun problème technique ou de sécurité, il manque juste la volonté de Free.

> Un certificat auto-signé est vérifiable, il faut juste l'ajouter à la liste de confiance. > Il apporte le même niveau de sécurité qu'un certificat signé par une autorité reconnue de base par ton navigateur. Je rappelle qu'ici on cherche des excuses à Free pour ne pas mettre du HTTPS:// et la raison la plus crédible est celle du certificat et des problèmes que cela peut poser pour un noob. Et un noob ne saura pas installer un nouveau certificat d'autorité de certification.

> C'est possible, http://tools.ietf.org/html/rfc2818#section-3.1 Oui, c'est prévu dans la syntaxe mais ça ne veut pas dire que c'est kascher : D'après Jean-Marc Desperrier : https://bugzilla.mozilla.org/show_bug.cgi?id=553754#c3 <<< RFC 2818 is purely informational. The current SSL CA policy of Mozilla does not describe how to secure a IP address. Being able to match a IP address is a hack, and there's no good reason to keep that hack working. >>> Voir Mozilla CA Certificate Inclusion Policy (Version 2.1) : http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html <<< This is the official Mozilla policy for Certification Authorities applying for inclusion of their CA Certificates to be distributed in Mozilla products: (...) 7. We consider verification of certificate signing requests to be acceptable if it meets or exceeds the following requirements: (...) for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf; >>> Bon, tu pourrais dire que puisque ça ne parle pas d'adresses IP alors rien n'est interdit, moi je dirais que rien n'est prévu donc que rien de tel n'est autorisé par Mozilla.

OlivierL: Perso, je ne suis pas là pour chercher des excuses pour Free, je suis là pour leur faire entendre raison, c'est bien le but de tout bug/feature request. Et je pense qu'il est temps d'arrêter de tout ramener au noob, si personne ne savait utiliser internet, est-ce qu'il serait normal que les personnes qui savent le faire s'en passent? Si qqn ne sait pas utiliser une fonctionnalité, il n'y touche pas, ou alors on lui donne la main, mais qu'on ne laisse pas moisir à l'âge de pierre les gens qualifiés. Les noobs sont un faux problème. Autre example, vos PC ont tous un bios, ou maintenant un boot EFI qui, entre les mauvaises mains, pourrait faire griller le CPU en moins de 2, les constructeurs l'omettent-ils pour autant? Non monsieur. Ils sont déclinés (en tout cas chez Asus) en version basique, et version avancée, ainsi tout le monde y gagne, et je peux overclocker mon CPU comme bon me semble. corrector: S'il fallait que tout le monde voulant encrypter sa connexion achète un nom de domaine, on n'aurait pas fini. J'accède à mon NAS uniquement par adresse IP, aussi bien en local qu'à distance (et nous avons la chance d'avoir une IP publique fixe, pas besoin de DynDNS). Il est nécessaire d'utiliser l'IP dans le certificat, ajouter plusieurs SAN, DNS et IP, est la seule solution que j'ai pu trouver pour que ça fonctionne sous les 2 OS. Pour une raison que j'ignore, Linux reconnaît uniquement les SAN IP, et Win les SAN DNS (ou inversement). Si Free se décide enfin à franchir le pas, ils seront confrontés au même problème s'ils génèrent un certificat self-signed à l'activation de l'encryption, et en voici la solution (Free connaît l'IP publique de ses abonnés, et localement mafreebox.freebox.fr, ou 192.168.0.254 ne change pour personne). Et si la personne a souscrit à un nom de domaine, demander un certificat tout fait à une autorité est très simple, reste ensuite à l'uploader sur la box via l'interface. A titre de référence, voir ici pour qqc de très bien fait et d'on ne peut plus simple: http://www.synology.fr/products/dsm_livedemo.php Control Panel -> DSM Settings -> Certificate -> Create Certificate ou Import Certificate Ensuite Export Certificate pour l'importer dans le keyring de votre OS favori, 5min maximum.

Sinon il faudrait un frontal (un seul certificat à acheter et gérer pour free) qui serait le point d'entrée unique pour accéder à toutes les freebox en fonction de l'identifiant. Voir mon commentaire du jeudi 27 décembre, 2012 à 11:48:44

Le plus utile serait de passer par la rubrique mon compte de free.fr, car l’accès est sécurisé. et ensuite, dans la catégorie ma freebox qui permet de faire des paramétrages divers (mais qui ne sont pas pris en compte sans reboot du freebox server; qui ne sont pas non plus avec les mêmes valeurs que celles du freebox serveur... allez savoir pourquoi...) Bref, il s'agirait d'insérer l'accès au freebox OS à partir de là. Bien sur, cela sécuriserait uniquement la connexion vers free.fr, il faudrait que le site free.fr puisse accéder à son tour au freebox serveur de manière sécurisé (mais je me doute qu'il y à déjà ce genre d'accès... l'assistance utilise probablement ce moyen pour contrôler l'état de la freebox à distance.....) ensuite, rien n’empêche d'avoir un pc avec un serveur https installé sur le réseau, qui redirige sur mafreebox.free.fr. Il suffit juste de configurer une redirection de port https (443) vers ce seveur, ce que je fait déja avec mon Raspberry pi !

djack42: Je fais déjà ça avec lighttpd pour mon client transmission sur mon NAS dont l'interface web ne supporte pas l'encryption. Ca marche plutôt bien, mais ça reste un workaround. Je vais faire ça en attendant, je ne sais pas pourquoi je n'y ai pas pensé plus tôt. Thx.

Si tu as un Syno, tu peux aussi activer le VPN et te connecter en VPN pour accéder à l'interface de gestion.

Oui, j'ai pensé à faire ça pendant un moment, seulement je préfère me connecter à l'interface en tapant mon IP publique plutôt que d'ouvrir une connexion VPN à chaque fois. D'autant plus que mon up n'est pas terrible, surfer deviendrait vraiment pénible :(

> me connecter à l'interface en tapant mon IP publique Pas de reverse DNS sur domaine perso ? C'est balot

Non, je n'ai juste pas de domaine perso :P Je n'en ai pas encore éprouvé le besoin.

@ OlivierL > Pas de reverse DNS sur domaine perso ? Quel intérêt? Quel rapport?

> corrector: S'il fallait que tout le monde voulant encrypter sa connexion achète un nom de domaine, on n'aurait pas fini. Je n'ai jamais parlé d'acheter son nom de domaine! > Et si la personne a souscrit à un nom de domaine, demander un certificat tout fait à une autorité est très simple, reste ensuite à l'uploader sur la box via l'interface. D'accord avec ça.

On a vu que le statut d'un certificat SSH délivré sur une IP est ... flou. Donc il faut un nom de domaine. Le plus evident est d'utiliser ceux fournis par reverse par Proxad ... mais ils sont encore plus compliqués à retenir qu'une IP.

> certificat SSH lire "certificat SSL/TLS" bien sûr! > Le plus evident est d'utiliser ceux fournis par reverse par Proxad . Oui > mais ils sont encore plus compliqués à retenir qu'une IP. Oui, beurk :( Sinon, il y a aussi les DNS personnalisés proposés par Free (xxx.hd.free.fr) : Free pourrait distribuer le certificat correspondant (en *.hd.free.fr). Bien sûr, un certificat générique, c'est pas magnifique niveau sécurité (puisque la clef privée sera commune à toutes les box), mais bon, c'est mille fois mieux qu'un certificat invérifiable. Ou alors, il faut que Free soit une autorité intermédiaire (subordinate CA), avec contrainte sur le domaine. voir rfc 5280 : 4.2.1.10. Name Constraints http://tools.ietf.org/html/rfc5280#section-4.2.1.10 Pratique encouragée par : Mozilla CA Certificate Inclusion Policy (Version 2.1) http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html <<< 9. We encourage CAs to technically constrain all subordinate CA certificates. For a certificate to be considered technically constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying all extended key usages that the subordinate CA is authorized to issue certificates for. (...) For each dNSName in permittedSubtrees, the issuing CA MUST confirm that the subordinate CA has registered the dNSName or has been authorized by the domain registrant to act on the registrant's behalf. Each dNSName in permittedSubtrees must be a registered domain (with zero or more subdomains) according to the Public Suffix List algorithm. >>>

corrector: Oh, je ne sa

Hmm, appuyer sur tab+espace sans le faire exprès peut avoir des effets non désirés... corrector: Merci pour l'info! Je ne savais pas qu'on avait droit à un nom de domaine personnalisé, je viens de créer le mien. Il est temps de me refaire un certificat :) Pour info, j'ai pu rediriger la connexion à l'interface de gestion avec encryptage de la même façon que pour transmission, avec lighttpd, ça fonctionne parfaitement. Ca reste tout de même un workaround, une solution native est toujours la bienvenue, d'autant plus que l'app Android ne permet pas de customiser la connexion à la freebox et passe toujours par un canal non crypté.

Depuis le passage en v2 de l'OS du boîtier server, il est possible de faire passer l'interface d'administration par un reverse proxy HTTPS (hébergé en esterne, sur un raspberry pi par exemple). C'est déjà une grande avancée. Deux possibilités sont: * Génération d'un certificat autosigné avec l'IP publique, l'IPv6 du serveur externe et le reverse DNS actif. Cette solution est la plus simple pour l'utilisateur non averti, mais affichera un avertissement moche sur le navigateur. * Importation d'un certificat préalablement généré par l'utilisateur (éventuellement auprès d'une autorité comme StartSSL qui propose des Class 1 gratuitement). Cette solution est moins accessible, mais donne à l'utilisateur un meilleur contrôle. Pour ma part, l'utilisation du reverse proxy TLS est (et restera) ma solution, dans la mesure où j'effectue l'authentification externe avec des certificats client.

Attention, pour avoir un certificat gratuit via StartSSL il faut d'abord enregistrer un nom de domaine, ce qui n'est pas gratuit. Par ailleurs je ne vois pas bien ce que le reverse vient faire dans cette histoire.

> Attention, pour avoir un certificat gratuit via StartSSL il faut d'abord enregistrer un nom de domaine, ce qui n'est pas gratuit. C'est pour cela qu'il faut proposer le certificat autosigné :-) > Par ailleurs je ne vois pas bien ce que le reverse vient faire dans cette histoire. Le FQDN de ta box est personnalisable chez free (soit il est fourni par free et il termine par .hd.free.fr, soit tu as ton propre domaine et free te propose de personnaliser le PTR, ce qui est pratique quand tu as un serveur mail). Tu vas probablement utiliser ce FQDN pour te connecter sur ta box, dans la mesure où c'est plus simple à retenir qu'une addresse IPv4 (ou v6). Si la box ne connait pas son FQDN, qui est à priori le cas vu que le PTR peut être personnalisé pour un domaine externe, le plus simple pour elle est d'interroger son PTR.

Ok , si on ne peut pas mettre de certificat , pourquoi ne pas passez par une double authentification genre GoogleAuth... ca mettrait un peut plus de sécurité... oups non pas Google ;-) , j'avais oublier ( Free doesn't love Goo)

> oups non pas Google ;-) , j'avais oublier ( Free doesn't love Goo) Ah bon? Alors pourquoi mettre Google Analytics sur la console mafreebox?

cela n'est plus depuis le 2.0.1

MacMorning du matin :) Allez hop on s'intercalle et interception du traffic de la borne macdal... et paf en écoute du traffic 9 couples login/pass de freebox reuperés en Une heure !! et c'est pas un gros macdal parisien blindé des le matin. Alors ? toujours pas de chiffrement ? Bon sang mais DESACTIVEZ CETTE PUTAIN D'OPTION D'ACCES DISTANT TANT QUE C'EST PAS SECURISE !!!!!!!

+1 qui désespère de pouvoir un jour ne serait-ce que naviguer sur des sites "intranet" auto-signés : le navigateur du freeplayer dit "SSL handshake erreur".... pouvoir mémoriser un certificat SSL pour tout le réseau local au niveau de l'ensemble des boitiers Freebox serait sympa, qu'il soit auto-signé, gracieusement offert par Free ou autre. @Kirimandarine : tout à fait d'accord ! ARRÊTEZ LE CARNAGE open bar des trames de connexion en accès distant !!!

Je rejoins la plupart des commentaires, l'accès distant et les liens sans HTTPS c'est pas une solution. Un certificat auto-signé par défaut et la possibilité d'uploader un certificat tiers semble raisonnable comme solution et déjà largement utilisée, je ne comprend pas pourquoi permettre un truc sympa tel que les liens externes si on doit ouvrir la porte à tout le monde... On va tarder à voir des programmes dédié à la récupération des identifiants pour aspirer tout contenu de la box, en effet une fois le password récupérer rien n'empêche l'attaquant à se partager lui même ce qu'il a besoin

un petit serveur openvpn sur la freebox permettrait de sécuriser l'accès distant. et pourquoi pas un client openvpn spécial fonction torrent plutôt qu'une blocklist aléatoire ;)

Avec une page spéciale pour l'installation des certificats le certificat Racine en particulier.

C'est vrai que le message fait "un peu" peur ;) Pourquoi ne pas proposer un portail comme https://subscribe.free.fr/login/

Merci Maxime de confirmer que effectivement la signature du certificat est à l'origine du délai de cette fonctionnalité. En version 0.1, ne pourriez-vous pas fournir la fonctionnalité mais activable seulement si l'utilisateur fourni son propre certificat ? Pas de certificat, pas de chocolat. Et si l'utilisateur fait l'effort de chercher ce qu'est un certificat, alors il comprendra les problèmatiques de signature.

Arrêtez de parler dans le vide, je pense que le message est passé... Il ne reste plus qu'à attendre que l'équipe de free trouve une solution pour le grand public, on leur fait confiance. Troll : et puis si free met toutes les fonctionnalités demandés en v6, alors il n'y aura pas grand chose de révolutionnaire en v7...

Cool merci pour ces infos Maxime !

Il FAUT que Free propose un système qui propose le HTTPS de façon UTILISABLE à ceux qui n'ont pas un domaine et un certificat correspondant! Il reste donc la solution d'un UNIQUE certificat valable pour - *.fbx.proxad.net - mafreebox.freebox.fr - *.hd.free.fr (oui, toutes les Freebox ont donc la même clef, c'est pas glop mais les alternatives sont pires) Et vive le DNS tout ça. C'est clairement LE bon endroit pour ancrer la confiance (la confiance ici se limite à la confiance en un nom DNS). Remarque : je n'ai pas spécialement confiance en Proxad/Free et je ne voudrais pas vous mettre en CA (no offense).

> trop facile de se le faire voler. Vous laissez entendre que ce qui se trouve sur la Freebox n'est pas solidement protégé! Espérons que té èf hein ne lise pas ça.

> proposez des solutions constructives ou allez troller ailleurs svp C'est ce que j'ai fait. Calmez-vous. Vous n'êtes pas propriétaire de ce forum.

Pourquoi on n'arriverai pas a reproduire ce fonctionnement: http://free.korben.info/index.php/Auto-signer_son_certificat_SSL pour la Freebox ? il suffirait que la box crée sont propre certificat basé sur son ip publique

Oui je suis d'accord , et il suffit de se laisser guider pour mettre une exception. c'est déjà plus secure que la solution actuelle

> ceci n'est *PAS* un forum, vos interventions inutiles cachent les commentaires importants. Cette seule remarque démontre que c'en est un. Merci d'arrêter ces inepties "ceci n'est pas un forum". > ce site est géré en collaboration avec la communauté freeplayer.org, et si vous continuez vous serez banni. Merci de vous calmez.

> dans le 2eme cas, entre le challenge que nous avons aujourd'hui, ou accepter un certificat au hasard, pas de différence. Au contraire, il y a une différence : l'attaque ne peut avoir lieu qu'à la première connexion. C'est le modèle utilisé par ssh : en pratique, presque personne ne vérifie le fingerprint la première fois. La sécurité PRATIQUE obtenue ainsi est considérée comme "décente" (pas idéale, mais 1000 mieux que rien).

>Notez que depuis la 2.0, le mot de passe ne passe plus en clair pendant le procédure de login, il y a un challenge en JS. Ca n'empêche pas les attaques MITM mais un simple sniffer ne suffit plus. Du coup quel différence si le mot de passe ne pas plus en clair par rapport à une connexion sécurisée https?

Je rejoins l'avis de corrector, la grosse différence c'est qu'une fois le certficat accepté on est secure. Et dans la plus grande majorité des cas, l'accès pour activer un partage ou même l'accès à distance sera fait via le laptop qui servira pour l'accès distant et donc le certificat aura été "validé" Personnellement pas de HTTPS = pas d'acces distant pour moi. Comme déjà discuté plus haut, si ça fait peur pour le plus grand nombre il suffit de rendre optionnel l'activation du HTTPS

Optrolight > "Du coup quel différence si le mot de passe ne pas plus en clair par rapport à une connexion sécurisée https?" Tout le reste du trafic, reste lui en clair ;) Alors, ok c'est mieux. enfin disons que c'est moins pire.

Et accessoirement, j'ai deja redigé des doc pour des utilisateurs lambda - - (genre pour ceux qui entrent leurs url directement dans la barre de recherche de google, enfin ce level la quoi) leur permettant d'installer des CA foot sur leurs postes pour ne plus avoir de messages d'erreur. Ba meme eux ils ont reussi, n'etant pas un genie (quoi que ^^) c'est que c'est quand meme possible de faire ca au grand public. Un truc redigé à peu pret proprement avec deux trois captures d'écran et ca roule tout seul. Allez hop au boulot ;) ... pas taper pas taper.

" Du coup quel différence si le mot de passe ne pas plus en clair par rapport à une connexion sécurisée https? " Le principal risque a été expliqué par Maxime Bizon : " Notez que depuis la 2.0, le mot de passe ne passe plus en clair pendant le procédure de login, il y a un challenge en JS. Ca n'empêche pas les attaques MITM mais un simple sniffer ne suffit plus. " Retenir cela : ça n'empêche pas les attaques MITM. Tu ne peux pas récupérer le MdP juste avec une écoute réseau, mais une attaque ACTIVE peut le récupérer. En pratique, la sécurité du MdP n'est PAS assurée, mais c'est quand même nettement mieux que le MdP en clair! De plus, avec une écoute du trafic, tu récupères les échanges qui ont permis au serveur de vérifier le MdP, et tu peux toi aussi vérifier si tu crois connaitre le MdP avec ce vérificateur. Explication : En général le protocole ressemble essentiellement à ça : S->C : x C->S : login, hash(MdP + x) S: serveur C: client hash = hachage cryptographique (peut être SHA-1) Le serveur peut vérifier que le client a bien envoyé hash(MdP + x); mais si tu enregistres l'échange, tu peux tester si le mot de passe est "titi" : tu calcules hash("titi" + x) et tu compares à la valeur envoyée. Donc tu peux aussi faire une attaque à dictionnaire contre le mot de passe. Et cela ne concerne que la protection du MdP. Après avoir envoyé le MdP, tu vas faire autre chose; si la session n'est pas protégée, un adversaire peut interférer. C'est la porte ouverte à toutes les fenêtres. Bon, je m'arrête là, parce que comme dit l'aut', c'est pas un forum ici!

Merci pour ces précisions !!! j'y connais pas grand choses mais pourquoi ne pas utiliser une base de certificat interne chez free creer pour chaque V6. Ensuite la freebox va le chercher à chaque loging via le réseau interne en 10.x.x.x?

> une base de certificat interne chez free creer pour chaque V6. Free a actuellement un certificat TLS que tu peux voir sur https://subscribe.free.fr/ Parmi les infos du certificat, on peut lire : CN = *.free.fr OU = Domain Control Validated - (R) C'est le même certificat qui est utilisé sur https://adsls.free.fr Comme l'indique "*" le certificat est valable pour tout sous-domaine de "free.fr" : Free a donc payé UNE SEULE FOIS à la société GeoTrust pour un certificat de la marque "RapidSSL" valable du samedi 27 avril 2013 17:02:22 au mardi 30 juin 2015 15:13:38. > une base de certificat interne chez free creer pour chaque V6 Donc ce que tu proposes, c'est que Free paye pour UN certificat PAR Freeboxé Revolution? Ou bien tu proposes que Free devienne une Autorité de certification, comme GeoTrust l'est? Il faut passer par un processus d'audit pour devenir une autorité approuvée par les censeurs comme Mozilla ou Microsoft. Comme l'a dit "corrector" : > Voir Mozilla CA Certificate Inclusion Policy (Version 2.1) : > > http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Si Free devient une Autorité de certification nommée "Free CA", Free aura un certificat racine "Free Root CA". Si "Free CA" est une Autorité non approuvée par Mozilla et Microsoft, il faudra installer le certificat "Free Root CA" auto-signé dans le client (pour Firefox) ou dans l'OS (pour Windows). L'idéal AMHA serait que Free devienne une Autorité intermédiaire, c'est à dire une Autorité disposant d'une délégation depuis une Autorité racine reconnue, MAIS avec une restriction sur les domaines autorisés : *.free.fr *.proxad.fr *.proxad.net Voir http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html " We encourage CAs to technically constrain all subordinate CA certificates. For a certificate to be considered technically constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying all extended key usages that the subordinate CA is authorized to issue certificates for. " Voir aussi http://tools.ietf.org/html/rfc5280#section-4.2.1.12 If the extension is present, then the certificate MUST only be used for one of the purposes indicated. Voir aussi http://tools.ietf.org/html/rfc5280#section-4.2.1.10 4.2.1.10. Name Constraints The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in subsequent certificates in a certification path MUST be located. Restrictions apply to the subject distinguished name and apply to subject alternative names. (...) Restrictions are defined in terms of permitted or excluded name subtrees. (...) For URIs, the constraint applies to the host part of the name. The constraint MUST be specified as a fully qualified domain name and MAY specify a host or a domain. Examples would be "host.example.com" and ".example.com". When the constraint begins with a period, it MAY be expanded with one or more labels. That is, the constraint ".example.com" is satisfied by both host.example.com and my.host.example.com. Bon, comme dit l'aut', ici ce n'est pas un forum, et en tout cas ce n'est pas un forum sur le concept de certificat et la technologie TLS, donc si tu as d'autres questions, il vaudrait mieux les poser dans un autre forum.

Heu, on peut tres bien mettre une IP en CN hein pas dbesoin de nom de domaine :) pas besoin de nom de domaine, juste quelques lignes de commandes pour se creer soi meme (ou mieux via une GUI liée à l'openssh present sur la box) bref. on attend que le "problème" soit résolu. ps l'importation automatique du CA root peut tres bien se faire à la creation de "l'autosigné" et etre mis à disposition sur le serveur de la box.

cela devrait obligatoire de le proposer par défaut. ca rappelle les premières box wifi sans sécurité (même pas WEP)
98 commentaires , 1 seul vote ???

Comme tous les autres, je refuse d'activer cette option tant qu'on n'aura pas la possibilité de configurer un accès sécurisé (même si elle me serait extrêmement utile et que c'est pour cette fonctionnalité de NAS que j'ai choisi la Revolution).

Sérieusement, ça va faire 3 ans que ce ticket est ouvert et on a toujours pas la possibilité ne serait-ce que de configurer nous même notre propre certificat... Déjà que proposer un accès distant sans cette option est à la base un peu borderline alors là...

Bon ceci dit, d'ici les 3 autres années qui arrivent, un concurrent aura peut-être la bonne idée de faire les choses jusqu'au bout...

a voté !!

+1
Je viens de me rendre compte que j'ai saisi un ticket identique #14625 alors que ce ticket existe depuis longtemps...
Je n'ai pas eu le temps de tout lire. C'est quoi le problème en gros pour que l'accès sécurisé ne soit toujours pas sorti des cartons?

Je comprend pas la difficulté d'implémentation alors que OpenVPN a été ajouté.
Il est basé sur SSL aussi il me semble.

D'ailleurs globalement, le HTTPS pour la console de gestion garde son utilité pour l'application mobile qui au passage peut se connecter tous le temps même si l'accès distant est désactivé.
Avoir un certificat auto-généré au premier boot de la box sur le firmware, ça sera pas pire que tous les serveurs qui avait un OpenSSL "troué" depuis 2 ans.

+1000

++++

+1

Grâce au VPN, on peut maintenant contourner ce faible niveau de sécurité qu'offre l’authentification en http : il suffit de se connecter via VPN sur son freebox server, puis on se connecte à freebox OS via http://mafreebox.freebox.fr/ et le tour est joué en toute sécurité !
MERCI FREE !

Ca doit etre facile d'implémenter HTTPS surtout qu'on ne sait pas toujours qui renifle ces informations dont le mot de passe qui n'est pas chiffré.
Bon pour le moment une connexion au VPN bridgé permet de contourner ce problème .
Merci à FREE
PRIORITE : ELEVEE

+1 pour https, on n'est jamais trop sécurisé !

+1

Surtout quand on connaît la puissance des outils de pénétration réseau. Affligeant que la v6 ne soit pas administrable en https.

Avec peut etre la future implémentation de la domotique sur les box, ne pensez vous pas quand même que cet évolution devrait etre la priorité numéro 1 ?

Bonjour,

Est-ce que l'initiative Let's encrypt (https://letsencrypt.org/) pourrait aider à implémenter le https sur la Freebox ?
Ce système permet d'obtenir un certificat SSL valide et gratuit avec un simple client en ligne de commande.
Ce service sera en beta public au 3 décembre.

Avec une petite UI pour choisir le dns (sur un sous-domaine de free.fr par défaut pour les non-initiés), il suffirait d'utiliser ce client en ligne de commande pour générer le certificat pour le serveur http de la freebox.
Le client est même capable d'auto-configurer un serveur Apache/Nginx.

+1

Il existe un doublon FS#16559.

+1 s'il vous plaît, https everywhere !