Commentaires sur : Crashdump.fr passe en AES-256.

Par : Crashdump

Crashdump — Wed, 25 Jan 2012 07:58:14 +0000

Très bonne question ! Tout d’abord je vais répondre a une autre question: Pourquoi permettre la connexion en https ? En ajouter le support du SSL je voulais permettre a ceux qui le veulent d’empêcher qu’on sniffe les contenu auxquels ils accèdent.

Mais il faut aussi savoir que le HTTP/SSL est bien plus consommateur de ressources (CPU et connexions réseau) j’ai donc voulu laisser le choix aux visiteurs de ce site !

Par : HardKor

HardKor — Tue, 24 Jan 2012 14:56:19 +0000

Pourquoi ne pas passer en full HTTPS avec une redirection 301 du http:// vers le https:// ?

Par : Adri

Adri — Thu, 23 Jun 2011 21:44:23 +0000

En effet, il ne s’agit la que de la configuration de WordPress ! La configuration des certificats au niveau service web pouvant différer suivant le daemon choisi: Apache2/Nginx/(IIS?).. etc.

Chez 1and1 je suppose que tu parles d’un hébergement mutualité, donc AMHA, tu devrais trouver une interface similaire à celle d’OVH.

Adrien.

Par : mac Grenoble

mac Grenoble — Thu, 23 Jun 2011 10:23:34 +0000

une chose que je n’ai pas comprise …

nous sommes bien d’accord que ces réglages ne concernent que wp …
il y a la partie serveur derrière à configurer … non ?

j’ai fait cela avec OVH uniquement pour la partie admin et login parcequ’ils proposent cela … j’aimerai faire la même chose avec 1and1 enfait !

Merci

Sébastien

Par : crashdump

crashdump — Sat, 24 Apr 2010 18:16:05 +0000

Le seul module existant https-for-wordpress est completement outdaté.. j'ai tenté de mettre un peu les mains dedans mais ça ne résout pas tout.. Comme par exemple ce plugin de commentaires qui charge son js/css depuis le site du créateur qui n'as pas jugé interessant de mettre a disposition une version https…

Par : DjinnS

DjinnS — Fri, 23 Apr 2010 15:49:20 +0000

Mais, du coup, tu ne gères pas le problème des medias qui sont en HTTP ! Du coup la page n'est pas complétement sécurisée, on n'a pas droit à la superbe barre bleu dans FF … Je sais, je suis confronté au même problème. En pousant plus loin, tout ce que tu vas inclures (images distante, flash sale distant, etc …) devra aussi être en HTTPS.

Il faudrait que les URL sont réécrites, seulement, lorsque le site est en HTTPS.

Peut être un module existe déjà ? (oui j'ai pas encore cherché …)

Par : Adri

Adri — Sat, 04 Jul 2009 07:01:07 +0000

Aye, sûrement une mise a jour de plugin qui a provoqué ça… La solution la plus élégante étant d’utiliser des url relatives – ça n’as pas l’air d’avoir traversé l’esprit de certain devs …
Il faut que je me penche sur du rewriting via apache parce que si je dois modifier les plugins a chaque mise à jour, ça risque de devenir gonflant.
Dès que je trouve une solution correcte je la posterais ici ;)

Par : Xorax

Xorax — Sat, 04 Jul 2009 05:05:43 +0000

Bien vu pour le https !

Je suis aussi en train de le mettre en place mais je me rend compte qu’il va falloir réécrire à la volée toutes les urls… je pensais à un outputfilter sur apache.

Je suis passé hier aprem sur ta page d’accueil https et il me semblait que t’avais bien changé tout les liens ? mais maintenant ils sont tous redevenu normal… j’ai rêvé ???

Par : Adri

Adri — Fri, 03 Jul 2009 14:57:31 +0000

En fait – avec cette manipulation – je ne l’empêche pas de lire le robot.txt, j’utilise simplement deux sources différentes pour un seul fichier, ex:
http://www.crashdump.fr/robots.txt donnera

1
2
3

User-agent: *
Allow: /
Sitemap: http://www.crashdump.fr/sitemap.xml.gz

https://www.crashdump.fr/robots.txt donnera

1 2	User-agent: * Disallow: /

Donc le GoogleBot n’indexera pas la ‘partie’ https (puisqu’il consulte ce fichier avant toute chose).
—-
A mon sens, le deuxième intérêt au Https, c’est le filtrage par contenu, ce qui est rendu bien plus difficile. Il serait dommage de perdre cet atout. Nous ne sommes pas encore en Chine… mais quand je vois ce qui se profile pour nous en république populaire de France, je m’inquiète un peu.

Par : Mr Xhark

Mr Xhark — Fri, 03 Jul 2009 14:49:37 +0000

Je ne pense pas qu’en l’interdisant à lire le fichier robot.txt empeche le duplicate.

L’idéal étant je pense de laisser l’accès HTTPS uniquement pour l’auteur du blog pour éviter en wifi quelques soucis.

Mais pour les visiteurs, forcer le HTTP (et pour les bots).

Pour la détection, une règle de rewrite dans le htaccess autorisant uniquement l’auteur. Si ip dynamique créer le fichier .htaccess via php à la volée avec l’ip récupérée en formulaire

Par : Adri

Adri — Fri, 03 Jul 2009 14:39:25 +0000

@Mr Xhark: Tiens, c’est bien vu, je n’avais pas pensé au duplicate content de Google c’est un coup a plonger dans les abimes du pagerank.. J’en profite pour partager une solution a l’utilisation de deux robots.txt (http/https):
Il suffit d’utiliser les RewriteRules de apache (via un .htaccess ou directement dans le fichier de conf du vhost):

1
2
3
4
5
6

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{SERVER_PORT} ^443$
RewriteRule ^robots\.txt$ robots_ssl.txt [L]
</IfModule>

Et créer un robot_ssl.txt a la racine du site (c’est ce dernier qui sera servi lors d’une requête SSL.)
Quand au contenu du robot_ssl.txt:

1 2	User-agent: * Disallow: /

Par : Mr Xhark

Mr Xhark — Fri, 03 Jul 2009 09:52:27 +0000

Attention tout de même à bien laisser la possibilité de consultation en HTTP, car certains firewall très restrictif (entreprise, cyber, etc.) ne laissent passer que le 80.

Attention également au duplicate content, interdit à Google l’accès en HTTPS, ça évitera au passage la charge CPU :)

Merci pour ton billet !

Par : Petitjean

Petitjean — Wed, 17 Jun 2009 12:48:06 +0000

Okai merci, je vois un peu mieux.
Je me disait bien que les certificats de ce style étaient payant, car il me semble ce sont ceux utiliser pour les paiement en ligne par CB.
C’était assez confus dans mon esprit.
Bonne continuation, et si tu rédige un article sur le sujet il sera le bienvenue je pense ! @+

Par : Adri

Adri — Wed, 17 Jun 2009 08:19:51 +0000

Bonjour petitjean,
L’intérêt (pour un blog comme celui ci) réside dans le chiffrement des données entre le client (toi) et le serveur de telle façon que le contenu de toutes les pages que tu consulte ne sois connu que de toi. Certes, en France et de nos jours l’intérêt est limité mais si l’on pense aux internautes des pays comme la Chine ou la Corée (et j’en passe) l’utilité est avérée.

Pour résumer, ça apporte le chiffrement et l’authentification:
* Login chiffrée (pas de mot de passes/cookies en clair) – la je pense a la protection d’une attaque MITM sur un réseau local/wifi (ndlr: https://www.crashdump.fr/securite/arp-spoofing-arp-cache-poisoning-59/)
* Contenu inconnu pour ton FAI (Les requêtes et les réponses sont chiffrés, ex d’une requête https (http/ssl implicite): 1. La connexion TCP (three-way handshake) 2. le protocole SSL (négociation des clés) 3. requête HTTP dans le canal chiffré établi précédemment.)
* L’authentification du serveur: En vérifiant la validité du certificat on peux très vite savoir si le serveur est vraiment celui attendu par la requête (encore plus évident si le certificat a été signé par une CA reconnue).

Par contre, les inconvénients:
* Il faut avoir son propre serveur (ou alors que l’hébergeur le propose)
* l’Installation est pas toujours évidente.
* Un certificat reconnu.. c’est payant. (voir Gandi.net qui propose en ce moment un certificat offert a chaque nouvel achat/renouvellement de domaine)
* La charge serveur est plus importante (le CPU est bien plus sollicité a chaque requête)

Du coup ta question m’interpelle, je vais peut être écrire un billet sur ce sujet.. en espérant avoir répondu a ta question pour le moment.

Par : Petitjean

Petitjean — Wed, 17 Jun 2009 07:47:59 +0000

Salut,
je suis étudiant en 2ème année bts info industriel.
J’aime bien consulter ton site, les articles sur la sécu sont vachement intéressant.
Par contre pour cette article, est ce que tu peux expliquer un peu a a quoi sa sert de mettre son site en « https ».
Un ou deux exemple.
Car j’ai déjà entendu parler un peu du SSL mais rien de plus, et sa m’intéresse.
@+
Et bonne continuation

Par : Adri

Adri — Wed, 17 Jun 2009 07:33:37 +0000

Je viens de finir de régler un des plus gros problèmes du passage de WP en https: les plugins ! Il se trouve que pas mal de developpeur n’utilisent pas les variables globales (siteurl, wpurl, url) du cms et implémentent des requêtes du genre http://x.x/truc.css .. ce qui fout un peu en l’air la beauté de la chose.
Après réécriture de quelques uns de ces plugins.. si vous développez des plugins pour wp, ce message est pour vous: « S’il vous plaît, pensez a ça la prochaine fois. »