Use `//` instead of `http://` or `https://` : HTTP client will use whatever protocol the page was fetched with - https://news.ycombinator.com/item?id=5514784 #SSL #HTTP #HTTPS
- #SSL
-
-
-
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>
-
Permettre un accès en #HTTPS à Seenthis, c’est très cool (pour les lecteurs situés dans des pays dictatoriaux, ou qui travaillent dans une entreprise qui flique ses salariés, c’est même recommandé par l’EFF). Mais il faudrait un certificat plus sérieux. Mon Firefox me dit :
« The certificate is not trusted because it is self-signed. »
Il faudrait utiliser une AC comme CAcert ou StartSSL ou autre.
« The certificate is not valid for any server names. »
Et, en effet, aucun nom de serveur n’est indiqué dans le certificat.
« The certificate expired on 01/12/12 16:37. The current time is 11/20/12 10:41. »
Il faudrait renouveler le certificat (truc : CAcert envoie un rappel automatiquement)
#SeenThis_bug #TLS #X.509
-
-
Je trouve que c’est de toutes manières inutilisable, parce que les liens « Accueil » et « Seenthis » renvoient vers la version http.
-
je vote aussi pour une utilisation plus fluide avec #HTTPS. Et pourquoi pas une case à cocher dans les préférences pour être systématiquement redirigé vers la version https?
-
-
4 Simple Changes to Stop Online Tracking | Electronic Frontier Foundation
https://www.eff.org/deeplinks/2012/04/4-simple-changes-protect-your-privacy-online#publicité #tracking #surveillance #adblock+ #cookies #referers_off #https_everywhere
-
RFC 6698 : The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol : TLSA
À chaque seconde, d’innombrables transactions sur l’Internet sont protégées contre l’écoute et la modification malveillante par le protocole #TLS. Ce dernier est capable de chiffrer la session (pour la protéger contre l’écoute par un tiers) et d’authentifier le pair avec qui on parle (pour s’assurer qu’on n’est pas en train de communiquer avec un usurpateur). Comment TLS authentifie t-il ? La méthode la plus courante aujourd’hui est de se servir de certificats #X.509 vérifiés (en théorie) par une Autorité de Certification. Ce mécanisme repose sur une confiance aveugle dans de très nombreuses organisations, et a de nombreuses faiblesses, comme on l’a vu en 2011 où le piratage de plusieurs AC a permis à des attaquants d’obtenir de « vrais-faux » certificats, y compris pour des organisations qui n’étaient pas clientes des AC piratées. La démonstration étant ainsi faite que X.509 n’était pas digne de la confiance que certains lui accordent, il restait à concevoir une meilleure solution. Rendue possible par le déploiement de #DNSSEC, voici #DANE (DNS-based Authentication of Named Entities) et ses enregistrements #DNS #TLSA. DANE permet à chacun de publier de manière sécurisés ses certificats, bouchant ainsi les vulnérabilités de X.509, ou permettant même de s’en passer complètement.
DANE permettrait par exemple, d’accéder à SeenThis sans se faire engueuler par son navigateur. Aujourd’hui, SeenThis est accessible en #HTTPS mais avec un certificat auto-signé, et pour un nom invalide ("SeenThis" et pas "seenthis.net"). Ajouter un enregistrement TLSA à _443._tcp.seenthis.net permettrait de ne plus avoir d’avertissement de sécurité (pour les futurs navigateurs Web avec gestion de DANE/TLSA).
http://www.bortzmeyer.org/6698.html
#RFC
-
Tor and HTTPS
https://www.eff.org/pages/tor-and-httpsUne infographie de l’Electronic Frontier Foundation pour visualiser les informations qui peuvent être interceptées - et à quels moments - lorsque vous vous connectez à un site, selon que vous utilisez Tor ou le https, les deux, ou encore aucun.
Conclusion : pour garantir la confidentialité de sa navigation ou de ses communications numériques, il faut utiliser Tor ET le https ET avoir une pleine confiance dans l’administrateur système du site hébergé (notamment dans le choix des outils qu’il met en place). Note : dans le graphique, ISP signifie fournisseur d’accès.Click the “Tor” button to see what data is visible to eavesdroppers when you’re using Tor. The button will turn green to indicate that Tor is on.
Click the “HTTPS” button to see what data is visible to eavesdroppers when you’re using HTTPS. The button will turn green to indicate that HTTPS is on. -
Sovereign #Keys : A Proposal to Make #HTTPS and #Email More Secure | Electronic Frontier Foundation
https://www.eff.org/deeplinks/2011/11/sovereign-keys-proposal-make-https-and-email-more-secureIn a previous post, we discussed some structural insecurities in HTTPS and TLS/SSL, and how those are beginning to pose serious problems for the security of the Web.
In this post I will introduce a new proposal called “Sovereign Keys”, which is intended to systematically fix these weaknesses in the way that encrypted Internet protocols perform authentication.
est-ce une réponse à http://seenthis.net/messages/37879
(#sécurité #internet #cryptographie, twitté par @natmaka)
-
La proposition semble très sérieuse. Je suis d’accord avec la plupart des remarques préalables des auteurs (notamment le fait que passer outre un avertissement de sécurité X.509 est une réaction rationnelle). Leur conception du nouveau protocole semble correcte. Bref, un projet prometteur.
Comme avec tous les systèmes où l’utilisateur contrôle entièrement la clé privée, le gros problème est celui de la perte d’une clé (oubli de la phrase de passe, panne du disque où la clé était stockée). Un tel système rend difficile ou impossible l’obtention d’une nouvelle clé (pas de tierce partie qui puisse en envoyer une nouvelle, qui sera immédiatement reconnue). C’est le principal point sur lequel il faudra travailler.
-
-
ssl/ssh multiplexer
http://www.rutschle.net/tech/sslh.shtml#sslh accepts #HTTPS, #SSH and #OpenVPN connections on the same port. This makes it possible to connect to an SSH server or an OpenVPN on port 443 (e.g. from inside a corporate firewall, which almost never block port 443) while still serving HTTPS on that port.
#vpn
- #This
-
Testé (très) rapidement, ça m’a pas convaincu : https dans les choux, et les adresses IP source sont toutes transformées en 127.0.0.1. Varnish m’embête déjà assez avec ça sur mon http pour que j’ai envie de gérer la même chose en https:-)
-
Autre article sur le même programme, qui met davantage l’accent sur l’aspect politique : http://linuxfr.org/news/sslh%C2%A0110-la-b%C3%AAte-noire-des-censeurs
-
Accéder à Reflets.info en HTTPS | bluetouff
http://reflets.info/acceder-a-reflets-info-en-httpsSuite à une remarque il y a quelques minutes, non dénuée de sens, de @Dam_ned sur Twitter nous signifiant qu’il s’étonnait de ne pas voir Reflets.info accessible en https malgré un bon nombre d’article traitant de Deep Packet Inspection, nous avons à l’instant configuré un certificat tout neuf pour vous. Vous pouvez donc maintenant tous accéder à Reflets en https via https://reflets.info Comme nous ne faisons pas plus que ça confiance aux « tiers de confiance », nous avons nous même auto-signé notre certificat (./rebuild.sh étant la société qui édite le site Reflets.info), ne soyez donc pas étonnés si votre navigateur vous dit qu’il n’est pas fiable, pour nous il l’est plus qu’en passant par un tiers. Le voici :
-
-
L’EFF souhaite généraliser la connexion sécurisée HTTPS
http://www.numerama.com/magazine/18617-l-eff-souhaite-generaliser-la-connexion-securisee-https.htmlUn an après avoir dévoilé HTTPS Everywhere, un module complémentaire pour Firefox, l’Electronic Frontier Foundation lance une campagne en faveur des connexions sécurisées. L’ONG américaine a lancé un wiki dans lequel elle fait le point sur la sécurité mise en œuvre par les différents sites web pour protéger les internautes.
#confidentialités #données_personnelles #https #Firefox #EFF #Electronic_Frontier_Foundation
-
-
Perspectives : Firefox Extension
http://www.cs.cmu.edu/%7Eperspectives/firefox.html“an extension to the popular Firefox browser that contacts network notaries whenever your browser connects an HTTPS website”
#firefox #extension #https #certificat #contrôle #vérification #sécurité #clevermarks
-
