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

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 168
    • Twitter LaFibre.info
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:

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 676
  • La Madeleine (59)
Bouygues passe l'interface d'admin de sa Bbox en https. Vous avez testé ?
« Réponse #1 le: 28 novembre 2018 à 23:36:38 »
Ç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) <<--

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 804
  • 73
Bouygues passe l'interface d'admin de sa Bbox en https. Vous avez testé ?
« Réponse #2 le: 29 novembre 2018 à 05:25:17 »
- 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 :)

tomfibre

  • Abonné Sosh fibre
  • *
  • Messages: 323
Bouygues passe l'interface d'admin de sa Bbox en https. Vous avez testé ?
« Réponse #3 le: 29 novembre 2018 à 07:03:17 »
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...

LeNuageux

  • Abonné Free fibre
  • *
  • Messages: 153
  • Mulhouse (68)
Bouygues passer l'interface d'admin de sa Bbox en https. Vous avez testé ?
« Réponse #4 le: 29 novembre 2018 à 07:33:05 »

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)

vivien

  • Administrateur
  • *
  • Messages: 47 168
    • Twitter LaFibre.info
Bouygues passe l'interface d'admin de sa Bbox en https. Vous avez testé ?
« Réponse #5 le: 29 novembre 2018 à 07:37:58 »
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.

vivien

  • Administrateur
  • *
  • Messages: 47 168
    • Twitter LaFibre.info
Bouygues passe l'interface d'admin de sa Bbox en https. Vous avez testé ?
« Réponse #6 le: 29 novembre 2018 à 09:33:53 »
A priori, les certificats sont maintenant fourni pour une durée maximum de 2 ans, depuis le début 2018.

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 804
  • 73
Bouygues passer l'interface d'admin de sa Bbox en https. Vous avez testé ?
« Réponse #7 le: 29 novembre 2018 à 09:35:36 »
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.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 676
  • La Madeleine (59)
Bouygues passe l'interface d'admin de sa Bbox en https. Vous avez testé ?
« Réponse #8 le: 29 novembre 2018 à 10:18:23 »
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

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 804
  • 73
Bouygues passe l'interface d'admin de sa Bbox en https. Vous avez testé ?
« Réponse #9 le: 29 novembre 2018 à 10:30:33 »
Vrai, TXT est parfois bien utile. Mais je préfère encore CHAOS.

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 091
  • Paris (75)
Bouygues passe l'interface d'admin de sa Bbox en https. Vous avez testé ?
« Réponse #10 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.

vivien

  • Administrateur
  • *
  • Messages: 47 168
    • Twitter LaFibre.info
Bouygues passe l'interface d'admin de sa Bbox en https. Vous avez testé ?
« Réponse #11 le: 29 novembre 2018 à 10:32:16 »
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.