La Fibre
Télécom => Réseau => 
Protocoles réseaux sécurisés (https) => Discussion démarrée par: vivien le 28 novembre 2018 à 16:28:24
-
Bouygues Telecom semble passer l'interface d'administration de sa Bbox en https. Ca serait le premier FAI à faire du https par défaut sur l'interface de sa box.
Pour administrer sa Bbox, il ne faut plus aller sur http://192.168.1.254 , celle ce n’hébergeant plus l'interface, mais un simple renvoi vers https://mabbox.bytel.fr/ la nouvelle url pour administrer la Bbox.
Serait-il possible d'avoir vos retours sur https://mabbox.bytel.fr ? (je n'ai plus de Bbox)
Quel est le certificat utilisé ? TLS 1.2 est utilisé ? TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 est utilisé ? (il suffit de cliquer sur le cadenas situé à gauche de l'URL et de cliquer sur "plus d'information")
Édit:
(https://lafibre.info/images/ssl/201811_mabbox_certificat.png)
-
Ça commence bien : mabbox.bytel.fr ne résout pas (dig mabbox.bytel.fr -> NXDOMAIN)
En trichant, tu trouvera ci-dessous le détail
Ce qu'on peut noter:
- le certificat utilisé provient de globalsign. C'est un bon choix de ne pas utiliser letsencrypt pour ce cas d'usage. On note que la durée de validité du certificat est de deux ans, à voir si la box sera maintenu convenablement à ce niveau.
- la configuration tls est plutôt laxiste: tls 1 est supporté, de même que des ciphers comme 3DES. Certainement, le panel de client supporté est ainsi très large
M'enfin, c'est bien
https://hastebin.milkywan.fr/wuwihedase.js
(Limite de 20000 char atteinte, d'où les liens externes)
testssl https://mabbox.bytel.fr
No engine or GOST support via engine with your /usr/bin/openssl
###########################################################
testssl 2.9.5-4 from https://testssl.sh/
This program is free software. Distribution and
modification under GPLv2 permitted.
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!
Please file bugs @ https://testssl.sh/bugs/
###########################################################
Using "OpenSSL 1.1.1a 20 Nov 2018" [~162 ciphers]
on debian:/usr/bin/openssl
(built: "Nov 22 18:40:54 2018", platform: "debian-amd64")
Start 2018-11-28 23:10:53 -->> 192.168.1.254:443 (mabbox.bytel.fr) <<--
A record via /etc/hosts
rDNS (192.168.1.254): --
Service detected: HTTP
Testing protocols via sockets except SPDY+HTTP2
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 offered
TLS 1.1 offered
TLS 1.2 offered (OK)
SPDY/NPN not offered
HTTP2/ALPN not offered
Testing ~standard cipher categories
NULL ciphers (no encryption) not offered (OK)
Anonymous NULL Ciphers (no authentication) not offered (OK)
Export ciphers (w/o ADH+NULL) not offered (OK)
LOW: 64 Bit + DES encryption (w/o export) not offered (OK)
Weak 128 Bit ciphers (SEED, IDEA, RC[2,4]) offered (NOT ok)
Triple DES Ciphers (Medium) offered
High encryption (AES+Camellia, no AEAD) offered (OK)
Strong encryption (AEAD ciphers) offered (OK)
Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4
PFS is offered (OK) ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA DHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-SHA256 DHE-RSA-AES256-SHA
ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES128-SHA256 DHE-RSA-AES128-SHA
DHE-RSA-SEED-SHA
Elliptic curves offered: prime256v1
Testing server preferences
Has server cipher order? nope (NOT ok)
Negotiated protocol TLSv1.2
Negotiated cipher ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256) (limited sense as client will pick)
Negotiated cipher per proto (limited sense as client will pick)
ECDHE-RSA-AES256-SHA: TLSv1, TLSv1.1
ECDHE-RSA-AES256-GCM-SHA384: TLSv1.2
No further cipher order check has been done as order is determined by the client
Testing server defaults (Server Hello)
TLS extensions (standard) "server name/#0" "renegotiation info/#65281" "EC point formats/#11" "session ticket/#35" "heartbeat/#15"
Session Ticket RFC 5077 hint 300 seconds, session tickets keys seems to be rotated < daily
SSL Session ID support yes
Session Resumption Tickets: yes, ID: yes
TLS clock skew Random values, no fingerprinting possible
Signature Algorithm SHA256 with RSA
Server key size RSA 2048 bits
Fingerprint / Serial SHA1 3E2623B3F7EFF176D3B44F10BD9B7D433BB4334F / 05FED1FE1549919287C6D15201AA8315
SHA256 046C7CBC18D3E57734CF7456FF0EB0D7E72702614F1EE89C11FDCA9101063377
Common Name (CN) mabbox.bytel.fr
subjectAltName (SAN) mabbox.bytel.fr
Issuer DigiCert SHA2 Secure Server CA (DigiCert Inc from US)
Trust (hostname) Ok via SAN and CN (same w/o SNI)
Chain of trust Ok
EV cert (experimental) no
Certificate Expiration 554 >= 60 days (UTC: 2018-06-05 02:00 --> 2020-06-05 14:00)
# of certificates provided 3
Certificate Revocation List http://crl3.digicert.com/ssca-sha2-g6.crl
http://crl4.digicert.com/ssca-sha2-g6.crl
OCSP URI http://ocsp.digicert.com
OCSP stapling --
OCSP must staple no
DNS CAA RR (experimental) --
Certificate Transparency yes (certificate extension)
Testing HTTP header response @ "/"
HTTP Status Code 307 Temporary Redirect, redirecting to "/login.html"
HTTP clock skew +12 sec from localtime
Strict Transport Security --
Public Key Pinning --
Server banner Lighttpd
Application banner --
Cookie(s) (none issued at "/") -- HTTP status 307 signals you maybe missed the web application
Security headers X-Frame-Options SAMEORIGIN
X-XSS-Protection 1
X-Content-Type-Options nosniff
Reverse Proxy banner --
Testing vulnerabilities
Heartbleed (CVE-2014-0160) not vulnerable (OK), timed out
CCS (CVE-2014-0224) not vulnerable (OK)
Ticketbleed (CVE-2016-9244), experiment. not vulnerable (OK)
Secure Renegotiation (CVE-2009-3555) not vulnerable (OK)
Secure Client-Initiated Renegotiation not vulnerable (OK)
CRIME, TLS (CVE-2012-4929) not vulnerable (OK)
BREACH (CVE-2013-3587) no HTTP compression (OK) - only supplied "/" tested
POODLE, SSL (CVE-2014-3566) not vulnerable (OK)
TLS_FALLBACK_SCSV (RFC 7507) No fallback possible, TLS 1.2 is the only protocol (OK)
SWEET32 (CVE-2016-2183, CVE-2016-6329) VULNERABLE, uses 64 bit block ciphers
FREAK (CVE-2015-0204) not vulnerable (OK)
DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable on this host and port (OK)
make sure you don't use this certificate elsewhere with SSLv2 enabled services
https://censys.io/ipv4?q=046C7CBC18D3E57734CF7456FF0EB0D7E72702614F1EE89C11FDCA9101063377 could help you to find out
LOGJAM (CVE-2015-4000), experimental VULNERABLE (NOT ok): common prime RFC5114/1024-bit DSA group with 160-bit prime order subgroup detected (1024 bits),
but no DH EXPORT ciphers
BEAST (CVE-2011-3389) TLS1: ECDHE-RSA-AES256-SHA DHE-RSA-AES256-SHA AES256-SHA ECDHE-RSA-AES128-SHA DHE-RSA-AES128-SHA DHE-RSA-SEED-SHA AES128-SHA SEED-SHA
ECDHE-RSA-DES-CBC3-SHA EDH-RSA-DES-CBC3-SHA DES-CBC3-SHA
VULNERABLE -- but also supports higher protocols (possible mitigation): TLSv1.1 TLSv1.2
LUCKY13 (CVE-2013-0169), experimental potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS
RC4 (CVE-2013-2566, CVE-2015-2808) no RC4 ciphers detected (OK)
Testing 359 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength
Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (RFC)
-----------------------------------------------------------------------------------------------------------------------------
xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 256 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
xc028 ECDHE-RSA-AES256-SHA384 ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
xc014 ECDHE-RSA-AES256-SHA ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
x9f DHE-RSA-AES256-GCM-SHA384 DH 1024 AESGCM 256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
x6b DHE-RSA-AES256-SHA256 DH 1024 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
x39 DHE-RSA-AES256-SHA DH 1024 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA
x9d AES256-GCM-SHA384 RSA AESGCM 256 TLS_RSA_WITH_AES_256_GCM_SHA384
x3d AES256-SHA256 RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA256
x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA
xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 256 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
xc027 ECDHE-RSA-AES128-SHA256 ECDH 256 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
xc013 ECDHE-RSA-AES128-SHA ECDH 256 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
x9e DHE-RSA-AES128-GCM-SHA256 DH 1024 AESGCM 128 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
x67 DHE-RSA-AES128-SHA256 DH 1024 AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
x33 DHE-RSA-AES128-SHA DH 1024 AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
x9a DHE-RSA-SEED-SHA DH 1024 SEED 128 TLS_DHE_RSA_WITH_SEED_CBC_SHA
x9c AES128-GCM-SHA256 RSA AESGCM 128 TLS_RSA_WITH_AES_128_GCM_SHA256
x3c AES128-SHA256 RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA256
x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA
x96 SEED-SHA RSA SEED 128 TLS_RSA_WITH_SEED_CBC_SHA
xc012 ECDHE-RSA-DES-CBC3-SHA ECDH 256 3DES 168 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
x16 EDH-RSA-DES-CBC3-SHA DH 1024 3DES 168 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
x0a DES-CBC3-SHA RSA 3DES 168 TLS_RSA_WITH_3DES_EDE_CBC_SHA
Running client simulations via sockets
Android 2.3.7 TLSv1.0 AES128-SHA
Android 4.1.1 TLSv1.0 ECDHE-RSA-AES256-SHA, 256 bit ECDH (P-256)
Android 4.3 TLSv1.0 ECDHE-RSA-AES256-SHA, 256 bit ECDH (P-256)
Android 4.4.2 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
Android 5.0.0 TLSv1.2 ECDHE-RSA-AES256-SHA, 256 bit ECDH (P-256)
Android 6.0 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Android 7.0 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Chrome 51 Win 7 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Chrome 57 Win 7 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Firefox 49 Win 7 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Firefox 53 Win 7 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
IE 6 XP No connection
IE 7 Vista TLSv1.0 AES128-SHA
IE 8 XP TLSv1.0 DES-CBC3-SHA
IE 8 Win 7 TLSv1.0 AES128-SHA
IE 11 Win 7 TLSv1.2 ECDHE-RSA-AES256-SHA384, 256 bit ECDH (P-256)
IE 11 Win 8.1 TLSv1.2 ECDHE-RSA-AES256-SHA384, 256 bit ECDH (P-256)
IE 11 Win Phone 8.1 Update TLSv1.2 ECDHE-RSA-AES256-SHA384, 256 bit ECDH (P-256)
IE 11 Win 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
Edge 13 Win 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
Edge 13 Win Phone 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
Opera 17 Win 7 TLSv1.2 ECDHE-RSA-AES256-SHA, 256 bit ECDH (P-256)
Safari 5.1.9 OS X 10.6.8 TLSv1.0 ECDHE-RSA-AES128-SHA, 256 bit ECDH (P-256)
Safari 7 iOS 7.1 TLSv1.2 ECDHE-RSA-AES256-SHA384, 256 bit ECDH (P-256)
Safari 9 OS X 10.11 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
Safari 10 OS X 10.12 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
Apple ATS 9 iOS 9 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
Tor 17.0.9 Win 7 TLSv1.0 ECDHE-RSA-AES256-SHA, 256 bit ECDH (P-256)
Java 6u45 TLSv1.0 AES128-SHA
Java 7u25 TLSv1.0 ECDHE-RSA-AES128-SHA, 256 bit ECDH (P-256)
Java 8u31 TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH (P-256)
OpenSSL 1.0.1l TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
OpenSSL 1.0.2e TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
Done 2018-11-28 23:13:34 [ 163s] -->> 192.168.1.254:443 (mabbox.bytel.fr) <<--
-
- le certificat utilisé provient de globalsign. C'est un bon choix de ne pas utiliser letsencrypt pour ce cas d'usage.
C'est surtout impossible tant qu'ils ne laissent pas ce domaine résoudre vers une IP publique de l'extérieur vu que le certbot a besoin de prouver l'authenticité du domaine...
On note d'ailleurs l'utilisation d'un domaine relativement peu conventionnel (bytel.fr) sans doute pour limiter les risques potentiels de sécurité web liés à l'origine du domaine, un peu comme Free utilise mafreebox.fr (eux pour résoudre une adresse publique en 212.x.x.x qui est en fait un loopback au niveau de la box).
M'enfin, c'est bien
C'est surtout nécessaire pour éviter des cauchemars de support par rapport aux gens qui utilisent un navigateur qui leur affiche que leur connexion n'est pas sécurisée quand ils cliquent sur le formulaire de mot de passe... et même un peu tard je pense :)
-
C'est surtout nécessaire pour éviter des cauchemars de support par rapport aux gens qui utilisent un navigateur qui leur affiche que leur connexion n'est pas sécurisée quand ils cliquent sur le formulaire de mot de passe... et même un peu tard je pense :)
Je me souviens d'avoir vu quelque part sur un forum officiel opérateur quelqu'un se plaindre que sur la page de la box y'avait "non sécurisé et qui pensait que tout internet était pas sécurisé du coup...
-
C'est surtout nécessaire pour éviter des cauchemars de support par rapport aux gens qui utilisent un navigateur qui leur affiche que leur connexion n'est pas sécurisée quand ils cliquent sur le formulaire de mot de passe... et même un peu tard je pense :)
Bitdefender 2019 bloquait carrèment les requêtes http, des lors il y avait un champ de mot de passe, sur un site non sécurisé par HTTPS ! (j'ai eu ce cas-là sur la page d'authentification de la Livebox)
-
Oui, je pense que c'est une des raison pour laquelle Bouygues Telecom passe sa box en https.
Apple devrait être aussi plus strict à l'avenir sur les informations rentrées sur un site en http (comme Bitdefender ?)
Le certificat sera probablement maintenu à jour, car son expiration entraînerait un message assez anxiogène pour la configuration de la box, sachant qu'il n'est plus possible d'y accéder en http (redirection systématique vers le site en https)
Par contre pourquoi avoir un certificat de seulement 2 ans ?
Issuer: C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA
Validity
Not Before: Jun 5 00:00:00 2018 GMT
Not After : Jun 5 12:00:00 2020 GMT
Subject: C = FR, L = Paris, O = Bouygues Telecom, CN = mabbox.bytel.fr
Cela ne se fait plus des certificats de 3 ans ?
Vu qu'il faut un nouveau firmware pour le nouveau certificat et que cela demande pas mal de temps entre la validation et le déploiement généralisé, une validité de 3 ans permet d'avoir moins de firmwares à produire pour ce besoin. A moins qu'il soit possible de mettre à jour le certificat via l'ACS sans nouveau firmware...
Voici un exemple de certificat valable 3ans, intégré dans l'applicatif serveur propriétaire de nPerf :
$ openssl s_client -connect fr-bouygues-massy-01-40g.nperf.net:443 </dev/null 2>/dev/null | openssl x509 -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
59:00:25:ee:82:df:27:77:dd:30:e5:b3:ce:e5:1b:0e
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = FR, ST = Paris, L = Paris, O = Gandi, CN = Gandi Standard SSL CA 2
Validity
Not Before: Feb 1 00:00:00 2016 GMT
Not After : Feb 1 23:59:59 2019 GMT
Subject: OU = Domain Control Validated, OU = Gandi Standard Wildcard SSL, CN = *.nperf.net
Il date de début 2016, si cela se trouve, maintenant ce sont des certificats de deux ans qui sont émis.
-
A priori, les certificats sont maintenant fourni pour une durée maximum de 2 ans, depuis le début 2018.
-
Quand tu cherches des infos sur le sujet, tu t'aperçois que le CA/Browser Forum (grand organisme rassemblant les navigateurs et les CA) a décidé que la validité maximale d'un certificat public devait être de 2 ans, ce à compter du 1er mars 2018. Avant j'ai le souvenir de certificats bien plus longs.
https://www.globalsign.com/en/blog/ssl-certificate-validity-capped-at-maximum-two-years/
https://www.ssl.com/blogs/ssl-certificate-maximum-duration-825-days/
Il me paraît évident que le fait que ce certificat soit mis en dur dans le firmware apparaît comme une rustine. Le déploiement de nouveaux certificats via TR-069 apparaît effectivement comme la solution la plus correcte, après, est-ce que l'implèmentation actuelle de Bouygues permet de modifier le système de fichiers, je ne sais pas.
-
C'est surtout impossible tant qu'ils ne laissent pas ce domaine résoudre vers une IP publique de l'extérieur vu que le certbot a besoin de prouver l'authenticité du domaine...
Il n'est absolument pas nécessaire de se connecter depuis internet sur un serveur pour générer un certificat Let's encrypt, cf le challenge DNS par exemple
-
Vrai, TXT est parfois bien utile. Mais je préfère encore CHAOS.
-
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.
-
Ookla génère les certificats Let's Encrypt à distance pour chacun des serveurs de test de débit.
L’applicatif coté serveur de test (non contrôlé par Ookla et lancé sans les droits root - il écoute le port 8080) télécharge ensuite le certificat obtenu depuis un serveur Ookla. Rien n'est stocké en local sur le serveur de test de débit, le certificat est téléchargé à chaque chargement du logiciel serveur ookla et régulièrement ensuite.
-
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 :
$ 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
-
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.
$ host mafreebox.freebox.fr
mafreebox.freebox.fr is an alias for freeplayer.freebox.fr.
freeplayer.freebox.fr has address 212.27.38.253
-
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:
~$ 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:
~$ 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
-
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://twitter.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.
-
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. :)
-
Ralala , ces FAIs qui rivalisent d'astuces à la **** pour faire joli :D
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 ..."
-
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
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)
-
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 :-*
-
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".
-
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 ;D
-
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.
(https://i.imgur.com/F4AWnZI.png?1)
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.
-
Yes, je parlais des logiciels de protection qui bloquent la page carrèment.
Ca sort le fusil direct, relax un peu :D
-
Yes, je parlais des logiciels de protection qui bloquent la page carrèment.
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é ...
Je n'ai pas vu d'ou tu parlais des "logiciels de protection" dans tes messages précédents :)
-
Je n'ai pas vu d'ou tu parlais des "logiciels de protection" dans tes messages précédents :)
J'avais ça en tête à moitié ^^
Et les ptits messages aussi, genre FF dans les champs password sous http. C'est bon, JE SAIS ;D
-
A priori, les certificats sont maintenant fourni pour une durée maximum de 2 ans, depuis le début 2018.
Pour être plus précis, la durée maximale d'un certificat est de 825 jours, depuis le 1er mars 2018, cf https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.1.pdf
825 jours, cela fait 2 ans et 95 jours (2 ans et 94 jours si années bissextiles).
-
SFR ne propose pas de https pour l’accès à sa box ( http://192.168.0.1 ), mais https était bien géré quand on active l’accès à distance, et c'est même la seule solution pour l'accés à distance (pas de http possible) :
Type de box : Sagem LABOXV3B (Box 4k pour réseau câble)
Version logiciel : NCC-PC20_3.445.0
# testssl https://109.13.104.9:4430/
###########################################################
testssl.sh 2.9.5-4 from https://testssl.sh/
This program is free software. Distribution and
modification under GPLv2 permitted.
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!
Please file bugs @ https://testssl.sh/bugs/
###########################################################
Using "OpenSSL 1.0.2-chacha (1.0.2i-dev)" [~183 ciphers]
on vivien1:/snap/testssl/2/bin/openssl.Linux.x86_64
(built: "Jun 22 19:32:29 2016", platform: "linux-x86_64")
Start 2019-07-07 07:40:06 -->> 109.13.104.9:4430 (109.13.104.9) <<--
rDNS (109.13.104.9): 9.104.13.109.rev.sfr.net.
Service detected: HTTP
Testing protocols via sockets except SPDY+HTTP2
SSLv2 not offered (OK)
SSLv3 offered (NOT ok)
TLS 1 offered
TLS 1.1 offered
TLS 1.2 offered (OK)
SPDY/NPN not offered
HTTP2/ALPN not offered
Testing ~standard cipher categories
NULL ciphers (no encryption) not offered (OK)
Anonymous NULL Ciphers (no authentication) not offered (OK)
Export ciphers (w/o ADH+NULL) not offered (OK)
LOW: 64 Bit + DES encryption (w/o export) not offered (OK)
Weak 128 Bit ciphers (SEED, IDEA, RC[2,4]) offered (NOT ok)
Triple DES Ciphers (Medium) offered
High encryption (AES+Camellia, no AEAD) offered (OK)
Strong encryption (AEAD ciphers) offered (OK)
Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4
No ciphers supporting Forward Secrecy offered
Testing server preferences
Has server cipher order? nope (NOT ok)
Negotiated protocol TLSv1.2
Negotiated cipher AES256-GCM-SHA384 (limited sense as client will pick)
Negotiated cipher per proto (limited sense as client will pick)
AES256-SHA: SSLv3, TLSv1, TLSv1.1
AES256-GCM-SHA384: TLSv1.2
No further cipher order check has been done as order is determined by the client
Testing server defaults (Server Hello)
TLS extensions (standard) "renegotiation info/#65281" "heartbeat/#15"
Session Ticket RFC 5077 hint (no lifetime advertised)
SSL Session ID support yes
Session Resumption Tickets no, ID: no
TLS clock skew Random values, no fingerprinting possible
Signature Algorithm SHA1 with RSA -- besides: users will receive a strong browser WARNING
Server key size RSA 1024 bits
Fingerprint / Serial SHA1 F9286CF3A59EF26EC52DD50CEDECD048837FB26F / 2013B8D94D0B2A60
SHA256 4FA54AE65E9B3BE5ED906651B26D4B1D23F7431AAEDD3DC0F3121A0E7143BB1D
Common Name (CN) B8:D9:4D:0B:2A:60
subjectAltName (SAN) missing (NOT ok) -- Browsers are complaining
Issuer Askey Cable Modem Root Certificate Authority (Askey from TW)
Trust (hostname) certificate does not match supplied URI
Chain of trust NOT ok (chain incomplete)
EV cert (experimental) no
Certificate Expiration 4941 >= 60 days (UTC: 2013-01-16 01:00 --> 2033-01-16 00:59)
# of certificates provided 1
Certificate Revocation List NOT ok -- neither CRL nor OCSP URI provided
OCSP URI --
OCSP stapling --
OCSP must staple no
DNS CAA RR (experimental) --
Certificate Transparency no
Testing HTTP header response @ "/"
HTTP Status Code 200 OK
HTTP clock skew Got no HTTP time, maybe try different URL?
Strict Transport Security --
Public Key Pinning --
Server banner (no "Server" line in header, interesting!)
Application banner --
Cookie(s) (none issued at "/")
Security headers --
Reverse Proxy banner --
Testing vulnerabilities
Heartbleed (CVE-2014-0160) not vulnerable (OK), timed out
CCS (CVE-2014-0224) not vulnerable (OK)
Ticketbleed (CVE-2016-9244), experiment. not vulnerable (OK), no session ticket extension
Secure Renegotiation (CVE-2009-3555) not vulnerable (OK)
Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), DoS threat
CRIME, TLS (CVE-2012-4929) not vulnerable (OK)
BREACH (CVE-2013-3587) no HTTP compression (OK) - only supplied "/" tested
POODLE, SSL (CVE-2014-3566) VULNERABLE (NOT ok), uses SSLv3+CBC (check TLS_FALLBACK_SCSV mitigation below)
TLS_FALLBACK_SCSV (RFC 7507) Downgrade attack prevention supported (OK)
SWEET32 (CVE-2016-2183, CVE-2016-6329) VULNERABLE, uses 64 bit block ciphers
FREAK (CVE-2015-0204) not vulnerable (OK)
DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable on this host and port (OK)
make sure you don't use this certificate elsewhere with SSLv2 enabled services
https://censys.io/ipv4?q=4FA54AE65E9B3BE5ED906651B26D4B1D23F7431AAEDD3DC0F3121A0E7143BB1D could help you to find out
LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH EXPORT ciphers, no DH key detected
BEAST (CVE-2011-3389) SSL3: AES256-SHA CAMELLIA256-SHA AES128-SHA SEED-SHA CAMELLIA128-SHA IDEA-CBC-SHA DES-CBC3-SHA
TLS1: AES256-SHA CAMELLIA256-SHA AES128-SHA SEED-SHA CAMELLIA128-SHA IDEA-CBC-SHA DES-CBC3-SHA
VULNERABLE -- but also supports higher protocols (possible mitigation): TLSv1.1 TLSv1.2
LUCKY13 (CVE-2013-0169), experimental potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS
RC4 (CVE-2013-2566, CVE-2015-2808) VULNERABLE (NOT ok): RC4-SHA RC4-MD5
Testing 359 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength
Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (RFC)
-----------------------------------------------------------------------------------------------------------------------------
x9d AES256-GCM-SHA384 RSA AESGCM 256 TLS_RSA_WITH_AES_256_GCM_SHA384
x3d AES256-SHA256 RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA256
x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA
x84 CAMELLIA256-SHA RSA Camellia 256 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
x9c AES128-GCM-SHA256 RSA AESGCM 128 TLS_RSA_WITH_AES_128_GCM_SHA256
x3c AES128-SHA256 RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA256
x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA
x96 SEED-SHA RSA SEED 128 TLS_RSA_WITH_SEED_CBC_SHA
x41 CAMELLIA128-SHA RSA Camellia 128 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
x07 IDEA-CBC-SHA RSA IDEA 128 TLS_RSA_WITH_IDEA_CBC_SHA
x05 RC4-SHA RSA RC4 128 TLS_RSA_WITH_RC4_128_SHA
x04 RC4-MD5 RSA RC4 128 TLS_RSA_WITH_RC4_128_MD5
x0a DES-CBC3-SHA RSA 3DES 168 TLS_RSA_WITH_3DES_EDE_CBC_SHA
Running client simulations via sockets
Android 2.3.7 TLSv1.0 RC4-MD5
Android 4.1.1 TLSv1.0 AES256-SHA
Android 4.3 TLSv1.0 AES256-SHA
Android 4.4.2 TLSv1.2 AES256-GCM-SHA384
Android 5.0.0 TLSv1.2 AES256-SHA
Android 6.0 TLSv1.2 AES128-GCM-SHA256
Android 7.0 TLSv1.2 AES128-GCM-SHA256
Chrome 51 Win 7 TLSv1.2 AES128-GCM-SHA256
Chrome 57 Win 7 TLSv1.2 AES128-GCM-SHA256
Firefox 49 Win 7 TLSv1.2 AES128-SHA
Firefox 53 Win 7 TLSv1.2 AES128-SHA
IE 6 XP SSLv3 RC4-MD5
IE 7 Vista TLSv1.0 AES128-SHA
IE 8 XP TLSv1.0 RC4-MD5
IE 8 Win 7 TLSv1.0 AES128-SHA
IE 11 Win 7 TLSv1.2 AES256-GCM-SHA384
IE 11 Win 8.1 TLSv1.2 AES256-GCM-SHA384
IE 11 Win Phone 8.1 Update TLSv1.2 AES256-GCM-SHA384
IE 11 Win 10 TLSv1.2 AES256-GCM-SHA384
Edge 13 Win 10 TLSv1.2 AES256-GCM-SHA384
Edge 13 Win Phone 10 TLSv1.2 AES256-GCM-SHA384
Opera 17 Win 7 TLSv1.2 AES256-SHA
Safari 5.1.9 OS X 10.6.8 TLSv1.0 AES128-SHA
Safari 7 iOS 7.1 TLSv1.2 AES256-SHA256
Safari 9 OS X 10.11 TLSv1.2 AES256-GCM-SHA384
Safari 10 OS X 10.12 TLSv1.2 AES256-GCM-SHA384
Apple ATS 9 iOS 9 No connection
Tor 17.0.9 Win 7 TLSv1.0 CAMELLIA256-SHA
Java 6u45 TLSv1.0 RC4-MD5
Java 7u25 TLSv1.0 AES128-SHA
Java 8u31 TLSv1.2 AES128-SHA256
OpenSSL 1.0.1l TLSv1.2 AES256-GCM-SHA384
OpenSSL 1.0.2e TLSv1.2 AES256-GCM-SHA384
Done 2019-07-07 07:41:27 [ 83s] -->> 109.13.104.9:4430 (109.13.104.9) <<--
-
J'ai essayé avec une box câble un peu plus ancienne (conception en 2014 par Sagem): https est aussi supporté, mais pas TLS 1.1 / TLS 1.2 : c'est SSLv2 / SSLv3 / TLS 1.0 qui est proposé, sans possibilité de http.
Type de box : Sagem F@st 3284 DC (Box Internet RED Câble)
Version logiciel : NCC-PC20_2.146.0
# testssl https://77.136.113.9:4430/
###########################################################
testssl.sh 2.9.5-4 from https://testssl.sh/
This program is free software. Distribution and
modification under GPLv2 permitted.
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!
Please file bugs @ https://testssl.sh/bugs/
###########################################################
Using "OpenSSL 1.0.2-chacha (1.0.2i-dev)" [~183 ciphers]
on vivien1:/snap/testssl/2/bin/openssl.Linux.x86_64
(built: "Jun 22 19:32:29 2016", platform: "linux-x86_64")
Start 2019-07-07 08:03:04 -->> 77.136.113.9:4430 (77.136.113.9) <<--
rDNS (77.136.113.9): 68.113.136.77.rev.sfr.net.
Service detected: HTTP
Testing protocols via sockets except SPDY+HTTP2
SSLv2 offered (NOT ok), also VULNERABLE to DROWN attack -- 5 ciphers
SSLv3 offered (NOT ok)
TLS 1 offered
TLS 1.1 not offered
TLS 1.2 not offered
SPDY/NPN not offered
HTTP2/ALPN not offered
Testing ~standard cipher categories
NULL ciphers (no encryption) not offered (OK)
Anonymous NULL Ciphers (no authentication) not offered (OK)
Export ciphers (w/o ADH+NULL) offered (NOT ok)
LOW: 64 Bit + DES encryption (w/o export) offered (NOT ok)
Weak 128 Bit ciphers (SEED, IDEA, RC[2,4]) offered (NOT ok)
Triple DES Ciphers (Medium) offered
High encryption (AES+Camellia, no AEAD) offered (OK)
Strong encryption (AEAD ciphers) not offered
Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4
No ciphers supporting Forward Secrecy offered
Testing server preferences
Has server cipher order? nope (NOT ok)
Negotiated protocol TLSv1
Negotiated cipher AES256-SHA (limited sense as client will pick)
Negotiated cipher per proto (limited sense as client will pick)
RC4-MD5: SSLv2
AES256-SHA: SSLv3, TLSv1
No further cipher order check has been done as order is determined by the client
Testing server defaults (Server Hello)
TLS extensions (standard) (none)
Session Ticket RFC 5077 hint (no lifetime advertised)
SSL Session ID support yes
Session Resumption Tickets no, ID: no
TLS clock skew +7199 sec from localtime
Signature Algorithm SHA1 with RSA -- besides: users will receive a strong browser WARNING
Server key size RSA 1024 bits
Fingerprint / Serial SHA1 222D926A70954A93CF8388EC205E4F39D9124593 / 20130037B75042A8
SHA256 03ADF19B8C26B5CC3BBE12A98C3C25706385ADEB6F53E3113018AD71A9A93C04
Common Name (CN) 00:37:B7:50:42:A8
subjectAltName (SAN) missing (NOT ok) -- Browsers are complaining
Issuer Askey Cable Modem Root Certificate Authority (Askey from TW)
Trust (hostname) certificate does not match supplied URI
Chain of trust NOT ok (chain incomplete)
EV cert (experimental) no
Certificate Expiration 4941 >= 60 days (UTC: 2013-01-16 01:00 --> 2033-01-16 00:59)
# of certificates provided 1
Certificate Revocation List NOT ok -- neither CRL nor OCSP URI provided
OCSP URI --
OCSP stapling --
OCSP must staple no
DNS CAA RR (experimental) --
Certificate Transparency no
Testing HTTP header response @ "/"
HTTP Status Code 200 OK
HTTP clock skew Got no HTTP time, maybe try different URL?
Strict Transport Security --
Public Key Pinning --
Server banner (no "Server" line in header, interesting!)
Application banner --
Cookie(s) (none issued at "/")
Security headers --
Reverse Proxy banner --
Testing vulnerabilities
Heartbleed (CVE-2014-0160) not vulnerable (OK), no heartbeat extension
CCS (CVE-2014-0224) VULNERABLE (NOT ok)
Ticketbleed (CVE-2016-9244), experiment. not vulnerable (OK), no session ticket extension
Secure Renegotiation (CVE-2009-3555) VULNERABLE (NOT ok)
Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), DoS threat
CRIME, TLS (CVE-2012-4929) not vulnerable (OK)
BREACH (CVE-2013-3587) no HTTP compression (OK) - only supplied "/" tested
POODLE, SSL (CVE-2014-3566) VULNERABLE (NOT ok), uses SSLv3+CBC (check TLS_FALLBACK_SCSV mitigation below)
TLS_FALLBACK_SCSV (RFC 7507) Downgrade attack prevention NOT supported and vulnerable to POODLE SSL
SWEET32 (CVE-2016-2183, CVE-2016-6329) VULNERABLE, uses 64 bit block ciphers
FREAK (CVE-2015-0204) VULNERABLE (NOT ok), uses EXPORT RSA ciphers
DROWN (CVE-2016-0800, CVE-2016-0703) VULNERABLE (NOT ok), SSLv2 offered with 5 ciphers
Make sure you don't use this certificate elsewhere, see:
https://censys.io/ipv4?q=03ADF19B8C26B5CC3BBE12A98C3C25706385ADEB6F53E3113018AD71A9A93C04
LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH EXPORT ciphers, no DH key detected
BEAST (CVE-2011-3389) SSL3: AES256-SHA AES128-SHA DES-CBC3-SHA EXP1024-DES-CBC-SHA DES-CBC-SHA
TLS1: AES256-SHA AES128-SHA DES-CBC3-SHA EXP1024-DES-CBC-SHA DES-CBC-SHA
VULNERABLE -- and no higher protocols as mitigation supported
LUCKY13 (CVE-2013-0169), experimental potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS
RC4 (CVE-2013-2566, CVE-2015-2808) VULNERABLE (NOT ok): RC4-SHA RC4-MD5 RC4-MD5 RC4-64-MD5 EXP1024-RC4-SHA EXP1024-RC4-MD5 EXP-RC4-MD5
Testing 359 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength
Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (RFC)
-----------------------------------------------------------------------------------------------------------------------------
x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA
x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA
x05 RC4-SHA RSA RC4 128 TLS_RSA_WITH_RC4_128_SHA
x04 RC4-MD5 RSA RC4 128 TLS_RSA_WITH_RC4_128_MD5
x010080 RC4-MD5 RSA RC4 128 SSL_CK_RC4_128_WITH_MD5
x0a DES-CBC3-SHA RSA 3DES 168 TLS_RSA_WITH_3DES_EDE_CBC_SHA
x0700c0 DES-CBC3-MD5 RSA 3DES 168 SSL_CK_DES_192_EDE3_CBC_WITH_MD5
x080080 RC4-64-MD5 RSA RC4 64 SSL_CK_RC4_64_WITH_MD5
x62 EXP1024-DES-CBC-SHA RSA(1024) DES 56,exp TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
x09 DES-CBC-SHA RSA DES 56 TLS_RSA_WITH_DES_CBC_SHA
x060040 DES-CBC-MD5 RSA DES 56 SSL_CK_DES_64_CBC_WITH_MD5
x64 EXP1024-RC4-SHA RSA(1024) RC4 56,exp TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
x60 EXP1024-RC4-MD5 RSA(1024) RC4 56,exp TLS_RSA_EXPORT1024_WITH_RC4_56_MD5
x020080 EXP-RC4-MD5 RSA(512) RC4 40,exp SSL_CK_RC4_128_EXPORT40_WITH_MD5
Running client simulations via sockets
Android 2.3.7 TLSv1.0 RC4-MD5
Android 4.1.1 TLSv1.0 AES256-SHA
Android 4.3 TLSv1.0 AES256-SHA
Android 4.4.2 TLSv1.0 AES256-SHA
Android 5.0.0 TLSv1.0 AES256-SHA
Android 6.0 TLSv1.0 AES256-SHA
Android 7.0 TLSv1.0 AES128-SHA
Chrome 51 Win 7 TLSv1.0 AES128-SHA
Chrome 57 Win 7 TLSv1.0 AES128-SHA
Firefox 49 Win 7 TLSv1.0 AES128-SHA
Firefox 53 Win 7 TLSv1.0 AES128-SHA
IE 6 XP SSLv3 RC4-MD5
IE 7 Vista TLSv1.0 AES128-SHA
IE 8 XP TLSv1.0 RC4-MD5
IE 8 Win 7 TLSv1.0 AES128-SHA
IE 11 Win 7 TLSv1.0 AES256-SHA
IE 11 Win 8.1 TLSv1.0 AES256-SHA
IE 11 Win Phone 8.1 Update TLSv1.0 AES256-SHA
IE 11 Win 10 TLSv1.0 AES256-SHA
Edge 13 Win 10 TLSv1.0 AES256-SHA
Edge 13 Win Phone 10 TLSv1.0 AES256-SHA
Opera 17 Win 7 TLSv1.0 AES256-SHA
Safari 5.1.9 OS X 10.6.8 TLSv1.0 AES128-SHA
Safari 7 iOS 7.1 TLSv1.0 AES128-SHA
Safari 9 OS X 10.11 TLSv1.0 AES256-SHA
Safari 10 OS X 10.12 TLSv1.0 AES256-SHA
Apple ATS 9 iOS 9 No connection
Tor 17.0.9 Win 7 TLSv1.0 AES256-SHA
Java 6u45 TLSv1.0 RC4-MD5
Java 7u25 TLSv1.0 AES128-SHA
Java 8u31 TLSv1.0 AES128-SHA
OpenSSL 1.0.1l TLSv1.0 AES256-SHA
OpenSSL 1.0.2e TLSv1.0 AES256-SHA
Done 2019-07-07 08:04:43 [ 101s] -->> 77.136.113.9:4430 (77.136.113.9) <<--
-
Le successeur de la Sagem F@st 3284 DC :
Type de box : Sagem F@st 3686 (Box Internet RED Câble avec WiFi 801.11ac)
Version logiciel : SFR-PC20_3.454.0
# testssl https://89.158.21.12:4430
###########################################################
testssl.sh 2.9.5-4 from https://testssl.sh/
This program is free software. Distribution and
modification under GPLv2 permitted.
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!
Please file bugs @ https://testssl.sh/bugs/
###########################################################
Using "OpenSSL 1.0.2-chacha (1.0.2i-dev)" [~183 ciphers]
on vivien5:/snap/testssl/2/bin/openssl.Linux.x86_64
(built: "Jun 22 19:32:29 2016", platform: "linux-x86_64")
Start 2019-08-11 09:54:40 -->> 89.158.21.12:4430 (89.158.21.12) <<--
rDNS (89.158.21.12): 89-158-21-12.rev.numericable.fr.
Service detected: HTTP
Testing protocols via sockets except SPDY+HTTP2
SSLv2 not offered (OK)
SSLv3 offered (NOT ok)
TLS 1 offered
TLS 1.1 offered
TLS 1.2 offered (OK)
SPDY/NPN not offered
HTTP2/ALPN not offered
Testing ~standard cipher categories
NULL ciphers (no encryption) not offered (OK)
Anonymous NULL Ciphers (no authentication) not offered (OK)
Export ciphers (w/o ADH+NULL) not offered (OK)
LOW: 64 Bit + DES encryption (w/o export) not offered (OK)
Weak 128 Bit ciphers (SEED, IDEA, RC[2,4]) offered (NOT ok)
Triple DES Ciphers (Medium) offered
High encryption (AES+Camellia, no AEAD) offered (OK)
Strong encryption (AEAD ciphers) offered (OK)
Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4
No ciphers supporting Forward Secrecy offered
Testing server preferences
Has server cipher order? nope (NOT ok)
Negotiated protocol TLSv1.2
Negotiated cipher AES256-GCM-SHA384 (limited sense as client will pick)
Negotiated cipher per proto (limited sense as client will pick)
AES256-SHA: SSLv3, TLSv1, TLSv1.1
AES256-GCM-SHA384: TLSv1.2
No further cipher order check has been done as order is determined by the client
Testing server defaults (Server Hello)
TLS extensions (standard) "renegotiation info/#65281" "heartbeat/#15"
Session Ticket RFC 5077 hint (no lifetime advertised)
SSL Session ID support yes
Session Resumption Tickets no, ID: no
TLS clock skew Random values, no fingerprinting possible
Signature Algorithm SHA1 with RSA -- besides: users will receive a strong browser WARNING
Server key size RSA 1024 bits
Fingerprint / Serial SHA1 C8AFAECE761D116EDDE1013C6BE9D35B921B18F3 / 2013A08E78029B98
SHA256 81BAD9778AB34B5DBACAA37291C430D36A2E3B9083C78F48BFA332D05D614313
Common Name (CN) A0:8E:78:02:9B:98
subjectAltName (SAN) missing (NOT ok) -- Browsers are complaining
Issuer Askey Cable Modem Root Certificate Authority (Askey from TW)
Trust (hostname) certificate does not match supplied URI
Chain of trust NOT ok (chain incomplete)
EV cert (experimental) no
Certificate Expiration 4906 >= 60 days (UTC: 2013-01-16 01:00 --> 2033-01-16 00:59)
# of certificates provided 1
Certificate Revocation List NOT ok -- neither CRL nor OCSP URI provided
OCSP URI --
OCSP stapling --
OCSP must staple no
DNS CAA RR (experimental) --
Certificate Transparency no
Testing HTTP header response @ "/"
HTTP Status Code 200 OK
HTTP clock skew Got no HTTP time, maybe try different URL?
Strict Transport Security --
Public Key Pinning --
Server banner (no "Server" line in header, interesting!)
Application banner --
Cookie(s) (none issued at "/")
Security headers --
Reverse Proxy banner --
Testing vulnerabilities
Heartbleed (CVE-2014-0160) not vulnerable (OK), timed out
CCS (CVE-2014-0224) not vulnerable (OK)
Ticketbleed (CVE-2016-9244), experiment. not vulnerable (OK), no session ticket extension
Secure Renegotiation (CVE-2009-3555) not vulnerable (OK)
Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), DoS threat
CRIME, TLS (CVE-2012-4929) not vulnerable (OK)
BREACH (CVE-2013-3587) no HTTP compression (OK) - only supplied "/" tested
POODLE, SSL (CVE-2014-3566) VULNERABLE (NOT ok), uses SSLv3+CBC (check TLS_FALLBACK_SCSV mitigation below)
TLS_FALLBACK_SCSV (RFC 7507) Downgrade attack prevention supported (OK)
SWEET32 (CVE-2016-2183, CVE-2016-6329) VULNERABLE, uses 64 bit block ciphers
FREAK (CVE-2015-0204) not vulnerable (OK)
DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable on this host and port (OK)
make sure you don't use this certificate elsewhere with SSLv2 enabled services
https://censys.io/ipv4?q=81BAD9778AB34B5DBACAA37291C430D36A2E3B9083C78F48BFA332D05D614313 could help you to find out
LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH EXPORT ciphers, no DH key detected
BEAST (CVE-2011-3389) SSL3: AES256-SHA CAMELLIA256-SHA
AES128-SHA SEED-SHA
CAMELLIA128-SHA IDEA-CBC-SHA
DES-CBC3-SHA
TLS1: AES256-SHA CAMELLIA256-SHA
AES128-SHA SEED-SHA
CAMELLIA128-SHA IDEA-CBC-SHA
DES-CBC3-SHA
VULNERABLE -- but also supports higher protocols (possible mitigation): TLSv1.1 TLSv1.2
LUCKY13 (CVE-2013-0169), experimental potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS
RC4 (CVE-2013-2566, CVE-2015-2808) VULNERABLE (NOT ok): RC4-SHA RC4-MD5
Testing 359 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength
Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (RFC)
-----------------------------------------------------------------------------------------------------------------------------
x9d AES256-GCM-SHA384 RSA AESGCM 256 TLS_RSA_WITH_AES_256_GCM_SHA384
x3d AES256-SHA256 RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA256
x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA
x84 CAMELLIA256-SHA RSA Camellia 256 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
x9c AES128-GCM-SHA256 RSA AESGCM 128 TLS_RSA_WITH_AES_128_GCM_SHA256
x3c AES128-SHA256 RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA256
x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA
x96 SEED-SHA RSA SEED 128 TLS_RSA_WITH_SEED_CBC_SHA
x41 CAMELLIA128-SHA RSA Camellia 128 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
x07 IDEA-CBC-SHA RSA IDEA 128 TLS_RSA_WITH_IDEA_CBC_SHA
x05 RC4-SHA RSA RC4 128 TLS_RSA_WITH_RC4_128_SHA
x04 RC4-MD5 RSA RC4 128 TLS_RSA_WITH_RC4_128_MD5
x0a DES-CBC3-SHA RSA 3DES 168 TLS_RSA_WITH_3DES_EDE_CBC_SHA
Running client simulations via sockets
Android 2.3.7 TLSv1.0 RC4-MD5
Android 4.1.1 TLSv1.0 AES256-SHA
Android 4.3 TLSv1.0 AES256-SHA
Android 4.4.2 TLSv1.2 AES256-GCM-SHA384
Android 5.0.0 TLSv1.2 AES256-SHA
Android 6.0 TLSv1.2 AES128-GCM-SHA256
Android 7.0 TLSv1.2 AES128-GCM-SHA256
Chrome 51 Win 7 TLSv1.2 AES128-GCM-SHA256
Chrome 57 Win 7 TLSv1.2 AES128-GCM-SHA256
Firefox 49 Win 7 TLSv1.2 AES128-SHA
Firefox 53 Win 7 TLSv1.2 AES128-SHA
IE 6 XP SSLv3 RC4-MD5
IE 7 Vista TLSv1.0 AES128-SHA
IE 8 XP TLSv1.0 RC4-MD5
IE 8 Win 7 TLSv1.0 AES128-SHA
IE 11 Win 7 TLSv1.2 AES256-GCM-SHA384
IE 11 Win 8.1 TLSv1.2 AES256-GCM-SHA384
IE 11 Win Phone 8.1 Update TLSv1.2 AES256-GCM-SHA384
IE 11 Win 10 TLSv1.2 AES256-GCM-SHA384
Edge 13 Win 10 TLSv1.2 AES256-GCM-SHA384
Edge 13 Win Phone 10 TLSv1.2 AES256-GCM-SHA384
Opera 17 Win 7 TLSv1.2 AES256-SHA
Safari 5.1.9 OS X 10.6.8 TLSv1.0 AES128-SHA
Safari 7 iOS 7.1 TLSv1.2 AES256-SHA256
Safari 9 OS X 10.11 TLSv1.2 AES256-GCM-SHA384
Safari 10 OS X 10.12 TLSv1.2 AES256-GCM-SHA384
Apple ATS 9 iOS 9 No connection
Tor 17.0.9 Win 7 TLSv1.0 CAMELLIA256-SHA
Java 6u45 TLSv1.0 RC4-MD5
Java 7u25 TLSv1.0 AES128-SHA
Java 8u31 TLSv1.2 AES128-SHA256
OpenSSL 1.0.1l TLSv1.2 AES256-GCM-SHA384
OpenSSL 1.0.2e TLSv1.2 AES256-GCM-SHA384
Done 2019-08-11 09:56:42 [ 124s] -->> 89.158.21.12:4430 (89.158.21.12) <<--
-
SFR: Pour accéder à la box RED Sagem F@st 3284 DC, https est imposé, mais :
- Le choix se limite à SSLv2, SSLv3 et TLS 1.0 !
- https sans certificat valide
Écran 1, à cause d'absence de TLS 1.2 ou supérieur :
(https://lafibre.info/images/ssl/202003_box_red_sagem_fast3284dc_1.png)
Écran 2, à cause d'absence de certificat valide :
(https://lafibre.info/images/ssl/202003_box_red_sagem_fast3284dc_2.png)
Écran 3, on arrive sur l'interface de la box :
(https://lafibre.info/images/ssl/202003_box_red_sagem_fast3284dc_3.png)
-
J'ai eu le service client RED, après avoir bien expliqué la chose, ils ont cherchés, mais il n'y a aucun moyen de déclarer un incident sur l’accès à distance à l'interface de la box.
Selon le service client RED, La configuration des "Paramètres avancés" se fait sous la responsabilité de l’utilisateur.
Bref, l'accès à distance à l'interface web ne fonctionnera bientôt plus.
-
Bouygues Telecom n'a pas mis à jour son certificat sur sa Bbox Wi-Fi 6, on a donc une alerte :
(https://lafibre.info/images/ssl/202106_mabbox_certificat_1.png)
Le certificat n'est plus valide depuis samedi 5 juin :
(https://lafibre.info/images/ssl/202106_mabbox_certificat_2.png)