“We, the Chrome Security Team, propose that user agents (UAs) gradually change their UX to display non-secure origins as affirmatively non-secure.”
[Today, HTTPS is displayed in green and HTTP without any indicator. The idea is to have a warning indicator for HTTP.]
▻https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
Encore récemment, où je proposais à un client un certificat... celui-ci me répond que les données échangées n’ont aucun caractère confidentiel... qu’un tel certificat ne sert à rien. Idem pour la protection d’un phpMyAdmin... le client m’explique que les données de la base de données n’ont aucun caractère marchand ou confidentiel.
Finalement, c’est contre quoi qu’ils veulent nous protéger les gens de Chrome ? Contre le fait que les fichiers téléchargés, on n’est pas du tout sûr qu’ils proviennent du site qu’on croit consulter ? Ça devient lourd à expliquer aux utilisateurs !
Stéphane, que penses-tu des certificats qui vont être proposés « bientôt » par l’EFF et la Fondation Mozilla ? Car c’est bien gentil de passer en https, mais ça coûte très cher auprès des vendeurs de certificats (mais c’est une éventuelle source de revenus pour le grand G, qui peut compenser la fin de l’ère du web publicitaire).
@hlc Si c’est une question de prix (mais il y a aussi la question du statut de ces AC, toutes des boîtes privées à but lucratif), essaie CAcert ►http://seenthis.net/messages/98342 ►http://seenthis.net/messages/97239 que SeenThis devrait AMHA adopter.
@hlc Et sur le projet EFF/Mozilla, voir ►http://seenthis.net/messages/314991
Il y a effectivement une question de prix quand on gère plusieurs domaines. Mais les certificats gratuits ne sont pas reconnus par les navigateurs et produisent une grosse alerte qui effraient les usagers. C’est une méthode un peu mafieuse, sous couvert de sécurité, qui consiste à dire, « si tu ne payes pas un des copains de la bande des certifieurs, alors on va détourner les gens de ton site ». La même chose que Amazon qui dit qu’un livre est indisponible si Amazon n’en est pas le libraire/distributeur.
Visiblement, en lisant les articles que tu propose, les certificats de Let’s encrypt seront reconnus... c’est une grande différence avec des certificats auto-signés.
Mais partant du principe « quand c’est gratuit, il faut se méfier », je voudrais avoir ton avis éclairé.
@hlc Ce n’est pas le fait qu’ils soient gratuits (StartSSL l’est aussi, pour un usage non commercial), c’est plus arbitraire que ça. Et si les certificats de Let’s Encrypt seront acceptés, mais pas ceux de CAcert, cela illustrera simplement cet arbitraire.
Je ne prône pas les auto-signés (qui n’offrent aucune garantie : un attaquant Homme du Milieu a pu les générer) mais l’utilisation d’autorité de certification démocratiques et populaires :-) comme CAcert.
Pour le reste, j’attends DANE ►http://www.bortzmeyer.org/jres-dane-2011.html
Le #SSL sera gratuit d’ici 2015
▻http://www.journaldunet.com/solutions/expert/59156/le-ssl-sera-gratuit-d-ici-2015.shtml
l’EFF (Electronic Frontier Foundation) annonce la gratuité du SSL pour l’été 2015.
ça sonne bizarre une alliance entre Mozilla et EFF d’un côté, et Akamai et Cisco de l’autre.
Je me demande quelles sont les implications d’un usage massif de SSL. Est-ce que ça ne serait pas une façon pour les grands silos (GAFA) de s’assurer de l’identité des visiteurs et renforcer le ciblage ? En particulier, est-ce qu’utiliser HTTPS ne diminue pas l’intérêt d’utiliser TOR ?
Peut être @stephane peut nous dire si je raconte n’importe quoi :)
@severo C’est en effet n’importe quoi :-) HTTPS n’est quasiment jamais utilisé pour authentifier/identifier le client. Les sites qui fliquent leurs visiteurs le font via des techniques qui marchent en HTTP comme en HTTPS (cookies, fingerprinting, Web bugs).
Et, lorsqu’on utilise TOR, il est très recommandé de chiffrer (HTTPS pour le Web) car, sinon, le nœud TOR d’entrée et celui de sortie (qui peuvent être contrôlés par la même organisation) voient le trafic en clair.
@James C’est un titre qui est vraiment du raccourci journalistique. Il existe depuis longtemps des Autorités de Certification gratuites ►http://seenthis.net/messages/98342
Cependant, aujourd’hui :
►https://www.cacert.org me dit :
www.cacert.org utilise un certificat de sécurité invalide.
:)
@stephane Merci :)
Aucun effet négatif à cette annonce, donc ?
Et, sauf si j’ai mal compris, ►https://www.startssl.com/?lang=fr propose un certificat gratuit (pour 1 sous-domaine, je suppose) pour un an. Le renouvellement est gratuit aussi ?
@James Le navigateur ne donne pas d’avantage de détails ? Car le certificat de CAcert n’est pas invalide. C’est peut-être simplement que le certificat racine de CAcert n’est pas dans le magasin du navigateur (un problème qu’aura aussi la nouvelle AC).
On peut aussi rappeler que le titre de l’article fait allusion à un protocole, SSL, fini depuis quinze ans. HTTPS utilise TLS, pas SSL.
@severo Non, rien de négatif, mais je ne comprends pas non plus l’enthousiasme médiatique. Rien ne garantit que la nouvelle AC sera mieux acceptée (par exemple par Microsoft pour Internet Explorer) que les gratuites existantes.
Mieux vaut lire la bonne discussion sur LinuxFR ▻https://linuxfr.org/users/claudex/journaux/encryptons
Voilà comment faire grimper SeenThis dans les résultats Google : mettre enfin une configuration #HTTPS correcte !
▻http://arstechnica.com/security/2014/08/in-major-shift-google-boosts-search-rankings-of-https-protected-sites
Rappel de l’analyse de Firefox sur ►https://seenthis.net : « The certificate is not trusted because it is self-signed. The certificate is not valid for any server names. The certificate expired on 12/01/2012 16:37. The current time is 08/08/2014 08:45. »
Le problème c’est que l’on ne sait pas si les AC qui ne sont « reconnues universellement » comme CAcert auront le même impact que les Verisign & co.
@ledeuns Dans ce cas, prendre du StartSSL. Gratuit, commercial et reconnu très largement (alors que CAcert est gratuit, libre, et peu reconnu).
Je ne connaissais pas CAcert. Merci pour l’info ! Ça va me servir. Il y a un thread ici ▻http://mondedie.fr/viewtopic.php?id=5378
Attention : notre hébergeur exige que nous changions d’adresse IP. La nouvelle IP est : 195.154.255.5
Théoriquement j’ai fait les motifs sur le serveur (euh…) et sur le nom de domaine, mais bon, si jamais Seenthis disparaît des écrans radars dans quelques instants, vous saurez d’où ça vient (si vous avez lu ce message avant).
Je me serais bien passé de ce genre de jonglerie, mais voilà :
Afin de préparer le démontage de ce réseau, nous vous rappelons que :
– Des pénalités de surcharge de l’ancien réseau de 50€ seront
appliquées sur la facturation du 1er septembre pour chaque serveur
n’ayant pas été migré avant le 31 août au soir ;
(C’est légal cette histoire de pénalités ?)
Les motifs ? Pas les modifs ?
Le TTL est de trois heures dans le DNS donc faut pas virer l’ancienne adresse avant. ▻http://www.bortzmeyer.org/changement-adresse-et-dns.html
Je viens de terminer la mienne (de migration). Mais n’empêche... Une IP failover, c’est fait pour la garder... pas pour la changer... J’ai été contraint de passer sur tous les firewalls (un certain nombre)... quand ce n’était pas pour la passerelle de messagerie... c’était pour les sondes nagios... groumf...
Le jour où ils m’ont appelé, pour s’assurer que j’avais bien planifié la migration... je n’ai pas été désagréable... à quoi bon s’en prendre au messager... mais n’empêche...
Alors, est-ce légal... j’imagine qu’il y a une clause dans leur contrat, qui prévoit qu’ils peuvent prendre toute mesure, unilatéralement, à condition de te prévenir à l’avance. On a plus vite fait de tout modifier... mais quand même... ce fut pénible. Limite ils pourraient envisager un dédommagement. Tiens, il faudrait le suggérer sur leur compte twitter... pour ceux qui en ont un :-D
Oui, comme le dit Stéphane, il est possible de laisser l’ancienne adresse en alias dans la configuration de la carte réseau (dans le système d’exploitation).
J’ai fait qu’est-ce qu’ils disent de faire. Dans la config, j’ai maintenant eth0 avec la nouvelle IP, et eth0:0 (de mémoire) avec l’ancienne.
Mais bon, d’ici 3 heures, suspens suspens. :-)
Bon, là, j’y vois que du feu !
Une des conséquences de la migration a été de casser HTTPS. On a maintenant « Secure Connection Failed \ An error occurred during a connection to seenthis.net. SSL received a record that exceeded the maximum permissible length. (Error code : ssl_error_rx_record_too_long) » Bien sûr, l’accès HTTPS n’était pas terrible, avec son certificat auto-signé et expiré ►http://seenthis.net/messages/98342 mais c’est dommage (pauvre Snowden) de l’avoir cassé :—) #SeenThis_bug
Autre conséquence, ça a apparemment cassé l’API. Les requêtes POST disent désormais « HTTP Error 405 : Method Not Allowed » #SeenThis_gros_bug
Ce matin, c’était Varnish qui expédiait les gens vers la mauvaise IP.
Il semble que HTTPS et l’API remarchent.
Un certain nombre de services sur l’Internet, notamment de serveurs Web, sont protégés par le protocole #TLS, qui utilise presque toujours un #certificat #X.509 pour vérifier l’authenticité du serveur. Ces certificats ont une durée de vie limitée et doivent donc être renouvelés de temps en temps. Comme un certain nombre d’administrateurs ont oublié, au moins une fois, un tel renouvellement, il me semble utile de donner ce conseil : intégrez la surveillance des dates d’expiration dans votre système de #supervision !
►http://www.bortzmeyer.org/tester-expiration-certifs.html
PS : le certificat de SeenThis a expiré mais, de toute façon, il est tellement à l’Ouest ►http://seenthis.net/messages/98342 que ce n’est pas le problème le plus grave.
RFC 6797 : HTTP Strict Transport Security (HSTS)
La technique #HSTS (HTTP Strict Transport Security), normalisée dans ce #RFC (mais déjà largement déployée) vise à résoudre une attaque contre #TLS. Si un site Web est accessible en #HTTPS, et qu’un méchant arrive à convaincre un utilisateur de se connecter en HTTP ordinaire à la place, le méchant peut alors monter une attaque de l’homme du milieu. Le fait que le site soit protégé par TLS n’aidera pas dans ce cas. Pour éviter cette attaque, HSTS permet à un site de déclarer qu’il n’est accessible qu’en HTTPS. Si l’utilisateur a visité le site ne serait-ce qu’une fois, son navigateur se souviendra de cette déclaration et ne fera plus ensuite de connexions non sécurisées.
►http://www.bortzmeyer.org/6797.html
Ça serait cool pour améliorer la sécurité de SeenThis mais, de toute façon, il faudrait d’abord résoudre <►http://seenthis.net/messages/98342>