Hi,
[cleaning my INBOX]
tl;dr: all the proposed changes were applied in Tails 2.4. Thanks!
intrigeri (Thu, 11 Feb 2016):
> intrigeri wrote (05 Mar 2015 21:14:50 GMT) :
>> intrigeri wrote (18 Jan 2015 21:45:15 GMT) :
>>> I see this thread has been quiet for a bit more than a month.
>>> Maybe
intrigeri:
> intrigeri wrote (05 Mar 2015 21:14:50 GMT) :
>> intrigeri wrote (18 Jan 2015 21:45:15 GMT) :
>>> I see this thread has been quiet for a bit more than a month.
>
>>> Maybe it's time for someone to sum up whatever consensus was reached,
>>> and whatever disagreement may still be
sajolida wrote (12 Feb 2016 17:20:16 GMT) :
> So I'm just wondering whether we have tickets to track this?
We have none, as far I know. Someone volunteered to create them back
them, once it was clarified that this was something we wanted, but
didn't do it in the end. Feel free to create it if you
Hi,
intrigeri wrote (05 Mar 2015 21:14:50 GMT) :
> intrigeri wrote (18 Jan 2015 21:45:15 GMT) :
>> I see this thread has been quiet for a bit more than a month.
>> Maybe it's time for someone to sum up whatever consensus was reached,
>> and whatever disagreement may still be remaining?
>> Jake,
Hi,
[disclaimer: I've not read the entire thread yet.]
I see this thread has been quiet for a bit more than a month.
Maybe it's time for someone to sum up whatever consensus was reached,
and whatever disagreement may still be remaining?
Jake, maybe?
Cheers,
--
intrigeri
On 04/12/14 21:16, Oliver-Tobias Ripka wrote:
According to anonym on Thu, Dec 04 2014:
FWIW I experienced no issues during my tests with *only* ESTABLISHED in
both the INPUT and OUTPUT chains so neither NEW nor RELATED seems
essential for the basic usage I tested. And of course the above
According to anonym on Thu, Dec 11 2014:
So, in addition to proto tcp, how does --syn compare to state NEW?
Actually, what is it we are trying to defend against here? Is there any
conceivable attack vector based on sending non-syn packets for
non-ESTABLISHED (i.e. NEW) TCP streams?
Ok...
According to Jacob Appelbaum on Thu, Dec 04 2014:
On 12/4/14, Oliver-Tobias Ripka o...@bockcay.de wrote:
According to anonym on Thu, Dec 04 2014:
FWIW I experienced no issues during my tests with *only* ESTABLISHED in
both the INPUT and OUTPUT chains so neither NEW nor RELATED seems
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/12/14 01:06, Oliver-Tobias Ripka wrote:
- DHCP still works. Which is strange, isn't? I configured the
firewall to drop everything so DHCP should not work.
To debug a little I inserted some code into
Hi,
I retried the test but deleted the lease files from the directory you
mentioned before reconnecting. I now see a complete DHCP DORA
(Discovery, Offer, Request, Ack) on the wire. So nothing gets blocked. I
would also expect that just doing a renewal (request, ack) should be
blocked as the Ack
On 03/12/14 18:22, Jacob Appelbaum wrote:
I propose that we change the rule to be:
mod state state (NEW ESTABLISHED) ACCEPT;
The reason is pretty simple - RELATED makes the kernel do a lot of
extra lifting that is not needed by using the conntrack kernel code:
While I think we
On 12/4/14, anonym ano...@riseup.net wrote:
On 03/12/14 18:22, Jacob Appelbaum wrote:
I propose that we change the rule to be:
mod state state (NEW ESTABLISHED) ACCEPT;
The reason is pretty simple - RELATED makes the kernel do a lot of
extra lifting that is not needed by using
On 12/4/14, Oliver-Tobias Ripka o...@bockcay.de wrote:
Hi,
I retried the test but deleted the lease files from the directory you
mentioned before reconnecting. I now see a complete DHCP DORA
(Discovery, Offer, Request, Ack) on the wire. So nothing gets blocked. I
would also expect that just
According to anonym on Thu, Dec 04 2014:
FWIW I experienced no issues during my tests with *only* ESTABLISHED in
both the INPUT and OUTPUT chains so neither NEW nor RELATED seems
essential for the basic usage I tested. And of course the above
exploits didn't work due to the absence of NEW.
Thinking some more about this I think that there might not only be the
TCP PATH MTU issue, but also my list of protocols used by Tails was
incomplete. While it does not run by default I think I2P is supported
within Tails and it seems to have also UDP firewall requirements [1]
that need to be
On 12/4/14, Oliver-Tobias Ripka o...@bockcay.de wrote:
According to anonym on Thu, Dec 04 2014:
FWIW I experienced no issues during my tests with *only* ESTABLISHED in
both the INPUT and OUTPUT chains so neither NEW nor RELATED seems
essential for the basic usage I tested. And of course the
On 12/4/14, Oliver-Tobias Ripka o...@bockcay.de wrote:
Thinking some more about this I think that there might not only be the
TCP PATH MTU issue,
How should we test this, I wonder?
but also my list of protocols used by Tails was
incomplete. While it does not run by default I think I2P is
Hi,
After talking with a new friend about netfilter and the kernel, we
discussed a funny thing that happens to lots of people who use
iptables. As a result, I took a look at Tails and sure enough, that
funny little issue is present. I think as a result, we should make a
reasonable, minimal change
Hi Jake,
Jacob Appelbaum wrote (03 Dec 2014 17:22:30 GMT) :
Thoughts?
Thanks a lot for this detailed report! :)
Were the proposed changes tested in Tails?
If yes, then the next steps are:
1. filing a ticket about that
2. proposing a branch that implements the proposed changes
3.
On 12/3/14, intrigeri intrig...@boum.org wrote:
Hi Jake,
Jacob Appelbaum wrote (03 Dec 2014 17:22:30 GMT) :
Thoughts?
Thanks a lot for this detailed report! :)
Sure - happy to help. :)
Were the proposed changes tested in Tails?
I've not tested it - I was hoping that someone might
Hey,
I agree that removing the attack surface is a good idea. Some thoughts
and material for discussion on this...:
You make no distinction between the INPUT and OUTPUT chains and suggest
that both should be changed to NEW, ESTABLISHED. I understand your
argument for the OUTPUT chain but I would
21 matches
Mail list logo
