Une des solutions qu'ont les crackers pour contourner cette sécurité est de s'insérer entre le client et le serveur. L'internaute demande d'abord une page web sans préciser au premier abord s'il désire une page sécurisé. Ensuite, éventuellement, le site transfère cette connexion (http) vers une connexion sécurisée (https). Le cracker peut dans ce cas s'insérer entre ces deux étapes, on appelle ça Attaque de l'homme du milieu. Un autre moyen possible est d'utiliser les failles des navigateurs web. Ceux-ci, afin d'être compatibles avec les sites qui n'utilisent pas le https correctement, se compromettent en laissant passer des erreurs. Par exemple, le cracker crée un certificat auto-signé, le navigateur web propose à l'utilisateur d'accepter ce certificat en le mettant en garde, et en cas d'acceptation envoie l'internaute sur une page qui peut ne pas être bien sécurisé. Sinon, sans en venir à "forcer" l'utilisateur à passer en http, certains sites (comme gmail), pour être compatible avec les versions http et https, mémorisent les identifiants de session dans des cookies non sécurisés. Le cracker peut alors récupérer les information sur une simple requête http au site.
Depuis 2008, deux chercheurs en informatique, Collin Jackson et Adam Barth (Université de Standford), proposent une alternative pour sécuriser les sites web : ForceHTTPS (voir leur article ForceHTTPS: Protecting High-Security Web Sites from Network Attacks). Avec un cookie ForceHTTP intégré à un site web, le propriétaire du site demande aux navigateurs web de traiter des erreurs HTTPS comme des attaques, et non comme des erreurs de configuration. Ce petit détail change un certain nombre de choses. Une connexion HTTP normale est automatiquement redirigée vers du HTTPS (et donc, à aucun moment, il n'y a eu connexion au site de manière non sécurisée). Toute erreur TLS met fin à la session. Toute tentative d'insérer du contenu non sécurisé au site se termine en erreur réseau.
Cette idée a germé dans l'esprit des développeurs et de là est né HTTP Strict Transport Security (HSTS). Cette amélioration est déjà accessible via une extension pour Firefox (HTTPS Everywhere), mais aussi, et surtout, mozilla a annoncé il y a quelques semaines que HSTS sera présent dans le futur Firefox 4. Voilà qui méritait d'être noté.
Aller plus loin
- Annonce de Mozilla (14 clics)
- Explications par Mozilla (20 clics)
- Publication d'origine (1 clic)
- Dernière révision de HSTS (13 clics)
- HTTPS Everywhere (13 clics)
# Certificat auto-signé
Posté par Anonyme . Évalué à 10.
Même en tant qu'utilisateur c'est lourd, beaucoup de site sur le logiciel libre utilisent des certificats auto-signés, et voir ces erreurs en permanence finit par la banaliser et finit par faire en sorte que lorsqu'on est face à un véritable problème de sécurité, on y fera probablement pas attention...
[^] # Re: Certificat auto-signé
Posté par Cyril Pascal (site web personnel) . Évalué à 5.
- soit tu surfes sur un site qui utilise HSTS, alors il n'enverra jamais de requête sur HTTP mais que sur HTTPS, et là il sera très strict
- soit tu surfes sur un site qui ne l'utilise pas (pour les applications non-critiques comme tu dis) et le comportement deviendra un comportement normal
Chrome, qui utilise apparemment aussi cette fonctionnalité, a aussi une liste statique de serveurs qui utilisent le HSTS, pour éviter de se faire attaquer la première fois qu'on visite le site (l'information est transmise normalement avec un header sur le site HTTP, donc facilement manipulable par une attaque man in the middle, ou encore un virus).
Cf : http://sites.google.com/a/chromium.org/dev/sts
[^] # Re: Certificat auto-signé
Posté par Larry Cow . Évalué à 2.
Tu es certain? Parce que ton lien indique le contraire, et ce que j'ai lu sur le sujet jusqu'ici aussi.
An HSTS enabled server can include the following header in an HTTPS reply:
Strict-Transport-Security: max-age=16070400; includeSubDomains
[^] # Re: Certificat auto-signé
Posté par Boa Treize (site web personnel) . Évalué à 1.
(Ce n'est pas une obligation, car il y a des problématiques de sécurité liées à ce genre de méthode, cf. la note dans la spec.)
Par contre, le serveur ne doit pas donner l'en-tête Strict-Transport-Security dans une réponse HTTP non-sécurisée.
¹ http://tools.ietf.org/html/draft-hodges-strict-transport-sec(...)
[^] # Re: Certificat auto-signé
Posté par Corentin Chary (site web personnel) . Évalué à 2.
Avec firefox ça se script bien, avec IE j'imagine que ça se gère dans l'AD, avec les autres ça doit être faisable aussi.
En tant qu'utilisateur, .. bah .. heu .. tu peux patcher le code pour utiliser tout et n'importe quoi ? :p
[^] # Re: Certificat auto-signé
Posté par Xavier Poinsard . Évalué à 2.
[^] # Re: Certificat auto-signé
Posté par inico (site web personnel) . Évalué à 2.
[^] # Re: Certificat auto-signé
Posté par Larry Cow . Évalué à 2.
[^] # Re: Certificat auto-signé
Posté par Éric (site web personnel) . Évalué à 8.
Moi j'aime bien les pages de Mozilla où ajouter une exception n'est pas une simple validation et où clairement le bouton si on ne réfléchit pas est "je m'en vais".
Pour ce qui est de la banalisation, même avec les pages de Mozilla, on y est déjà.
Je me rappelle à une conférence de développeurs web, probablement des développeurs du haut du panier, des gens qui comprennent, qui savent, et qui font attention.
On avait du wifi prêté pour des ateliers, géré par une école (peut être par l'administration, peut être par des étudiants, on n'en sait rien). Là dessus ils avaient un proxy filtrant aussi le HTTPS (donc cassant les certificats, tous apparaissaient comme des certificats auto-signés).
Et bien ... tous se sont connectés à gmail et à twitter, en validant les erreurs "certificat ssl incorrect". Tous sans exception, j'ai fait un sondage.
Le réflexe est tellement ancré tous se croient plus sachant que le système et que jamais les erreurs du système ne sont acceptées comme bloquantes. Le "Je veux" de l'utilisateur ne s'arrête plus aux "non" du système, quelle que soit la forme qu'on leur donne ou la connaissance de l'utilisateur.
La seule solution que je vois serait de permettre aux navigateurs :
- de faire la différence entre un certificat sans CA de confiance visité pour la première fois (probablement un auto-signé) et un certificat sans CA de confiance pour un site qui était certifié auparavant (probablement un problème de MITM)
- de faire la différence entre un certificat à problème sur une connexion cable habituelle et sur une connexion wifi publique (avec une gravité supplémentaire pour ce dernier cas qui rend plus vraissembable l'attaque)
- d'utiliser un tiers de confiance pour savoir si la signature du certificat auto-signée est la même que celle que les autres ont et ont eu par le passé ou pas (auquel cas si je suis le seul, c'est certainement un MITM)
[^] # Re: Certificat auto-signé
Posté par Aldoo . Évalué à 2.
On pourrait distinguer
1 - banal http
2 - https avec certificat auto-signé inconnu (accepté temporairement après popup)
3 - https avec certificat auto-signé déjà ajouté à la whitelist
4 - https dûment signé
Le passage d'un niveau à un niveau inférieur pour un même domaine devrait faire surgir une alerte.
[^] # mouif
Posté par Gniarf . Évalué à 10.
[^] # Re: Certificat auto-signé
Posté par Zenitram (site web personnel) . Évalué à 7.
Ben moi j'aime pas, car tout ce qu'on cherche à faire c'est d'accéder à ce site alors que ce put**** de navigateur nous donne un labyrinthe qui ne change rien au final.
Chrome n'est pas beaucoup mieux (mais mieux quand même de mon point de vue car il indique la différence entre http signé et auto-signé), il pose une question à chaque fois qu'on redémarre le navigateur, sans prévenir si le certificat a changé ou pas.
Alors qu'on a une solution simple depuis un moment avec SSH par exemple :
- Première connexion, on accepte ou pas le certificat en disant bien que si ce certificat est nouveau, et que donc il faut avoir confiance dans notre liaison. Pas avec des warnings super-méga mechant qui passent pour ridicule (trop gros, ça passe pas). Dans la barre d'URL, mettre une couleur spéciale pour dire que la validation ne s'est pas faite de manière 100% sécure (ça, c'est pour Firefox)
- Connexions suivantes sans questions (ça c'est pour Chrome) si le certificat n'a pas changé (et que la personne a demandé de garder en mémoire le certificat par exemple)
Avec Firefox, tout ce que ça fait c'est d'inciter les gens à cliquer partout où ils peuvent car ils ne comprennent pas le problème avec le texte alarmiste et qu'on file un labyrinthe pour y accéder au site à visiter, et plus tard, ils continuent de cliquer partout sans lire plus car la première fois c'était pour bizarre. Pas sûr que la sécurité s’améliore avec ce système.
Et dans ton exemple, le reproche que je ferai est que le navigateur n'avertit pas que le certificat a changé pour un site déjà visité auparavant.
[^] # Re: Certificat auto-signé
Posté par Moonz . Évalué à 2.
Et j’ajouterai que 95% des sites qui ont un certificat auto-signé sont loin d’être des sites ultra-sensibles. Une popup avec deux boutons continuer/annuler, ok, mais toute procédure plus longue que ça est inutilement chiante.
[^] # Re: Certificat auto-signé
Posté par Éric (site web personnel) . Évalué à 3.
Tout d'abord non, la plupart des gens ne souhaitent pas simplement accéder à ce ** de site. Ils veulent le faire *et* ne pas compromettre la sécurité (sinon autant aller en http simple).
Ensuite non, nous ne sommes pas dans une configuration similaire à SSH. SSH se fait souvent dans des conditions idéales :
- peu de destinations, toutes connues,
- généralement ces destinations sont fortement maitrisées (souvent on est l'administrateur de la machine)
- généralement accédé depuis son poste et d'un réseau connu, maitrisé
- on ne rencontre jamais de nouveau serveur "par hasard" ou par découverte, la liste change rarement
- si le serveur ssh change de certificat on le sait, on sait facilement que c'est anormal dans le cas contraire
- on s'adresse à des utilisateurs tous très avertis
Là côté web c'est tout le contraire :
- il y a facile une centaine de destinations même pour l'utilisateur de base
- aucune n'est maitrisée (mais alors *pas* du tout)
- pas si rarement accédées en situation de mobilité, à partir de réseaux non contrôlés
- on découvre fréquemment de nouveaux serveurs, qu'on ne connait pas auparavant, la liste change souvent
- on ne sait jamais si un nouveau certificat est normal ou s'il est révélateur d'une malveillance
- on s'adresse en partie à des utilisateurs qui n'y connaissent rien (voire pire : qui se méprennent)
Et ça change tout.
- On me signale par mail un problème avec mon compte en banque, je vais sur le wifi du mac do avec mon téléphone portable, c'est ma première connexion au site avec ce téléphone, je fais quoi ?
- Un copain me conseille un site par mail, j'y vais pour la première fois, le certificat semble auto-signé, je fais quoi ? est-ce normal ?
- Le certificat de Linuxfr.org change, il est auto-signé (imaginons), comment sait-je s'il y a eu un problème ou s'il a réellement changé ?
Le résultat c'est que le comportement par défaut doit bien être d'abandonner. Le fait d'avertir si le certificat a changé n'est pas suffisant. Si on reprend les habitudes de ssh sur le web, on revient rapidement à ce qu'il y avait avant sous Mozilla : aucun labyrinthe, juste une popup qui retient le statut ensuite. C'est simple, excellent, mais finalement la popup ne sert quasiment à rien, on cliquera toujours sur "continuer" ou presque.
On est d'accord que un changement est un critère principal dans l'équation, mais la problématique n'est pas simple pour autant. Dans mon exemple le navigateur avait bel et bien prévenu que le certificat avait changé (puisque tous ont eu le labyrinthe Mozilla, sinon ça serait passé direct). Ca n'a pas suffit.
En fait une des solutions serait d'avoir enfin une autorité de confiance gratuite *ET* qui fait son boulot (donc qui vérifie réellement la propriété du domaine avant d'envoyer le certificat) *ET* qui passe un audit pour être intégrée dans les navigateurs courants (l'intégration de cacert dans les distributions Linux n'a pas été une bonne chose amha)
[^] # Re: Certificat auto-signé
Posté par Zenitram (site web personnel) . Évalué à 4.
Mais à mon avis (que je partage), le fait d'avoir fait un méga-warning pour les sites auto-signés, et mettre ce même warning pour les sites non auto-signés qui passent bizarrement en auto-signé (Man in the middle), n'a fait que tuer la sécurité : maintenant, les gens sont gavés d'alertes de sécurité "à la con" (celui de l'auto-signé qui a toujours été auto-signé, genre... LinuxFr, cacert n'étant pas dans les version officielles des navigateurs), ils cliquent partout pour que ça marche, même quand le comportement est bizarre (gmail qui passe en auto-signé). Même réaction que quand Microsoft a mis l'UAC partout, il a fallu Windows 7 pour qu'ils corrigent un peu le tir.
Trop d'alertes tuent les alertes, et c'est ce qu'il se passe en ce moment. Le mal est fait, les navigateurs sauront-ils corriger le tir?
Une chose est sûre : le comportement actuel des navigateurs ne fait que faire chier, et n'améliore pas la sécurité, au contraire, du fait du trop grand nombre d'alertes faites sans assez de réflexions. Il y a quelque chose à changer.
[^] # Re: Certificat auto-signé
Posté par Éric (site web personnel) . Évalué à 1.
- que le certificat n'a pas changé ce dernier mois (donc pas de compromission du côté du serveur ou du réseau global)
- que le certificat qui est vu d'une autre partie du réseau est bien le même que celui que je vois (donc pas de compromission du côté du réseau que j'utilise)
Avec ces deux critères, un simple warning à la première connexion devrait suffire (sans labyrinthe j'entends)
Ca ne coute pas grand chose à faire, qui se lance ?
[^] # Re: Certificat auto-signé
Posté par PLuG . Évalué à 2.
Quel est l'intérêt d'un certificat autosigné puisqu'il ne permet pas de valider l'identité du serveur, et qu'il permet de chiffrer la connexion ... mais on ne sait pas avec qui.
A mon sens le problème, c'est plutôt qu'on a pas d'autorité de certification gratuite. Le seul gain de "s'autosigner" c'est les quelques centaines d'euros/ an de certificat.
Or c'est assez simple a faire une autorité de confiance, y' a pas de raison que cela coute cher.
qui se lance ?
[^] # Re: Certificat auto-signé
Posté par Zenitram (site web personnel) . Évalué à 2.
http://www.positivessl.com/ssl-certificate-products/addsuppo(...) est à 10€/an, d'autres sont à 100€/an, je suis perdu dans ces prix totalement différents... C'est quoi la différénce entre un certificat startssl gratuit et un qui coûte plus de 100€/an même en class 1? (et quelle est l'utilité de monter à class 2 pour la sécurité de la communication entre mon navigateur et le serveur, question peut-être con désolé)
[^] # Re: Certificat auto-signé
Posté par PLuG . Évalué à 1.
Pouvoir obtenir un certificat pour un serveur web, en validant uniquement qu'on est bien au bout de "webmaster@mondomaine.com", ce qui est déjà pas mal comme preuve de propriété. On pourrait aussi utiliser les adresses email du whois du domaine... rien de très compliqué.
Dans ce cas, est-ce que les admins de linuxfr.org pourraient nous expliquer POURQUOI ils ne prennent pas un certificat chez startssl ?? Quel serait l'inconvénient par rapport a un certificat autosigné ?? Parceque coté utilisateur ça simplifierai bien la vie !!
quelqu'un pour répondre ?
[^] # Re: Certificat auto-signé
Posté par Bruno Michel (site web personnel) . Évalué à 4.
[^] # Re: Certificat auto-signé
Posté par Zenitram (site web personnel) . Évalué à 1.
En pratique, ça revient exactement au même : méga-warning "attention vous allez avoir les pires trucs si vous faites le labyrinthe qu'on vous met".
Je comprend l'argumentation du pourquoi, mais j'ai bien peur que les bienfaits de l'action (ne pas avoir d'oligopole) ne compense pas les méfaits (inciter les gens à passer outre les warnings sans plus les lire tellement il y en a).
Question con : à ma connaissance, pour être dans les navigateurs il "suffit" d'être audité et montrer qu'on peut être de confiance, plusieurs entités (j'en ai une bonne dizaine encore en enlevant les doublons) sont dans les navigateurs, alors pourquoi pas CaCert au moins dans Firefox et Chrome si admettons Microsoft fait de la résistance? StartCom (StartSSL) a le gros avantage d'être dans les navigateurs par défaut, et donc ne pas afficher les méga-warning. Jusqu'au changement de politique des navigateurs sur le comment alerter sur ce genre de certificat, ça pouvait aller, maintenant avec les méga-warnings c'est plus délicat de continuer comme ça.
[^] # Re: Certificat auto-signé
Posté par Spack . Évalué à 3.
Oui pour être inclus [http://wiki.cacert.org/InclusionStatus], il faut être audité [http://wiki.cacert.org/Audit] mais cela n'est pas une tâche simple [http://wiki.cacert.org/AuditToDo] et chacun à ses propres critères d'inclusion [http://wiki.cacert.org/Audit/CriteriaAlphabetSoup].
Bref un audit n'est pas gratuit et peu avoir un coût très élevé. Il semblerait que les critères de Mozilla soient très élevés [https://www.mozilla.org/projects/security/certs/policy/] et CAcert attend sont inclusion depuis 7 ans déjà [https://bugzilla.mozilla.org/show_bug.cgi?id=215243]. Comparativement, Debian semble avoir inclus CAcert sans trop rechigner [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=213086].
[^] # Re: Certificat auto-signé
Posté par Bruno Michel (site web personnel) . Évalué à 3.
En gros, CaCert ne se considérait pas prête pour l'inclusion et voulait faire une grosse liste de tâches avant de redemander son inclusion. Je sais que depuis il s'est passé pas mal de temps et que la liste de tâches a avancé, mais je ne saurais pas dire quel est son degré d'avancement.
[^] # Re: Certificat auto-signé
Posté par Éric (site web personnel) . Évalué à 4.
Parce que déclarer "je vois le même certificat que toi" n'a pas la même force et ne demande pas la même infrastructure/sécurité que certifier le site.
> Quel est l'intérêt d'un certificat autosigné puisqu'il ne permet pas de valider l'identité du serveur, et qu'il permet de chiffrer la connexion ... mais on ne sait pas avec qui.
La signature de l'autorité de confiance est un moyen d'identifier le site, pas le seul. On peut passer par une certification "de masse" (on sait que le site est le bon parce que la masse déclare qu'il est le bon). On peut aussi certifier par soi même (ce qui est fait pour la plupart des intranet ou applis persos).
Ces moyens ne sont pas forcément plus mauvais que de faire confiance à Verisign qu'on ne connait pas et dont on ne peut pas contrôler la bonne foi ou l'absence de faille.
> Or c'est assez simple a faire une autorité de confiance, y' a pas de raison que cela coute cher.
qui se lance ?
vas voir cacert.org
Mais ce n'est pas si simple. Il va te falloir une infrastructure de sécurité qui convainque tous les éditeurs de navigateur que ta clef maitresse ne sera pas compromise. Il va aussi te falloir assurer que tu ne certifies que le propriétaire du site et pas n'importe qui.
Ca demande une organisation, une infrastructure, et ça coute des sous.
CaCert n'est toujours pas dans Firefox justement pour ça, ils n'ont pas encore pu prouver par un audit qu'ils apportaient toutes les garanties nécessaires (et pas à cause de questions de monopole ou de non-commercial)
[^] # Re: Certificat auto-signé
Posté par DLFP est mort . Évalué à 2.
http://patrol.psyced.org/
DLFP >> PCInpact > Numerama >> LinuxFr.org
# Par défaut ?
Posté par dieppe . Évalué à 5.
Pour ceux qui ont la flemme de cliquer :
"Sinon, dans un autre domaine, ForceTLS risque bien d'être coupé par défaut. Plusieurs sites ne fonctionnent plus et un soucis d'attaque par régression a été soumis à l'IETF qui standardise TLS. Chrome 6 a d'ailleurs fait de même (c'est le même dev qui l'a développé pour les deux navigateurs), le support y a été désactivé par défaut."
Donc, je sais pas ce qu'il en est maintenant, si quelqu'un a une idée...
# En tout cas, ça marche !
Posté par Phil Actaire . Évalué à 3.
D'un autre côté, j'ai testé cette page parce qu'à cause du proxy-facho-mitm-powered du boulot, c'est la seule page sécurisée que je visite ou presque.
En fait, après vérification, c'est pareil sur le site d'addons de Mozilla (qui ne fonctionnait déjà qu'en https avant) et ici même si je passe en https.
# NoScript, l'outil ultime des paranos
Posté par DLFP est mort . Évalué à 9.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: NoScript, l'outil ultime des paranos
Posté par JGO . Évalué à 4.
[^] # Re: NoScript, l'outil ultime des paranos
Posté par DLFP est mort . Évalué à 3.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: NoScript, l'outil ultime des paranos
Posté par JGO . Évalué à 3.
Par exemple :
cd ~/.mozilla/firefox/dx99x99x.default/extensions/https-everywhere@eff.org/chrome/content/rules
$ cat Linuxfr.xml
<ruleset name="linuxfr">
<rule from="^http://(www\.)?linuxfr\.org/" to="https://linuxfr.org/"/>
</ruleset>
La liste est lue au lancement, il faut redémarrer Firefox.
# HTTP->HTTPS
Posté par monde_de_merde . Évalué à 2.
Impossible d'accéder à gmail ou tout autre service qui redirige vers du https...
Et pas un mot de la part de Mozilla quand à la correction de ce problème sur le raport de bug (à part "c'est corrigé, au revoir merci pour le rapport").
[^] # Re: HTTP->HTTPS
Posté par Omnisilver . Évalué à 4.
En gros, c'est corrigé sur le tronc, et ça sera disponible avec la beta 7 (la 6 étant une 5 + quelques corrections de failles de sécurtié qu'ils ont été obligé de de publier plus tôt que prévu). Si tu veux faire du test de version instable et profiter des corrections quotidiennes, je te conseille Minefield, qui intègre la correction depuis au moins lundi.
Si tu veux suivre l'actualité du développement de Firefox 4, je te conseille de suivre le sujet déjà indiqué dans les commentaires précédents sur les forums de geckozone : http://www.geckozone.org/forum/viewtopic.php?f=13&t=7618(...)
[^] # Re: HTTP->HTTPS
Posté par monde_de_merde . Évalué à 2.
Ils ont introduit un bugs, ouf c'est une bêta. Ce bug rend la bêta intestable (alors que c'est son dessein) sur 25% du web (en gros) et ça ne les fait pas bouger d'un poil sur leur planning. Pourquoi le fix n'est pas dans la bêta intercallaire 6 ? Pas de réponse.
J'en ai parler au détour d'un canal IRC avec un développeur de mozilla, qui ne voit pas le problème, pour lui (eux ?) leur communication est exemplaire... Peut être est-ce là une position officielle mais quand même, c'est inapproprié de la part d'un projet qui se dit communautaire, ouvert et défenseur de la bidouillabilité et qui communique autant la dessus.
Le fait que tu donnes un lien vers un obscur forum plutôt qu'un blog un peu officiel pour suivre le développement est significatif de ce que je ressent vis-à-vis de leur mode de fonctionnement.
[^] # Re: HTTP->HTTPS
Posté par GnunuX (site web personnel) . Évalué à 5.
[^] # Canaux de communication de l'information
Posté par Omnisilver . Évalué à 2.
Peut-être qu'au niveau de la communication Mozilla cela gagnerait à être plus clairement dit, mais en tout cas, au niveau de la bidouillabilité, c'est un parfait contre-exemple : le bug a été corrigé rapidement, et les nightly build téléchargeable pour toutes les plate-formes ont donc la correction de bug depuis ce jour, donc le bidouilleur qui veut règler ce problème a très facilement la possibilité d'utiliser Minefield en attendant la beta 7.
Quand à Geckozone, c'est le forum francophone de référence, il existe depuis plus de 7 ans, et c'est l'un des plus important des communautés locales Mozilla (même le plus important d'après mes coups d'oeils du côté espagnol, allemand, et italien). Il est cité comme exemple par David Tenser, membre de la Fondation Mozilla chargé du support utilisateur (cf ses slides lors du Mozcamp Barcelone en 2008 : http://www.mozilla-europe.org/fr/press/2008/10/22/1194-mozil(...) ).
Des membres de Mozilla Europe participent parfois aux sujets sur geckozone (Pascal Chevrel et Paul Rouget notamment).
Et si tu crois toujours que le site est obscur, va sur mozilla-europe.org et cliques sur assistance : http://www.mozilla-europe.org/fr/support/ Quel est le premier lien, en gras ? Les forums de geckozone ... Et le second est la liste de discussion de geckozone, pour ceux qui préfèrent ce moyen de communication.
Est-ce que c'est le fait que le site n'ait pas un domaine en mozilla.org qui te donne l'impression que l'information qui s'y trouve n'est pas fiable ? En quoi un blog donne-t-il des informations plus fiables qu'un sujet de discussion entre passionnés ? Je t'assure que teoli, qui anime le sujet dont j'ai donné le lien ci-dessus, est très pointu et donne des informations encore plus pertinentes que ce que l'on peut lire sur les blogs, étant donné qu'il suite de très près tout l'actualité des développements (les blogs anglophones mais également bugzilla, et il teste toutes les nouveautés sur Minefield).
Enfin, si tu cherches un blog officiel, et que te te serai donné la peine d'utiliser un moteur de recherche, tu serais tombé très vite sur http://planet.mozilla.org/ pour les annonces officielles en anglais, http://planete.mozfr.org/ en français, et en cadeau bonus, je te met le lien vers l'annonce offcielle que tu dis ne pas exister : https://developer.mozilla.org/devnews/index.php/2010/09/13/f(...)
# A quand ?
Posté par ze_lionix (site web personnel) . Évalué à 4.
Fuse : j'en Use et Abuse !
[^] # Re: A quand ?
Posté par Bruno Michel (site web personnel) . Évalué à 4.
# Path spécifique ?
Posté par Jean B . Évalué à 3.
Je suis passé à coté ou ça n'existe pas ?
[^] # Re: Path spécifique ?
Posté par Ellendhel (site web personnel) . Évalué à 4.
Je suis passé à coté ou ça n'existe pas ?
Ça existe comme directive au niveau d'un serveur Apache pour forcer l'utilisation de SSL :
< Directory /srv/apache2/mon-site/mon-repertoire/ >
SSLRequireSSL
< /Directory >
Après, est-ce suffisant pour gérer aussi HSTS ? J'aurais tendance à penser que oui, mais il faudrait tester.
Pour d'autres serveurs web, je serais curieux de savoir s'il y a un équivalent.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.