Google vient d'annoncer qu'il commence à prendre en compte la présence du protocole d'accès HTTPS pour évaluer le score d'un site web (PageRank) :
HTTPS as a ranking signal
J'ai commencé la construction d'un site web pour la première fois et j'ai choisi de rediriger tout le traffic vers l'HTTPS par défaut.
Il n'y a donc aucun accès possible par HTTP.
J'avoue ne pas avoir trop réfléchi à la question et jusqu'ici je n'ai vu que les 3 inconvénients suivant :
A) Il faut un installer un certificat SSL, de préférence un certificat wildcard pour la souplesse
B) Le CPU et la RAM sont plus sollicités
C) Problèmes de compatibilités ou d'accès avec certains navigateurs/logiciels
A et B correspondent à un handicap financier (il faut installer/maintenir le certificat, il faut avoir une machine plus puissante, etc.). C'est quand même assez relatif car les certificats sont devenus assez abordables (parfois même gratuits dans certain cas) et les machines de base semblent assez puissantes aujourd'hui.
Pour C, il semblerait que ce ne soit plus vraiment un problème aujourd'hui.
Si on laisse de côté le problème de fond des certificats SSL (Pourquoi ne prenez pas un certificat SSL/TLS gratuit ou payant de chez Machin qui est par défaut dans un navigateur, quelles raisons peuvent bien retenir de passer son site web au tout HTTPS ? Surtout que l'on a maintenant un réel avantage en améliorant le score du site web.
Par exemple j'ai cru voir qu'à une époque AdSense n'était pas compatible, mais cela a été corrigé.
Avez-vous donc quelques pistes intéressantes pour justifier de conserver un accès HTTP ?
# Noui…
Posté par berumuron . Évalué à 2.
Je suis un peu tiraillé par la question du HTTPS. Si en soit c'est une bonne idée, j'ai l'impression que depuis Snowden on tombe dans une sorte de paranoïa (peut-être justifiée ?) où chaque page web DOIT être accessible en HTTPS. C'est souvent utile certes, mais dans le cas d'un petit site perso j'ai du mal à y voir un grand intérêt (mise à part la zone d'administration). La dernière fois que j'ai écrit un article là-dessus, on m'a fait remarquer (avec raison) que HTTPS a deux fonctions :
Donc voilà : je m'interroge sur l'intérêt du HTTPS dans certains cas, encore plus quand on nous demande (ou force !) d'accepter un certificat auto-signé…
[^] # Re: Noui…
Posté par Adrien . Évalué à 10.
Pour ma part, je pense que HTTPS apporte un mieux, pour pas grand chose, le surcoût CPU/RAM étant très limité
– Avoir du HTTPS partout rend plus difficile l'espionnage de masse, c'est une très bonne chose.
– Avoir du HTTPS partout limite l'utilisation des techniques genre DPI au niveau du FAI, c'est une très bonne chose.
– Dès qu'un site permet une authentification, on devrait obligatoirement avoir du HTTPS, pour le login/mot de passe. Or aujourd'hui la plupart des site perso sont basé sur des trucs genre Wordpress, Mediawiki, etc, qui utilise une authentification. Donc si on met en place HTTPS pour la partie admin, ça ne coûte pas grand chose à faire pour le reste…
Globalement il me semble que la généralisation d'HTTPS favorise un environnement sécurisé, pour un surcoût faible.
Par contre je suis absolument contre le certificat auto-signé. D'un point de vue utilisateur, c'est vraiment catastrophique: les gens prennent l'habitude d'accepter n'importe quoi, ce qui abaisse la sécurité globale.
[^] # Re: Noui…
Posté par Pulco . Évalué à 2.
+1
de plus l'utilisation d'un certificat auto signé pour un site visant une audience publique c'est vraiment se rajouter un handicape inutilement en effrayant le visiteur avec un gros avertissement de sécurité.
L'effet inverse du résultat escompté
[^] # Re: Noui…
Posté par berumuron . Évalué à 2.
Entièrement d'accord avec toi ! Si au moins la mise en place était bien faite, je ne dis pas, mais quand on me demande d'accepter un certificat auto-signé pour lire un article de blog, pour le moment je regarde si je peux y accéder en HTTP mais un de ces jours je ne ferais même plus cet effort.
Perso, j'ai mis en place un certificat (au début auto-signé) que j'utilise uniquement pour la partie administration : c'est le mien, je sais la tête qu'il doit avoir. Le reste du site / blog est en accès par HTTP par défaut. Mais maintenant que j'ai un certificat certifié par StartSSL je continue de même parce que j'en ai marre de cette paranoïa. C'est un peu comme si je devais me déguiser avec un chapeau, des lunettes de soleil, une fausse moustache et un long manteau noir pour aller voir mon voisin… je trouve ça aberrant (mais j'ai bien conscience que c'est parfois nécessaire vu les excès en matière d'espionnage, DPI, etc.).
De plus, si la mise en place d'un certificat est facile pour un domaine, ça commence à devenir galère pour du multi-domaine avec des sous-domaines dans tous les sens…
[^] # Re: Noui…
Posté par desktop.ready . Évalué à 2.
Personnellement je ne me suis même pas posé ce genre de questions philosophiques.
En gros tu peux trouver pleins de bonnes raisons pour utiliser HTTPS (voir plus haut le message d'Adrien par exemple) et quand je demande les inconvénients c'est presque le vide complet.
Donc vu la facilité avec laquelle j'ai mis cela en place et le coût relatif, le choix a été vite fait.
Est-ce qu'un certificat wildcard ne règle pas ce problème ? oui c'est un peu plus cher…
[^] # Re: Noui…
Posté par claudex . Évalué à 8.
Le seul inconvénient du HTTPS, c'est qu'il n'est pas possible de mettre les pages dans un cache de manière globale. C'est-à-dire que si tu un réseau un peu conséquent et que tu veux cacher le JS de Google ou les vidéos Youtube pour tous tes clients, ce n'est pas possible (sans faire du MitM).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Noui…
Posté par ribwund . Évalué à -1.
Si t'as un réseau conséquent, tu contactes le fournisseur de service et il met un cache dans ton réseau.
[^] # Re: Noui…
Posté par claudex . Évalué à 5.
Si tu as un réseau conséquent au point que le fournisseur de service vienne mettre un cache chez toi, c'est que tu es un gros FAI et que tu ne devrais pas faire de cache. Je pensais plutôt des entreprises où il y a beaucoup de personnes derrière une seule ligne.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Noui…
Posté par Kioob (site web personnel) . Évalué à 2.
Pas seulement le cache global, le cache local est également affecté : à moins que ça ait changé, les navigateurs tels que Firefox ne stockent pas sur le disque les fichiers téléchargés en HTTPS.
À chaque redémarrage du navigateur, il faut donc re-télécharger tous les CSS, JS et autres éléments du design des sites.
alf.life
[^] # Re: Noui…
Posté par Kioob (site web personnel) . Évalué à 4.
Et bien je n'avais pas re-vérifier depuis longtemps visiblement, Firefox a effectivement changé de comportement en 2010, car il était le seul à ne pas mettre en cache.
alf.life
[^] # Re: Noui…
Posté par Adrien . Évalué à 5.
Tu n'est pourtant pas à poil dans la rue, mais habillé, et en été ou sur la plage, ça n'est pas pour se protéger du froid ;-)
Préserver son intimité et sa vie privée n'est pas aberrant…
[^] # Re: Noui…
Posté par Zylabon . Évalué à 6.
Il y a une règle empirique que j'essaye de valider sur le net : Toute assertion débutant par « les gens » est une ânerie.
Je suis un utilisateur, et un "gens", et j'apprécie les certificats auto-signés. Comme beaucoup d'autres utilisateurs, et gens, je sais ce que je fais, et je ne m'habitue pas. Merci.
Please do not feed the trolls
[^] # Re: Noui…
Posté par Adrien . Évalué à 6.
Je vais donc appliquer ta règle. Tu as des sources ? des études ? des chiffres fiables ? ou le « beaucoup d'utilisateur », c'est juste aussi bidon que moi ?
Perso je parle d'expérience : au boulot les certificats auto-signés engendrent des réactions mitigées : j'appelle le support pour savoir quoi faire avant de faire une connerie (en général des gens peu à l'aise avec l'outil informatique) au je clique suivant suivant pour avoir la page, sans vraiment comprendre les conséquence. Ceux qui lisent effectivement le message et le comprennent sont une infime minorité (navigateur: firefox).
Effectivement, je n'ai pas d'étude sous la main, uniquement l'approche empirique auprès de plusieurs centaines de gens. Si quelqu'un à des données plus fiable, objective, ça serait intéressant.
[^] # Re: Noui…
Posté par mael . Évalué à 6.
Je suis d'accord avec tous tes points (sauf pour le certificat auto-signé), mais malgré tout, je trouve ça profondément débile que la présence ou l'absence de HTTPS entre en ligne de compte dans le PageRank. La présence ou l'absence de HTTPS ne donne absolument aucune indication sur la pertinence d'un résultat. Or, un moteur de recherche est quand même censé être là pour nous donner une liste de résultats pertinents.
A la limite, pourquoi pas un filtre que l'utilisateur pourrait activer "je souhaite prioriser les sites utilisables en HTTPS"…
[^] # Re: Noui…
Posté par Zenitram (site web personnel) . Évalué à -3. Dernière modification le 08 août 2014 à 16:54.
Pas moi : la présence de HTTPS montre le respect qu'a l'admin des préférences de l'utilisateur. C'est justement une très bonne idée que de regarder comment l'admin prend en compte les utilisateurs.
J'espère que Google fera aussi de même prochainement pour IPv6 (pour la même raison).
[^] # Re: Noui…
Posté par mael . Évalué à 5.
Je vois pas le rapport entre le respect de l'admin et la pertinence de la réponse… Perso, quand je fais une recherche, j'en ai rien à secouer de l'état d'esprit de l'admin et de son soi-disant respect vis à vis de l'utilisateur. Je veux juste un lien vers un site qui donne une réponse pertinente à ma question. Et la présence / absence de HTTPS n'a aucun lien avec cette pertinence.
[^] # Re: Noui…
Posté par iGor (site web personnel) . Évalué à 2.
J'ai cru comprendre que le critère "https" ne devient pas d'un coup LE critère principal :
Source
Voir le billet de Benjamin Sonntag sur le sujet.
[^] # Re: Noui…
Posté par mael . Évalué à 6.
Oui, heureusement, ça n'est pas le critère principal. Mais au fur et à mesure, Google ajoute des critères qui (pour moi) ne sont pas liés à la pertinence : temps de chargement de la page (si un site met 2 minutes à charger, OK, je vais abandonner, mais en soi ça n'est pas un critère de pertinence, et au pire, ça pourrait être un message d'information à côté du résultat), "fraîcheur" de l'information, et maintenant HTTPS… Et peut-être d'autres que je ne connais pas, je ne suis pas spécialiste SEO.
L'entreprise fait ce qu'elle veut, c'est son algo et peut-être que ça plaît à la majorité des clients, mais je trouve que la pertinence de mes recherches sur leur moteur est de moins en moins bonne. C'est peut-être également lié à l'évolution des sites web, je n'en sais rien.
[^] # Re: Noui…
Posté par barmic . Évalué à 1.
La pertinence c'est le fait de te fournir l'information le plus efficacement possible. Si à la question "va-t'il faire beau demain ?", je te répons "oui" est-ce que ce plus ou moins pertinent que si je te fourni l'ensemble des données mesurées ces 5 derniers jours, les statistiques de ces 4 dernières années, les algo d'analyses qui vont avec et que je finis en t'expliquant que ben oui il va faire beau ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Noui…
Posté par mael . Évalué à 2.
Je ne vois pas le rapport avec ce que j'ai écrit ?
[^] # Re: Noui…
Posté par barmic . Évalué à 2. Dernière modification le 11 août 2014 à 14:55.
L'important c'est que le temps entre le moment où tu commence ta recherche et le moment où tu as l'information soit le plus court possible (pas de passer 5 jours de formation pour pouvoir déduire la réponse).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Noui…
Posté par barmic . Évalué à 2.
En fait ce n'est pas si simple. L'objectif de google search ce n'est pas simplement d'être pertinent, mais de fournir la meilleure expérience possible et pour cela de retourner des pages entre autre qui sont accessibles, qui existent encore, qui ne prennent pas 20 minutes à charger, qui ne sont pas vérolées par de vielles XSS, etc
Tu préfèrera avoir une page simple rapide à chargée, en https, accessibles aux handicapés qui donne à peu près la bonne réponse, que la thèse qui donne le résultat précis en 160 pages au format djvu.
Donc oui la frontière entre ce qui est pertinent est ce qui ne l'est pas n'est pas aussi simple que ça. Mais oui Google se sert aussi de son moteur de recherche pour faire évoluer les habitudes (c'est par exemple le cas de l'accessibilité, à la fois ça incite aux bonnes pratiques à la fois c'est bon pour les utilisateurs de google).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Noui…
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Pourtant il mets souvent en avant des sites bloated de js tiers de chez google!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Noui…
Posté par Zylabon . Évalué à 10.
Même avec un certificat auto-signé, la sécurité du https est strictement supérieure à celle du http. Le https avec un certificat auto-signé c'est le chiffrement sans l'authentification (si le certificat est accepté aveuglément), c'est mieux que sans chiffrement ET sans authentification.
En revanche, je reconnais que j'aimerais avoir une grosse icône dans mon navigateur qui me rappelle que le certificat est auto-signé, et je regrette que la case "se souvenir du certificat pour les prochaines sessions" soit cochée par défaut.
Please do not feed the trolls
[^] # Re: Noui…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Pluzun. C'est d'ailleurs un gros problème des navigateurs actuels, pour lequel j'avais ouvert un rapport de bogue sur Firefox : lorsqu'un utilisateur se connecte sur un serveur dont le certificat ne peut pas être validé, il y a un avertissement effrayant, alors que lorsqu'il envoie en clair un mot de passe, ce qui est bien pire, il n'y a aucun avertissement.
[^] # Re: Noui…
Posté par aiolos . Évalué à 3.
Autant, je suis d'accord sur la seconde partie de la phrase (sur le rappel dans le navigateur), autant je ne suis pas d'accord sur la seconde partie ("se souvenir…"). En effet, se souvenir d'un certificat pour un site donné permet d'être averti en cas de changement du certificat, ce qui peut-être un signe de Man-In-The-Middle… Par contre, on peut sans doute améliorer les messages affichés dans ce cas précis.
[^] # Re: Noui…
Posté par Julien L. . Évalué à 2.
Si je me trompe pas j'irais même plus loin: avec un certificat auto-signé, la sécurité du https est strictement supérieure à celle du https, pour l'utilisation https en chiffrement du trafic (pas pour l'authentification)
Pourquoi? Parce qu'on a pas besoin d'un tiers pour générer son certificat ce qui peut être problématique car une partie de la sécurité repose sur ce tiers qui peut être compromis.
Cette conférence est très intéressante sur ce qui concerne le SSL et la sécurité: DEFCON 17: More Tricks For Defeating SSL
[^] # Re: Noui…
Posté par 2PetitsVerres . Évalué à 4.
L'autorité de certification n'a pas à voir la partie privée du certificat, donc il n'y a pas moins de sécurité pour le chiffrement.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Noui…
Posté par oinkoink_daotter . Évalué à 7.
CERTAINEMENT PAS !!!
Sans authentification, tu ne peux garantir la confidentialité. Si t'as de la chance c'est bon, sinon le certificat est forgé par un gars entre toi et le serveur. Et tu es incapable de savoir ce que t'es écouté.
Tu contournes le problème de l'authent par un sybillin "(si le certificat est accepté aveuglément)". Le problème c'est que même en vérifiant les champs du certificat, si tu ne sais pas à quoi t'attendre (en gros avec du certificate pinning ou en connaissant avant les empreintes, ce qui est très rapidement ingérable), tu peux te faire forger TOUS les champs (c'est même faisable à la volée en plus).
[^] # Re: Noui…
Posté par oinkoink_daotter . Évalué à 4. Dernière modification le 08 août 2014 à 17:14.
Il y a de plus un truc pire que l'absence de sécurité qui est le faux sentiment de sécurité. Quand tout passe en clair, on le sait (ou on devrait le savoir), donc on s'adapte. Si le truc dit que c'est chiffré, c'est bon on peut se lâcher. Euh wait, c'est autosigné, donc c'est pas fiable ? En fait, on va rien dire de sensible. Du coup pourquoi chiffrer ?
edit : Shit, ca m'a bouffé un bout du message.
Enfin, aujourd'hui, les gens dont on cherche à se protéger (FAI, grandes noreilles) s'interressent plus à l'existence d'une communication qu'à son contenu. Du coup chiffrement ou pas, ca n'a pas vraiment d'importance.
Pour finir j'ajouterai que pour ces gens la, le certificat autosigné, c'est que du bonheur
[^] # Re: Noui…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Parce que c'est mieux que de ne pas chiffrer du tout. Le chiffrement sans authentification est vulnérable aux attaques par réécriture, mais pas aux écoutes passives.
[^] # Re: Noui…
Posté par oinkoink_daotter . Évalué à 1.
Et donc, on donne son numéro de CB sur un site autosigné ou pas ?
[^] # Re: Noui…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5. Dernière modification le 08 août 2014 à 17:24.
Non, et ça tombe bien, on n'a pas besoin. Les paiements se font sur le site d'un intermédiaire de paiement qui est tout à fait sécurisé.
En revanche, pour, disons, le wiki d'un projet quelconque, il est préférable de transmettre son mot de passe en HTTPS sans authentification du serveur, que de le transmettre en clair, bien que le navigateur rendre cette seconde pratique moins effrayante que la première.
[^] # Re: Noui…
Posté par groumly . Évalué à 0.
Pourquoi?
Les deux sont strictement équivalent d'un point de vue sécurité, tu n'as aucune garantie que quelqu'un dans la chaine n'est pas en train d'écouter le traffic. Un mitma synchrone sur du https auto signe est tres simple a mettre en oeuvre, surtout a l'heure du wifi gratuit un peu partout.
Du https auto signe, ca sert juste a bouffer des cycles cpu et du réseau a faire des handshakes de partout.
Si le deuxième ne fait pas gueuler le browser, c'est parce qu'il n'est pas capable de detecter que t'envoie un mot de passe. Et encore, si tu fais du http basic auth, safari va te prévenir avant d'envoyer le mot de passe sur du http.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Noui…
Posté par Zylabon . Évalué à 7.
CERTAINEMENT !
Par exemple, pour voler mot passe sur une connexion HTTP il faut juste pouvoir écouter ce qui passe. La même sur une connexion HTTPS avec un certificat auto-signé, il faire un vrai man in the middle, se faire passer pour client auprès du serveur (ça, c'est facile) et se faire passer pour le serveur auprès du client, ça suppose de pouvoir être actif sur le réseau, ce qui exclus beaucoup d'attaques. Donc la sécurité qu'offre le HTTPS est strictement supérieure à celle qu'offre le HTTP. Dit autrement, et sauf erreur de ma part, il n'existe aucune attaque qui est possible sur le HTTPS mais pas sur le HTTP. Bref, le HTTPS est plus sûr.
Please do not feed the trolls
[^] # Re: Noui…
Posté par Zenitram (site web personnel) . Évalué à 1.
Ca, OK…
Mauvais codeur, virer ce codeur.
On a inventé certaines choses pour ne pas voler le pass en HTTP…
[^] # Re: Noui…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Ces techniques nécessitent un stockage du mot de passe en clair sur le serveur, et sont donc à éviter.
[^] # Re: Noui…
Posté par Zenitram (site web personnel) . Évalué à 2.
Ah…
"The password is not used directly in the digest, but rather HA1 = MD5(username:realm:password). This allows some implementations (e.g. JBoss[3]) to store HA1 rather than the cleartext password"
J'avais vu d'autres implémentations (Yahoo mail par exemple de mémoire).
Mais de manière générale, oui, c'est un pis aller (on ne peut pas mettre de bcrypt etc…). Faut juste arrêter de croire que "le pass passe en clair" en HTTP : ce n'est pas parfait, mais on peut gérer.
[^] # Re: Noui…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
De sorte que HA1 devient le véritable mot de passe, stocké en clair sur le serveur. Supaire.
[^] # Re: Noui…
Posté par Antoine . Évalué à 2.
Il y a des moyens de contrer ça, en rajoutant un sel qui change régulièrement. Enfin bref, c'est faisable, par contre c'est clair que ce n'est pas la stratégie adoptée par la plupart des sites ou "applications" Web.
[^] # Re: Noui…
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
+1
Et je n'ai jamais compris (bon, j'ai pas trop cherché non plus) le pourquoi de ce choix étonnant, d'autant qu'il me semble que ce choix par défaut ne peut pas être changé dans les préférences.
[^] # Re: Noui…
Posté par jigso . Évalué à 3.
Quid du cache des proxy en HTTPS ? ils sont un peu niqués du coup, non ?
[^] # Re: Noui…
Posté par desktop.ready . Évalué à 0.
Aucun problème de mon côté avec Varnish et l'HTTPS.
[^] # Re: Noui…
Posté par desktop.ready . Évalué à 1.
Zut voir la réponse plus bas : j'ai confondu proxy et reverse-proxy
[^] # Re: Noui…
Posté par rakoo (site web personnel) . Évalué à 6.
J'ai souvent entendu ce "mais de toute façon mon site c'est juste du contenu public, statique". La tu pars du principe que passer en HTTPS a un cout non négligeable. Je pense au contraire que le cout est négligeable (je ne prends pas en compte la cabale mondiale des CA qui est un non-sens total) et qu'il faudrait plutôt expliquer pourquoi rester en HTTP.
Comme dit plus bas, dans le pire des cas, HTTPS non authentifié est moins pire que HTTP tout nu, et pourtant le deuxième ne lève aucun avertissement. Parce qu'en fait, ton problème, c'est pas tant HTTP vs HTTPS: c'est surtout que tu veux pas avoir a cliquer de bouton en plus juste pour lire ce satané contenu. Il faudrait donc inverser la réaction du navigateur entre HTTP tout nu et HTTPS non authentifié: le premier pose de gros problème, le deuxième est potentiellement dangereux mais on laisse l'utilisateur juger si le site est le bon ou pas.
Sinon dans les avantages, j'en vois un autre intéressant quand même: tu es sur que le contenu n'a pas été modifié. Encore une fois, depuis l'endroit ou se situe la clé privée associée au certificat.
[^] # Re: Noui…
Posté par Martin Peres (site web personnel) . Évalué à 3.
Tiens, ça va te plaire: https://www.youtube.com/watch?v=kLt_uqSCEUA
Ça explique comment un homme du milieu peut injecter du js dans tes pages pour ensuite espionner le trafic même quand tu ne passes plus par cet homme du milieu. Si la page était chiffrée, il n'y aurait pas ce problème.
# Objets externes
Posté par tuxicoman (site web personnel) . Évalué à 5. Dernière modification le 08 août 2014 à 12:46.
Et si la moitié du code dudit site web provient d'objets externes (images, video youtube, script JS, etc…) qui sont hebergés sans https. Ca compte comlebt dans le ranking?
[^] # Re: Objets externes
Posté par Julien L. . Évalué à -1.
Déjà tout dépend du type de contenu. Si sur une page en https tu as des images en http elles seront chargées. De mémoire, le CSS aussi. Par contre si c'est un script appelé en http in ne sera pas chargé.
# Idem, pour mon premier site web, tout est en HTTPS
Posté par polytan . Évalué à 2.
Et bien tout comme toi, j'ai lancé mon petit site web perso, et j'ai choisi de tout passer en HTTPS.
Reste l'envoi des emails avec SSL que je ne sais pas faire.
Le site web que j'ai est très simple :
- VPS OVH à 3€/mois
- Serveur courriels
- Owncloud
- Wordpress
- deux ou trois trucs sur les côtés "pour le fun".
Le plus compliqué reste à trouver des certificats SSL abordables. En gros, un certificat pour un nom de domaine coute 5 à 10€ et un wildcard entre 50 et 100€ (après, on peut trouver encore plus cher où seule la garantie si ça foire est plus importante financièrement parlant).
Le seul argument qui tient vraiment la route (je ne dis pas que je suis d'accord avec, je suis même anti-pub et n'hésite pas à payer pour certains sites, mais c'est ce que j'ai lu sur le web) concernant la difficulté d'avoir du HTTPS partout concerne la pub sur les sites web : en effet, peu de vendeur de pub propose du HTTPS.
[^] # Re: Idem, pour mon premier site web, tout est en HTTPS
Posté par berumuron . Évalué à 2.
Tu peux passer par StartSSL qui propose des certificats reconnus gratuits pour un domaine + un sous-domaine. Il y a CACert aussi qui fonctionne un peu différemment (communautaire toussa toussa) mais qui n'est pas aussi bien reconnu par les navigateurs.
[^] # Re: Idem, pour mon premier site web, tout est en HTTPS
Posté par oinkoink_daotter . Évalué à 4.
Pour être exact : qui n'est fourni de base par aucun navigateur vanilla, et qui est donc ajouté manuellement par les distrib, et qui est enlevé par debian depuis Mars 2014.
http://wiki.cacert.org/InclusionStatus
[^] # Re: Idem, pour mon premier site web, tout est en HTTPS
Posté par Cyril Brulebois (site web personnel) . Évalué à 4.
À noter : StartSSL facture la révocation (US$ 24.90), quelle que soit la raison.
(Coucou Heartbleed.)
Debian Consultant @ DEBAMAX
[^] # Re: Idem, pour mon premier site web, tout est en HTTPS
Posté par desktop.ready . Évalué à 0. Dernière modification le 08 août 2014 à 13:29.
Tu n'arrives pas à configurer pour utiliser TLS ?
Je n'ai pas souvenir d'avoir eu beaucoup de difficultés.
Tu peux trouver des certificats wildcard gratuits sous certaines conditions. Par exemple au hasard (je n'ai pas essayé, j'ai juste pris le premier lien sous Google) :
Free SSL Certificates for Open Source Projects
Ah voilà une raison valable ! Comme marqué dans mon journal, AdSense est passé au HTTPS. Je suppose que les autres ne vont pas tarder.
# Consommation ressource
Posté par Zylabon . Évalué à 4.
C'est négligeable, cf : https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
De la crypto lourde c'est rien par rapport à des pages « légère » en php.
Please do not feed the trolls
# Redirection HTTPS
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
Ce qui est une grave erreur. En effet, le visiteur peut ainsi s'habituer à taper l'adresse sans HTTPS et se reposer sur la redirection sans y prêter attention. En cas d'attaque, la première chose que fera un pirate en interception et réécriture sera de faire sauter la redirection en question et de laisser l'internaute rester en HTTP.
Il y a plusieurs alternatives à cette approche dangereuse :
[^] # Re: Redirection HTTPS
Posté par desktop.ready . Évalué à 2.
Je suis un peu mitigé sur l'idée.
Est-ce que tu aurais quelques statistiques sur l'effet de ce genre de politique ?
Il ne me semble jamais avoir vu de site web avec ce genre de système en place, tu as des examples ?
J'avoue y avoir pensé mais avant de mettre une longue durée pour max-age, j'attendais un peu d'avoir les réponses à mes interrogations dans mon journal.
Si quelqu'un arrive avec des raisons valables de garder un accès HTTP, je vais peut-être remettre en question pas mal de choses.
[^] # Re: Redirection HTTPS
Posté par Kerro . Évalué à 2.
Si le pirate est en mesure d'intercepter le flux réseau, alors il fait ce qu'il veut.
Il redirige vers n'importe quel site.
HSTS n'y change rien non plus (pour les nouveaux visiteurs, ça protège tout de même les anciens). Le pirate ne va pas transmettre l'en-tête HSTS donc basta.
Et il fait échouer les requêtes vers HTTPS pour être bien certain que la victime ne puisse pas tomber dessus par hasard. D'ailleurs ça se passe comment pour ceux qui ont déjà visité le site ? Ils peuvent facilement dire au navigateur de passer outre ? Ce serait dommage.
[^] # Re: Redirection HTTPS
Posté par groumly . Évalué à 5.
Oui, enfin a ce compte la, si tu t'adresses au grand public, autant plier les gaules et partir élever des chèvres dans le larzac, je te garantit qu'une grande majorité des gens n'arriveront pas a accéder a ton site.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Redirection HTTPS
Posté par claudex . Évalué à 4.
s/n'arriveront pas/& ni ne voudront/
parce même moi, ça me ferrait chier et je ne continuerais que si j'ai certaines garanties que ça en vaille la peine.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Et si on passait à un truc genre DKIM ?
Posté par Framasky (site web personnel) . Évalué à 1.
Dans le système de signature DKIM, le serveur qui reçoit le mail va aller chercher un élément (je sais pas lequel) dans un enregistrement DNS kivabien pour valider la signature du mail. Du coup, pas d'autorité de certification, pas de frais, pas de "certificat signé par une autorité de certification non reconnue"
Pourquoi on passerait pas à un truc comme ça ? Éventuellement, on pourrait imaginer un système de réplication de l'enregistrement DNS sur un autre domaine DNS, histoire que quelqu'un qui prend le contrôle du DNS ne puisse pas juste remplacer la clé. Ou alors se reposer sur un truc style protocole bitcoin (ou bitcloud ! http://bitcloudproject.org/) pour stocker la clé de validation ?
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Et si on passait à un truc genre DKIM ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
On ne t'a pas attendu pour ça !
https://en.wikipedia.org/wiki/DANE
http://www.bortzmeyer.org/6698.html
https://tools.ietf.org/html/rfc6698
Reste à convaincre les éditeurs de logiciels clients de s'y mettre. Bon courage.
[^] # Re: Et si on passait à un truc genre DKIM ?
Posté par gouttegd (site web personnel) . Évalué à 6.
Ça existe, c’est le DNS-based Authentication of Named Entities. Mais ce n’est ni répandu dans les domaines ni supporté nativement par les navigateurs (je n’en connais aucun qui supporte ça nativement — il y a une extension Firefox, et je suis en train de bidouiller un plugin pour Uzbl).
En plus, ça dépend de DNSSEC, qui lui aussi n’est ni largement répandu ni bien supporté par les clients.
Je crois quand même pas mal à ce système, même si au final je penche plutôt pour une cohabitation entre plusieurs méthodes d’authentification, et laisser le client utiliser celle(s) qu’il veut. Par exemple, sur ma machine j’ai quatre méthodes pour vérifier un certificat :
J’accepte automatiquement un certificat s’il est validé par au moins une des méthodes sans être strictement invalidé par aucune autre.
[^] # Re: Et si on passait à un truc genre DKIM ?
Posté par rakoo (site web personnel) . Évalué à 5.
Comme dit en dessous, c'est DANE. Le problème de DANE est qu'il part du principe que les enregistrements DNS arrivent intacts depuis le NS du domaine jusqu’à chez toi, ce qui est pour le moment hautement illusoire. Il faut utiliser DNSSEC (ou autres) pour acheminer les enregistrements, mains DNSSEC c'est une autre paire de manches a installer et maintenir.
Et bien justement, dnschain permet ça. Le principe est simple: il y a deja des specifications pour enregistrer ses noms de domaines et son identite dans Namecoin. Malheureseument Namecoin c'est son monde a part avec son client specialement fait pour. C'est la que dnschain fait le pont, puisqu'il permet d'acceder aux informations depuis des moyens connus:
[^] # Re: Et si on passait à un truc genre DKIM ?
Posté par Sufflope (site web personnel) . Évalué à 1.
Utiliser du HTTP mitm-able par un nourrisson pour récupérer laborieusement des infos DNS qu'on voulait authentifier, comment dire…
# Serveur Proxy
Posté par Wawet76 (site web personnel) . Évalué à 3.
Un autre inconvénient de l'HTTPS est qu'on ne peut plus utiliser de proxy cache (à moins que j'ai raté un truc).
[^] # Re: Serveur Proxy
Posté par desktop.ready . Évalué à -1.
Même réponse que plus haut : j'utilise Varnish et cela marche très bien avec HTTPS.
J'ai juste mis Nginx devant pour interpréter l'HTTPS et il se débrouille après avec Varnish.
Il y a 2-3 trucs à configurer pour mettre les bons en-têtes mais j'étais loin d'être le premier à faire cela et on trouve pleins d'explication sur internet.
[^] # Re: Serveur Proxy
Posté par Spack . Évalué à 3.
Le problème est plutôt du côté client. Un service proxy en coupure n'a aucun moyen de mettre en cache les connexions HTTPS. Or ceci est assez utile lorsque l'on veut économiser de la bande passante.
[^] # Re: Serveur Proxy
Posté par desktop.ready . Évalué à 0.
Ah j'ai confondu proxy et reverse-proxy, c'est pas la même chose effectivement.
[^] # Re: Serveur Proxy
Posté par steph1978 . Évalué à 3.
J'ai croisé, en entreprise, des proxies qui forgeaient des certificats à la volée pour les sites en https. L'autorité de certification était ajoutée au master du poste utilisateur dans le navigateur par défaut (IE ou FF dans mes cas).
Cela n'était détectable que dans un navigateur vanillia, genre portable FF. Très dangereux car dans un cas, le proxy acceptait les certificats auto-signés sans avertir l'utilisateur. Le navigateur ne pouvait pas le détecter puisque le certificat qui lui était présenté était valide.
Je pense que c'est avant tout pour inspecter le flux (fuite d'information tout ça), mais dans cette configuration, rien n'empêche de faire de la mise en cache.
[^] # Re: Serveur Proxy
Posté par Zylabon . Évalué à 2.
Est-ce que c'est légal en France ça ?
Please do not feed the trolls
[^] # Re: Serveur Proxy
Posté par steph1978 . Évalué à 3.
Je me suis aussi posé la question car sans y prêter attention, il est possible de se connecter à sa banque, en clair pour l'administrateur du proxy.
Soit disant que les admins ont pas accès (croix de bois, croix de fer, …) et que c'est dis dans la charte, que je n'ai jamais eu entre les mains en tant que presta.
Bref, ça doit être très limite, mais je pouvais pas trop faire de vague et comme je ne me suis pas faire prendre au piège, j'ai laissé courir.
[^] # Re: Serveur Proxy
Posté par claudex . Évalué à 3.
À mon avis, c'était aussi détectable en vérifiant l'autorité de certification, dans ce genre de cas, les entreprises s'amusent rarement à usurper le nom d'une autre.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Serveur Proxy
Posté par oinkoink_daotter . Évalué à 2.
Non, effectivement. Et en plus, ca ne met pas une partie de la barre en vert pour les gros sites qui se sont payés de l'EV machin.
# Un classement suivant l’autorité de certification
Posté par Flyinva . Évalué à 5.
Je suis dubitatif sur ce nouveau critère de Google. On pourrait imaginer par le suite que Google améliore le page rank des sites qui ont un certificat de telle ou telle autorité et pas d'une autre, ou de ceux qui paient cher leur certificat (au plutôt l'assurance associée) et pas les autres.
Ce qui me gène c'est qu'il y pourrait y avoir une discrimination sur l'argent que tu mets dans un certificat. Du coup, si tu as un super site avec un certificat autosigné, tu pourrais te retrouver au fin fond du classement (en 2ème page ;-) ).
Donc mouais.
[^] # Re: Un classement suivant l’autorité de certification
Posté par desktop.ready . Évalué à -1.
Procès d'intention ?
[^] # Re: Un classement suivant l’autorité de certification
Posté par Ytterbium . Évalué à 1.
Qui te dit que ce n'est pas déjà le cas ?
L'algorithme de Google est complètement arbitraire, et peuvent donc choisir n'importe qui en première position (qui va régulièrement sur la deuxième page de recherches ?), et c'est bien ce qui pose problème, vu qu'ils sont le principal accès aux web aujourd'hui.
# Sympa...
Posté par Zenitram (site web personnel) . Évalué à -1.
Laisser le choix au gens plutôt que leur imposer ta vision du monde?
Sinon, sympa pour les gens qui ont accès qu'au port 80 à cause de proxy nazi.
Question inverse : avez-vous donc quelques pistes intéressantes pour justifier de ne pas conserver un accès HTTP ? Pour la sécurité, c'est mort, te requète HTTP étant acceptée on peut l'intercepter et rediriger autrement.
Pourquoi cette manie d'imposer aux autres sa vision en refusant de laisser un choix?
Il y a 36 solutions pour faire du HTTPS sans imposer (par exemple, la façon dont fait LinuxFr avec un cookie "j'ai déjà été en HTTPS, je souhaite donc de nouveau l'être même si je tape comme un couillon http:// , un petit warning et une offre de passer en HTTPS si HTTP etc…), et quand il y aura moins d'1% d'utilisateurs en HTTP tu pourras te dire que ça ne sert plus…
en attendant, HTTP ne te fait pas de mal.
[^] # Re: Sympa...
Posté par desktop.ready . Évalué à 3.
L'argument se tiendrait si cela avait un impact significatif sur « les gens ».
En pratique j'ai subis le proxy Websense et de mémoire il laissait tranquille le HTTPS.
Il y en a beaucoup des proxy qui filtrent sans discrimination l'HTTPS ?
C'est une question de compromis : combien de personnes je perds à cause de ces proxy nazi et combien de temps je passe à maintenir 2 accès.
J'ai eu le même genre de question lorsque j'ai dû choisir mon hébergement : certains hébergeurs sont bloqués par certains proxy (kimsufi par exemple) mais par contre ils ne sont pas chers.
Si personne n'a de statistiques pertinentes sur le sujet, je suppose que je peux réaliser moi-même l'expérience et voir dans mes logs combien d'accès HTTP ne sont pas suivis par un accès HTTPS.
Ben oui : cela m'évite des efforts pour installer/maintenir.
Pour le moment, je considère que j'y gagne plus (i.e. moins de temps à installer/maintenir) et que j'y perds pas grand chose (les gens qui subissent les proxy nazi).
Le but de ce journal c'est justement de voir si quelqu'un a des données factuelles pour remettre en question mon raisonnement.
Si tu as des sources qui donnent des chiffres à propos de ces proxy nazi, cela m'intéresse beaucoup.
Sinon je verrai par moi-même.
Je ne comprends pas : rediriger vers où ?
Tu veux dire que http://example.com peut être redirigé vers https://example.com.piratage ?
Si oui je ne vois pas en quoi c'est différent de rediriger https://example.com vers https://example.com.piratage
Parce que tout est affaire de compromis ?
Je suis justement à la recherche de bons arguments pour réaliser le meilleur compromis.
Ton argument avec celui plus haut que l'HTTPS n'est pas compatible avec certaines publicités sont les seuls qui répondent vraiment à la question du journal. Par contre c'est relativement vague (pas de données chiffrées) et donc ne fait pas trop pencher la balance.
Je vais rechercher par curiosité si on ne trouve pas des chiffres sur tes proxy nazi.
[^] # Re: Sympa...
Posté par desktop.ready . Évalué à 1.
Et un lien rigolo et relatif au sujet :
Cochons dansants
[^] # Re: Sympa...
Posté par Zenitram (site web personnel) . Évalué à -3.
Par curiosité (bon, OK : pour rigoler), chiffre ce temps.
D'ailleurs, dans ton journal, tu dis que tu continues à maintenir HTTP quand même (redirection, mais quand même présent).
Perso, je m'en fout un peu de ça à partir du moment où ça me coûte pas grand chose à maintenir : question de respect du visiteur sans lui imposer mes choix "pour son bien".
[^] # Re: Sympa...
Posté par desktop.ready . Évalué à -1. Dernière modification le 08 août 2014 à 17:08.
J'ai mis grosso-modo 20-30h au doigt mouillé pour configurer l'HTTPS en partant de zéro (c'est mon premier site web, soyez indulgent).
Ajouter l'accès HTTP en parallèle me prendrait je pense la moitié du temps.
Mais c'est surtout la perte de la simplicité de mon site dont j'ai peur. Et il sera plus dur à administrer.
La maintenance de l'accès HTTP c'est un peu plus qu'une simple redirection dans mon cas.
Par exemple j'ai un proxy cache comme Varnish et il faudrait que je modifie la ré-écriture des en-têtes proprement (actuellement fait dans Varnish) et que je voie comment le backend doit gérer les cookies (j'ai activé l'option "cookie via HTTPS seulement" car c'était plus simple).
Je ne dis pas que ce ne serait pas plus facile pour toi ou pour des administrateurs expérimentés. Mais bon comme c'est mon premier site web je suis allé au plus simple.
Tu vois bien que tu fais ce compromis toi aussi « à partir du moment où ça me coûte pas grand chose à maintenir ».
Dans mon cas, je dois être moins expérimenté donc cela me coûte beaucoup.
[^] # Re: Sympa...
Posté par Zenitram (site web personnel) . Évalué à -3. Dernière modification le 08 août 2014 à 17:23.
Euh…
Euh… (bis)
[^] # Re: Sympa...
Posté par desktop.ready . Évalué à -1.
J'ai pas compris
[^] # Re: Sympa...
Posté par Antoine . Évalué à 9.
S'ils n'ont pas accès à Internet, c'est la faute au proxy, pas aux fournisseurs de services qui tournent ailleurs que sur le port 80.
# IPv6
Posté par Gof (site web personnel) . Évalué à 4.
J'espère qu'il compte aussi l'accès via IPv6 pour leur ranking…
(Je dis ça car mon site est accessible via IPv6, mais pas via HTTPS :-) )
# et dans tous ces commentaires
Posté par maboiteaspam . Évalué à -7.
à aucun moment personne ne s'offusque de ce monde de merde où il faut protéger jusqu'à son site web perso pour être visible.
bran****tte intellectuelle du vendredi soir ? Expliquez moi …
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.