La Fibre
Télécom => Réseau => 
Protocoles réseaux sécurisés (https) => Discussion démarrée par: vivien le 08 juin 2012 à 08:09:01
-
* À ce sujet, ça serait pas mal que lafibre.info se dote d'un certificat TLS (on peut en obtenir gratuitement).
Tu pourrais m'en dire plus ?
Pour moi si on ne payait pas on se retrouve avec les messages du navigateur qui prévient qu'on est sur un site sécurisé suspect, le navigateur demande d'autoriser le certificat après lecture d'un long message qui décourage 90% des personnes.
Proposer LaFibre.info en https me semble tout à fait réalisable.
-
Qui fait peur surtout à 90% des personnes
-
Plusieurs associations à but non lucratif se sont montées de par le monde afin de devenir autorités de certification.
Elles distribuent des certificats gratuitement (sous certaines conditions).
C'est par exemple le cas de http://www.cacert.org (http://www.cacert.org).
La seule "grosse" contrainte avec eux, c'est la durée de validité réduite du certificat (6 mois), mais rien n'empêche de le renouveler.
-
* À ce sujet, ça serait pas mal que lafibre.info se dote d'un certificat TLS (on peut en obtenir gratuitement).
Il y a des solutions pour valider les clefs auto-certifiées :
- Perspective
- Convergence
- utiliser le mode de passe de l'utilisateur pour authentifier le site
-
Quand je vais sur https://www.cacert.org/ (https://www.cacert.org/) j'ai justement le message que je ne souhaites pas (avec Firefox 13) :
(https://lafibre.info/images/bistro/201206_certification_cacert_org.png)
-
Heu... c'est un gag?
Signature Algorithm: md5WithRSAEncryptionhttp://www.cacert.org/certs/root.txt (http://www.cacert.org/certs/root.txt)
-
J'ai sauté le pas du ssl sur mon serveur a la maison la semaine dernière: https://15-sign.15-cloud.fr (https://15-sign.15-cloud.fr).
Le certificat de 3 ans m'a coûté $23 chez www.CheapSSL.com (http://www.CheapSSL.com) qui revendent des Certificat Comodo pour une fraction du prix sur le site Comodo :D.
J'ai eu mon certificat en ~15 minute et il est parfaitement accepter sur firefox, IE8, Chrome etc.
-
Tirez pas sur l'ambulance, je ne fais que donner quelques pistes. ???
CACert.org est un exemple que j'avais en tête (et sans doute pas le meilleur, effectivement), mais il y a d'autres possibilités.
En pas gratuit, mais accessible et supporté nativement par la plupart des navigateurs : https://cert.startcom.org
-
Pour moi si on ne payait pas on se retrouve avec les messages du navigateur qui préviens qu'on est sur un site sécurisé suspect, le navigateur demande d'autoriser le certificat après lecture d'un long message qui décourage 90% des personnes.
Pas un site "suspect", un site qui envoie un certificat TLS qui n'est pas validé par le client TLS dans sa configuration actuelle parce
- (a) le certificat n'est en lui-même pas acceptable
- il est mal-formé, illisible (grossière erreur de configuration, très rare)
- il utilise une clé très faible (que le client TLS est configuré pour refuser)
- le certificat a expiré, ou bien il sera valide dans le futur (= problème d'horloge)
- le certificat n'indique pas le nom de domaine du site visité (grosse bourde qui arrive parfois à des grosses boites, dont Google)
- (b) le certificat ne peut pas être vérifié :
- le certificat n'est pas signé du tout (très très rare)
- le certificat est signé, mais la signature n'est pas vérifiable parce que le certificat qui l'atteste est :
- toutes les raisons citées en (a) de non-validité d'un certificat
- le certificat qui signe le certificat du site n'est pas autorisé à signer un certificat (n'est pas une autorité de certification)
- l'algorithme de signature n'est pas supporté par le client
- la racine de la chaine de certificats n'est pas vérifiable : la racine n'est pas un CA appartenant au magasin de certificats racines
- le certificat est positivement valide, mais il est révoqué par son CA
- l'existence d'une révocation d'un des certificats n'est pas vérifiable parce que le serveur de statut de révocation du CA :
- n'est pas joignable (souvent le cas derrière un portail captif!)
- renvoie une erreur
et le client est configuré pour vérifier la révocation des certificats (c'était le cas par défaut pour Firefox, ce n'est plus le cas sur les versions récentes)
et le client est configuré pour traiter l'impossibilité de vérifier la révocation comme une cause de certificat invalide (pas le cas par défaut pour Firefox)
La vérification devrait être récursive : chaque certificat intermédiaire devrait être vérifié comme le certificat du site, y compris l'existence d'une révocation. En pratique ce n'est pas fait pour une question de performance.
-
Pour moi si on ne payait pas on se retrouve avec les messages du navigateur qui prévient qu'on est sur un site sécurisé suspect, le navigateur demande d'autoriser le certificat après lecture d'un long message qui décourage 90% des personnes.
Je crois que tu confonds ne pas payer et ne pas faire certifier sa clef : le navigateur proteste parce que la clé fournie par le serveur TLS étant invérifiable, il ne sait pas si la connexion chiffrée est établie avec le serveur TLS correspondant bien au nom de domaine de l'URL et pas n'importe quel autre serveur TLS appartenant à n'importe qui.
StartSSL propose des certificats d'entrée de gamme gratuits pour les serveurs TLS :
StartSSL™ Comparison Chart (http://www.startssl.com/?app=40)
À ce prix là, tu n'as pas droit au joker (*.lafibre.info).
-
J'ai mis en place un certificat auto-signé : https://lafibre.info
-
J'ai mis en place un certificat auto-signé : https://lafibre.info
La page d'accueil rouge de chrome est vraiment repoussante :(
-
Rappelez moi l’intérêt pour un forum d'avoir du https?
il y a des choses sensible dessus?
-
Augmenter le nombre de connexions chiffrées rendant ainsi plus difficile l'analyse statistique des communications.
Si tout ce qui sort de ta machine est du TLS, on ne peut pas déduire quand tu fais quelque chose de sensible.
En prime, cela permet d'augmenter le cout des DPI :)
-
J'ai sauté le pas du ssl sur mon serveur a la maison la semaine dernière: https://15-sign.15-cloud.fr (https://15-sign.15-cloud.fr).
Je viens de faire le test depuis mon domicile avec Ubuntu 12.04 + Chromium 18 => OK (https et cadenas vert)
Avec Ubuntu 12.04 + Firefox 13 (installation par défaut sans modifier les certificats) j'ai le message "Cette connexion n'est pas certifiée" :
Vous avez demandé à Firefox de se connecter de manière sécurisée à 15-sign.15-cloud.fr, mais nous ne pouvons pas confirmer que votre connexion est sécurisée.
15-sign.15-cloud.fr utilise un certificat de sécurité invalide.
Le certificat n'est pas sûr car l'autorité délivrant le certificat est inconnue.
(Code d'erreur : sec_error_unknown_issuer)
A noter que ce n'est pas ton serveur, j'ai le même souci avec ton fournisseur de certificat : https://www.cheapssls.com (https://www.cheapssls.com)
-
Je viens de faire le test depuis mon domicile avec Ubuntu 12.04 + Chromium 18 => OK (https et cadenas vert)
Avec Ubuntu 12.04 + Firefox 13 (installation par défaut sans modifier les certificats) j'ai le message "Cette connexion n'est pas certifiée"
Pas sûr que le problème vienne du certificat (qui est accepté sans broncher chez moi par Iceweasel [la version totalement libre de Firefox utilisée dans Debian] 10).
Le souci pourrait aussi provenir de l'activation par défaut de SPDY dans Firefox 13.
Vérifiable en le désactivant (about:config => network.http.spdy.enabled = false).
Ceci dit, c'est un certificat qui s'appuie sur AddTrust, quii a aussi un passé sulfureux.
Possible que Mozilla (qui s'était fait hacker son certificat addons.mozilla.org l'an dernier) ait purement et simplement décidé de faire le ménage (http://news.cnet.com/8301-27080_3-20103615-245/mozilla-gets-tough-after-digital-certificates-hack/) ...
-
CN = AddTrust External CA Root
OU = AddTrust External TTP Network
O = AddTrust AB
C = SE
Tu as ça dans ton magasin?
-
Le souci pourrait aussi provenir de l'activation par défaut de SPDY dans Firefox 13.
Vérifiable en le désactivant (about:config => network.http.spdy.enabled = false).
J'ai testé en le désactivant : idem
Autre PC avec la même configuration (Ubuntu 12.04 et Firefox 13) : pas de souci
J'ai supprimé mon dossier avec les préférences de mozilla (c'est un firefox qui a subit les différentes mises a jour depuis la version 3.6, le dossier .mozilla faisait 500 Mo !) et cela fonctionne maintenant.
-
Le certificat de 3 ans m'a coûté $23 chez www.CheapSSL.com (http://www.CheapSSL.com) qui revendent des Certificat Comodo pour une fraction du prix sur le site Comodo :D.
C'est ça que tu as acheté ?
C'est effectivement un prix imbattable...
(https://lafibre.info/images/bistro/201206_certificat_ssl_comodo.png)
Pour ceux qui veulent s'amuser, il y a des certificats gratuits pendant 90 jours sur le site de Comodo (http://www.comodo.com/e-commerce/ssl-certificates/free-ssl-certificate.php?track=2736&key5sk1=8f1d9cf12fcfcc3cb4db7885c180b596884743b7&key5sk2=2128&key5sk3=1339264842000&key5sk6=2736&key5sk7=1339264841000&key5sk8=2736&key5sk9=1339264849000&key6sk1=comodo+ssl&key6sk2=FF130&key6sk3=8&key6sk4=en-us&key6sk5=&key6sk6=0&key6sk7=Google&key6sk8=112202&key6sk9=19201080&key6sk10=true&key6sk11=7177a12083fce381c03cd80e6b68d6c80834649b&key7sk1=2&key1sk1=ors&key1sk2=Google&key1sk3=comodo+ssl)
Sinon j'ai rêvé, OVH ne proposait pas des certificats à une époque ?
-
En cherchant un peu, j'ai trouvé des certificats gratuits qui semble fonctionner dans la plupart des navigateurs : Que pensez-vous de StartCom ?
=> http://cert.startcom.org/?lang=fr (http://cert.startcom.org/?lang=fr)
-
Présent dans la plupart des trousseaux de CA.
Il n'y a pas de wildcard pour les certificats gratuits.
-
Que pensez-vous de StartCom ?
=> http://cert.startcom.org/?lang=fr (http://cert.startcom.org/?lang=fr)
C'est Eddy Nigg (https://blog.startcom.org/?page_id=2) qui a déclenché le 1er scandale COMODO en dénonçant publiquement un revendeur véreux. Ce qui n'était pas évident : en dénonçant un concurrent pourri, il prenait le risque de dégrader l'image de l'ensemble des tiers de confiance. Dans ce genre de business personne n'aime critiquer ses concurrents et surtout confrères. C'est un bon point pour StartCom.
Eddy Nigg a aussi abondamment critiqué les mauvaises pratiques des CA, comme de décerner des certificats officiels (liés à une racine officielle) pour des domaines qui n'existent pas ou des adresses IP, deux choses qui ne peuvent jamais "appartenir" à un demandeur. Si un CA veut certifier toto.local, il peut le faire, mais avec un certificat qui n'est pas officiellement accepté par un navigateur.
En fournissant des certificats gratuits, Eddy Nigg s'est attiré les foudres des pères la vertu, croyants du Dieu $$$, qui expliquaient que cela encouragerait le phishing. Il leur a tenu tête. Au dernières nouvelles le phishing se porte bien, il n'a pas besoin de certificats gratuits ou payants (les utilisateurs qui se sont avoir par ces arnaques basiques ne vérifient généralement pas s'ils vont sur un site avec un certificat TLS correct).
Eddy Nigg n'est pas un révolutionnaire (il ne veut pas abolir les CA), mais il parait être quelqu'un qui fait bouger les choses plutôt dans la bonne direction dans le monde très opaque de CA, à partir de là il m'inspire plutôt confiance.
-
Il n'y a pas de wildcard pour les certificats gratuits.
C'est pour ça que je n'avais pas parlé de leur offre gratuite à l'origine.
Mais bon, le wildcard est-il nécessaire ?
-
Le wildcard c'est bien pour certifier les sous-domaines du type "toto.lafibre.info" ?
-
Le wildcard c'est bien pour certifier les sous-domaines du type "toto.lafibre.info" ?
Le wildcard c'est un certificat pour *.lafibre.info qui valide toto.lafibre.info et titi.lafibre.info.
Je pense que tu peux faire signer un certificat avec plusieurs altServerName.
-
Rappelez moi l’intérêt pour un forum d'avoir du https?
il y a des choses sensible dessus?
Des décennies de bridage de l'usage de la crypto, etc. aboutissent à ce qu'on trouve normal de soumettre un mot de passe en clair!
Tous les forum devraient être en HTTPS dès qu'un utilisateur est connecté (pas forcèment en simple consultation anonyme).
-
C'est marrant de lire ca. C'est exactement la raison pour laquel je suis passe sur SSL. Ou TLS, if you please.
Et pour moi, COMODO ou autre je m'en tape, vu que la cles privée reste privée. Ce qui m’intéresse c'est que mon site est encrypte :D.
-
Augmenter le nombre de connexions codés rendant ainsi plus difficile l'analyse statistique des communications.
Si tous ce qui sort de ta machine est du TLS, on ne peut pas déduire quand tu fais quelque chose de sensible.
Il y aurait des choses sensibles, qui méritent qu'on analyse statistiquement les communications, sur lafibre.info?
En prime, cela permet d'augmenter le cout des DPI :)
Augmenter?
Tu crois que le DPI est possible avec TLS? ???
-
Tu crois que le DPI est possible avec TLS? ???
Oui, on arrive à sortir des choses d'une communication TLS.
Ici pour une petite démo :) (http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-google-maps.html)
-
Petite remarque :
Il est évident que tu peux corréler des informations publiques et une session TLS que tu observes : si tu vois que quelqu'un se connecte à lafibre et POST quelque chose (ce qui se voit facilement parce que c'est le seul cas où l'upload est de plus de quelques octets en HTTP), et qu'un message apparait sur le site, alors bingo tu sais qu'il vient de publier un message donc tu sais qui c'est.
Si aucun message n'apparait, essaie de voir si un message a été modifié : où trouve t-on la liste des messages modifiés sur lafibre?
Sinon, bonne chance pour savoir s'il a envoyé un MP ou s'il a utilisé la prévisualisation!
-
On pourrait faire la différence entre envoyer un MP et envoyer un message publique: l'interface est suffisamment différente (la frame de prévisualisation effectivement).
Mais ce n'était pas l'orientation de ma remarque: en http il suffit de lire l'entête, en https il faut jouer avec des analyses de comportements.
Cela n"a pas le même cout ...
-
- StartCom Certification Authority
- StartCom Class 1 Primary Intermediate Server CA
- www.lafibre.info
E = postmaster@lafibre.info
CN = www.lafibre.info (http://www.lafibre.info)
C = FR
Identificateur d'objet (2 5 4 13) = 73RklQnT78nJak3e
Nom alternatif :
Non critique
Nom DNS: www.lafibre.info (http://www.lafibre.info)
Nom DNS: lafibre.info
Bravo!
-
J'ai fait des tests et effectivement IE8 ne met plus d'alerte après avoir fait la mise a jour des certificats racine via Windows upate.
Sous windows XP SP3 avec mise à jour c*des certificats racine, c'est ok :
- IE 8
- Chrome 19
- Opéra 11.64
Par contre, avec Firefox 13 ce n'est pas bon :
(https://lafibre.info/images/bistro/201206_certification_lafibre_firefox_xp.png)
A noter que Firefox 13 sous Ubuntu 12.04 ne pose pas de problème...
-
Le SSL Report de Qualis SSL Labs relève des anomalies dans la chaine de certificats. (https://www.ssllabs.com/ssltest/analyze.html?d=lafibre.info)
Il faut que ton serveur Apache envoie la chaine complète donc StartCom Certification Authority puis StartCom Class 1 Primary Intermediate Server CA puis le certificat de ton serveur.
Cela implique soit remplir SSLCACertificatePath avec un pem contenant les 2 certificats publiques de la CA soit basculer sur un fichier pem complet (contenant les 3 certificats publique) en utilisant SSLCertificateChainFile.
Désactive également les vieux ciphers DES aka:
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
-
SSLCipherSuite Directive (http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslciphersuite)
MAC Digest Algorithm:
MD5 MD5 hash function
Pourquoi "!MD5"???
-
D'après la documentation d'Apache, cela désactive tous les ciphers utilisant MD5 comme algo d'hashage. (https://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslciphersuite)
C'est conseillé après les différentes attaques réussis sur MD5.
Sur une vieille Debian Etch, cela donne les ciphers suivants:
admin@cyteen:~$ openssl ciphers -v 'ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH'
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
-
OK, mais pourquoi?
-
Parce qu'on obtient trop facilement une collision avec MD5 ce qui le rends impropre comme fonction servant à garantir l’intégrité d'une session tls ?
-
À cause des collisions (http://www.win.tue.nl/hashclash/rogue-ca/) :
Our attack takes advantage of a weakness in the MD5 cryptographic hash function that allows the construction of different messages with the same MD5 hash. This is known as an MD5 "collision". Previous work on MD5 collisions between 2004 and 2007 showed that the use of this hash function in digital signatures can lead to theoretical attack scenarios. Our current work proves that at least one attack scenario can be exploited in practice, thus exposing the security infrastructure of the web to realistic threats.
-
Parce qu'on obtient trop facilement une collision avec MD5
Certes.
ce qui le rends impropre comme fonction servant à garantir l’intégrité d'une session tls ?
Plait-il?
Pour avoir une collision, il faut contrôler le contenu! Et surtout connaitre la clef!
À cause des collisions (http://www.win.tue.nl/hashclash/rogue-ca/) :
Our attack takes advantage of a weakness in the MD5 cryptographic hash function that allows the construction of different messages with the same MD5 hash. This is known as an MD5 "collision". Previous work on MD5 collisions between 2004 and 2007 showed that the use of this hash function in digital signatures can lead to theoretical attack scenarios. Our current work proves that at least one attack scenario can be exploited in practice, thus exposing the security infrastructure of the web to realistic threats.
Et?
Je ne vois pas le rapport.
-
N'importe quoi!
Pour avoir une collision, il faut contrôler le contenu!
Et connaitre la clef!
Il faut pouvoir contrôler une partie du contenu.
Ors, justement tu es dans le cas où tu peux modifier les paquets.
De toute façon, c'est une recommandation de l'US-CERT donc appliqué au gouvernement US (http://www.kb.cert.org/vuls/id/836068)
edit: Les éditions ne sont pas indiqué par le forum ...
-
Il faut pouvoir contrôler le contenu que tu veux altérer.
Bon, comme c'est un forum, tu peux en partie contrôler le contenu! Mais pas trop quand même, sauf dans une image peut-être.
Enfin, il est reconnu qu'il n'y a là aucune vulnérabilité.
-
Cacert est au courant: ils ne signent plus de certificats avec md5 ce qui évite l'attaque rogue CA (https://blog.cacert.org/2009/01/356.html)
Mais oui, il devrait changer le certificat intermédiaire.
-
Parce qu'on obtient trop facilement une collision avec MD5 ce qui le rends impropre comme fonction servant à garantir l’intégrité d'une session tls ?
C'est bizarre, quand c'est l'outil que tu as toi même proposé qui le mentionne :
https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Flafibre.info%2F (https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Flafibre.info%2F)
TLS_RSA_WITH_RC4_128_MD5 (0x4) 128
Cet outil ne relève rien d'anormal!
Et tu cites cet outil ne relevant rien d'anormal, ne relevant rien d'anormal.
-
Cacert est au courant: ils ne signent plus de certificats avec md5 ce qui évite l'attaque rogue CA (https://blog.cacert.org/2009/01/356.html)
Mais oui, il devrait changer le certificat intermédiaire.
CAcert is currently still using an intermediate CA that was issued with an MD5 based signature 3 years ago.
Donc en 2006 ils ont joyeusement fait un certificat intermédiaire avec une compression MD5? C'est vraiment n'importe quoi.
Les éditeurs de navigateurs, et autres outils, auraient dû interdire ça depuis des années! >:(
Quelle bande de branleurs! (http://[url=https://lafibre.info/images/smileys/Violence_12.gif]https://lafibre.info/images/smileys/Violence_12.gif[/url])
-
Pas compression, hashage: md5 n'est pas réversible.
Le projet Rogue CA date de 2008 donc en 2006 il n'y avait que des doutes. (http://www.phreedom.org/research/rogue-ca/)
Tient, on disait quoi déjà sur md5 comme fonction de hashage utilisé pour l’intégrité d'une session tls ?
Plus sérieusement, cela fait 3 ans qu'il aurait du révoquer ce certificat intermédiaire.
La racine CACert peut rester en md5 par contre, ce n'est pas important.
-
Pas compression, hashage: md5 n'est pas réversible.
Si tu préfères. (Le terme compression ne signifie pas inversible.)
Le projet Rogue CA date de 2008 donc en 2006 il n'y avait que des doutes. (http://www.phreedom.org/research/rogue-ca/)
"que des doutes", tu plaisantes j'espère!
Déjà en 1993 :
"Collisions for the compression function of MD5", 23 July 1993 (http://www.cosic.esat.kuleuven.be/publications/article-143.pdf)
En 1996 "il n'y avait que des doutes", mais aussi et surtout de la prudence :
RSA's CryptoBytes - Summer 1996 (http://ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf)
The Status of MD5 After a Recent Attack
Conclusions
The presented attack does not yet threaten practical applications of MD5, but it comes rather close. In view of the flexibility of the new analytic techniques it would be unwise to assume that the attack could not be improved.
(...)
Therefore we suggest that in the future MD5 should no longer be implemented in applications like signature schemes, where a collision-resistant hash function is required.
En 2005 des collisions "utiles" sont trouvées :
Colliding X.509 Certificates version 1.0, 1st March 2005 (http://www.win.tue.nl/~bdeweger/CollidingCertificates/CollidingCertificates.pdf)
We announce a method for the construction of pairs of valid X.509 certificates in which the “to
be signed” parts form a collision for the MD5 hash function. As a result the issuer signatures
in the certificates will be the same when the issuer uses MD5 as its hash function.
With this construction we show that MD5 collisions can be crafted easily in such a way that
the principles underlying the trust in Public Key Infrastructure are violated.
Colliding X.509 Certificates based on MD5-collisions (http://www.win.tue.nl/~bdeweger/CollidingCertificates/)
donc l'idée d'une signature basée sur MD5 était morte et enterrée.
En 2008 ça fait déjà 12 ans que l'usage de MD5 n'est pas recommandé, c'est mort-enterré-bouffé-par-les-vers, au point que la plupart des gens pensaient que ça n'existait plus, et tout ce monde est tombé des nues en apprenant qu'un CA fournissait des certificats MD5. À cette époque quasiment personne ne pense que MD5 est encore en vie quelque part.
Tient, on disait quoi déjà sur md5 comme fonction de hashage utilisé pour l’intégrité d'une session tls ?
Oui?
Plus sérieusement, cela fait 3 ans qu'il aurait du révoquer ce certificat intermédiaire.
Au moins ne plus l'utiliser.
La racine CACert peut rester en md5 par contre, ce n'est pas important.
Bien sûr que c'est important!
Il faut interdire l'usage de MD5-RSA, point final.
Et ça fait plus de dix ans qu'on le sait.
-
Le SSL Report de Qualis SSL Labs relève des anomalies dans la chaine de certificats. (https://www.ssllabs.com/ssltest/analyze.html?d=lafibre.info)
Il faut que ton serveur Apache envoie la chaine complète donc StartCom Certification Authority puis StartCom Class 1 Primary Intermediate Server CA puis le certificat de ton serveur.
Cela implique soit remplir SSLCACertificatePath avec un pem contenant les 2 certificats publiques de la CA soit basculer sur un fichier pem complet (contenant les 3 certificats publique) en utilisant SSLCertificateChainFile.
Merci !
J'avais utilisé le ca.pem livré avec Ubuntu Server.
Depuis l'utilisation de ceux de StartCom, plus de souci avec Firefox sous Windows XP.
Pour améliorer SSL report (https://www.ssllabs.com/ssltest/analyze.html?d=lafibre.info), tu me conseilles de rajouter les deux lignes suivantes dans le fichier de configuration d'Apache2 ? (j'ai fait clear cache mais la notation est restée identique)
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
Aujourd'hui, j'ai :
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM
SSLCertificateFile /etc/ssl/lafibre.crt
SSLCertificateKeyFile /etc/ssl/lafibre.key
SSLCertificateChainFile /etc/ssl/sub.class1.server.ca.pem
SSLCACertificateFile /etc/ssl/ca.pem
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
J'ai un peu de mal a comprendre les implications des options des lignes
Actuelle : SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM
Proposée : SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
-
Bien sûr que c'est important!
Il faut interdire l'usage de MD5-RSA, point final.
Et ça fait plus de dix ans qu'on le sait.
Leur racine ne signe qu'une seule clé (la clé privée CA est stocké hors-ligne): le certificat intermédiaire.
Les possibilités de collision sont pratiquement inexistante.
Par contre, il faut que le certificat intermédiaire utilise autre chose que md5.
Pourquoi crois-tu qu'il reste des CA avec une racine en md5 valide dans le CA Store de Windows et Mozilla NSS ?
Je ne suis pas certain de l'intérêt de spécifier "!aNULL".
Cela ne fait pas de mal de spécifier explicitement ce qu'on refuse (ici du TLS sans authentification - miaam le MITM).
@vivien: rajoute le SSLHonorCipherOrder On et relance Apache.
-
Leur racine ne signe qu'une seule clé (la clé privée CA est stocké hors-ligne): le certificat intermédiaire.
Les possibilités de collision sont pratiquement inexistante.
Il me semble qu'aucune collision n'est réalisable dans ce cas là avec les connaissances actuelles, ce n'est pas la question.
Le problème est le support des certificats MD5.
Pourquoi crois-tu qu'il reste des CA avec une racine en md5 valide dans le CA Store de Windows et Mozilla NSS ?
1) Parce que c'est des glandeurs?
2) Parce qu'ils s'en foutent?
3) Parce que c'est un bordel monstre dans ces certificats racines?
Dans tous les cas, c'est inadmissible.
Le support des certificats MD5 devrait avoir été désactivé déjà il y a une dizaines d'années. Un machin qui était considéré comme à ne plus utiliser en 1996!!!
Cela ne fait pas de mal de spécifier explicitement ce qu'on refuse (ici du TLS sans authentification - miaam le MITM).
Je ne vois l'intérêt de refuser le TLS sans authentification/le MITM : qu'est-ce que ça change?
-
@vivien: rajoute le SSLHonorCipherOrder On et relance Apache.
Fait.
Avant :
(https://lafibre.info/images/bistro/201206_sslabs_original.png)
Après :
(https://lafibre.info/images/bistro/201206_sslabs_SSLHonorCipherOrder_On.png)
-
Il ne reste plus que le STS mais je pense que c'est légèrement overkill ici.
Exemple de configuration ici (https://github.com/ioerror/duraconf/blob/master/configs/apache2/https-hsts.conf)
-
Alors, pour le chaînage CBC non sûr, tu fais quoi?
Pourquoi tu ne fais pas ce que j'ai proposé (mettre en priorité les algo RC4)?
Il ne reste plus que le STS mais je pense que c'est légèrement overkill ici.
Exemple de configuration ici (https://github.com/ioerror/duraconf/blob/master/configs/apache2/https-hsts.conf)
Non, vivien a bien précisé qu'il voulait que le site soit aussi accessible en HTTP (ce qui va bien compliquer les choses).
Il reste plein d'autres problèmes :
- contenu HTTP inclus
- liens vers le site en HTTP
etc.
-
Ah, ça change :
TLS_RSA_WITH_RC4_128_MD5 est revenu (OK), mais des méthodes DES (LS_DHE_RSA_WITH_DES_CBC_SHA ...) aussi (pas bon).
-
@vivien: tu as pris la SSLCipherSuite du fichier duraconf ?
-
Je viens de prendre le SSLCipherSuite en suivant l'exemple de configuration :
SSLProtocol
Avant : SSLProtocol all -SSLv2
Aprés : SSLProtocol -all +SSLv3 +TLSv1
SSLCipherSuite
Avant :SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM
Aprés : SSLCipherSuite HIGH:!aNULL:!SSLv2:!MD5:@STRENGTH
La note ne change pas mais la liste des protocole est diminuée :
(https://lafibre.info/images/bistro/201206_sslabs_SSLCipherSuite.png)
Comment supprimer la vulnérabilité "BEAST attack" ?
-
J'ai regardé les notations sur SSL labs (https://www.ssllabs.com/ssltest/analyze.html?d=lafibre.info) pour quelques sites de e-commerce et c'est une catastrophe !
Un exemple : (AuchanDirect a la même note)
(https://lafibre.info/images/bistro/201206_sslabs_grosbill.png)
Les banques, c'est un peu mieux.
-
J'ai regardé les notations sur SSL labs (https://www.ssllabs.com/ssltest/analyze.html?d=lafibre.info) pour quelques sites de e-commerce et c'est une catastrophe !
Si tu as envie de rigoler/pleurer/hurler un bon coup, teste sfr.fr.
La classe internationale ...
Et authentification.numericable.fr, avec son certificat expiré depuis 18 mois, c'est pas mal aussi.
(https://lafibre.info/images/altice/201206_qualys_ssl_labs_sfr.png)
-
vivien, pour la nième fois :
- ça ne sert à rien d'exclure les chiffres utilisant MD5
- il faut privilégier RC4
Je ne sais pas comment je devrais le dire...
-
RFC 2246 - The TLS Protocol Version 1.0 (http://www.ietf.org/rfc/rfc2246.txt)
The following cipher suites are used for completely anonymous
Diffie-Hellman communications in which neither party is
authenticated. Note that this mode is vulnerable to man-in-the-middle
attacks (...)
CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
donc il est inutile de supprimer ces méthodes sur le serveur!
EDIT : citation clarifiée
-
Leur racine ne signe qu'une seule clé (la clé privée CA est stocké hors-ligne): le certificat intermédiaire.
Les possibilités de collision sont pratiquement inexistante.
Oui, mais : Sourcerer Says (https://blog.cacert.org/2009/01/356.html#comment-208)
Yes, unfortunately the SSL Blacklist can’t differentiate between old MD5 certificates that are not vulnerable and new MD5 certificates that are vulnerable, so it classifies our class3 certificate as potentially rogue.
donc il ne fallait pas fabriquer ce certificat alors qu'on savait que MD5 était cassé.
C'est comme d'embarquer à bord du Titanic alors qu'il est déjà au fond.
Cela ne fait pas de mal de spécifier explicitement ce qu'on refuse (ici du TLS sans authentification - miaam le MITM).
vivien configure le serveur, pas le client, alors...
-
Avant :SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM
Aprés : SSLCipherSuite HIGH:!aNULL:!SSLv2:!MD5:@STRENGTH
Corrector, privilégier RC4 ca donne quoi comme ligne ?
-
Corrector, privilégier RC4 ca donne quoi comme ligne ?
Quelque chose dans le style:
SSLCipherSuite +RC4:!ADH:HIGH:!aNULL:!SSLv2:!MD5:@STRENGTH
Mais la configuration actuelle est bonne.
Tu peut laisser comme ça.
@corrector,
deprecated ne veut pas dire désactivé.
-
Quelque chose dans le style:
SSLCipherSuite +RC4:!ADH:HIGH:!aNULL:!SSLv2:!MD5:@STRENGTH
Mais la configuration actuelle est bonne.
Tu peut laisser comme ça.
Donc pour toi il n'y a aucune faille dans le fonctionnement CBC de TLS v1?
@corrector,
deprecated ne veut pas dire désactivé.
Certes, je suis le premier à le dire.
Je n'ai pas parlé de "deprecated".
-
Si tu as envie de rigoler/pleurer/hurler un bon coup, teste sfr.fr.
La classe internationale ...
Et authentification.numericable.fr, avec son certificat expiré depuis 18 mois, c'est pas mal aussi.
(https://lafibre.info/images/altice/201206_qualys_ssl_labs_sfr.png)
Bon, suppose que tu es un bot :
- qui visite systématiquement les sites et n'a rien à cacher
- qui n'a pas de magasin de certificats racines ni aucune autre ancre de sécurité
qui n'a donc ni les moyens ni le besoin d'authentifier les serveurs auxquels il se connecte.
Dans ce cas, tu ne voudrais pas utiliser une méthode D-H anonyme (sans clé serveur)?
Je ne vois que des avantages à proposer les méthodes anonymes.
-
J'ai rajouté RC4 en suivant la configuration proposée par thenico :
Voici la conf actuelle :
SSLEngine on
SSLProtocol -all +SSLv3 +TLSv1
SSLCipherSuite +RC4:!ADH:HIGH:!aNULL:!SSLv2:!MD5:@STRENGTH
SSLHonorCipherOrder On
SSLCertificateFile /etc/ssl/lafibre.crt
SSLCertificateKeyFile /etc/ssl/lafibre.key
SSLCertificateChainFile /etc/ssl/sub.class1.server.ca.pem
SSLCACertificateFile /etc/ssl/ca.pem
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
Ca ne change rien pour le "BEAST attack Vulnerable"
-
Je pense qu'il faut indiquer RC4+RSA
Parce que là il n'inclut pas du tout RC4.
-
C'est fait :
SSLCipherSuite +RC4+RSA:!ADH:HIGH:!aNULL:!SSLv2:!MD5:@STRENGTH
-
Toujours aucun RC4 à l'horizon.
Que signifie :@STRENGTH?
Où est la doc de cette commande?
-
Toujours aucun RC4 à l'horizon.
Que signifie :@STRENGTH?
Où est la doc de cette commande?
The cipher string @STRENGTH sorts the current cipher list in order of the length of the encryption algorithm key.
Documentation Apache 2.2 ici (https://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslciphersuite)
Documentation fournis par Adobe (http://livedocs.adobe.com/flashmediaserver/3.0/docs/08_xmlref_296.html)
-
The cipher string @STRENGTH sorts the current cipher list in order of the length of the encryption algorithm key.
Ce qu'on ne veut pas faire, au contraire!
Documentation Apache 2.2 ici (https://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslciphersuite)
Documentation fournis par Adobe (http://livedocs.adobe.com/flashmediaserver/3.0/docs/08_xmlref_296.html)
On parle d'Apache ou d'Adobe ici?
Cette doc Apache ne mentionne pas @STRENGTH.
Je propose :
SSLCipherSuite RC4+RSA
et basta!
-
Je passais un lien vers la doc d'Adobe parce que c'est le même code derrière.
nico@Gallifrey:~$ openssl ciphers -v 'RC4+RSA'
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
Juste NON !
SSLCipherSuite +RC4+RSA:!ADH:HIGH:!aNULL:!SSLv2:!MD5 à la rigueur.
-
Cela ne fait pas de mal de spécifier explicitement ce qu'on refuse (ici du TLS sans authentification - miaam le MITM).
Si le MITM est possible, ça ne sert à rien de l'interdire!
-
Si le MITM est possible, ça ne sert à rien de l'interdire!
Sauf que la tendance est à la sauvegarde des caractéristiques des sites justement pour éviter cela.
-
Sauf que la tendance est à la sauvegarde des caractéristiques des sites justement pour éviter cela.
Comment ça marche?
-
Comme pour le STS, la première fois que tu te connecte à un site en HTTPS, tu stocke les ciphers autorisés(et la chaine de certification au passage).
Aux visites suivantes, tu compares ce que tu as maintenant à ce que tu as eu dans le passé.
Si cela ne matche pas, tu soulève une alerte.
-
"Kx=RSA(512)" ça veut dire que la clé RSA fait 512 bits?
-
Bon, suppose que tu es un bot :
- qui visite systématiquement les sites et n'a rien à cacher
- qui n'a pas de magasin de certificats racines ni aucune autre ancre de sécurité
qui n'a donc ni les moyens ni le besoin d'authentifier les serveurs auxquels il se connecte.
Dans ce cas, tu ne voudrais pas utiliser une méthode D-H anonyme (sans clé serveur)?
Non, parce qu'en bon bot qui se respecte, je ne broute les sites en https que si j'y suis contraint.
Pas le cas chez SFR, donc aucun intérêt.
Accessoirement, il me semble bien que les bots de Google font de la vérification de certificats ...
-
SSLCipherSuite +RC4+RSA:!ADH:HIGH:!aNULL:!SSLv2:!MD5 à la rigueur.
C'est fait !
C'est toujours "BEAST attack Vulnerable"
-
Et avec :
SSLCipherSuite RC4+RSA:!ADH:!aNULL:!SSLv2
-
SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5
Comme ça, les clients voulant du plus costaud peuvent choisir.
Au passage, !MD5 désactive SSLv2 :)
-
SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5
Comme ça, les clients voulant du plus costaud peuvent choisir.
NON!
Il ne faut pas que le client puisse choisir autre chose que RC4.
SSLCipherSuite RC4-SHA:HIGH:!aNULL:!MD5
-
SSLCipherSuite RC4-SHA:HIGH:!aNULL:!MD5
C'est mis en place !
Merci thenico, corrector et seb, SSL Labs (https://www.ssllabs.com/ssltest/analyze.html?d=lafibre.info) dit que je ne suis plus vulnérable au "BEAST attack" !
-
Bravo! :)
Reste à passer le site en HTTPS!
Petit up la signature du domaine lafibre.info (info. est signé (http://dnssec-debugger.verisignlabs.com/info)).
OVH : Service DNSSEC (https://www.ovh.com/fr/domaines/service_dnssec.xml)
Disponible sur :
- .eu, .com, .net, .pl [NOUVEAU]
- les extensions Afnic : .fr, .re, .yt, .tf, .wf et .pm
Pas de chance!
-
J'ai mis le site de feu citéFibre (https://lafibre.info/sitecitefibreindex-htm/) en https (lui a l'intégralité du contenu sans appel a http => toutes les images sont en https)
-
En attendant que vivien bascule le site en HTTPS, on peut le faire dans son navigateur avec la fonction HSTS (= HTTPS everywhere).
Pour Chrome :
- aller dans chrome://net-internals/#hsts
- entrer "lafibre.info", cocher "Include subdomains", cliquer sur "Add"
-
Toutes les url http sont modifiées en https ?
sympa !
Il doit y avoir une extension pour Firefox, non ?
-
L'extension NoScript (http://noscript.net/) pour Firefox propose HSTS, et apporte bien d'autres protections hautement configurables. (Il n'existe aucun équivalent de NoScript pour Chrome parce que Chrome ne permet de véritables extensions comme Firefox.)
L'extension HTTPS Everywhere (https://www.eff.org/https-everywhere) est conçue spécialement pour utiliser les sites en HTTPS, même quand le domaine en http n'est pas utilisable en https; anciens exemples (qui ne sont plus vrais) :
- encrypted.google.com (https://encrypted.google.com/) vs. www.google.com (https://www.google.com) (subtilité : https://encrypted.google.com et https://www.google.com ne sont pas tout à fait équivalents (https://www.eff.org/deeplinks/2011/10/google-encrypts-more-searches))
- https://secure.wikimedia.org (https://secure.wikimedia.org/) vs https://en.wikipedia.org (https://en.wikipedia.org)
-
Pour NoScript :
Aller dans Options, dans Avancé, dans HTTPS, ajouter "Forcer les sites suivants à utiliser une connexion sécurisée" : lafibre.info
Zou, ça marche!
(Ce qui ne veut pas dire que le site lui-même ne devrait pas être corrigé!)
-
Salut
J'ai trouvé une astuce pour passer entièrement la fibre en HTTPS (sauf pour l'édition de message)
avec https everywhere il y a possibilité de créer un fichier xml pour réécrire les url en https (je pense que c'est ce qui te manquais corrector)
cf:
https://www.eff.org/https-everywhere/rulesets (https://www.eff.org/https-everywhere/rulesets)
le contenu du fichier xml "lafibre.xml" à créer dans le dossier personnel de firefox (trouvable en rentrant cette adresse dans le champ url: about:support puis dossier de profil et ouvrir.... chez moi "C:\Users\**user**\AppData\Roaming\Mozilla\Firefox\Profiles\jiwyvae6.default\HTTPSEverywhereUserRules")
"
<ruleset name="Lafibre.info">
<target host="www.lafibre.info" />
<target host="lafibre.info" />
<rule from="^http://(www\.)?lafibre\.info/" to="https://lafibre.info/"/>
</ruleset>
"
vérifier que le fichier à bien été appliqué https://lafibre.info (https://lafibre.info) ça doit rediriger vers la version https
a+
-
Une page de comparaison des CA avec les principaux clients supportés :
Comparison of SSL certificates for web servers (https://en.wikipedia.org/wiki/Comparison_of_SSL_certificates_for_web_servers)
-
StartCom est clairement le bon choix. Gratuit et bien supporté.
Sinon, ça vous dirait si dans 1an ou deux je bascule tout en https (qui serait obligatoire, je modifierais la base de données pour que les url des images en dur http soient en https)
-
Aie, RC4 est vulnérable à une attaque par textes en clair connus. (http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html)
Il ne va plus rester grand chose dans les ciphers securisé valide dans tls 1.1 ...
Quel problème?
C'est trop tard, ton navigateur a déjà envoyé en clair les cookies.
Il faudrait rajouter un
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Et espérer que les navigateurs respectent la spec et convertissent tout seul les url http en https ...
(Et encore, j'ai l'impression que smf force un post en http - mais l'implementation sts de noscript workaround cela :) )
-
Il y a une faille dans RC4 a condition d'ouvrir la session au moins 16 millions de fois. Bref, ce n'est pas très facilement exploitable même si l'on sait désormais que ce n'est plus sur à 100%
-
On sait depuis longtemps qu'il y a un problème statistique avec ARC4!
-
Après des difficultés pour renouveler le certificat, en voici un nouveau.
Le retour de SSL Labs (https://www.ssllabs.com/ssltest/analyze.html?d=lafibre.info) :
(https://lafibre.info/images/bistro/201206_sslabs_lafibre.png)
-
Je viens de profiter de ce dimanche matin pour modifier l'intégralité des liens http du forum en https
-
J'espère que tu n'étais pas encore ivre du samedi soir xD
-
Oui il faut mieux avoir les yeux en face des trous pour ce genre de manip.
-
Je préfère faire ça le matin après une bonne nuit au moment où il y a peu de personnes sur le forum si un retour arrière s’avère nécessaire.
N'hésitez pas à me signaler tout contenu http dans des pages https (ça affiche des messages avec Internet explorer pour savoir si l'utilisateur souhaite afficher le contenu non sécurisé avec par défaut une absence des éléments http).
Je suis en train d'essayer que les appels à des vidéos Youtube / Dailymotion se fassent en https et non en http
Il y a aussi des liens vers des pages du forum en http, j'ai bossé plusieurs heures dessus, mais c'est le système d'url rewriting qui pose problème :'(
-
Pour l'instant, tout a l'air de fonctionner.
-
Est-ce que tout le monde confirme qu'il ne se retrouve plus sur la version HTTP quand il clique sur un lien sur la version HTTPS?
-
Non pas de souci de coté là tous les liens sont https.
Par contre quand on fait une recherche sur google, ils renvoient pour l'instant sur la version http pour une grande majorité de pages, donc je ne suis pas authentifié.
Je pense que c'est lié aux cookies sécurisés que j'ai activé :
Activer cette option forcera la sécurisation des témoins (cookies) créés pour les utilisateurs de votre forum. Ne l'activez que si vous utilisez le protocole HTTPS sur tout votre site, faute de quoi la gestion des témoins sera fortement perturbée !
-
idem que toi vivien:
si on rentre https://lafibre.info (https://lafibre.info) on arrive sur la page d'accueil non connecté.
il suffit de cliquer sur n'importe quel lien pour se retrouver connecté!
sinon le navigateur de mon nokia 808 (sous symbian belle fp2) me sort une erreur de certificat
a+
EDIT : restauration du message original après modification systématique par vivien
-
si on rentre https://lafibre.info (https://lafibre.info) on arrive sur la page d'accueil non connecté.
Bien sûr, si lafibre.info est sécurisé, il n'est plus possible d'utiliser son compte en HTTP, c'est le principe même.
sinon le navigateur de mon nokia 808 (sous symbian belle fp2) me sort une erreur de certificat
Quelle erreur?
Si l'autorité n'est pas connue, il faut l'ajouter au magasin de racines.
EDIT : restauration du message après remplacement en masse par vivien
-
Non pas de souci de coté là tous les liens sont https.
Bravo!
Par contre quand on fais une recherche sur google, ils renvoient pour l'instant sur la version http pour une grade majorité de pages
Tu peux mettre une redirection de HTTP vers HTTPS?
la version http pour une grade majorité de pages, donc je ne suis pas authentifié.
Normal.
Je pense que c'est lié aux cookies sécurisés que j'ai activé :
Activer cette option forcera la sécurisation des témoins (cookies) créés pour les utilisateurs de votre forum. Ne l'activez que si vous utilisez le protocole HTTPS sur tout votre site, faute de quoi la gestion des témoins sera fortement perturbée !
Félicitation!
Enfin le site est sécurisé!
-
Tu peux mettre une redirection de HTTP vers HTTPS?
Oui, c'est possible mais je ne suis pas sûr de la syntaxe.
Il faut que je renvoie le port 80 vers un autre hébergement où je mets un fichier .htaccess de ce type :
RewriteEngine on
RewriteCond %{HTTP_HOST} !^lafibre.info$ [NC]
RewriteRule ^(.*)$ https://lafibre.info/$1 [L,R=301]
(là c'est la redirection utilisée quand on tape www devant lafibre.info)
Malheureusement, j'ai des cas à exclure où cela doit être impérativement en http : le serveur SpeedTest
Il faudrait donc dans la règle de redirection exclure les url qui commencent par /pingtest/*
L'intégralité des autres demandes doivent être par contre redirigées en https
Si tu as une idée sur la règle à mettre en place, je suis preneur.
Edit : Migration en full https réalisée : https://lafibre.info/evolution/full-https/
-
Sans rien toucher, la note se dégrade...
Je vais regarder la chose.
(https://lafibre.info/images/bistro/201405_sslabs_lafibre.png)
-
en effet, il faut faire attention a la chaine décrivant les ciphersuites a utiliser.
la meilleure pour l'instant est :
SSLEngine on
SSLProtocol ALL -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
-
Avant :
SSLEngine on
SSLProtocol -all +SSLv3 +TLSv1
SSLHonorCipherOrder On
SSLCipherSuite RC4-SHA:HIGH:!aNULL:!MD5
Maintenant :
SSLEngine on
SSLProtocol ALL -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
Le résultat :
(https://lafibre.info/images/bistro/201405_sslabs_lafibre_2.png)
Merci !
-
de rien ;-)
-
De rien
-
J'ai renouvelé le certificat qui arrivait à expiration dans 14 jours.
Je n'ai pas utilisé le SHA2 pour garder la compatibilité avec les clients Windows XP :
(https://lafibre.info/images/bistro/201406_hash_algorithm_sha2.png)
La note est inchangée sur SSL Lab :
(https://lafibre.info/images/bistro/201406_sslabs_lafibre.png)
-
Bravo pour ces suites de chiffrement, avec ECDHE_RSA, si un service espionne les communications et force vivien à révéler la clé privée (ou bien force de l'hébergeur à transmettre une copie de toutes les données du disque, ou bien obtient cette information par une intrusion), il ne pourra pas utiliser les écoutes qu'il a réalisé pour décrypter les contenus échangés secrets, par exemple les MP.
Lavabit, le fameux service de courriel utilisé par Snowden qui s'est sabordé après avoir reçu l'injonction de révéler les données de Snowden, ne pouvait pas en dire autant! Ce service a été contraint de révéler sa clé privée, ce qui a révélé l'ensemble des échanges de tous les utilisateurs qui avaient téléchargé ou téléversé quoi que ce soit depuis que le service était sur écoute.
-
Il faudrait donc dans la règle de redirection exclure les url qui commencent par /pingtest/*
Je parle ici d'expressions complète, implicitement accrochées des deux cotés "^expression$"
Par définition, la négation d'un expression rationnelle est rationnelle, et le conjonction de deux expressions est rationnelle, donc on doit pouvoir écrire une telle expression.
Pour commencer, la négation de "a" est facile "[^a]". La négation de "ab" est moins simple; en autorisant l'opérateur &, on peut écrire "ab" = "a.&.b" autrement dit "ab" est un texte qui contient "a suivi d'une lettre" et en même temps "une lettre suivi de b".
~(ab) = ~(a.&.b) = ~(a.) | ~(.b)
~(a.) est l'ensemble des textes qui ne correspondent pas à "a" suivi d'une lettre, donc soit une seule lettre soit deux lettres dont la première n'est pas "a" :
~(a.) = .|((~a).) = .|([^a].)
~(.b) = .|(.(~b)) = .|(.[^b])
donc ~(ab) = .|([^a].)|.|(.[^b]) = .|([^a].)|(.[^b])
c'est à dire un texte d'une lettre ou ne commençant pas par "a" ou ne finissant pas par "b"
Pour une expression contenant "a" : ".*a.*" la négation est facile
~(.*a.*) = (~a)* = [^a]*
Pour une expression ne contenant pas "ab", vous écrivez l'automate non déterministe qui reconnait l'expression ".*ab.*" il a 3 états (s1 : initial, s3 : final), les transitions sont :
s1 : a -> s2 ; . -> s1
s2 : b -> s3 ; . -> s2
s3 : . -> s3
ensuite vous le transformez en automate déterministe S, il a 3 états (S1 : état initial, S3 : état final), les
S1 : a -> S2 ; [^a] -> S1
S2 : b -> S3 ; a -> S2 ; [^ab] -> S1
S3 : . -> S3
On prend la négation c'est à dire l'automate déterministe dont les états finaux sont complèmentaires (S1 : état initial, {S1,S2} : états finaux).
Ex correspond à l'expression de l'état Sx
E1 = |((a+[^ab])*[^a])
E2 = ((a*[^ab])*[^a])a*
on obtient donc |((a+[^ab])*[^a])|((a*[^ab])*[^a])a*
On doit pouvoir faire ça avec 3 lettres, mais je fatigue.
-
Aie, RC4 est vulnérable à une attaque par textes en clair connus. (http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html)
Il ne va plus rester grand chose dans les ciphers securisé valide dans tls 1.1 ...
C'est trop tard, ton navigateur a déjà envoyé en clair les cookies.
Il faudrait rajouter un
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Avec Strict-Transport-Security les navigateurs sont très chiants, on ne peut plus passer outre les certificats invalides...
-
Petite évolution : j'ai remplacé la ligne
SSLProtocol ALL -SSLv2
par la ligne :
SSLProtocol +TLSv1.2 +TLSv1.1 +TLSv1
Concrètement voici ce que cela change :
- SSLv2 : interdit (aucun changement)
- SSLv3 : autorisé avant et interdit maintenant
- TLSv1 : autorisé (aucun changement)
- TLSv1.1 : autorisé (aucun changement)
- TLSv1.2 : autorisé (aucun changement)
Il est en effet conseillé de désactiver SSLv3.
L'effet de bord, c'est la perte de Internet Explorer 6 (et peut être Internet Explorer 7, je n'ai pas testé).
L'affichage ne se fait même pas en mode dégradé avec un message d’alerte mais la personne a un message "Internet Explorer ne peut pas afficher cette page web"
Internet Explorer 8, la dernière version d'IE sous Windows XP est toujours supporté pleinement.
Cela fait passer la note de "Protocole Support" sur SSL Labs de 90 à 95 :
(https://lafibre.info/images/bistro/201409_sslabs_lafibre.png)
A noter une erreur de SSL Labs : Ce site fonctionne très bien (aucun message d'alerte) sur les navigateurs sans support de SNI (SNI permet de mettre plusieurs sites https sur une même IP).
Concrètement j'ai 2 sites https sur mon serveur : https://lafibre.info et https://testdebit.info sur la même IP et les navigateurs qui ne supportent pas SNI (Internet Explorer sur Windows XP principalement) vont systématiquement récupérer le certificat de LaFibre.info vu qu'ils ne savent pas indiquer le site qu'ils vont visiter avant la récupérations du certificat. Cela va provoquer un gros message d'alerte sous Internet Explorer avec Windows XP, mais uniquement sur https://testdebit.info vu que dans les deux cas le certificat envoyé sera celui de LaFibre.info
-
Bien vu!
Il faut arrêter le support des dinosaures.
-
Tu as activé la confidentialité persistante, c'est bien, mais aussi les tickets : combien de temps sont-ils valables?
-
Tu parles de quoi ?
J'ai juste enlevé SSLv3 et la ligne concernant Microsoft Internet Explorer :
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
-
Je parle pas de ce dernier changement, je parle de la fois où tu as activé le Forward Secrecy.
-
27 janvier 2015 : activation du HTTP Strict Transport Security
C'est expliqué sur Wikipedia : https://fr.wikipedia.org/wiki/HTTP_Strict_Transport_Security
Concrètement, on indique au navigateur que pendant une durée (ici, j'ai mis 31536000 secondes, soit 1an) il ne doit pas utiliser http pour accéder au site web en http.
Prenons un exemple : vous voyagez avec votre PC portable. Vous allez à l'étranger et vous accédez avec votre marque page au favori qui est enregistré sans https mais en http.
En françe, vous avez le vrai site web qui répond qui vous transfert vers le site https.
Mais là, si il y a un pirate, il intercepte votre requête http et peut ne pas vous basculer en https pour récupérer vos données.
Avec Strict Transport Security, pendant 1an, votre navigateur note qu'il doit refuser de contacter votre site en http et tout basculer en https.
Il faut par contre être sur que le site web ne va pas avoir besoin de re-passer dans le futur en http, car sinon tous ceux qui ont déjà visité le site ne pourront pas y retourner.
Avec apache, cela nécessite d'activer le mod header : sudo a2enmod headers
On rajoute dans la conf https du serveur web la ligne suivante :
# Utiliser HSTS (HTTP Strict Transport Security) pour forcer le navigateur a contacter le nom de domaine pendant 1an que en https
Header always set Strict-Transport-Security "max-age=31536000; preload"
Cela permet d'avoir une note A+ sur Qualys SSL Labs :
(https://lafibre.info/images/bistro/201501_sslabs_lafibre.png)
-
Dans Chrome :
aller sur chrome://net-internals/#hsts
Found:
domain: lafibre.info
static_upgrade_mode: UNKNOWN
static_sts_include_subdomains:
static_pkp_include_subdomains:
static_sts_observed:
static_pkp_observed:
static_spki_hashes:
dynamic_upgrade_mode: STRICT
dynamic_sts_include_subdomains: false
dynamic_pkp_include_subdomains: false
dynamic_sts_observed: 1422378033.888885
dynamic_pkp_observed: 0
dynamic_spki_hashes:
-
intéressant. Merci Vivien
-
Vivien j'ai pas le souvenir que lors de l'écriture dun message le https ne soit pas valider sous chrome.
-
C'est un vieux problème, ça... qui date de l'époque où le site était dispo en http et en https. Certaines actions redirigeaient vers le site http.
Depuis le 15 septembre 2013, le serveur web http n'a plus accès au contenu (il ne fait que rediriger vers la même url avec https) ce qui signifie qu'il est impossible d'avoir une page sans https depuis cette date. Les navigateurs incompatibles ne peuvent pas afficher la page lafibre.info tout simplement.
Dernière phase pour le passage en https
Je viens de supprimer le contenu accessible sans https.
Aujourd'hui toute les connexions http vers lafibre.info sont renvoyée vers https.
C'est nécessaire car de nombreux liens tiers vont toujours sur le site en http et non en https.
Fichier de configuration pour http :
<VirtualHost *:80>
ServerName lafibre.info
ServerAlias [url=http://www.lafibre.info]www.lafibre.info[/url]
Redirect permanent / [url]https://lafibre.info/[/url]
</VirtualHost>
N'hésitez pas à me signaler des problèmes.
J'ai également supprimé les scripts tiers Cedexis (le radar cedexis) pour ne plus avoir le contenu mixte signalé par Corrector.