Re: [Tails-dev] Following additions are needed in the standard tails software
Hi,I think that passing your traffic through a VPN before Tor will not lead to any improvement in privacy, security or performance. Regarding the firewall, Tails already makes use of iptables/nftables. Regarding SSL enforcement for HTTP browser connections, use HTTPS Everywhere, which offers such an option cross-platform. Best regards Tobias Frei On Aug 17, 2019 20:04, Artorius K4M1 via Tails-dev wrote:1{ windscribe vpn; increase the layers (vpn - tor - source) 2( some firewall software that asks you when a new connection is being made3= ssl enforcer is available for windows and Mac maybe also for Debian? 4 = I'll let you know later Sent from ProtonMail mobile___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [SPAM] Re: Regarding position
Maybe that's why I have sometimes been unsubscribed for message bounces. I wonder if server side filtering of the filetype used here could be useful, and what the legal implications of filtering are. On Tue, Mar 12, 2019, 23:19 Peter N. Glaskowsky wrote: > I hope I don’t have to tell any of you DON’T OPEN THIS FILE. > > . png > > > On Mar 12, 2019, at 2:39 PM, Angie Pirkle > wrote: > > > > How's your day going? > > My name is Angie Pirkle and I'm interested in a job. > > > > I've attached a copy of my resume. > > The password for the document is 1234 > > > > > > Looking forward to hearing back from you! > > > > -- > > Angie Pirkle > > ___ > > Tails-dev mailing list > > Tails-dev@boum.org > > https://www.autistici.org/mailman/listinfo/tails-dev > > To unsubscribe from this list, send an empty email to > tails-dev-unsubscr...@boum.org. > > ___ > Tails-dev mailing list > Tails-dev@boum.org > https://www.autistici.org/mailman/listinfo/tails-dev > To unsubscribe from this list, send an empty email to > tails-dev-unsubscr...@boum.org. ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Advertising Inquiry - CyberGhost VPN \ Tails.boum.org
Hello Mr. Nahmias, please do not spam this development mailing list. It is extremely unlikely that a Tor-based Linux project is interested in advertising your VPN. If your company is interested in supporting this project and its users, a good way to do so would be running servers for the Tor network. Your company is likely capable of doing so. You could use your company's name as relay name to gain publicity that way. Best regards, Tobias Frei On Wed, Aug 8, 2018, 17:19 Shay Nahmias wrote: > Hi guys, Hope all is good. > > > > My name is Shay and I'm affiliate manager at *CyberGhost VPN*. > > > > *I would like to check the opportunity of advertising our VPN on your > website.* > > > > We are offering secured and anonymously surfing online which can be > relevant for your audience. > > > > We can cooperate in many ways like Banner \ Exit-Pop \ Product Review \ > Article about VPN etc.. > > > > We can also give a special deal for added value to your users. > > > > I can tell you that CyberGhost VPN is on the Top 5 best VPN's in the > industry. > > > > *We support: *7 devices (the highest in the industry) \ 2,700+ IP's & > Servers worldwide \ More than 60 countries & many other advantages. > > > > At the moment we have more than 15,000,000 active users all over the world. > > > > Waiting for your feedback, > > > > #You can also add me on skype – shay.nahmias1 > > > > Thanks, > > > > * Shay Nahmias **|**Publisher Relations Manager* > > [image: https://account.cyberghostvpn.com/2.0/img/logos/cg_withtext.png] > > [image: cid:image009.jpg@01D39B5C.6096FA00] sha...@cyberghost.ro > <%20%20sha...@cyberghost.ro> > www.cyberghost.com > [image: cid:image011.jpg@01D39B5C.6096FA00] shay.nahmias1 > > [image: cid:image019.png@01D39B50.8B8D5260] > <https://www.facebook.com/cyberghostvpn> [image: > cid:image020.png@01D39B50.8B8D5260] > <https://www.linkedin.com/company/2309944/> [image: > cid:image021.png@01D39B50.8B8D5260] <https://twitter.com/cyberghostvpn> Trade > Register No.: J40/1278/2011 | UDI/VAT ID: RO28003392 > > > ___ > Tails-dev mailing list > Tails-dev@boum.org > https://mailman.boum.org/listinfo/tails-dev > To unsubscribe from this list, send an empty email to > tails-dev-unsubscr...@boum.org. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] DeepOnion project
Advertisement?! Where is this going at? On Tue, Jul 17, 2018, 18:52 Vaas ! wrote: > Hi Tails Project, > > We are glad to let your Team know that we were working on the Debian > Repository in the last months with our Development Team and we did a lot of > progress on it. We took your words about doing something first as a way to > earn the trust from your members and who that we want to help and build > something for the good of all with real commitment. > Right now we are even looking for a mentor for Debian (I don't know if > some people from your Team can help us with this) but all the hard work > seems to be done and we are on the testing phase. > We would like to know if one of your Team would like to Talk with us on > Wire, we can set a meeting with our Developers for testing purposes and > then, we can cooperate together for donations (we would like to donate to > your project in reward for some advertisement) and even future improvements. > > Hope we can get in touch soon and again, thank you so much for your time. > > Best Regards, > Vaas, DeepOnion.org Moderator. > > > On 22 May 2018 at 03:51, Vaas ! wrote: > >> Thanks for your quick response and sorry for writing you back a bit late. >> >> I have been talking with our Developers and they started to work on the >> Debian Repository, we hope this cycle can be good for both of us. >> >> I will send you more details in the future. >> >> Best Regards, >> Vaas, DeepOnion.org Moderator. >> >> >> On 7 May 2018 at 08:10, intrigeri wrote: >> >>> Hi, >>> >>> Vaas !: >>> > In the past I contacted your project regarding to donations for your >>> > platform, DeepOnion is an anonymous Cryptocurrency that uses Tor and we >>> > have been donating to the Tor project just to be grateful for their >>> > development, also helping with more Nodes to the network. >>> >>> > People from the Tails Project said that it could work if we create a >>> Debian >>> > Repository for it since your software uses Debian and we can handle >>> this >>> > with our Development Team. I just want to update our conversation, to >>> know >>> > if we should go on with this Development and also if you can consider >>> to >>> > use our Wallet in your pre installed apps (maybe some download app) >>> from >>> > your OS in the future (of course this is not something that you must >>> do but >>> > we would be happy for it since some of our users use Tails). >>> >>> There are two aspects to this: >>> >>> 1. Allowing Tails users to use DeepOnion >>> >>>Once your client software is in Debian (stable or worst case >>>stable backports), then Tails users will be able to easily install >>>and use it. If needed we can ship whatever tiny config file is >>>needed to make it go through Tor so that it works out of the box. >>> >>>Creating a third-party Debian repository would also work but using >>>that is much harder (for Tails users) to set up and the amount of >>>trust they have to put into your project and its infrastructure is >>>much greater. So this might be a reasonable first step but I would >>>suggest you don't stop and that and instead include your software >>>in Debian proper :) >>> >>> 2. Accepting donations to Tails with DeepOnion >>> >>>It seems that every cryptocurrency project around there has been >>>getting in touch with us in the last 2 years, requesting that we >>>accept donations made with their tool. We work with limited >>>resources and can definitely not support them all. If somebody >>>built an unbiased comparison that allowed us to draw a conclusion >>>like "it would be worth the effort to support cryptocurrency X, >>>here's how you would do it" then we might do it. But so far I've >>>not seen this happen. Needless to say, members of cryptocurrency >>>projects are not the best placed people to build such an unbiased >>>summary :) >>> >>>And most of the time, to accept such donations we would need to run >>>software ourselves that's not in Debian, which our internal teams' >>>security policy forbids ⇒ point #1 above is relevant here as well. >>> >>> Cheers, >>> -- >>> intrigeri >>> >> >> > ___ > Tails-dev mailing list > Tails-dev@boum.org > https://mailman.boum.org/listinfo/tails-dev > To unsubscribe from this list, send an empty email to > tails-dev-unsubscr...@boum.org. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] DeepOnion project
Hi, Are cryptocurrencies really still a thing? What would one do with them, other than trying to sell them to "even more silly" people until the pyramid scheme collapses? Which goods that are really useful to me can I buy using your currency, and why would I use it instead of real money or gold? I personally am not worried about your usage of the Tor network either, because every single YouTube user will likely cause more traffic in five hours than this cryptocurrency will until it is abandoned and considered to be "not cool enough anymore" by its initially enthusiastic developers. ;) Best regards Tobias Frei On Thu, May 3, 2018, 04:20 Vaas ! <vaas...@gmail.com> wrote: > Greetings Tails Project, > > In the past I contacted your project regarding to donations for your > platform, DeepOnion is an anonymous Cryptocurrency that uses Tor and we > have been donating to the Tor project just to be grateful for their > development, also helping with more Nodes to the network. > > People from the Tails Project said that it could work if we create a > Debian Repository for it since your software uses Debian and we can handle > this with our Development Team. I just want to update our conversation, to > know if we should go on with this Development and also if you can consider > to use our Wallet in your pre installed apps (maybe some download app) from > your OS in the future (of course this is not something that you must do but > we would be happy for it since some of our users use Tails). > > We aim to create a good relationship with other open source projects and > we invite you to visit our Community. > > https://deeponion.org/community > > Since 40 weeks we are working to build this project and maybe that can > help to show our commitment. > > Best Regards, > Vaas, DeepOnion.org Moderator. > > ___ > Tails-dev mailing list > Tails-dev@boum.org > https://mailman.boum.org/listinfo/tails-dev > To unsubscribe from this list, send an empty email to > tails-dev-unsubscr...@boum.org. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] BIOS attack
Hi, "in all likelihood": When you hear hoofbeats, think of horses not zebras. ;) https://en.wikipedia.org/wiki/Soft_error Best regards Tobias Frei On Fri, Feb 2, 2018, 21:50 <james.john.jo...@tutanota.com> wrote: > Thanks Tobias, > It is always good to know that contact has been made. > What a shame that it is not likely to be one of those scenarios that you > outline :( > > I do accept that it could be a bizarre coincidence, but. > > > "While the scenario outlined below is very 'Grand Jeu' I will not be at > all surprised to learn that you believe this to be a hack." > > > This must be taken seriously. > I haven't carefully crafted the email to waste peoples valuable time. > There is every reason to consider the event as a realistic scenario. > > It may not be. > That would be great. > > My problem is that, like most people, I never studied digital security. > I'm having to catch up; but I can't - it's too complex. > > I got Tails, and some secure mailboxes. > However, with hindsight; logically, this is merely a security layer to be > overcome. > > Anyway, my guess is: that is what happened. > > For a variety of reasons, it would be useful to know. > Even if we can't run tests. > > Can such a hack be implemented with a mobile phone? > Is the laptop in all likelihood lost? > > Are there any devs that can answer these questions? > > I'm one of the good guys. > I'd appreciate some help on this :) > > > > > -- > Securely sent with Tutanota. Claim your encrypted mailbox today! > https://tutanota.com > > 2. Feb 2018 19:12 by tob...@freiwuppertal.de: > > > Hey, > > Disclaimer: I am a regular user, not a security expert. I am not a > developer in this project, I'm subscribed to the list because I ran a Tails > mirror for some years. > > Three things that came to my naive mind when reading: > > - Cui bono? > - Hanlon's Razor > - Number of users vs. Coincidence > > Is there any reason for an attack? Does the specific worker have any > theoretical reason to be malicious here? > > Also, when a product is used by a billion people, a bug with a probability > of "only 1:100" will occur about 1000 times. Extremely unlikely > scenarios can suddenly actually happen when many people are using the same > software. It is almost guaranteed that somewhere in the world, an > earthquake will occur in the moment someone starts their computer. The > computer, however, did not cause the earthquake to happen. > > There is a wonderful book called "Spurious Correlations". It makes fun of > exactly this problem. > > Best regards > Tobias Frei > > > On Fri, Feb 2, 2018, 19:40 <james.john.jo...@tutanota.com> wrote: > >> Excuse me - I have joined this group to discuss what may have been a >> 'high end' BIOS attack. >> I am presuming that this group contains the most knowledgeable people. >> I need that. >> >> While the scenario outlined below is very 'Grand Jeu' I will not be at >> all surprised to learn that you believe this to be a hack. >> >> --- >> >> This is exactly what happened: >> >> Laptop circa 2011 (bios date) >> AMD DCP C-50 >> Tails 3.5 loaded from a USB drive >> >> At a friends - laptop on the table in kitchen (pre-arranged over the >> phone). >> Workmen are doing jobs. >> (The IP box can give the WiFi connection at the press of a button) ;) >> >> A Libre Office doc saved in the session - other docs saved on a mounted >> removable drive. >> >> One worker comes in the kitchen - he starts tapping away on his mobile >> (just 3 meters away). >> >> Note - he has no need to be in the kitchen to get a signal - the walls >> are thick, so outside would be better (if you don't have the wifi code). >> >> He makes a final tap, and walks... and my pc shuts down. >> Some code appeared, but it shut down. >> >> Obviously it could be coincidental; but I'm sick of frigging coincidences. >> The shutdown was simultaneous to his final tap on his mobile. >> >> - >> >> Post reboot - no apparent problems, other than it seemed to take slightly >> longer to log into accounts. >> I carried out my communications. >> >> A day later, I posted an email to tails-support-priv...@boum.org (on >> this question). >> I received no reply. >> >> Researched BIOS attacks, and checked my bios version. >> https://www.schneier.com/blog/archives/2015/03/bios_hacki
Re: [Tails-dev] BIOS attack
Hey, Disclaimer: I am a regular user, not a security expert. I am not a developer in this project, I'm subscribed to the list because I ran a Tails mirror for some years. Three things that came to my naive mind when reading: - Cui bono? - Hanlon's Razor - Number of users vs. Coincidence Is there any reason for an attack? Does the specific worker have any theoretical reason to be malicious here? Also, when a product is used by a billion people, a bug with a probability of "only 1:100" will occur about 1000 times. Extremely unlikely scenarios can suddenly actually happen when many people are using the same software. It is almost guaranteed that somewhere in the world, an earthquake will occur in the moment someone starts their computer. The computer, however, did not cause the earthquake to happen. There is a wonderful book called "Spurious Correlations". It makes fun of exactly this problem. Best regards Tobias Frei On Fri, Feb 2, 2018, 19:40 <james.john.jo...@tutanota.com> wrote: > Excuse me - I have joined this group to discuss what may have been a 'high > end' BIOS attack. > I am presuming that this group contains the most knowledgeable people. > I need that. > > While the scenario outlined below is very 'Grand Jeu' I will not be at all > surprised to learn that you believe this to be a hack. > > --- > > This is exactly what happened: > > Laptop circa 2011 (bios date) > AMD DCP C-50 > Tails 3.5 loaded from a USB drive > > At a friends - laptop on the table in kitchen (pre-arranged over the > phone). > Workmen are doing jobs. > (The IP box can give the WiFi connection at the press of a button) ;) > > A Libre Office doc saved in the session - other docs saved on a mounted > removable drive. > > One worker comes in the kitchen - he starts tapping away on his mobile > (just 3 meters away). > > Note - he has no need to be in the kitchen to get a signal - the walls are > thick, so outside would be better (if you don't have the wifi code). > > He makes a final tap, and walks... and my pc shuts down. > Some code appeared, but it shut down. > > Obviously it could be coincidental; but I'm sick of frigging coincidences. > The shutdown was simultaneous to his final tap on his mobile. > > - > > Post reboot - no apparent problems, other than it seemed to take slightly > longer to log into accounts. > I carried out my communications. > > A day later, I posted an email to tails-support-priv...@boum.org (on this > question). > I received no reply. > > Researched BIOS attacks, and checked my bios version. > https://www.schneier.com/blog/archives/2015/03/bios_hacking.html > > Talk of : > "Their exploit turns down existing protections in place to prevent > re-flashing of the firmware, enabling the implant to be inserted and > executed. > > The devious part of their exploit is that they've found a way to insert > their agent into System Management Mode, which is used by firmware and runs > separately from the operating system, managing various hardware controls. > System Management Mode also has access to memory, which puts supposedly > secure operating systems such as Tails in the line of fire of the implant." > > > Also: > "The method used to get at the BIOS then allows the likes of GCHQ et al to > get at other modifiable ROM in the likes of HDs, Sound Chips, Network cards > and other "below the OS" areas. > > Having done this they can then put the main BIOS back the way it was, so > that it's harder to find what they have been up to." > > - > > Rebooted to Tails. > Tails warns: can't check for upgrades. > > Tutanota mailbox warns: Couldn't connect to server - it seems like you are > offline. > But I was online, and could see my mailbox. > - > > First thing is: > Have you received this mail? > Could someone respond, to confirm this? > > Does it seem likely that I have been hacked? > Is there any way of knowing eg. running tests? > If it has been hacked - is the laptop now unusable? > If I was hacked - have they got everything that I've done since that point > (and the data off my drives)? > > I'm cool either way. > What's done is done; but I'd rather know > > BTW, I tried to get a riseup email, but it kept demanding an invite code. > Anyway, I figured that I first need to check with you guys re my current > status, before doing anything else. > > Thanks :) > > -- > Securely sent with Tutanota. Claim your encrypted mailbox today! > https://tutanota.com > ___
Re: [Tails-dev] [RFC] Dropping requirement for OpenPGP communication with HTTP mirror operators?
PS: If the OpenPGP requirement is removed, I'd strongly suggest at least
asking for a confirmation for significant requests (e.g. removal of a
server from the pool). The confirmation should contain a full quote of the
e-mail it is sent in reply to. That way, at least easy spoofing is
prevented. It provides no additional security against a man-in-the-middle
attacker, but sending an e-mail with a forged "From" header is probably
much, much easier ("trivial & legal" vs. "requiring illegal cracking or
being the NSA") than circumventing this additional protection.
2016-03-04 21:39 GMT+01:00 Tobias Frei <tob...@freiwuppertal.de>:
> Hi,
>
> the requirement to use OpenPGP encryption has been somewhat annoying for
> me personally in the past, especially because it did not allow me to read
> mirror-related e-mails (sometimes relatively time-critical ones) on my
> smartphone. This has happened to me on vacation in another country (I don't
> have a laptop) and at the local university, during breaks that I could have
> used to fix a problem if I had known which one it was.
>
> Also, the information shared via encrypted e-mail about my mirror in any
> direction has never been so confidential that encryption would have been
> necessary in my opinion. I know that it is probably best to encrypt all
> communication to prevent an attacker (e.g. NSA) from understanding which
> e-mails are really interesting, but the cost of encryption has outweighed
> the benefits for me so far.
>
> What I'd absolutely keep, though, is the *signing* of e-mails. I need to
> be able to check if a request has really been sent by the undersigning
> person. If can be sure that the request is valid (e.g. "your server is
> down") without verifying the OpenPGP signature, I might react directly
> (e.g. restart the server) instead of verifying the signature. If I can't, I
> must verify the signature.
> Also, I hope that the same level of verification is applied when I send an
> e-mail about my mirror. If I quote the sender's e-mail in my reply and
> simply confirm fixing a problem, checking my signature might be
> unnecessary. If I request the removal of my mirror from the pool, I really
> hope that the request will be properly verified. If my signature is
> missing, I hope that I'd be asked to provide a valid OpenPGP signature, a
> message on my website or whatever else would be sufficient to identify me
> as the sender of the request.
>
> Sending and receiving encrypted e-mails is rather annoying, sending and
> receiving signed e-mails is necessary, I'd say.
>
> Best regards,
> Tobias Frei
>
>
> 2016-03-04 20:18 GMT+01:00 intrigeri <intrig...@boum.org>:
>
>> Hi,
>>
>> We'll soon be in a position to add more servers to the pool of HTTP
>> mirrors that server our ISO images and IUKs. Before I publish the
>> corresponding call for help, and get in touch with operators of
>> potential fast mirrors (#11079), I'd like to make sure we get the
>> requirements right.
>>
>> So far, we (or was it perhaps just me?) have insisted on having a way
>> to communicate using OpenPGP with each operator of a HTTP mirror in
>> our pool. I'm starting to question this. [In case anyone here didn't
>> get that memo: yes, it often takes me years to change my mind.]
>>
>> This requirement has one clear disadvantage: it excludes some fast
>> mirrors, e.g. lots of those that are run in universities (I have to
>> trust people who are more in touch with operators of such candidate
>> mirrors, on this one, as I have personally no idea). Also, on our side
>> it adds to the burden of maintaining our pool of mirrors: maintaining
>> a keyring isn't easy, and it gets quite hard if one wants to try to do
>> it seriously.
>>
>> We are in the process of dropping at least another requirement of ours
>> (the need for a dedicated hostname) that might have been a blocker, so
>> I think it's time to check our list of requirements.
>>
>> I think the main advantages of requiring OpenPGP -enabled
>> communication with mirror operators are:
>>
>> * We can authenticate requests sent to us by mirror operators: e.g.
>>"please remove my mirror from the pool", that could otherwise be
>>used to degrade our pool of mirrors, just by spoofing the sender
>>address.
>>
>>- Are we seriously checking the OpenPGP signature on such requests?
>> I used to do it, and used to require a good trust path for key
>> updates, but I am under the impression that this might all have
>> been handled in a more flexible way recently. sajolida?
>>
>>- Perhaps we would notice
Re: [Tails-dev] [RFC] Dropping requirement for OpenPGP communication with HTTP mirror operators?
Hi, the requirement to use OpenPGP encryption has been somewhat annoying for me personally in the past, especially because it did not allow me to read mirror-related e-mails (sometimes relatively time-critical ones) on my smartphone. This has happened to me on vacation in another country (I don't have a laptop) and at the local university, during breaks that I could have used to fix a problem if I had known which one it was. Also, the information shared via encrypted e-mail about my mirror in any direction has never been so confidential that encryption would have been necessary in my opinion. I know that it is probably best to encrypt all communication to prevent an attacker (e.g. NSA) from understanding which e-mails are really interesting, but the cost of encryption has outweighed the benefits for me so far. What I'd absolutely keep, though, is the *signing* of e-mails. I need to be able to check if a request has really been sent by the undersigning person. If can be sure that the request is valid (e.g. "your server is down") without verifying the OpenPGP signature, I might react directly (e.g. restart the server) instead of verifying the signature. If I can't, I must verify the signature. Also, I hope that the same level of verification is applied when I send an e-mail about my mirror. If I quote the sender's e-mail in my reply and simply confirm fixing a problem, checking my signature might be unnecessary. If I request the removal of my mirror from the pool, I really hope that the request will be properly verified. If my signature is missing, I hope that I'd be asked to provide a valid OpenPGP signature, a message on my website or whatever else would be sufficient to identify me as the sender of the request. Sending and receiving encrypted e-mails is rather annoying, sending and receiving signed e-mails is necessary, I'd say. Best regards, Tobias Frei 2016-03-04 20:18 GMT+01:00 intrigeri <intrig...@boum.org>: > Hi, > > We'll soon be in a position to add more servers to the pool of HTTP > mirrors that server our ISO images and IUKs. Before I publish the > corresponding call for help, and get in touch with operators of > potential fast mirrors (#11079), I'd like to make sure we get the > requirements right. > > So far, we (or was it perhaps just me?) have insisted on having a way > to communicate using OpenPGP with each operator of a HTTP mirror in > our pool. I'm starting to question this. [In case anyone here didn't > get that memo: yes, it often takes me years to change my mind.] > > This requirement has one clear disadvantage: it excludes some fast > mirrors, e.g. lots of those that are run in universities (I have to > trust people who are more in touch with operators of such candidate > mirrors, on this one, as I have personally no idea). Also, on our side > it adds to the burden of maintaining our pool of mirrors: maintaining > a keyring isn't easy, and it gets quite hard if one wants to try to do > it seriously. > > We are in the process of dropping at least another requirement of ours > (the need for a dedicated hostname) that might have been a blocker, so > I think it's time to check our list of requirements. > > I think the main advantages of requiring OpenPGP -enabled > communication with mirror operators are: > > * We can authenticate requests sent to us by mirror operators: e.g. >"please remove my mirror from the pool", that could otherwise be >used to degrade our pool of mirrors, just by spoofing the sender >address. > >- Are we seriously checking the OpenPGP signature on such requests? > I used to do it, and used to require a good trust path for key > updates, but I am under the impression that this might all have > been handled in a more flexible way recently. sajolida? > >- Perhaps we would notice if too many mirrors were removed (this > calls for a monitoring check, I guess), and perhaps mirror > operators would notice if they don't get the traffic they expect? > IOW, perhaps we have other ways to avoid such attacks from being > effective enough to be attractive in the first place. > > * Mirror operators can authenticate instructions we send them, e.g. >"please add this option to your nginx configuration". Without this, >anyone can quite trivially DoS our pool of HTTP mirrors, until >someone notices. The thing is, we have no idea if the operators of >our mirrors check this, i.e. whether they would notice if some >email apparently coming from us was not signed. > > * More? > > I'm now less convinced that these advantages are worth the drawbacks, > and could be ready to drop the OpenPGP communication requirement. > > Thoughts? > > Cheers, > -- > intrigeri > __
Re: [Tails-dev] Resolving the DNS Round Robin limit for mirrors
[Copying this from my bug comment on https://labs.riseup.net/code/issues/8639 because I do not really know if it belongs there, here or both :)] Hi again, I've written a very small and simple PHP draft here: https://tails.boum.org/blueprint/HTTP_mirror_pool/#index4h1 Simplicity might be the best idea, though, as the code needs to be audited (#8640) before it can be used. Best regards, Tobias Frei Am 19.01.2015 um 19:49 schrieb sajolida: Thomas White: Not sure if anyone knows of this, but the following might be a good solution to scale the current mirror system and is used by a number of other open source projects. http://mirrorbrain.org Thanks for your input, We already considered using mirrorbrain and it is already mentioned on our blueprint for a new mirror infrastructure: https://tails.boum.org/blueprint/HTTP_mirror_pool Our current plan is to write a very minimal custom PHP script. The downside of mirrorbrain here is that it's quite big (probably too big for what we want to do) and it's not in Debian, not really authenticated, audited, etc. Still, if we want to further improve our custom script in the future, for example to include load balancing or geolocation, we might end up reinventing partly the wheel when more complex tools such as mirrorbrain already exist. Anyway, I don't feel like I'm the right person to best argue or decide on this. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] TOR browser addon Adblock Plus vs. uBlock
Hi L.R. D.S., Stating your opinion on a controversial topic and announcing to leave the list in the same message feels like someone shouting their opinion into a room full of people and slamming the door from the outside before anyone can react. Also, doing so after someone pointed out to you why your criticism was probably unjustified makes this behavior even more sad, I'd say. I'm sure nobody here thinks that criticism has to be perfect, and I also don't think that - even after your first angry reaction - a calm, objective explanation of the reasons for the criticized current behavior is dodging at all. About the PS, Tails already makes use of iptables to prevent (nearly) any non-Tor traffic from happening. However, using a firewall to block specific web pages will probably not work in the way you might expect it to do - if there is the legitimate site http://example.org/information, and the advertisement banner http://example.org/advertisement.png, then you can't remove that banner by denying access to the IP behind example.org. As far as I know, you could, if the traffic is unencrypted (fails for Tor and even HTTPS itself), use some special iptables rules to intercept all text and block connections that contain what you're looking for. Add 1000 of these rules, and network performance becomes horrible, I guess. DNS solutions additionally fail whenever advertisement hosts are referenced using their IP address instead of their hostname. http://192.0.2.1/advertisement.png evades DNS solutions. For Tails/Tor specifically, there's another huge problem with your suggestion: DNS lookups are performed by the exit node, not your own computer. Else, your DNS provider could easily see which hostnames you look up, breaking anonymity. Connections in general are not made directly to the web hosts, but instead to the Tor entry node, which forwards your request. The only place to implement firewall/DNS adblocking would be the exit node, not the computer running Tails. I'm pretty sure you don't want the exit node operator to decide which hosts you and all other Tor users are allowed to connect to. ;D Without any dodging at all, I hope, this explains why neither firewall nor DNS solutions can be more effective and efficient than a browser addon for blocking advertisements on web pages. After all, use cases like this one are what browser addons exist for. Have a nice day, and feel free to come back whenever you want to. ^.^ Best regards, Tobias Frei [just yet another guest; not an official list admin statement or whatever it might look like.] Am 17.05.2015 um 01:42 schrieb L.R. D.S.: basic guideline: Be excellent to each other. I do not agree with this. I should interpret better these 'sjw' guideline before enter here. By the way, I think you folks are using it to dodge the critic. If you think that a critic need to be excellent in all ways, then you'll never have a real critic here after all. I'll just remove myself from this list to evite more non-excellent mails. ps: A pf firewall or dns filtering would be more effective and efficient then a addon. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Fw: schneier.com comments
Hi bert, thank you very much for the brief explanation. It makes me sad that some people try to make users afraid of using Tails, and it makes me very happy to see that the developers of my favorite USB operating system confront this scaremongering bravely. ^.^ Best regards, Tobias Frei On Tue, Mar 31, 2015, 12:11 bertagaz berta...@ptitcanardnoir.org wrote: Hi, On Tue, Mar 31, 2015 at 06:27:43AM +, goupille wrote: Hi! a user send us that... cheers. Begin forwarded message: FYI from last 100 comments @ Schneier.com: This is FUD someone is spreading since some time on the schneier website comments. She didn't read the warning on top of the tails-autotest-remote-shell script probably: # ATTENTION: Yes, this can be used as a backdoor, but only for an # adversary with access to you *physical* serial port, which means # that you are screwed any way. Whisperback send *encrypted* messages to us through hidden services. If someone is able to change its behavior, is that she is root on your machine and thus you have other problems. The same apply for the do_not_ever_run_me script. I don't know what I'm speaking about, I've just read the script name. You are warned. Would be a more correct quote rather. :) bert. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Shared screen locking solution for live distributions in Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi sajolida, I love this idea and have always been looking for exactly such a solution. On Tails, I am currently using xlock with a custom administrator password; here on my Ubuntu PC, xlock does not even seem to be an existing package. It would be awesome for me to have a working screen locking tool shipped with Tails; preferably one that asks me for the used password before locking the screen. The icing on the cake might be the possibility to define a password that will be used for locking if the computer has not been used for an user-defined amount of seconds. In my opinion, the password should be stored using a strong hashing algorithm that may well take some seconds to be calculated - the legitimate user can afford waiting some seconds after entering the password to unlock the screen; an attacker should have a hard time extracting the screen lock password even if the built-in software security mechanisms are somehow circumvented. But I'm not a security expert and maybe this would just be an illusion of security without actual benefits. Best regards, Tobias Frei Am 31.12.2014 um 15:03 schrieb sajolida: Hi, I'm part of the people working on Tails, a live distribution that aims at preserving privacy and anonymity: https://tails.boum.org/. Tails is currently lacking a screen locker and this has been a frequent feature request. See https://labs.riseup.net/code/issues/5684. For example, as Tails is been adopted more and more by journalists, they want to be able to leave their computer unattended in their office to go to the toilets for a minute and have their screen locked. I'm writing this emails to various Live distributions based on Debian (Knoppix, Grml, Jondo, Kali, Debian Live, and Tanglu). I'm also putting Micah Lee in copy as he has shown particular interest in this feature. I've been investigating the screen locking mechanism of those various Debian based live distributions, and I found out that none of them had a real mechanism to do so. They either: - Do not provide any screen locking mechanism (Knoppix, Grml, Jondo Live). - Either rely on their default password to unlock the screen (Kali, Tanglu, Debian Live). The purpose of this email is to know whether you would be interested in working on a common Debian package to provide a generic screen locking solution for Debian based live distributions. The core usability issue that we are facing here is the one of the unlocking password. As we are live distributions, there either is no password or a default one. Still, screen locking only make sense if the user is able to use a custom password. As an interesting exception, note that in Jondo Live, the user is prompted for a user password on boot. In Tails the user can set up an administration password but this is disabled by default for security reasons so we cannot rely on this for screen locking. During our last monthly meeting we came up with the idea of asking for a custom password *in the process of locking the screen* for the first time. For example, in GNOME, when doing Meta+L for the first time, the user would be prompted to enter a screen locking password, then only the screen would get locked. If she locks the screen again, the same password would be reused. What do you think? Please answer to tails-dev@boum.org and feel free to subscribe to the list to follow the thread: https://mailman.boum.org/listinfo/tails-dev/ -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUpBdGAAoJEOaAxTHjKzK7LFUP/1eiRFz0ZxYMI8V9Y5OYHeDP W/jq+jCOgkAo3YUxb/4rZPvIEjWw+5kC93bDDlIDsDQUsM2fi6dhgbNyeNOM6NTF zaQ/nfHRc0OGKjM738/ar91MC5BXVMhctYRSE7423bO6ZxEHRIY1dSW34YhpGgzn e7WN6kXegEsY2yYmxzrep/UbiE61TeIwsGbkOG+l/JX82pLXb/IYJ7q3ML8xMc2v jynU162L0bRrxzY9eG+VTZZCGsu8hUfUUukmQqAF7v42/557TuWoHZX2rK3+cvkE BsHwrzvXAPVx+4wBDnfAplUmcLDJ0oMs21SwiVq54PDb3QMC/oBvYOQtQCEIearN ZZCPjtnpwmy5qkq0CHu2nfzpm4CDqK9jT0wY+UqCtAb5+YSF1p6D2O5tW3ywhH4L viMzJosUZxeiK7Lr166gl7ti2tiChy8gi2Fwp4nJJf2b2ZBg6DuRYlQxP8BiqBKA FkWYdFpp+mL5kfU/fmGryofGx/oU00y1xcFM2katkJoeMjq+X1jbxKkwS2MIBuqv K7ZeIhtvMWqZyUPq4a6yvurhVOTin1cxSjg4VpB9Lpfi53JC3xfiue5CW6W42N9f tyIfQTO8PtVcjgGJgdI3hb5utBb01j8KmrliFjO1sJKjRfcQmCVWog2tgPWeYpds 6QrhfTj3XDVx+1gB4XZc =u2/+ -END PGP SIGNATURE- ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Cloudflare
Hi x3dre, what I was trying to say is that you probably don't give up your anonymity just because you enter a CAPTCHA. How would a CAPTCHA break your anonymity in any way? All information you give to someone offering a CAPTCHA is that you are not a bot. You're one of these 7 billion people on Earth, that's all a CAPTCHA will reduce your anonymity to, as far as I know. ;) Best regards, Tobias Frei Am 07.10.2014 um 17:38 schrieb x3...@unseen.is: On 06/10/2014 08:42 PM, Tobias Frei wrote: Hi x3dre, On 06.10.2014, 16:26, x3...@unseen.is wrote: [...] Though having to authenticate oneself as a Human means you're giving up your anonymity, even using TOR ... You're giving up your anonymity by entering a CAPTCHA? :) Yes I am having to do just that to many sites now that is coming under the cloudflare banner. Here is one for example http://www.change.org/p/2108459?share_id=YwVZVdJmzzutm_campaign=share_button_action_boxutm_medium=facebookutm_source=share_petition If I browse in the unsafe or standard iceweasel browser I do not get challenged. I only get challenged using the TBB or Tails. The exit node will be discovered in the process.. The list of exit nodes is already public. https://www.torproject.org/docs/faq#HideExits Best regards, Tobias Frei ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Cloudflare
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi x3dre, On 06.10.2014, 16:26, x3...@unseen.is wrote: [...] Though having to authenticate oneself as a Human means you're giving up your anonymity, even using TOR ... You're giving up your anonymity by entering a CAPTCHA? :) The exit node will be discovered in the process.. The list of exit nodes is already public. https://www.torproject.org/docs/faq#HideExits Best regards, Tobias Frei -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUMvCQAAoJEOaAxTHjKzK7u/AQAJ9YPJlNSnRC3FEqrPvKMIG4 Ik+wPiCh27XDkwILbDZc9EnhIbjIvBmTb+zZsZW5wAtk606OnjEYU6ee0UxLU3PN Gy1MB+VAqjsnfSDS2Jq3MCMSfyJXM9MzaR1FwUq82AmV0Vbr1VzNEXrgAo8CoTeF eul9pKmFRQPS51ePMIPyRYu297BD1bmdFHsRNYINk3ldUli5+JPw+h2A+yboqAB3 zSd7XxY8JWiDydveiGJhdxePUoq0DK2rP/kyTfVXD795z/1+SLvZLrBeNxSk0HH9 nVFbw9Jr/U9PFuV3qTvzON5dt3hm2UsBlAJyvrdoVBBenLvmUbvk4kLEjfnnMSnQ GW/ecFqrhldp6Yd2rfLL26QgQRN9sVZxshl7j4HkiW+2VImZ8ffJsOnPLxacpSED wMGSA3gdCokh4saf1zaT0tCAtvccRtMf/DZbcMehBdlfSq28sEGZGkReMV0KSmzn kBfOxJyUcRNV6dwJ0Og1kDfUzsK/gTIs2gmttesnZmKa22e/E7dRfBY6FhFrMQEX 4X1NGNMVFbgdmaIM0w2lVnbRpuCirbI00hAkgaPLSgq2eYsbwm6be6zL3xfM50fp OAbII3I3sn161sGxMI7ALZ3YBfk7pWmU2PMGOyBxmYpZn0sVXRWOLnM7fUYe3PJh nw4YXAlNlxqKloD8mYcL =60+B -END PGP SIGNATURE- ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [SPAM] Presentation Accueil Proprete
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I just noticed* how easy it is to report this spam to the sending e-mail provider using SpamCop (spamcop.net); all you need is to disable all report addresses which were triggered by the https://mailman.boum.org/listinfo/tails-dev; link, as boum.org is obviously not the origin of this spam. If multiple people report it, it might cause an automatic blacklist entry on the SpamCop blacklist to be created, and maybe the provider is more likely to understand that this is actually unsolicited bulk spam. The provider can easily inform SpamCop that this issue has been dealt with, so that no further reports will be sent. Providers which do not want to receive this kind of reports can also easily opt-out, so we won't be sending abuse reports to people who would be annoyed by them. Even if you decide not to report this spam now because I already did so, I hope this might be an useful resource for reporting further spam. Best regards, Tobias Frei *(I was mostly surprised that SpamCop works on mailing lists too) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJT9QrsAAoJEOaAxTHjKzK7YrgP/1DsdIlSzflozThRPAmfvvRt LsvE6k/8XbayvrEV4WnUGHyKHXPAGsfQe5sW721oI2u96Pas5s+u8g5teyw1+Tfa zTVX0pHBcxqzTIRzmq4LIaX/zwbnpNGZDyWFf3ND/FLtVm5tIzYFswQpQ3WQZ+t0 A5irs7g207Rt03tv1XnHsnyu8zU/rlSp3gEN28LEETX8Q//XiXX9A0ONdQevABb5 sB2VM1S2rRWXSIMFrjBcNTPBV6GEgui2AFScgP5ufM7zo6mh7u29VJZjl8bxoJa/ joZ2Y/zzPwnge5nwMbHZmC8kxJF0eEG8sTq8Lu4OdpY8a/BTcSsTAdgJKAb8GvIU SKbxWSph1jlMypF65fAdeSPhzWRSlF9gUCV0uQ+n61gVaJEmXUBFcQARAWrNfN25 2nywXvsHdi4d7Bh6wJxGQJLEeYjwpPDcRawpPsFI+nm4huOZll0EoS2OMzEPSRLN LvBfXIa8VEhSZL5H6VWdJ47shsqLXRM52Fg3dVaMr39dLolwk38Ytt+u2MAWKkwP cuUJaJMLzFLefXdkM77BBQPl/40msvwP0n2ke8My08oDTpmAZpqcrkr860UJLXXj 3Jy1MWV+sT5j6hLpD85uiokZ7AzysqNdLDBETDx/etg6fwP6NIiW1yEorO/TKQ6J HXyMeDnW7oO5hqDWwU49 =fE7L -END PGP SIGNATURE- ---BeginMessage--- Cette newsletter vous a été envoyée au format graphique HTML. Si vous lisez cette version, alors votre logiciel de messagerie préfère les e-mails au format texte. Vous pouvez lire la version originale en ligne: http://ymlp320.net/z7o9Mg Mesdames, Messieurs, En cette période difficile, il est important de mettre en avant votre image de marque tout en misant sur un service de qualité à des prix très compétitifs !!! Pour celà, nous vous proposons notre nouvelle grille des tarif au rabais pour les prestations suivantes : - Nettoyage des locaux / immeubles / parkings / entrepôts - Nettoyage des vitres - Nettoyage à haute pression - Décapage des sols (cour, terrasses) Me tenant à votre entière disposition, pour toutes informations complémentaires ou demandes de devis au 01.83.74.41.86. Site Internet : http://www.accueil-proprete.net Cordialement Responsable Commercial _ Désinscription / Changer d'adresse e-mail: http://ymlp320.net/ugjyssmqgsgushujegbemggmqysjm Powered par YourMailingListProvider ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.---End Message--- ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [Freepto] Let's share username, /etc/hostname and /etc/host among all anonymity distributions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I wonder if the idea of using a random username has a serious problem: It makes every [Tails / anonymity distribution] session uniquely identifiable if the username gets sent in any way. And we *do* assume that it gets sent, because that's basically the idea behind the question what username should be used. Maybe I completely misunderstand this, but using a random username for every session basically sounds like creating a random (and unique!) stamp for every session. Not for every connection, but for every session, so that multiple connections in one session will share one unique username. Patrick Schleizer mentioned IRC idents as an example; maybe that's a good way to explain the problem: - - John Doe starts Tails. His username for this session will be ombbjp8GTE. - - John Doe starts an IRC client. He says something that should absolutely remain anonymous. - - John Doe closes the IRC client and surfs a bit. - - John Doe starts an IRC client again, this time on another network where he happily chats with some friends next to his Iceweasel window. == Anyone who sees both the happy chatting on network 2 and the anonymous information on network 1 knows that it has been sent by the same user, and probably even who this user is. With one default nick for all users, this could not have happened. I'm unsure how severe this issue is, but it would make me suggest *not* using a random username. Best regards, Tobias Frei -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJT7+9qAAoJEOaAxTHjKzK7RO0P/iGAtpryltjmaL1p9+ELdaIb a94hHlnYEuWOmhI4yFNbGnJYa1vG1d72XE7nqESxIZj8kjg0Dg2X8rX9+BbJMV1m XG/5fMlMuwCSYncn01a0h1aOMw191RmNV93g5LRUXlaQqBQDUqMjddyjvI4K5J/7 BpLmO+uAzWDlS/OsjI8e3PxaODFUPAwOhwt8DMEei11r0PiSmLnZnUb28uafxbHs VJXCvzhadyvDsDffLy/WX8yamPMwFXiBHIVCoVTzuEm6OWkJ4bGbZ0IhT7Q/IGFA MPNFYDVA2jY2jcRXoUHm/CwDJmhhZqiw3txkGFhjyTRb7NdbRe2jc9hX5Hkod903 hX8ycs17Vluwq1cgHsSOOlnGlAGvtuvAQMQ9D3jwRcACF18Y097/7Tb1ctxmCwNY 25c/nrs/hcdYc2JHSQmtle2OJ2juVh635uHET+dLtCZbmlsHCuxBKz/L/VMXc7ns ZZx2qVvYMKc2QYzSQDkgrcPsrDMSfWxFCf4c3g/nP4lj/uuKAsOStBkyHlGlMVA3 HPtHmUbCBYYxfTrNST22ggWz/yWIPd0PPMxvGIXImL9T/Y5RHDF4W5R1FWuyTIBU 82niqLwHvCXhkhWak6tl8FA+XKmcQIE96QODEdAu497FMpZSDlK6QL1gMPiq8fn3 zA1wYC7riF3PxhvJEeGD =8GPs -END PGP SIGNATURE- ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] mirror bandwidth
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Dustin, while I can't answer that question, you might be interested in this bug: https://labs.riseup.net/code/issues/7161 (Tails bugtracker) https://trac.torproject.org/projects/tor/ticket/11741 (Tor bugtracker) https://tails.boum.org/blueprint/HTTP_mirror_pool/ (ideas blueprint) (tl,dr: at the moment, you would push 0 bytes per year ;) ) Best regards, Tobias Frei Am 14.08.2014 um 02:30 schrieb Dustin Hess: for those of you that run mirrors, how much bandwidth are you actually going through on a regular basis? I mirror for some small projects already, but the FAQ makes it sound like I'd be pushing a few TB/month if I added tails to my list -Dustin ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJT7CAhAAoJEOaAxTHjKzK70/cP/11ktSGimrCVMtv0CSdRUyax +rgPl6UVy9/2gXsQt399eOVDhaDCo8Q37O8xxS8eZ/YGU8PH5QJg7ULXx5cKS4G4 ue7h6n5qBYA9E4NTrmsGETnFNKSvI9VUcFFKn/uD3q5QdCosujdEb95ysvJ1MBsn 7lZ7HkENJdREGYPLdTRftawY0Ss/1o6jT7WUwRixnuGIbDpjl4X+R4ozQIiV6U04 Yq2E9i4mC79UKT50ox8t3SSWRCF76o51II56bhN77bjR6iM3ugBVBxXuTxodcTLF nwPQ/fytd68ma24w+voJSG2hluTAw3KbhG8nzkKQOQwAeAVQub7lQura72KFEMpH HtHpsvPEJdSkj+G081jqkNxjzT1P1l79mSc5Lgrt/pLFXGCoMmVzTBER2p203RP7 YgwTfWKrALbEs2u0CQe04mYvvwJxgq3kuhShMegfnZ5dxVTeH2cVa0Jk3ap8K6ZI coKiA6WwihTysW03YNCa0MogQpzzapZQpiiAOyIGPQbcIkE1djxEy1/BaYU8Tud8 Dj8Y6hTGSmFZNJTy/3xkyzMe8WnbUJWbi/nk4uDCdUXp2vjsg56mRfTLproUGE85 6uNjvuqqRAP72BwNkr/Wsld6SU5o/zZW88tmKz2G6ok6ngAMVGwRvDHgRVFHXxR5 5CAd2BgDUdefPFxqMeDD =SMIb -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Some research about mirror infrastructure
Hi, ah right, I didn't think of the weighting problem with DNS - I had MX records in mind and thought the fallback could be weighted like these records. I also did not think about TLS; I was just happy to have an (at least temporary) solution which was simple enough for me to create using various StackOverflow suggestions and code snippets. That's also the reason why I can't provide a PHP equivalent of this code: While I could experiment with JavaScript safely, PHP is something which should only be coded by people who know the possible risks of running the code on the server. It's an entirely different thing from a security point of view, I think. If I make an error using JavaScript, the worst thing which can happen is a crashing browser (happened during my experiments!). Should I cause an equivalent error in PHP, something important might crash on the server, or in the worst case there might even be data loss. Also, even if I was able to create a PHP script for this task which worked perfectly fine, I'd probably still be too afraid of not having thought about possible security issues, problems with scalability etc. Maybe someone else with more coding experience and self-confidence could create a server-side solution. Mirrorbrain sounds nice; if available, I would suggest using something which is already used by other open source projects. :) Best regards, Tobias Frei Am 09.08.2014 um 10:22 schrieb intrigeri: Hi, [I've tried to reconcile the two threads by fiddling with the References header.] Tobias Frei wrote (09 Aug 2014 01:12:18 GMT) : this actually *is* a complementary approach to another one. :D The another one is the DNS solution you currently use. You could, for example, use the named server JavaScript idea *and* let it fall back to dl.amnesia.boum.org. The POC does exactly that. :) Example DNS configuration: dl.amnesia.boum.org - with 25 A records tormirror.dl.amnesia.boum.org - with a CNAME or A record another.dl.amnesia.boum.org - same here; this one is also one of the 25 yetanother.dl.amnesia.boum.org - etc. etc. [unlimited amount of other mirror names] If we do that, then we would have two (potentially overlapping) pools. The members of the first pool (served via JS) could be weighted relatively to each other, the members of the second pool (dl.a.b.o) could not (unless we have multiple DNS pools), and we would have no way to weight these two pools relatively to each other. Also, mirrors that are in the two pools will need to serve the same files on two different hostnames (e.g. ServerAlias). This is not a problem in itself, but then, once we introduce TLS for mirrors, we will need to provide them with a certificate that's valid for these two hostnames, which is more expensive and a bit more painful to get. Correct? As even the Tor Browser Bundle has javascript enabled by default,[1] I think the number of people who will use the fallback will be quite low. Minor data point: there's ongoing work on a security slider in TBB, that will make it easier to adjust one's JS prefs, and include an option for disabling JS by default. As a result, I expect that more TBB users (and then in turn, Tails users) will run their browser with JS disabled by default in the future. Cheers, ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tails-dev Digest, Vol 51, Issue 19
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi intrigeri, this actually *is* a complementary approach to another one. :D The another one is the DNS solution you currently use. You could, for example, use the named server JavaScript idea *and* let it fall back to dl.amnesia.boum.org. The POC does exactly that. :) Example DNS configuration: dl.amnesia.boum.org - with 25 A records tormirror.dl.amnesia.boum.org - with a CNAME or A record another.dl.amnesia.boum.org - same here; this one is also one of the 25 yetanother.dl.amnesia.boum.org - etc. etc. [unlimited amount of other mirror names] As even the Tor Browser Bundle has javascript enabled by default,[1] I think the number of people who will use the fallback will be quite low. It is not meant to be a complete replacement for DNS. I also think that we don't really *want* to completely replace DNS, because one day, tor-resolve might work as it should, and then we could switch back to it. This JavaScript fix is - in my opinion - the best, easiest, and (to quote the inofficial blueprint goal) most straightforward solution available. And it is done, it is here, it works.^^ Best regards, Tobias Frei [1] https://www.torproject.org/docs/faq#TBBJavaScriptEnabled (I have now disabled digests again; didn't think about the problems that digests cause with replies. Sorry if this one isn't sorted correctly; I followed the instructions at http://archivist.incutio.com/viewlist/css-discuss/89914 :s) Am 08.08.2014 um 17:38 schrieb tails-dev-requ...@boum.org: Message: 9 Date: Fri, 08 Aug 2014 15:57:40 +0200 From: intrigeri intrig...@boum.org To: The Tails public development discussion list tails-dev@boum.org Subject: Re: [Tails-dev] Some research about mirror infrastructure Message-ID: 85ha1naxt7@boum.org Content-Type: text/plain Hi Tobias, Tobias Frei wrote (07 Aug 2014 17:56:56 GMT) : I've now created the needed JavaScript code; all that would be left to be done is telling the mirror owners to do a small configuration change, depending on what solution you prefer. :) There is also an example website for both solutions linked on the blueprint page. https://labs.riseup.net/code/issues/7161#note-11 https://tails.boum.org/blueprint/HTTP_mirror_pool/#index3h1 Thanks a lot for working on this! As mentionned on the blueprint, though, a solution based on JavaScript can only be a complementary approach to another one, that works without JS. Are you interested in working on a PHP version too? Cheers, -- intrigeri - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJT5XVdAAoJEOaAxTHjKzK7mjMP/24HsWSpbHay70eKotN4dqUv nsmWqzsaTSlhv3wxIwGoTQy01K9qdeDVmkvDsGBc9ZX7aaPjUlEKmwC8FbReVFZ5 P+JQqEoMeQF9jpGnE/pV3HIunD1F+8tSpEYBSdjWA+enXuJgO6khv3nX9cpJSqsG 8HSCRyk/xMgG0kiy1I3NrB+OO9hsCYmZ28z/YHrXd9j+Wlqfwg9vTWmAVDokueeD iTu7iGiJpgJD62QCUT1I2jP6YOFCyhqYstNPmYllRkX0XtqfuXHbN1Wm95zQyJHb sAVutrwm5OUF39ATjsTtAdWAMsNr1xfF2+DagfF2Q+gBkRZsShro9Cd5GUwKB3t+ wH8EQ9GsHoQmqi1gR8/T3EE7LfDSNgSQxv/l1V64XFdx9oJ2O1rDLEtk0PaARnKe zJ8UWSFhxosYc9ube9lXfyjJzd/i47Aq8yKpPRw+8txXXfAULnVx/FSvmC/M8JSV 274k8K6UBUPu82yWxMDNRqHxzNYoJXIRYkjqEDU6PZg2LtYJlcShYDQisfmbky7w e5uf6Xy7CKQuQyIbuvsW1EwDIKUC6Z9gTQWLHkucZd9DRKS1mHZhaA3MZdeX343d cw3OjoLNAWPy0ZejtIg82XYN0EYumqhJpdks9/c8AMJYqg+i5Zl53WEqtolyCiQr nhIgG9JZ+H9i//bCjRZN =tK3A -END PGP SIGNATURE- ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
