Auteur Sujet: Bouygues passe l'interface d'admin de sa Bbox en https. Vous avez testé ? (Lu 40278 fois)

vivien · « **Réponse #12 le:** 29 novembre 2018 à 10:40:02 »

Citation de: kgersen le 29 novembre 2018 à 10:31:40

C'est pas tres clean leur facon de faire. Ca impose d'ajouter une entrée DNS quand on n'utilise pas la bbox comme serveur dns (ce qui va être de plus en plus fréquent avec DNS over TLS par exemple. J'ai 2 appareils sur mon LAN qui ne peuvent accéder a l'interface de la bbox a cause de cela).

L'approche de Free avec une IP public anycast est bien plus clean et universel.

Mais l'IP de mafreebox.fr ne semble pas annoncé sur Internet, donc je pense que si tu n'utilise pas les DNS de la box, cela ne fonctionne pas plus chez Free que chez Bouygues, non ?

Test réalisé avec SFR en 4G :

Code: [Sélectionner]

$ dig mafreebox.fr

; <<>> DiG 9.11.4-3ubuntu5-Ubuntu <<>> mafreebox.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46548
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;mafreebox.fr.			IN	A

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: jeu. nov. 29 10:37:43 CET 2018
;; MSG SIZE  rcvd: 41

Marin · « **Réponse #13 le:** 29 novembre 2018 à 10:43:30 »

En fait, je crois que mafreebox.fr n'est annoncé chez personne (testé depuis une Freebox v6).

Il appartient bien à Iliad, et a résolu dans le passé, en témoigne le DNS passif : https://www.virustotal.com/fr/domain/mafreebox.fr/information/

Mais le domaine qui résout aujourd'hui est mafreebox.freebox.fr, qui est plus répandu de mémoire.

Code: [Sélectionner]

$ host mafreebox.freebox.fr
mafreebox.freebox.fr is an alias for freeplayer.freebox.fr.
freeplayer.freebox.fr has address 212.27.38.253

kgersen · « **Réponse #14 le:** 29 novembre 2018 à 10:53:42 »

Citation de: vivien le 29 novembre 2018 à 10:40:02

Mais l'IP de mafreebox.fr ne semble pas annoncé sur Internet, donc je pense que si tu n'utilise pas les DNS de la box, cela ne fonctionne pas plus chez Free que chez Bouygues, non ?

mafreebox.freebox.fr ca marche de partout:

Code: [Sélectionner]

~$ dig +short mafreebox.freebox.fr @8.8.8.8
freeplayer.freebox.fr.
212.27.38.253

idem avec 1.1.1.1 et n'importe quel serveur dns au monde.

tandis que:

Code: [Sélectionner]

~$ dig +short mabbox.bytel.fr @8.8.8.8

marche que si la bbox est le serveur dns.

J'ai un pixel 2 wifi avec config DNS privé chez Cloudflare -> ne peux pas accéder a la bbox
J'ai un chromebook en wifi avec config dns 8.8.8.8 -> ne peux pas accéder a la bbox

buddy · « **Réponse #15 le:** 29 novembre 2018 à 11:08:43 »

Citation de: Marin le 29 novembre 2018 à 10:43:30

En fait, je crois que mafreebox.fr n'est annoncé chez personne (testé depuis une Freebox v6).

Il appartient bien à Iliad, et a résolu dans le passé, en témoigne le DNS passif : https://www.virustotal.com/fr/domain/mafreebox.fr/information/

Ma-freebox.fr n'appartenait pas à Iliad dans le passé, ils l'ont récupéré il y a quelques semaines . https://x.com/Muzikals/status/1054733313523494918
A mon avis, quand il résolvait vers quelque chose ce n'est pas pour le compte d'iliad mais pour une personne qui avait fait des "outils free" avec ce nom.

Marin · « **Réponse #16 le:** 29 novembre 2018 à 11:13:02 »

Attention, je parlais de mafreebox.fr sans tiret et non de ma-freebox.fr avec tiret.

mafreebox.fr a toujours appartenu à Iliad et été un alias pour mafreebox.freebox.fr aussi loin que je me souvienne. Il a été enregistré en 2006.

ma-freebox.fr a été un site d'aide tiers qui fournissait notamment des reverse DNS aux abonnés, créé en 2011, comme le montre le tweet que tu as mis en lien.

doctorrock · « **Réponse #17 le:** 29 novembre 2018 à 21:36:35 »

Ralala , ces FAIs qui rivalisent d'astuces à la **** pour faire joli

C'est beau de penser à ses clients comme ca

, c'est attentionné je trouve

"Bon alors, 192.168.1.1 c'est moche , my.box.myfai c'est plus joli , voyons voir ..."

vivien · « **Réponse #18 le:** 29 novembre 2018 à 21:50:58 »

Ce n'est pas pour faire joli : le http est en fin de vie et est de plus en plus bloqué.
Le passage en https est nécessaire.

Cf

Citation de: LeNuageux le 29 novembre 2018 à 07:33:05

Bitdefender 2019 bloquait carrèment les requêtes, des lors il y'avais un champ de mot de passe sur un site non sécurisé par HTTPS ! (j'ai eu ce cas la sur la page d'authentification de la Livebox)

doctorrock · « **Réponse #19 le:** 29 novembre 2018 à 21:57:20 »

Ah tu me provoques donc ?

Vraiment, je trouve le mouvement "https everywhere" totalement pas adapté. La preuve : en local, t'en a rien à taper de https, et il y a même plein de cas ou en grand réseau local en entreprise (local je parle), t'en a pas besoin non plus.
Chez moi j'ai plein de services, locaux, sans https parce que j'en ai rien à faire et que ca va plus me consommer du temps et du WTF-time qu'autre chose ... Donc j'aimerai quand même bien encore être capable d'y accéder, sans qu'on me gueule dessus pour autant ...

Donc si les navigateurs pouvaient faire la distinction entre ce qui nécessite d'être sécurisé, et ce qui ne le nécessite pas, ça serait pas mal. Là , on a plus l'impression de la solution de facilité ...
Mais je peux comprendre le mouvement hein, je dis juste que c'est un peu réfléchi à la va-vite facile

jack · « **Réponse #20 le:** 29 novembre 2018 à 22:07:24 »

Citation de: doctorrock le 29 novembre 2018 à 21:57:20

Il y a même plein de cas ou en grand réseau local en entreprise (local je parle), t'en a pas besoin non plus.

Pour citer mon homonyme : monumentale erreur
La sécurité se fait toujours sur les endpoints, jamais sur un équipement au milieu de communication

Il n'y a pas pire qu'un "bon, il est dans le réseau local / le vlan, donc je peux lui faire confiance".

doctorrock · « **Réponse #21 le:** 29 novembre 2018 à 22:13:38 »

Citation de: jack le 29 novembre 2018 à 22:07:24

Pour citer mon homonyme : monumentale erreur
La sécurité se fait toujours sur les endpoints, jamais sur un équipement au milieu de communication

Il n'y a pas pire qu'un "bon, il est dans le réseau local / le vlan, donc je peux lui faire confiance".

Ok, c'est une façon de voir les choses aussi ^^
Je fais plutot le contraire moi , mais ne me tape pas dessus

kgersen · « **Réponse #22 le:** 29 novembre 2018 à 22:14:47 »

Citation de: doctorrock le 29 novembre 2018 à 21:57:20

Ah tu me provoques donc ?

Vraiment, je trouve le mouvement "https everywhere" totalement pas adapté. La preuve : en local, t'en a rien à taper de https, et il y a même plein de cas ou en grand réseau local en entreprise (local je parle), t'en a pas besoin non plus.
Chez moi j'ai plein de services, locaux, sans https parce que j'en ai rien à faire et que ca va plus me consommer du temps et du WTF-time qu'autre chose ... Donc j'aimerai quand même bien encore être capable d'y accéder, sans qu'on me gueule dessus pour autant ...

Donc si les navigateurs pouvaient faire la distinction entre ce qui nécessite d'être sécurisé, et ce qui ne le nécessite pas, ça serait pas mal. Là , on a plus l'impression de la solution de facilité ...
Mais je peux comprendre le mouvement hein, je dis juste que c'est un peu réfléchi à la va-vite facile

Ca ne gueule pas, Chrome par exemple indique juste 'not secure' car c'est le cas meme sur un LAN.

C'est juste un rappel de pas oublier que des infos sensibles circulent en clair sur ce "réseau". Apres si t'es certain a 100% du "réseau", c'est toi qui décide.

Apres l'évolution c'est HTTP/2 qui de toute facon implique du chiffrement (meme si techniquement h2c, le HTTP/2 sans chiffrement, est possible peu de navigateurs le supporteront). Autant s'y préparer.

doctorrock · « **Réponse #23 le:** 29 novembre 2018 à 22:17:11 »

Yes, je parlais des logiciels de protection qui bloquent la page carrèment.
Ca sort le fusil direct, relax un peu