Auteur Sujet: HTTP Strict Transport Security (Lu 60437 fois)

corrector · « **Réponse #12 le:** 03 février 2015 à 03:54:48 »

Est-ce qu'il y a une extension Google Chrome pour ajouter le support de Strict-Transport-Security?

corrector · « **Réponse #13 le:** 22 février 2015 à 23:31:02 »

J'ai trouvé cette extension Google Chrome :
KB SSL Enforcer

Cela redirige automatiquement vers HTTPS les sites détectés. On peut ajouter des sites.

corrector · « **Réponse #14 le:** 05 avril 2015 à 05:30:23 »

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.

corrector · « **Réponse #15 le:** 15 avril 2015 à 18:16:37 »

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.

vivien · « **Réponse #16 le:** 15 avril 2015 à 19:06:56 »

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.

jack · « **Réponse #17 le:** 15 avril 2015 à 19:33:06 »

Quel est l'intérêt vis-à-vis d'une configuration correcte côté serveur (http vers https) ?

vivien · « **Réponse #18 le:** 15 avril 2015 à 21:00:28 »

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 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, 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

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.

corrector · « **Réponse #19 le:** 15 avril 2015 à 22:23:58 »

Citation de: vivien le 15 avril 2015 à 21:00:28

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.

corrector · « **Réponse #20 le:** 15 avril 2015 à 22:41:41 »

Citation de: jack le 15 avril 2015 à 19:33:06

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 !

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!

jack · « **Réponse #21 le:** 15 avril 2015 à 22:45:40 »

Citer

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.

corrector · « **Réponse #22 le:** 15 avril 2015 à 23:14:37 »

Citation de: jack le 15 avril 2015 à 22:45:40

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).

Citation de: jack le 15 avril 2015 à 22:45:40

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)

Citation de: jack le 15 avril 2015 à 22:45:40

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.

jack · « **Réponse #23 le:** 15 avril 2015 à 23:23:59 »

Citer

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 !

Citer

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 :

Code: [Sélectionner]

<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.

Auteur Sujet: HTTP Strict Transport Security (Lu 60437 fois)

corrector

Forcer le HTTPS

corrector

Forcer le HTTPS

corrector

KB SSL Enforcer

corrector

HTTP Strict Transport Security

vivien

HTTP Strict Transport Security

jack

HTTP Strict Transport Security

vivien

HTTP Strict Transport Security

corrector

HTTP Strict Transport Security

corrector

Forçage HTTPS

jack

HTTP Strict Transport Security

corrector

HTTP Strict Transport Security

jack

HTTP Strict Transport Security