La Fibre
Télécom => Réseau => 
Protocoles réseaux sécurisés (https) => Discussion démarrée par: vivien le 27 janvier 2015 à 15:45:59
-
surtout HSTP (https://fr.wikipedia.org/wiki/HTTP_Strict_Transport_Security)
HSTP ?
Tu voulais parler de HSTS, non ? (HTTP Strict Transport Security (https://fr.wikipedia.org/wiki/HTTP_Strict_Transport_Security))
Je suis en train de l'activer, cela permet d'avoir un A+ sur Qualys SSL Labs.
Avec apache, cela nécessite d'activer le mod header : sudo a2enmod headers
On rajoute dans la conf https du serveur web la ligne suivante :
# Utiliser HSTS (HTTP Strict Transport Security) pour forcer le navigateur a contacter le nom de domaine pendant 1an que en https
Header always set Strict-Transport-Security "max-age=31536000; preload"
Il faut faire attention de ne pas suivre l'exemple proposé sur Wikipedia avec "includeSubDomains;" si tous les sous-domaine ne sont pas en https.
Pour lafibre.info, les speedtest utilisent un sous-domaine et se font en http donc il ne faut surtout pas mettre cette directive, sinon les autres sous-domaines ne sont plus accessibles en http.
-
oui typo, HSTS.
-
Google recommande un 301 et surtout HSTS (https://fr.wikipedia.org/wiki/HTTP_Strict_Transport_Security) ( https://support.google.com/webmasters/answer/6073543?hl=fr )
En théorie, oui c'est une bonne chose.
En pratique, les navigateurs empêchent de passer outre les erreurs de certificats, et je ne connais pas de moyen de contourner ça. Et pour moi ça c'est juste inadmissible.
Et deux fois plus pour un logiciel "libre".
-
Sans doute à cause des auto-signé que beaucoup de monde utilise :
- sur le site de recette/pré-prod/dev
- sur le site monté à l'arrache pour des besoins internes
- passe que ça va plus vite à faire
-
Pour Chrome il y a l'option --ignore-certificate-errors
-
Cela abaisse fortement la sécurité, tu ne vois plus les attaques de type Man in The Middle qui se font massivement en Chine (pour voir les données chiffrées) et dans certaines entreprises ou chez l'opérateur Gogo aux USA :
Gogo bloque YouTube dans les avions avec un technique de pirate
Un ingénieur de Google a découvert que Gogo, FAI spécialisé à destination des usagers de nombreuses compagnies aériennes, remplaçait les certificats HTTPS de sites web comme YouTube avec ses propres certificats. Une technique de type Man in The Middle que Gogo indique utiliser uniquement pour limiter le trafic data web en vol et non pour espionner les passagers.
(https://lafibre.info/images/bistro/201501_mitm_certificat_ssl_gogo.jpg)
Certains passagers de compagnies aériennes s'y prendront peut être à deux fois avant de se connecter à Internet en plein vol. Gogo, spécialisé dans l'accès WiFi dans les avions de nombreuses compagnies aériennes (American Airlines, Delta Air Lines, Japan Airlines, Virgin America...), inspecte en effet de très près le trafic web des passagers. Un peu trop peut être, Gogo allant jusqu'à remplacer les certificats HTTPS de certains sites avec les siens.
La société indique que cette procédure, qui techniquement s'apparente à une attaque de type Man in The Middle (MiTM), est seulement effectuée pour quelques sites de streaming vidéo dans le cadre de ses efforts pour limiter ou bloquer l'utilisation de ce types de services. Ce problème a été découvert par hasard par Adrienne Porter Felt, ingénieur et chercheur de l'équipe de sécurité Google Chrome, qui a remarqué la présence d'un étrange certificat HTTPS lorsqu'elle a tenté d'accéder à Youtube.com via le WiFi Gogo au cours d'un vol.
La technique MiTM permet d'accéder à des informations sensibles
En réponse, Gogo a publié une réaction par le biais de son directeur technique, Anand Chari : « En ce moment, Gogo travaille sur de nombreuses façons d'apporter plus de bande passante dans un avion. Jusqu'à présent, nous avons annoncé que nous ne supportions pas le support de différents sites de streaming vidéo en utilisant plusieurs techniques pour limiter/bloquer le streaming vidéo. Quelque soit la technique utilisée, celle-ci n'affecte pas la sécurité du trafic web dans son ensemble mais est utilisée pour assurer que tout le monde puisse dans l'avion accéder à une bonne expérience de navigation ».
Et Anand Chari d'assurer qu'aucune information utilisateur n'est collectée lorsque de telles techniques sont utilisées. Et ce, bien que l'utilisation de techniques de type MiTM permettent justement d'intercepter des informations transitant entre le terminal de l'utilisateur et le proxy de Gogo mais également d'accéder à des données potentiellement sensibles relatifs aux comptes des utilisateurs. Le fait d'utiliser une technique MiTM pour limiter le streaming vidéo ne manque cependant pas de laisser perplexe, car il existe bien d'autres moyens pour bloquer ou limiter les accès aux services web tels que ceux de streaming vidéo sans intercepter tous les paquets.
Source : Le Monde Informatique (http://www.lemondeinformatique.fr/actualites/lire-gogo-bloque-youtube-dans-les-avions-avec-un-technique-de-pirate-59811.html) Article de Dominique Filippone, le 6 janvier 2015.
-
Pour la chine : Un article publié la semaine dernière mais il y en a régulièrement, la Chine a une véritable expertise technique dans le MITM...
Chine : une attaque 'Man in the middle' sur les messageries Outlook
Sécurité : Selon le site GreatFire.org, une attaque Man in the middle aurait été détectée en Chine, visant les utilisateurs du service de messagerie Outlook de Microsoft. L’association de défense des libertés soupçonne l’administration chinoise d’être à l’origine de l’attaque.
Le site Greatfire.org, qui surveille la politique toute particulière du gouvernement chinois face à Internet, tire à nouveau la sonnette d’alarme suite à des informations faisant état d’une attaque de type man in the middle visant les utilisateurs de la messagerie Outlook. L’attaque semble avoir été ponctuelle et n’avoir duré qu’une journée, selon l’association, mais ce signalement vient renforcer les inquiétudes à l’égard de la Chine.
Il faut rappeler que l’accès à Gmail reste perturbé sur le territoire chinois et selon l’association Greatfire.org, des attaques comparables à celle subie par Outlook ont déjà été constatées, sur différents services de messageries.
L’attaque 'Man in the Middle', comme son nom l’indique, consiste à se faire passer pour un destinataire afin d’intercepter les flux entrant et sortants sans que l’utilisateur ne soit capable de détecter la différence dans le fonctionnement du service.
Certificats biaisés
Plus précisèment, Greatfire.org s’inquiète du rôle joué par le China Internet Network Information Center (CNNIC), organisme directement placé sous la coupe du ministère de l’information et qui joue également le rôle d’autorité de certification. Ces certificats sont en effet le moyen généralement utilisé pour s’assurer que l’interlocuteur est bien celui qu’il prétend être dans le cadre d’une connexion internet. Le site Greatfire.org précise néanmoins qu’un message d’avertissement est présenté à l’utilisateur, qui peut alors décider de ne pas poursuivre la connexion.
Greatfire invite les acteurs tels que Microsoft et Apple à ne plus faire automatiquement confiance aux certificats signés par le CNNIC, arguant que les certificats approuvés par l’autorité ont fréquemment été identifiés dans plusieurs cas d’attaque similaires. Mozilla en 2010 se posait déjà la question de savoir si oui ou non l’autorité chinoise devait être par défaut considérée comme une autorité de certification valide et digne de confiance.
Contacté par Zdnet.com, Microsoft reconnait avoir été alerté de cette attaque et recommande aux utilisateurs affectés de contacter leurs fournisseurs d’accès pour obtenir de l’aide. L’attaque ne vise que les utilisateurs du client mail d’Outlook ou via les clients pour terminaux mobiles, les utilisateurs passant par l’interface web (Outlook.com) ne semblent pas affectés.
Source : ZD Net (http://www.zdnet.fr/actualites/chine-une-attaque-man-in-the-middle-sur-les-messageries-outlook-39813275.htm) le Mardi 20 Janvier 2015 par Par Louis Adam
-
La Chine aurait mené une attaque Man in the Middle contre iCloud
Le cryptage des données par Apple n'est pas du goût de la Chine. Le pays aurait donc décidé de s'attaquer à iCloud pour surveiller ses citoyens.
Alors que les iPhone 6 et 6 plus viennent d’arriver en Chine, Great Fire, une organisation à but non lucratif qui s’est fixé pour but de surveiller la censure d’Internet dans le pays, affirme que les autorités locales ont procédé à une attaque Man in the Middle sur iCloud.
Ce type d’attaque permet de récupérer des données en se plaçant entre deux parties sans qu’aucune ne se rende compte que le canal est compromis. Le gouvernement chinois chercherait ainsi à récolter des mots de passe et noms d’utilisateurs du service pour ensuite avoir accès à tous les documents stockés dans iCloud : photos, contacts, messages…
D’après Great Fire, certains navigateurs comme Chrome ou Firefox affichent une page d’erreur lorsque des utilisateurs cherchent à se connecter à iCloud depuis un ordinateur à l’inverse de Qihoo, le navigateur le plus utilisé en Chine.
Il y a peu, la firme de Cupertino avait annoncé qu’elle souhaitait stocker en Chine les données personnelles de ses utilisateurs locaux, mais qu’elles seraient cryptées, comme elle s’y était engagée dans sa nouvelle politique de protection des données. Il n’y a semble-t-il pas que les autorités américaines qui « déplorent » le fait qu’Apple ait accentué le chiffrement des données des utilisateurs de ses smartphones…
Source : 01net (http://www.01net.com/editorial/629110/la-chine-aurait-mene-une-attaque-man-in-the-middle-contre-icloud/), le 22 octobre 2014 par Cécile Bolesse.
-
J'ai un exemple de site qui a activé HTTP Strict Transport Security avec "includeSubDomains"
Or "includeSubDomains" devrait interdir d'accéer a un site en http avec le nom de domaine et ce n'est pas le cas.
Le site en question qui est en HTTP Strict Transport Security : https://dns.imt-systems.com
=> https://www.ssllabs.com/ssltest/analyze.html?d=dns.imt-systems.com
Pourtant, il est possible de surfer sur http://imt-systems.com
imt-systems.com ne s’applique pas avec la directive "includeSubDomains" ?
-
Pour Chrome il y a l'option --ignore-certificate-errors
Mauvaise idée.
En raison du comportement absolument inadmissible de Google Chrome concernant HSTS (= le fait que Chrome s'efforce de suive cette norme), j'ai été obligé de saccager HSTS directement dans le binaire de Chrome (très certainement en violation de la licence, mais faut pas me faire chier).
-
J'avais testé avec Firefox mais idem avec chrome : le site imt-systems est accessible en http alors que sont sous-domaine déclare le HTTP Strict Transport Security pour "includeSubDomains"
Je pense que "includeSubDomains" n'inclus pas le domaine parent
-
Pour info, un onglet 'security' est en cours de développement pour les DevTools (touche F12) de Chrome/Chromium.
C'est, pour le moment, prévu pour la version 43 donc la prochaine version de 'Chrome Canary' (version stable actuelle+2).
Ca permettra d'ausculter ce qui se passe au niveau sécurité.
un 'mockup' est dispo ici : https://craigfrancis.github.io/dev-security/#tls-hsts (on peut y peut click les differentes rubriques). ca ne sera pas forcement mis en oeuvre tel que mais ca donne une idée.
-
Est-ce qu'il y a une extension Google Chrome pour ajouter le support de Strict-Transport-Security?
-
J'ai trouvé cette extension Google Chrome :
KB SSL Enforcer (https://chrome.google.com/webstore/detail/kb-ssl-enforcer/flcpelgcagfhfoegekianiofphddckof)
Cela redirige automatiquement vers HTTPS les sites détectés. On peut ajouter des sites.
-
Cette extension provoque des soucis avec les sites qui ne sont pas entièrement disponibles en HTTPS mais dont la page HTML principale est dispo en HTTPS.
J'ai cessé de l'utiliser.
-
Pour moi HTST est une très mauvaise norme, notamment parce qu'elle suppose que le navigateur accumule une liste de sites HTST visités pour protéger les visites suivantes : cela implique de garder le plus longtemps possible un historique de noms de domaines (pas un historique d'URL visitées) ce qui pose problème quand les gens veulent effacer les traces de navigation.
C'est notamment un souci sur des ordinateurs en libre service où le navigateur est configuré pour effacer toutes les traces à la fin de chaque session.
C'est encore plus un souci en navigation Tor sur système en RAM où c'est un impératif de conception, alors que l'importance de la sécurité du transport assurée par TLS est encore plus grande, vu que le relais de sortie peut tout à fait enregistrer ou altérer les données et que n'importe qui peut devenir un relais de sortie.
-
Il me semble que Firefox a pris la décision de pré-embarquer une grande liste de sites HTST.
N'importe qui peut demander à être inclus dans la liste, j'ai peur que sa taille soit importante.
Google de son coté a une liste de taille réduite avec les sites Google et des sites à risques.
Note : Je n'ai pas demandé l'inclusion de lafibre.info sur la liste Firefox.
-
Quel est l'intérêt vis-à-vis d'une configuration correcte côté serveur (http vers https) ?
-
Forcer le navigateur à se connecter en https, si les équipements du gouvernement te proposent une connexion en http, tu peux raisonnablement penser que ta connexion passe par un proxy...
Il ne faut pas raisonner en France, mais en chine avec ses attaques 'Man in the middle'
Chine : une attaque 'Man in the middle' sur les messageries Outlook
Sécurité : Selon le site GreatFire.org, une attaque Man in the middle aurait été détectée en Chine, visant les utilisateurs du service de messagerie Outlook de Microsoft. L’association de défense des libertés soupçonne l’administration chinoise d’être à l’origine de l’attaque.
Le site Greatfire.org, qui surveille la politique toute particulière du gouvernement chinois face à Internet, tire à nouveau la sonnette d’alarme suite à des informations faisant état d’une attaque de type man in the middle visant les utilisateurs de la messagerie Outlook. L’attaque semble avoir été ponctuelle et n’avoir duré qu’une journée, selon l’association, mais ce signalement vient renforcer les inquiétudes à l’égard de la Chine.
Il faut rappeler que l’accès à Gmail reste perturbé sur le territoire chinois et selon l’association Greatfire.org, des attaques comparables à celle subie par Outlook ont déjà été constatées, sur différents services de messageries.
L’attaque 'Man in the Middle', comme son nom l’indique, consiste à se faire passer pour un destinataire afin d’intercepter les flux entrant et sortants sans que l’utilisateur ne soit capable de détecter la différence dans le fonctionnement du service.
Certificats biaisés
Plus précisèment, Greatfire.org s’inquiète du rôle joué par le China Internet Network Information Center (CNNIC), organisme directement placé sous la coupe du ministère de l’information et qui joue également le rôle d’autorité de certification. Ces certificats sont en effet le moyen généralement utilisé pour s’assurer que l’interlocuteur est bien celui qu’il prétend être dans le cadre d’une connexion internet. Le site Greatfire.org précise néanmoins qu’un message d’avertissement est présenté à l’utilisateur, qui peut alors décider de ne pas poursuivre la connexion.
Greatfire invite les acteurs tels que Microsoft et Apple à ne plus faire automatiquement confiance aux certificats signés par le CNNIC, arguant que les certificats approuvés par l’autorité ont fréquemment été identifiés dans plusieurs cas d’attaque similaires. Mozilla en 2010 se posait déjà la question de savoir si oui ou non l’autorité chinoise devait être par défaut considérée comme une autorité de certification valide et digne de confiance.
Contacté par Zdnet.com, Microsoft reconnait avoir été alerté de cette attaque et recommande aux utilisateurs affectés de contacter leurs fournisseurs d’accès pour obtenir de l’aide. L’attaque ne vise que les utilisateurs du client mail d’Outlook ou via les clients pour terminaux mobiles, les utilisateurs passant par l’interface web (Outlook.com) ne semblent pas affectés.
Source : ZD Net (http://www.zdnet.fr/actualites/chine-une-attaque-man-in-the-middle-sur-les-messageries-outlook-39813275.htm) le Mardi 20 Janvier 2015 par Par Louis Adam
Après, il y a encore un risque, qu'une autorité de certification reconnue par les navigateurs délivre un certificat pour un autre site.
Google a mis du code spécifique dans Google Chrome qui l’avertit si un client se retrouve avec un certificat Google qui n'est pas signé par l’autorité de certification de Google.
Cela lui permet de trouver régulièrement des société de certification qui ont signé un faux gmail.com.
On parlait dans l'article précédent de CNNIC, voici qu'on en reparle :
Google rejette en bloc les certificats de sécurité du chinois CNNIC
La semaine dernière, une autorité de certification avait produit au moins un certificat au nom de Google pour une utilisation que la firme de Mountain View était loin d’accepter. La conséquence est radicale : Google vient de bannir l’ensemble des certificats produits par CNNIC, au risque de provoquer toute une série de problèmes chez les utilisateurs. Mozilla se prépare de son côté à une action plus nuancée.
Un certificat généré au nom de Google, sans son autorisation
Rappel des faits. MCS Holdings, une autorité intermédiaire de certification opérant pour le compte de l’entreprise chinoise CNNIC (China Internet Network Information Center) a généré un certificat estampillé Google. Ce dernier a été utilisé dans un proxy agissant comme un « homme au milieu », capable de lire les transmissions de données sécurisées. Il s’agissait a priori pour CNNIC de mettre en place un équipement qui permettrait de vérifier ce qui entrait et sortait de son entreprise, donc de vérifier l’activité des employés et les échanges avec les clients. Un point sensible actuellement, comme l’ont montré en France les recommandations de la CNIL très récemment.
Le problème est que le certificat de sécurité a été généré au nom de Google sans aucune autorisation. La colère de l’entreprise ne s’est pas fait attendre : si toutes les autorités de certification se mettaient à créer de fausses preuves d’identité, comment être sûr finalement qu’un site est bien ce qu’il prétend être. En fait, comme nous l’indiquait justement Stéphane Bortzmeyer de l’Afnic la semaine dernière, les autorités sont des entreprises, donc gouvernées par des impératifs commerciaux. Si l’une d’entre elles refuse de délivrer un certificat, le client peut très bien s’adresser à un autre.
Google rejette les certificats racines de CNNIC
Google avait annoncé dans un premier temps que le fameux certificat avait été révoqué et qu’une mise à jour serait rapidement envoyée vers Chrome pour modifier la liste de ceux acceptés. Mais l’éditeur va finalement beaucoup plus loin : il rejette l’ensemble des certificats racines de CNNIC. Cette décision radicale a pour conséquence le rejet par cascade de tous les certificats qui auraient été générés par l’entreprise.
Une coupe d’autant plus franche que CNNIC est l’une des plus grosses autorités chinoises et que Chrome représente 52 % de parts de marché dans l’empire du milieu, loin devant les 23 % d’Internet Explorer. Les utilisateurs risquent donc de subir la décision de Google, même s’ils ont encore un peu de temps puisqu’il faudra attendre une mise à jour de Chrome pour que la mesure prenne effet.
Dans une mise à jour de son billet de blog original, Google explique que la décision a été discutée avec CNNIC. L’entreprise chinoise devrait se lancer dans certains travaux avant d’être considérée à nouveau comme une autorité de confiance par Google. Elle devrait surtout implèmenter Certificate Transparency, une initiative de Mountain View visant à gommer certains défauts du processus-même de génération des certificats. Il s’agit globalement de surveiller et de pouvoir auditer en temps réel n’importe quel certificat pour en tester la validité et surtout la légitimité. Dans le cas qui nous intéresse, Certificate Transparency aurait par exemple permis de détecter immédiatement qu’il y avait une erreur puisque le certificat n’avait pas été dûment demandé par Google. Une fois que cette infrastructure aura été mise en place, il ne devrait pas y avoir de raison pour que CNNIC soit laissé de côté.
Des décisions plus nuancées chez Mozilla et Microsoft
La décision reste radicale, nettement plus que pour la concurrence. Firefox et Internet Explorer rejettent ainsi les certificats issus de MCS Holdings, mais pas ceux de CNNIC. Bien que l’un agisse pour le compte de l’autre, la répercussion est donc moindre. Mozilla prépare cependant de son côté des actions complèmentaires. L’éditeur discute actuellement des mesures à prendre et, sans rejeter tout d’un bloc, devrait bloquer tous les certificats générés depuis une date donnée, qui reste à définir. La liste complète des certificats valides sera en outre réclamée pour que la communauté puisse la vérifier, et CNNIC devra « postuler » à nouveau après de Mozilla pour recevoir à nouveau sa pleine confiance. Cependant, si l’entreprise devait échouer, Mozilla en révoquerait cette fois les certificats racines, aboutissant alors à la même situation qu’avec Chrome.
Il devrait dans tous les cas y avoir une vraie gêne en Chine pour les utilisateurs puisque les certificats de CNNIC sont utilisés par des banques, des services de commerce et ainsi de suite. Du jour au lendemain, des internautes recevront des messages d’erreur les informant que l’identité de leurs sites ne peut plus être vérifiée. Comme toujours dans ce cas, il sera possible de passer outre l’avertissement, mais le contournement sera fortement déconseillé par le navigateur.
Google indique pour sa part qu’en dehors de la gêne occasionnée, il n’existe a priori pas de danger pour l’instant. Le certificat généré par MCS Holdings a en effet été utilisé en interne et n’est pas sorti du cadre de ce test.
Source : NextINpact (https://www.nextinpact.com/news/93686-google-rejette-en-bloc-certificats-securite-chinois-cnnic.htm), le 2 avril 2015.
Cela ne se passe pas que en Chine, mais aussi en France : Un certificat de l'ANSSI utilisé pour des attaques MITM sur les services Google (https://lafibre.info/cryptographie/lanssi-aurait-effectue-des-attaques-mitm-sur-les-services-google/)
HTTP Strict Transport Security est une brique de plus pour apporter gratuitement un petit peu plus de sécurité. Oui, comme le dit corrector, de nombreux cas passent à la trappe.
-
Forcer le navigateur a se connecter en https, si les équipements du gouvernement te proposent une connexion en http, tu peux raisonnablement penser que ta connexion passe par un proxy...
Il ne faut pas raisonner en France, mais en chine avec ses attaques 'Man in the middle'
(...)
Google a mis du code spécifique dans Google Chrome qui l’averti si un client se retrouve avec un certificat Google qui n'est pas signé par l’autorité de certification de Google.
vivien je pense que tu mélanges un peu tout!
HTTP Strict Transport Security est une protocole de forçage HTTPS comme les extensions de forçage (HTTPS Everywhere de l'EFF, KB SSL Enforcer, NoScript...). C'est un protocole basé sur une méta info HTTP et donc débile.
Et là tu parles des pins et des abus des CA, ça n'est pas la même chose.
-
Quel est l'intérêt vis-à-vis d'une configuration correcte côté serveur (http vers https) ?
Par "configuration correcte", tu entends un serveur qui quand il a une requête pour http://example/search?q=frobnicateur avec une redirection HTTP "moved permanently" vers https://example/search?q=frobnicateur ?
Le souci est évident : HTTP sur TCP n'est pas du tout sécurisé donc
1) Le navigateur a révélé que tu recherches des infos "frobnicateur"
2) La redirection ne protège le reste de la session que contre une écoute passive.
En effet, un adversaire actif peut retirer la redirection, ou même faire une redirection vers https://example.mafia.ru
ou https://exаmple (https://exаmple) !
Donc en mettant une redirection automatique mais non sécurisée, tu ne fais que masquer l'imprudence des utilisateurs!
Pour accéder à un contenu sécurisé, il faut y accéder de façon sécurisée!
-
Pour accéder à un contenu sécurisé, il faut y accéder de façon sécurisée!
Quelle différence avec le HSTS ?
Pour que le client l'ai, il faut qu'il se soit déjà connecté en HTTPS.
Autrement dit, celui qui se connecte en HTTP ne l'aura jamais.
En effet, la redirection 301 http vers https n'est pas parfaite.
En revanche, elle garantie que personne n'ira sur mon site sans avoir une sécurisation du transport.
-
Quelle différence avec le HSTS ?
Le navigateur mémorise le HSTS.
Ce qui est un des problèmes vu que ça laisse la trace des sites visités (mais pas des URL).
Pour que le client l'ai, il faut qu'il se soit déjà connecté en HTTPS.
Autrement dit, celui qui se connecte en HTTP ne l'aura jamais.
Ben si, en HTTP il voit la redirection vers HTTPS! (sauf s'il subit une attaque, cf supra)
En effet, la redirection 301 http vers https n'est pas parfaite.
En revanche, elle garantie que personne n'ira sur mon site sans avoir une sécurisation du transport.
NON
Elle ne garantit rien vu que HTTP n'est pas sécurisé!
Je viens de le dire.
-
Ben si, en HTTP il voit la redirection vers HTTPS! (sauf s'il subit une attaque, cf supra)
Ok, donc tu parles de mettre les deux : c'est bien !
NON
Elle ne garantit rien vu que HTTP n'est pas sécurisé!
Je viens de le dire.
Hum, oui, et tu as tord.
Mon serveur web s'en fout que le transport soit avec ou sans TLS.
Quand ma conf HTTP se résume à cela :
<VirtualHost *:80>
Redirect permanent / https://k-net.fr/
</VirtualHost>
Je peux t'assurer, et te garantir que personne, personne n'ira sur mon serveur, en HTTP, consulter k-net.fr.
Jamais, personne, c'est impossible.
-
Nah, franchement ?
-
personne n'est pas un nom, c'est une négation. Il y a un n'. Ne pas, ne plus, ne personne.
Est-ce qu'un site est une socket ? Ben, non, je ne laisse pas trainer mes sockets sales sur mes serveurs. J'ai un placard pour le linge.
Ou alors, tu parlais d'un socket, auquel cas, c'est tout aussi non. Cf couches OSI, il faut au moins du L7. Et un code HTTP 200, tant qu'à faire.
Est-ce que c'est un contenu ? Non. Si j'enregistre la page google.fr que je place sur bob.org, ce n'est pas le même site. L'un appartient à google, l'autre à moi.
Est-ce que tu peux obtenir un 200, avec un GET, sur http://k-net.fr ?
-
http://www.lepointdufle.net/ressources_fle/negation_regle.htm
Non.
Et donc?
Je peux t'assurer, et te garantir que personne, personne n'ira sur mon serveur, en HTTP, consulter k-net.fr.
Jamais, personne, c'est impossible.
-
Ce n'est pas le sujet.
Le sujet est :
HTTP n'est PAS sécurisé.
-
Mme michu ne met pas https quand elle va visiter un site web.
En temps normal : C'est la redirection mis sur ton site qui va forcer le https
Je vais maintenant imaginer une histoire tordue pour expliquer. Si l'opérateur XXXXXX au lieu de rediriger k-net.fr vers la bonne IP, redirige vers un site identique avec des prix 20€/mois plus cher, histoire de décourager les personnes de s'abonner à K-Net.
=> Sans HTTP Strict Transport Security, même michu, qui n'a pas mis https, verra les fausses offres proposées par XXXXXX.
=> Avec HTTP Strict Transport Security, si elle a déjà été visiter le site K-Net dans le passé, elle sera redirigé en https qui va afficher une alerte de sécurité qui va l'encourager à appeler K-Net plutôt que de regarder son site. Si elle n'a jamais visité le site, elle sera en http donc sans alerte.
=> Avec la liste pré-enregistrée dans Firefox de sites HTTP STS, même si Mme michu n'a pas été visiter le site K-Net, elle sera forcée en https.
Dans le cas de man in the middle, si 20% des personnes vont sur un site sans mettre https, tu peux facilement les berner.
-
Quand/si les navigateurs utiliseront HTTPS par défaut ca ira mieux non ?
Curieusement (et sauf erreur de ma part), quand je tape 'google.com' dans la barre de Chrome, ca va directement chercher "https://www.google.com" alors que quand je tape "lafibre.info" ca va chercher "https://lafibre.info/" qui fait un redirect 307 sur https://lafibre.info (on peut voir ca sous F12 notamment).
Ils ont 'codé en dur" pour google.com ou un truc m’échappe ? (ou c'est un effet de bord de HTTP/2 et QUIC?).
-
Quand/si les navigateurs utiliseront HTTPS par défaut ca ira mieux non ?
Quand une grande majorité de sites seront 100 % en HTTPS tu veux dire?
On risque d'attendre encore une peu.
Même des banques n'y sont pas!
-
Les listes de Google sont traitées spécifiquement des chrome (avec information remontée si l'autorité de certification du site n'est pas la bonne)
Il faudrait tester avec d'autres sites comme twitter, pour voir si c'est lié à la liste de sites HTTP Strict Transport Security codé dans le navigateur. (J'imagine que Twitter y est)
-
La liste de Google Chrome contient plus de 2200 noms de domaine :
https://code.google.com/p/chromium/codesearch#chromium/src/net/http/transport_security_state_static.json&l=180
(J'imagine que Twitter y est)
{ "name": "twitter.com", "mode": "force-https", "pins": "twitterCom" },
{ "name": "www.twitter.com", "include_subdomains": true, "mode": "force-https", "pins": "twitterCom" },
{ "name": "api.twitter.com", "include_subdomains": true, "pins": "twitterCDN" },
{ "name": "oauth.twitter.com", "include_subdomains": true, "pins": "twitterCom" },
{ "name": "mobile.twitter.com", "include_subdomains": true, "pins": "twitterCom" },
{ "name": "dev.twitter.com", "include_subdomains": true, "pins": "twitterCom" },
{ "name": "business.twitter.com", "include_subdomains": true, "pins": "twitterCom" },
{ "name": "platform.twitter.com", "include_subdomains": true, "pins": "twitterCDN" },
{ "name": "twimg.com", "include_subdomains": true, "pins": "twitterCDN" },
-
Quand une grande majorité de sites seront 100 % en HTTPS tu veux dire?
On risque d'attendre encore une peu.
Même des banques n'y sont pas!
non quand les navigateurs tenteront d’accéder en 1er a "https://domain.com" quand on tape 'domain.com'...quitte à faire attendre l'utilisateur si le site n'est pas dispo en https...ca forcera peut-etre les éditeurs de site a se bouger.
En pratique de toute façon ca passe (trop) souvent par le moteur de recherche (Google principalement donc): la plupart des gens tapent un nom puis plutôt qu'un domaine. Par exemple pour accéder a la BNP, je tape 'bnp' dans la barre de mon navigateur et ensuite je clique sur la 1ere réponse que Google me fournit: https://www.secure.bnpparibas.net (c'est une réponse personnalisée si je fréquente souvent cette url et c'est donc ok car c'est directement en https). Si je tape bnp.fr ou bnp.com ca mene nulle part de toute facon , la BNP n'a pas les moyens de se payer ses domaines...
si je tape "lcl.fr" ca fait un redirection http->https. la c'est pas good.
-
Les listes de Google sont traité spécifiquement des chrome (avec information remontée si l'autorité de certification du site n'est pas la bonne)
Il faudrait tester avec d'autres sites comme twitter, pour voir si c'est lié à la liste de sites HTTP Strict Transport Security codé dans le navigateur. (J'imagine que Twitter y est)
oui saisir "twitter.com" amène directement a https://twitter.com/ sans passer par la redirection.
-
Nah, franchement ?
Il y avait deux alternatives :
- ou bien tu joues sur les mots ou tu as une terminologie très très particulière
- ou bien tu ne comprends à pas ce qu'est la sécurité du transport, à quoi sert HTTPS et à quoi sert la crypto en général.
J'ai parié sur la première, mais en fait c'était la seconde.
-
non quand les navigateurs tenteront d’accéder en 1er a "https://domain.com" quand on tape 'domain.com'...
Qu'est-ce qui empêche de lancer deux connect(2) à la fois?
quitte à faire attendre l'utilisateur si le site n'est pas dispo en https...ca forcera peut-etre les éditeurs de site a se bouger.
Comme ça l'utilisateur trouvera le navigateur lent et changera de navigateur! :D
En pratique de toute façon ca passe (trop) souvent par le moteur de recherche (Google principalement donc): la plupart des gens tapent un nom puis plutôt qu'un domaine.
Tu arrives à te souvenir de machin.com vs. truc.fr vs. bidule.info ?
Par exemple pour accéder a la BNP, je tape 'bnp' dans la barre de mon navigateur et ensuite je clique sur la 1ere réponse que Google me fournit: https://www.secure.bnpparibas.net (c'est une réponse personnalisée si je fréquente souvent cette url et c'est donc ok car c'est directement en https).
Pour accéder à ma banque, je tape le début du nom dans l'omnibarre et l'historique retrouve l'URL.
Si je tape bnp.fr ou bnp.com ca mene nulle part de toute facon , la BNP n'a pas les moyens de se payer ses domaines...
Ben oui, c'est la crise, on l'a suffisamment répété.
-
- ou bien tu ne comprends à pas ce qu'est la sécurité du transport, à quoi sert HTTPS et à quoi sert la crypto en général.
Et toi, tu n'as pas compris que le transport n'est pas l'applicatif.
La sécurité au niveau 7 n'est pas modifiée par ton transport.
Quand mon serveur web refuse de servir du http (niveau 7), tu peux modifier ce que tu veux dans ton paquet TCP .. cela ne changera rien.
- ou bien tu joues sur les mots ou tu as une terminologie très très particulière
Ben non,.
Tu vas demandé à n'importe qui : quand il se prend une erreur 500 sur google.fr, il ne va pas dire "ha c'est bon, j'suis sur le site de google.fr !".
Quand tu lui dit "il n'y a personne dans cette maison", il ne va pas se demande de qui je parle.
Si tu confonds négation et nom .. tristesse.
[message modéré]
-
non quand les navigateurs tenteront d’accéder en 1er a "https://domain.com" quand on tape 'domain.com'...quitte à faire attendre l'utilisateur si le site n'est pas dispo en https...ca forcera peut-etre les éditeurs de site a se bouger.
Très, très mauvaise idée.
Pour différentes raisons :
- Ralentissement sur la plupart des sites sauf si tu fais deux connexions à la fois.
Augmentation du volume à télécharger et donc ralentissement potentiel si tu télécharges les deux objets HTTP à la fois.
C'est un souci si l'utilisateur se détourne de ce navigateur et préfère un autre qui n'a eu cette "idée géniale"!
- https://example.com ne donne pas forcèment accès au même site (contenu) que http://example.com (assez rare, mais ça existe)
- Problèmes de certificat du serveur TLS : https://example.com peut avoir un certificat
- intrinsèquement invalide sémantiquement : contrainte non remplie
- intrinsèquement invalide sémantiquement pour ce site (le nom de domaine ne correspond pas, très fréquent)
- invalide pour une raison triviale (expiré depuis 2 h)
- ou valide sémantiquement mais invérifiable et inacceptable par le navigateur : l'autorité n'est pas reconnue
tu fais quoi dans ce cas? (Accepter temporairement un certificat invalide conduit à un risque subtil que très peu de gens comprennent.)
- https://example.com est accessible, le certificat est valide, mais tous les liens internes (a href) au site sont en http: et non en relatif; est-ce que tu transformes les liens?
- https://example.com ne répond pas : tu fais quoi dans ce cas?
Est-ce que tu peux répondre à ces trois questions?
-
Très, très mauvaise idée.
Pour différentes raisons :
- Ralentissement sur la plupart des sites sauf si tu fais deux connexions à la fois. Augmentation du volume à télécharger et donc ralentissement potentiel si tu télécharges les deux objets HTTP à la fois.
- https://example.com ne donne pas forcèment accès au même site (contenu) que http://example.com (assez rare, mais ça existe)
- https://example.com peut ne pas avoir un certificat intrinsèquement valide pour le site (le nom de domaine ne correspond pas) ou acceptable pour le navigateur : tu fais quoi dans ce cas? (Accepter temporairement un certificat invalide conduit à un risque subtil que très peu de gens comprennent.)
- https://example.com ne répond pas : tu fais quoi dans ce cas?
Est-ce que tu peux répondre à ces trois questions?
je ferais comme ca:
1. l'utilisateur tape 'example.com'
2. tentative d'acces a https://example.com. si ok et certificat ok j'affiche.
3. si echec immédiat (refus nego, port fermé, etc) ou si ca ne répond pas apres le timeout usuel : une page s'affiche qui indique a l'utilisateur que le site ne répond pas en crypté (ou refuse un acces en crypté) et demande si l'utilisateur veut tenter d'y acceder en non crypté. si l'utilisateur clique 'oui' ca tente d'acceder a http://example.com
s'il le certificat n'est pas valide je présente la même question qu'en 2 en changeant le message.
Si ca concernent des sous-éléments d'une page (images, scripts, iframe, etc) je les refuse s'ils ne sont pas en HTTPS de toute facon.
Chaque fois que l'utilisateur click sur un lien non https ou saisi lui meme un url complet non https il voit l'avertissement et la question s'afficher aussi.
-
Si ca concernent des sous-éléments d'une page (images, scripts, iframe, etc) je les refuse s'ils ne sont pas en HTTPS de toute facon.
Chaque fois que l'utilisateur click sur un lien non https ou saisi lui meme un url complet non https il voit l'avertissement et la question s'afficher aussi.
Super l'ergonomie!
-
Super l'ergonomie!
C'est bien pour ca qu'ils ne le font pas et inventent des trucs complexes comme HSTS et mettent en 'dur' leur sites dans le navigateur ...car sinon le quidam moyen va retourner sur IE ;D
Maintenant si tout les navigateurs faisaient cela... mais la c'est au autre débat.
-
C'est bien pour ca qu'ils ne le font pas et inventent des trucs complexes comme HSTS et mettent en 'dur' leur sites dans le navigateur ...car sinon le quidam moyen va retourner sur IE ;D
Maintenant si tout les navigateurs faisaient cela... mais la c'est au autre débat.
Ben les gens (y compris Mme Michu) récupéreraient une ancienne version (bourrée de failles connues) qui n'aurait pas ce comportement.
Ne jamais sous-estimer la faculté des utilisateurs à contourner les obstacles.
-
Je suis évidemment d'accord sur le principe : n'importe quel site qui traite de données personnelles (n'importe quel site qui demande ne serait-ce que l'adresse email traite de données personnelles) DOIT absolument être sécurisé de bout-en-bout et donc DOIT être en HTTPS.
Ce serait peut être le cas si les freins juridiques n'avaient pas été aussi forts, en considérant la crypto comme un technologie militaire.
-
Il me semble que Firefox a pris la décision de pré-embarquer une grande liste de sites HTST.
N'importe qui peut demander à être inclus dans la liste, j'ai peur que sa taille soit importante.
Google de son coté a une liste de taille réduite avec les sites Google et des sites à risques.
Je ne comprends par pourquoi le système de la liste noire de Google Safe Browsing n'a pas été utilisée pour cela.