[tor-dev] Impending Facebook Onion-Site Certificate Changes
Hello All! Details: https://www.facebook.com/facebookcorewwwi/posts/703469239759799 https://www.facebook.com/facebookcorewwwi/posts/703469239759799 Summary: new EV-style SSL certificate rolls out to facebookcorewwwi.onion next week. - alec — Alec Muffett Security Infrastructure Facebook Engineering London signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] HTTPS Everywhere harmful
Maciej Soltysiak: http://www.w3.org/DesignIssues/Security-NotTheS.html The problem with his argument is that the web (and any protocol, really) needs a way to demand a hard guarantee that a request must proceed over a secure transport layer. If that layer is not available, the request must fail. Anything short of that is opportunistic security, and by definition not effective against an active attacker**. I suspect what Tim Berners-Lee is actually annoyed with is Mixed Content Blocking and its tendency to impede upgrade to HTTPS rather than encourage it (due to blocking HSTS-upgraded URLs and addon redirect HTTPS upgrades as if they were HTTP URLs, rather than allowing them to be treated as first-class HTTPS urls). With that, I sympathize. Mixed Content Blocking seems to be doing more harm than good in terms of encouraging HTTPS transition, and has forced HTTPS-Everywhere to have to disable thousands of HTTPS upgrade rules due to site breakage from improperly blocked Mixed Content. Unfortunately, it seems that conflating the Mixed Content Blocking issue with the HTTPS namespace issue will likely distract the standards community long enough to delay development of proper solutions to HTTPS migration (like an improved form of HSTS that addresses known issues with Mixed Content Blocking: https://w3c.github.io/webappsec/specs/upgrade/). Forgive me if I do my best to avoid this distraction myself. ** Sure, there could be a pile of new attribute flags that could be set on every HTML resource tag that says the resource must use a secure http: channel if the parent document happened to load over a secure channel, but the net engineering effort of deploying that correctly far exceeds the effort needed to mitigate the namespace fragmentation issues that Tim Berners-Lee is seemingly so concerned about. -- Mike Perry signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Draft of proposal Direct Onion Services: Fast-but-not-hidden services
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I like the term onion service to refer to a service that requires the use of Tor to access. For onion services whose operators do not want their identities discovered, I suggest renaming hidden service to anonymous onion service. For onion services that do not need anonymity (location is known but Tor must be used to access), I think known onion service is a great name (identified onion service also make sense, but I prefer known to identified). These suggestions are added to the wiki page: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Term inology Cheers, Rob -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVOpjiAAoJEO3Z5w0UVGXoKWQP/iMz4jWNZrS57dKEmp46NEIX 9cGib/RR2VQayLIGz+W8uFQ9IRtUPYS/rB4krmFH58JhGUJggzw7lUCU2SJMmdWG 4qu6kW2DT0iy2r/2hpKYPPYW5mmoySjGYN4qi7cNxGdhhR/899sN1S5qCUVlIFqS ZtAkuG0AqTTjuNr7u86Xt5EwLYGQ2XB8w4LOhSzS6WwrRfR48A5LS+1d5dOf+eo8 FIVTRUw0+yV64O460dCgdZVLzO/bkxpejoctdifnN0OVsd2SvskGc+/Xiq5YENqa EXFuUBE79Eka2VVvj+Ts+BVnu0B+kgDl1bWBRy5wEuM7PptSqxGS8cgr4CmWqZQH rE8Xpxvq97Aah6tK5OSrR6r4QuP99f+PdBm9rPBZFphCIub8nU4XuOIsWUXrFRAi hXJeayNslSlwyiFrQ2aWF03k5pw16VfcKC4PJ8ABT5pPIDmuRJcVAnLCLyS6Eosc Tm4To1ZVbZFm3YIW9VSsfUMDbou4QEUR7xkV3nasZQgSHY40+Ae3bHDHULc7NzGQ QvEOkabBe+INjjn2d+5Wj1RuNstl8ja9J3PRDNjtCluWJ7d0YHOAoFgzX7FTjjwF x+02tVXGvcLJ2LZrfKbaaZZC/S8l76owcRLzAbF5DeMvsrNQdWS2HyKOGTGW8GDM /oNLsCuEZOVzCq0NZWhd =xN7v -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] onionoo: increasing first_seen granularity + providing document fingerprints
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, timestamps are useful to link relays, unfortunately onionoo only says in which consensus the relay was first seen (granularity: 1hour) but does not include the timestamp of the first seen descriptor that ended up in the consensus (published line). That timestamp would have a higher granularity (seconds). What do you think about adding such a timestamp? (I acknowledge that I might be the only user of this field) I might want to prove to third parties that I'm indeed processing/providing authentic historic onionoo documents from onionoo.tpo. What do you think of signing them? thanks -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVOpLqAAoJEFv7XvVCELh0WaIP/jqLtHaeno0EEUNPeqT8rJQp XRV76Vfq6LOciexFBRfcN2p7kkG26Y1LunRs12QuRpJngNfSW/nu3/WNUruR205D PrFJCI2Olxn3s8Fktd/N5kNLJbtPDmzqkghhvWUP+f1MBuW0FstMWi4fZ+TyerE9 FTD8eTF8woFb/JEHIrKsH4LB5Os/uGCoJbWT+AlxKHQcU/mQn0rb4ZIIllbUr9LJ uuFUV7ajZAR/rBX2AWvpkJgaS3BfOk3cMOVd3dQgweDjtUlS66Q5v+vtvBHXYk1V jd+fXyQ3txFmFVj/oQgnJJFRmGSmqpm5hRWEkzOXjXlCdsnqMPUBBjwjrgU+vmGB sNQOi/NdXUImQ0bT+ryjPTOT7Gf5EXOihYyH4e4ebn5OEEEVTQh/86iXxrLB23I2 z7sciEw3q/Tt7mM21cSMRStxavBU5InixIvQz78TgK1sE9PpeohzhToxNedm8aDE Ny/O+KYBBBmKOuRwjmbyJQ86MxQHnmEwLhksVNSJ3MUuG0QmfFTrht3thkmlew6z UfFBS9YzfBIoztL7X5Pu4nFsNFy2ffxZIV/bs4Dmx1PlweIw0eUeCgUdcdZTcvA+ v4OjCukdzLupDpb8lhDuX5EqrmeYUnczlopMX3szeX8udLKr5G+MWaihGdKasdKw Fy6T4z11bbzuW/nBf6Ra =oJ6y -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
