Re: [tor-talk] Disabling the warning for self signed certificates in Tor Browser
Am 2014-04-22 08:54, schrieb Georg Koppen:
> antispa...@sent.at:
>> Could Tor Browser kill or minimize the warning triggered by entering a
>> site with a self signed certificate?
>
> Killing is not a good idea. What do you mean with "minimize"?
>
> Georg
>
>
>
>
I've wanted that for browsers too. Don't kill it, but notify
("non-blocking") that you should manually verify a checksum (bonus: just
display the sha1 directly).
You should check a checksum manually either way. Contious web services
post the sha1 of a new certificate (or offer to send it via sms or
whatever) and offer you to check it manually. Although it's signed by
some CA.
Self-signing is not at all less secure, quite often the opposite is true.
I'd *love* a firefox-notification (just like "plugin is missing") that
just reads the sha1 of the certificate in big letters.
--
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Disabling the warning for self signed certificates in Tor Browser
Georg Koppen: > antispa...@sent.at: >> Could Tor Browser kill or minimize the warning triggered by entering a >> site with a self signed certificate? > Killing is not a good idea. What do you mean with "minimize"? A self-signed certificate is better than no certificate. Given the trouble with a CA, it might be just as good as a CA certificate. Anyway, This Connection is Untrusted. Good. The Aholes from Firefox never bothered to write the same warning about plain HTTP connections. Ain't it funny? I know at least a dozen sites that do password authentification through HTTP. Are they any better? And I can't just browse the site after that warning. I can go to disney.com with "Get me out of here". Than there is that user friendly "Technical Details" which would make any granny click and get her glasses on 'cuz it's time to check the signatures. Maybe for you, the tech guys, that means something to be thankful for being so easy to reach. I don't think that the Iranian disident or the Turkish journalist would feel the same next time. I click I understand the risks. And nothing. I acknowledged the risk. Yet the browser won't let me proceed. So you have two extra paragraphs of curses. If they were so interesting, why aren't they on the first page? So finally I can add an exception. Which I have to confirm. Why not something like the NoScript banner/warning? Why not the same curses on ANY unencrypted page, or at least those that present the user with a password field? I checked that with Autistici.org. They have a wonderful AES 256bit key. All my online banking is done over RC4 128bit at best. That is as strong as Wikipedia! Autistici.org does generate that need for three extra pointless clicks. Any of my banking sites generates nothing. Any of the sites and forums that do authenticate through HTTP generate nothing. Sure it sounds like a conspiracy. But why feed the dangerous game of the CAs? Why do the free software has to fill the pockets of these companies? Why kick the sites that do care about their users in the teeth unless they pay for the CA ransom? -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Disabling the warning for self signed certificates in Tor Browser
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On that note. https://cacert.org root certificates are missing mostly. You have to install them by your own. Personally i prefer cacert.org, because firstly you have to identify yourself and secondly you actually are meeting assurers face to face with your passport in hand which will grant you points from 5 to 20. At 50 points you get a server certificate for 2 years. That's as close as you can get to a so called CA! On 23. April 2014 11:07:02 MESZ, antispa...@sent.at wrote: >Georg Koppen: >> antispa...@sent.at: >>> Could Tor Browser kill or minimize the warning triggered by entering >a >>> site with a self signed certificate? >> Killing is not a good idea. What do you mean with "minimize"? > >A self-signed certificate is better than no certificate. Given the >trouble with a CA, it might be just as good as a CA certificate. > >Anyway, This Connection is Untrusted. Good. The Aholes from Firefox >never bothered to write the same warning about plain HTTP connections. >Ain't it funny? I know at least a dozen sites that do password >authentification through HTTP. Are they any better? > >And I can't just browse the site after that warning. I can go to >disney.com with "Get me out of here". > >Than there is that user friendly "Technical Details" which would make >any granny click and get her glasses on 'cuz it's time to check the >signatures. Maybe for you, the tech guys, that means something to be >thankful for being so easy to reach. I don't think that the Iranian >disident or the Turkish journalist would feel the same next time. > >I click I understand the risks. And nothing. I acknowledged the risk. >Yet the browser won't let me proceed. So you have two extra paragraphs >of curses. If they were so interesting, why aren't they on the first >page? > >So finally I can add an exception. Which I have to confirm. > >Why not something like the NoScript banner/warning? > >Why not the same curses on ANY unencrypted page, or at least those that >present the user with a password field? > >I checked that with Autistici.org. They have a wonderful AES 256bit >key. >All my online banking is done over RC4 128bit at best. That is as >strong >as Wikipedia! Autistici.org does generate that need for three extra >pointless clicks. Any of my banking sites generates nothing. Any of the >sites and forums that do authenticate through HTTP generate nothing. > >Sure it sounds like a conspiracy. But why feed the dangerous game of >the >CAs? Why do the free software has to fill the pockets of these >companies? Why kick the sites that do care about their users in the >teeth unless they pay for the CA ransom? > >-- >tor-talk mailing list - tor-talk@lists.torproject.org >To unsubscribe or change other settings go to >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk - -- We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elri...@elrippoisland.net Encrypted messages are welcome. 0x84DF1F7E6AE03644 - -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.11 (GNU/Linux) mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7 uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/ axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt 7cwEDrW8W4
[tor-talk] Tor Weekly News — April 23rd, 2014
Tor Weekly News April 23rd, 2014 Welcome to the sixteenth issue of Tor Weekly News in 2014, the weekly newsletter that covers what is happening in the Tor community. Cutting out relays running version 0.2.2.x -- Tor relays running the now ancient Tor 0.2.2.x are scheduled to be removed from the consensus [1]. The change has already been merged in the master branch and will be out with the next Tor 0.2.5 alpha. Even if most relay operators have been warned, the change has not yet been widely announced. But as three directory authorities are already not voting for the deprecated versions, the downtime of two others while cleaning up after the OpenSSL “Heartbleed” issue was sufficient to get these relays removed from the consensus [2] for a couple of days, as Roger Dingledine explained [3]. Eventually relays running versions prior to 0.2.3.16-alpha might also be removed from the consensus. “I think 0.2.3.16-alpha’s fix of #6033 makes that one a plausible ’not below this one’ cutoff”, Roger writes in the relevant Trac entry [4]. Relay operators should always make sure to run a recommended Tor version [5]. The Tor Weather service [6] can be used by relay operators to get email notifications if an outdated version is detected. [1]: https://bugs.torproject.org/11149 [2]: https://metrics.torproject.org/network.html?graph=versions&start=2014-04-01&end=2014-04-23#versions [3]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004422.html [4]: https://bugs.torproject.org/11149#comment:7 [5]: https://consensus-health.torproject.org/#recommendedversions [6]: https://weather.torproject.org/subscribe/ Miscellaneous news -- Nathan Freitas announced [7] the third (and probably final) release candidate for Orbot 13.0.6: “The big improvements in this build are a fix for the disconnected UI/activity (Tor is on, but UI shows off), and improvements to the transparent proxying iptables scripts”. [7]: https://lists.mayfirst.org/pipermail/guardian-dev/2014-April/003436.html The Tails developers put out two calls for testing: the first [8] is for the first release candidate of Tails 1.0; while the second [9] is for UEFI support, which “allows you to start Tails using a USB stick on recent hardware, and especially on Mac”. “Test wildly”, and report any bugs you find! [8]: https://tails.boum.org/news/test_1.0-rc1/index.en.html [9]: https://tails.boum.org/news/test_UEFI/index.en.html Andrea Shepard sent [10] a list of 1777 fingerprints for relays “which have ever turned up as potentially exposed by Heartbleed”. It appears that enough directory authority operators now reject relays known to be problematic [11]: sssheep reported [12] that the still-vulnerable section of the network was down to 0.01% of the consensus weight. [10]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004340.html [11]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004362.html [12]: https://lists.torproject.org/pipermail/tor-talk/2014-April/032762.html Mick drew attention [13] to the fact that in its current state, arm [14] — the command-line relay status monitor — wrongly advises relay operators to run it with the same user as Tor, in order to access information about the relay’s connections. This is in fact a very bad idea, and a ticket [15] is already open to address this issue. Lunar detailed [16] the correct method of doing this, which is also explained in the ticket. [13]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004414.html [14]: https://www.atagar.com/arm/ [15]: https://bugs.torproject.org/10702 [16]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004412.html On the tor-relays mailing list, David Stainton mentioned [17] his Tor role [18] for the Ansible [19] automation tool. David hoped that “relay operators will find this useful for deploying and maintaining large numbers of Tor relays and bridges”. The documentation specifies that it currently works with Debian and Ubuntu systems, and contains several configuration examples. [17]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004373.html [18]: https://github.com/david415/ansible-tor [19]: http://www.ansible.com/ David Fifield continued his progress on meek [20], a pluggable transport “that routes your traffic through a third-party web service in a way that should be difficult to block”. David sent a call for wider testing [21] of experimental Tor Browser builds and a call for reviews of the code [22]. “There are a lot of components that make up the meek transport […] This is your chance to get in on the ground floor of a new transport!” [20]: https://trac.torproject.org/projects/tor/wiki/doc/meek [21]: https://lists.torproject.o
[tor-talk] Tor Weekly News — April 23rd, 2014
Tor Weekly News April 23rd, 2014 Welcome to the sixteenth issue of Tor Weekly News in 2014, the weekly newsletter that covers what is happening in the Tor community. Cutting out relays running version 0.2.2.x -- Tor relays running the now ancient Tor 0.2.2.x are scheduled to be removed from the consensus [1]. The change has already been merged in the master branch and will be out with the next Tor 0.2.5 alpha. Even if most relay operators have been warned, the change has not yet been widely announced. But as three directory authorities are already not voting for the deprecated versions, the downtime of two others while cleaning up after the OpenSSL “Heartbleed” issue was sufficient to get these relays removed from the consensus [2] for a couple of days, as Roger Dingledine explained [3]. Eventually relays running versions prior to 0.2.3.16-alpha might also be removed from the consensus. “I think 0.2.3.16-alpha’s fix of #6033 makes that one a plausible ’not below this one’ cutoff”, Roger writes in the relevant Trac entry [4]. Relay operators should always make sure to run a recommended Tor version [5]. The Tor Weather service [6] can be used by relay operators to get email notifications if an outdated version is detected. [1]: https://bugs.torproject.org/11149 [2]: https://metrics.torproject.org/network.html?graph=versions&start=2014-04-01&end=2014-04-23#versions [3]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004422.html [4]: https://bugs.torproject.org/11149#comment:7 [5]: https://consensus-health.torproject.org/#recommendedversions [6]: https://weather.torproject.org/subscribe/ Miscellaneous news -- Nathan Freitas announced [7] the third (and probably final) release candidate for Orbot 13.0.6: “The big improvements in this build are a fix for the disconnected UI/activity (Tor is on, but UI shows off), and improvements to the transparent proxying iptables scripts”. [7]: https://lists.mayfirst.org/pipermail/guardian-dev/2014-April/003436.html The Tails developers put out two calls for testing: the first [8] is for the first release candidate of Tails 1.0; while the second [9] is for UEFI support, which “allows you to start Tails using a USB stick on recent hardware, and especially on Mac”. “Test wildly”, and report any bugs you find! [8]: https://tails.boum.org/news/test_1.0-rc1/index.en.html [9]: https://tails.boum.org/news/test_UEFI/index.en.html Andrea Shepard sent [10] a list of 1777 fingerprints for relays “which have ever turned up as potentially exposed by Heartbleed”. It appears that enough directory authority operators now reject relays known to be problematic [11]: sssheep reported [12] that the still-vulnerable section of the network was down to 0.01% of the consensus weight. [10]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004340.html [11]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004362.html [12]: https://lists.torproject.org/pipermail/tor-talk/2014-April/032762.html Mick drew attention [13] to the fact that in its current state, arm [14] — the command-line relay status monitor — wrongly advises relay operators to run it with the same user as Tor, in order to access information about the relay’s connections. This is in fact a very bad idea, and a ticket [15] is already open to address this issue. Lunar detailed [16] the correct method of doing this, which is also explained in the ticket. [13]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004414.html [14]: https://www.atagar.com/arm/ [15]: https://bugs.torproject.org/10702 [16]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004412.html On the tor-relays mailing list, David Stainton mentioned [17] his Tor role [18] for the Ansible [19] automation tool. David hoped that “relay operators will find this useful for deploying and maintaining large numbers of Tor relays and bridges”. The documentation specifies that it currently works with Debian and Ubuntu systems, and contains several configuration examples. [17]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004373.html [18]: https://github.com/david415/ansible-tor [19]: http://www.ansible.com/ David Fifield continued his progress on meek [20], a pluggable transport “that routes your traffic through a third-party web service in a way that should be difficult to block”. David sent a call for wider testing [21] of experimental Tor Browser builds and a call for reviews of the code [22]. “There are a lot of components that make up the meek transport […] This is your chance to get in on the ground floor of a new transport!” [20]: https://trac.torproject.org/projects/tor/wiki/doc/meek [21]: https://lists.torproject.or
Re: [tor-talk] Tor Weekly News — April 23rd, 2014
I apologize for the formatting errors in this first version of the email; I have sent it again with corrections. harmony: > > Tor Weekly News April 23rd, 2014 > > > Welcome to the sixteenth issue of Tor Weekly News in 2014, the weekly > newsletter that covers what is happening in the Tor community. > > Cutting out relays running version 0.2.2.x > -- > > Tor relays running the now ancient Tor 0.2.2.x are scheduled to be > removed from the consensus [1]. The change has already been merged in > the master branch and will be out with the next Tor 0.2.5 alpha. > > Even if most relay operators have been warned, the change has not yet > been widely announced. But as three directory authorities are already > not voting for the deprecated versions, the downtime of two others while > cleaning up after the OpenSSL “Heartbleed” issue was sufficient to get > these relays removed from the consensus [2] for a couple of days, as > Roger Dingledine explained [3]. > > Eventually relays running versions prior to 0.2.3.16-alpha might also be > removed from the consensus. “I think 0.2.3.16-alpha’s fix of #6033 makes > that one a plausible ’not below this one’ cutoff”, Roger writes in the > relevant Trac entry [4]. > > Relay operators should always make sure to run a recommended Tor > version [5]. The Tor Weather service [6] can be used by relay operators > to get email notifications if an outdated version is detected. > > [1]: https://bugs.torproject.org/11149 > [2]: > https://metrics.torproject.org/network.html?graph=versions&start=2014-04-01&end=2014-04-23#versions > [3]: > https://lists.torproject.org/pipermail/tor-relays/2014-April/004422.html > [4]: https://bugs.torproject.org/11149#comment:7 > [5]: https://consensus-health.torproject.org/#recommendedversions > [6]: https://weather.torproject.org/subscribe/ > > Miscellaneous news > -- > > Nathan Freitas announced [7] the third (and probably final) release > candidate for Orbot 13.0.6: “The big improvements in this build are a > fix for the disconnected UI/activity (Tor is on, but UI shows off), and > improvements to the transparent proxying iptables scripts”. > > [7]: > https://lists.mayfirst.org/pipermail/guardian-dev/2014-April/003436.html > > The Tails developers put out two calls for testing: the first [8] is for > the first release candidate of Tails 1.0; while the second [9] is for > UEFI support, which “allows you to start Tails using a USB stick on > recent hardware, and especially on Mac”. “Test wildly”, and report any > bugs you find! > > [8]: https://tails.boum.org/news/test_1.0-rc1/index.en.html > [9]: https://tails.boum.org/news/test_UEFI/index.en.html > > Andrea Shepard sent [10] a list of 1777 fingerprints for relays “which > have ever turned up as potentially exposed by Heartbleed”. It appears > that enough directory authority operators now reject relays known to be > problematic [11]: sssheep reported [12] that the still-vulnerable > section of the network was down to 0.01% of the consensus weight. > > [10]: > https://lists.torproject.org/pipermail/tor-relays/2014-April/004340.html > [11]: > https://lists.torproject.org/pipermail/tor-relays/2014-April/004362.html > [12]: https://lists.torproject.org/pipermail/tor-talk/2014-April/032762.html > > Mick drew attention [13] to the fact that in its current state, arm [14] > — the command-line relay status monitor — wrongly advises relay > operators to run it with the same user as Tor, in order to access > information about the relay’s connections. This is in fact a very bad > idea, and a ticket [15] is already open to address this issue. Lunar > detailed [16] the correct method of doing this, which is also explained > in the ticket. > > [13]: > https://lists.torproject.org/pipermail/tor-relays/2014-April/004414.html > [14]: https://www.atagar.com/arm/ > [15]: https://bugs.torproject.org/10702 > [16]: > https://lists.torproject.org/pipermail/tor-relays/2014-April/004412.html > > On the tor-relays mailing list, David Stainton mentioned [17] his Tor > role [18] for the Ansible [19] automation tool. David hoped that “relay > operators will find this useful for deploying and maintaining large > numbers of Tor relays and bridges”. The documentation specifies that it > currently works with Debian and Ubuntu systems, and contains several > configuration examples. > > [17]: > https://lists.torproject.org/pipermail/tor-relays/2014-April/004373.html > [18]: https://github.com/david415/ansible-tor > [19]: http://www.ansible.com/ > > David Fifield continued his progress on meek [20], a pluggable transport > “that routes your traffic through a third-party web service in a way > that should be difficult to block”. David sent a call for wider
Re: [tor-talk] Disabling the warning for self signed certificates in Tor Browser
On Wed, Apr 23, 2014 at 09:07:02AM +, antispa...@sent.at wrote 2.2K bytes in 0 lines about: : A self-signed certificate is better than no certificate. Given the : trouble with a CA, it might be just as good as a CA certificate. Perhaps a better complaint for Mozilla than Tor. -- Andrew pgp 0x6B4D6475 -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] heartbleed: ETA for tor release(s) that blacklist affected directory authority keys? (#11464)
21/04/14 12:27, Nusenu wrote: > Hi, > > the code to blacklist heartbleed affected tor directory authority keys > has been merged about a week ago [1]. > > Do you have an ETA on when you are going to release it (tor and TBB > packages)? As the release manager for the Tails 1.0 release I'm also interested in an ETA for this. Ideally the Tails image intended for the 1.0 release will be built on 2014-04-27 (so this is when we'll truly freeze the version of Tor), and released two days later. We Tails developers would find it sad if its core piece of software becomes out-dated immediately or even just shortly after that. Nick (or any one else in the loop), do you have any idea of timings for the next stable Tor release? Cheers! -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] heartbleed: ETA for tor release(s) that blacklist affected directory authority keys? (#11464)
On Wed, Apr 23, 2014 at 10:28 AM, anonym wrote: > 21/04/14 12:27, Nusenu wrote: >> Hi, >> >> the code to blacklist heartbleed affected tor directory authority keys >> has been merged about a week ago [1]. >> >> Do you have an ETA on when you are going to release it (tor and TBB >> packages)? > > As the release manager for the Tails 1.0 release I'm also interested in > an ETA for this. Ideally the Tails image intended for the 1.0 release > will be built on 2014-04-27 (so this is when we'll truly freeze the > version of Tor), and released two days later. We Tails developers would > find it sad if its core piece of software becomes out-dated immediately > or even just shortly after that. > > Nick (or any one else in the loop), do you have any idea of timings for > the next stable Tor release? My goal is to get out a new alpha with the blacklist this week, and an 0.2.4 release by the end of the month. This is a goal; I don't know if I'm going to be able to make it, and I can't make mpromises there. If you like, it could be entirely reasonable to backport the code in question; the relevant commits are: 50ad3939242885b1a1a11688abd0c9756631747f 46cf63bb42f2818201bc0c39036f2c17e210fcdb 2ce0750d21d04c39a5a948b3d96203d8f68ae7ad ef3d7f2f97caf961effd7935dd3231e6bba62ca5 best wishes, -- Nick -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] US ip address
I would like to change to an US Ip address when I want to? possible? -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] US ip address
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 4/23/2014 5:58 PM, Ted Jackson wrote: > I would like to change to an US Ip address when I want to? > possible? > You can set a static exit node in your torrc but that is not recommended at all as it will have impact on your anonymity. Always remember that Tor works for you best when you use it as it comes "out of the box" with no customization whatsoever - this will camouflage you with the other many users, making something customized puts a highlight on you and individualizes you from the users. So, you can set an US relay as your default exit relay to use only that US IP address, but you are doing the wrong thing. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBCAAGBQJTV+BlAAoJEIN/pSyBJlsRMm4H/iRKjhnJ1y7626/UpoX3tE7O fVA/lntdhepVDKcmgvzHJQscXSvXbC/ID7cJP7pgpIKlzbQ7QnDwyFAyUEbWVzUv bT1L201mOn3Fj4KukWoGYF17x40s7kHALvPVXRrIVcRQryQ/tMwNrFhMjptzylH8 4tSftsfCEsSdNuPaybrPMI5T74ExuumiLk5kyP8lofMBLqCAjO3+BA2Lp9Sy+ug5 vNNzU92NbrbAYcNCYOBbto2xtDpvlsu84XfRBGJB7sqXgX/nf5Yb9I1RppqvZoEb 5NHhFlFnZz16YpGpjL17b1djVvE6HUHz9fIV978U/GA58Ioe9cisvkfKiXfJAJ4= =0U9t -END PGP SIGNATURE- -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] heartbleed: ETA for tor release(s) that blacklist affected directory authority keys? (#11464)
23/04/14 16:51, Nick Mathewson wrote: > On Wed, Apr 23, 2014 at 10:28 AM, anonym wrote: >> 21/04/14 12:27, Nusenu wrote: >>> Hi, >>> >>> the code to blacklist heartbleed affected tor directory authority keys >>> has been merged about a week ago [1]. >>> >>> Do you have an ETA on when you are going to release it (tor and TBB >>> packages)? >> >> As the release manager for the Tails 1.0 release I'm also interested in >> an ETA for this. Ideally the Tails image intended for the 1.0 release >> will be built on 2014-04-27 (so this is when we'll truly freeze the >> version of Tor), and released two days later. We Tails developers would >> find it sad if its core piece of software becomes out-dated immediately >> or even just shortly after that. >> >> Nick (or any one else in the loop), do you have any idea of timings for >> the next stable Tor release? > > My goal is to get out a new alpha with the blacklist this week, and an > 0.2.4 release by the end of the month. > > This is a goal; I don't know if I'm going to be able to make it, and I > can't make mpromises there. Thanks for letting us know! > If you like, it could be entirely reasonable to backport the code in > question; the relevant commits are: > > 50ad3939242885b1a1a11688abd0c9756631747f > 46cf63bb42f2818201bc0c39036f2c17e210fcdb > 2ce0750d21d04c39a5a948b3d96203d8f68ae7ad > ef3d7f2f97caf961effd7935dd3231e6bba62ca5 Given the planned release date for Tails 1.0, this actually doesn't look too bad a compromise. I had a quick look at the other tickets tagged `024-backport` and nothing seemed very important. However, before deciding on this, I'd really appreciate a confirmation from any of you Tor devs that, as it looks now, the next 0.2.4 release will have no other important security fixes affecting *Linux* *clients*. So, will it? Cheers! -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] heartbleed: ETA for tor release(s) that blacklist affected directory authority keys? (#11464)
On Wed, Apr 23, 2014 at 12:46 PM, anonym wrote: [...] > Given the planned release date for Tails 1.0, this actually doesn't look > too bad a compromise. I had a quick look at the other tickets tagged > `024-backport` and nothing seemed very important. For future reference, don't just look at 024-backport -- that's for tickets that are currently in 0.2.5 or later but which should (maybe!) get backported to 0.2.4 after a fix. Also look at the tickets in milestone "Tor: 0.2.4.x-final": those include ones that were never marked as backportable when they were in 0.2.5, but which, after resolving them, somebody decided we should consider for backport anyway. (It doesn't make a difference in this case, IMO, but it's something to be aware of.) > However, before > deciding on this, I'd really appreciate a confirmation from any of you > Tor devs that, as it looks now, the next 0.2.4 release will have no > other important security fixes affecting *Linux* *clients*. So, will it? It depends what you consider a "fix" versus a "feature", and what you think is "important". The only ones I'd consider to maybe meet your criteria are: #9386 #11438 -- those two will make clients significantly more resistant to using bad cryptography at the TLS layer. Also -- since you're asking for a solid confirmation here -- I need to insert the disclaimer that this is only based on what I know about today. I might be forgetting something, and we might learn about something tomorrow that would change all of this. In other words, it's a prediction, not a promise. ;) best wishes, -- Nick -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Disabling the warning for self signed certificates in Tor Browser
Andrew Lewman: > On Wed, Apr 23, 2014 at 09:07:02AM +, antispa...@sent.at wrote 2.2K bytes > in 0 lines about: > : A self-signed certificate is better than no certificate. Given the > : trouble with a CA, it might be just as good as a CA certificate. > > Perhaps a better complaint for Mozilla than Tor. My thinking was if that does not work with the Tor team which is quite security oriented, there's no hope with the Firefox. After all geolocation and other tie ins with google are a priority for them. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] US ip address
On 4/23/2014 10:48 AM, s...@sky-ip.org wrote: On 4/23/2014 5:58 PM, Ted Jackson wrote: I would like to change to an US Ip address when I want to? possible? You can set a static exit node in your torrc but that is not recommended at all as it will have impact on your anonymity. Follow up to Ted's question. I assume he meant "use US exit relay." What of those that create & then login to webmail accts using Tor? Some providers / servers make it very hard to login, if using exit relays different from the country used when creating the acct. Some providers might not allow access at all, if using exit relays in *specific* countries. Sometimes providers will present captchas or ask you to answer your security question, if the exit relay is different than when creating the acct. Sometimes, it just seems to fail. I suppose one way around this is use encrypted mail & don't worry about anonymous login. But one may want to send messages from "anonymous location / source," to persons that can't handle encrypted messages. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] US ip address
On 04/23/2014 04:58 PM, Ted Jackson wrote:
> I would like to change to an US Ip address when I want to? possible?
You can ask Tor to only use US exits, but this reduces your anonymity in
unclear ways.
ExitNodes {us}
--
Moritz Bartl
https://www.torservers.net/
--
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Disabling the warning for self signed certificates in Tor Browser
On Wed, 23 Apr 2014 09:07:02 + antispa...@sent.at wrote: > Georg Koppen: > > antispa...@sent.at: > >> Could Tor Browser kill or minimize the warning triggered by > >> entering a site with a self signed certificate? > > Killing is not a good idea. What do you mean with "minimize"? > > A self-signed certificate is better than no certificate. Given the > trouble with a CA, it might be just as good as a CA certificate. Or better? The certificates handed by the US government through its cronnies are compromised. A self signed certificate from a honest provider, less so. > > Anyway, This Connection is Untrusted. Good. The Aholes from Firefox > never bothered to write the same warning about plain HTTP connections. > Ain't it funny? I know at least a dozen sites that do password > authentification through HTTP. Are they any better? > > And I can't just browse the site after that warning. I can go to > disney.com with "Get me out of here". > > Than there is that user friendly "Technical Details" which would make > any granny click and get her glasses on 'cuz it's time to check the > signatures. Maybe for you, the tech guys, that means something to be > thankful for being so easy to reach. I don't think that the Iranian > disident or the Turkish journalist would feel the same next time. > > I click I understand the risks. And nothing. I acknowledged the risk. > Yet the browser won't let me proceed. So you have two extra paragraphs > of curses. If they were so interesting, why aren't they on the first > page? > > So finally I can add an exception. Which I have to confirm. > > Why not something like the NoScript banner/warning? > > Why not the same curses on ANY unencrypted page, or at least those > that present the user with a password field? > > I checked that with Autistici.org. They have a wonderful AES 256bit > key. All my online banking is done over RC4 128bit at best. That is > as strong as Wikipedia! Autistici.org does generate that need for > three extra pointless clicks. Any of my banking sites generates > nothing. Any of the sites and forums that do authenticate through > HTTP generate nothing. > > Sure it sounds like a conspiracy. But why feed the dangerous game of > the CAs? Why do the free software has to fill the pockets of these > companies? Why kick the sites that do care about their users in the > teeth unless they pay for the CA ransom? > -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] US ip address
Would it be possible to tell tor to use a specific exit node (or exit
country) for a specific subset of websites (I don't know if this is Ted's
specific use case), but for example if I was in Europe or Asia and wanted
to watch my normal Hulu shows and wanted tor to act normally for everything
else.
---
-ITG (ITechGeek)
i...@itechgeek.com
https://itg.nu/
GPG Keys: https://itg.nu/contact/gpg-key
Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A
Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook:
http://fb.me/Jbwa.Net
On Wed, Apr 23, 2014 at 6:09 PM, Moritz Bartl wrote:
> On 04/23/2014 04:58 PM, Ted Jackson wrote:
> > I would like to change to an US Ip address when I want to? possible?
>
> You can ask Tor to only use US exits, but this reduces your anonymity in
> unclear ways.
>
> ExitNodes {us}
>
> --
> Moritz Bartl
> https://www.torservers.net/
> --
> tor-talk mailing list - tor-talk@lists.torproject.org
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>
--
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] US ip address
That isn't what I'm running Tor relays for. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] US ip address
That was just the first example that came to mind and that most people are familiar w/ of something that is targeted geographically, but there are other things that are targeted geographically. --- -ITG (ITechGeek) i...@itechgeek.com https://itg.nu/ GPG Keys: https://itg.nu/contact/gpg-key Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: http://fb.me/Jbwa.Net On Wed, Apr 23, 2014 at 8:26 PM, I wrote: > That isn't what I'm running Tor relays for. > > > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] US ip address
Yes, I would recommend an option to select country, with the dropdown indicating how many exit nodes that would mean you would be rotating through. Start with a list of continents, followed with a list of countries. That would be something that a control panel would make easier to implement. -- Christopher Booth From: ITechGeek To: tor-talk@lists.torproject.org Sent: Wednesday, April 23, 2014 9:11 PM Subject: Re: [tor-talk] US ip address That was just the first example that came to mind and that most people are familiar w/ of something that is targeted geographically, but there are other things that are targeted geographically. --- -ITG (ITechGeek) i...@itechgeek.com https://itg.nu/ GPG Keys: https://itg.nu/contact/gpg-key Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: http://fb.me/Jbwa.Net On Wed, Apr 23, 2014 at 8:26 PM, I wrote: > That isn't what I'm running Tor relays for. > > > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
