On Thu 19 Oct 2017 at 20:53:50 (-0400), Celejar wrote:
> On Thu, 19 Oct 2017 13:46:08 -0500
> David Wright wrote:
>
> > On Thu 19 Oct 2017 at 18:07:20 (+0200), to...@tuxteam.de wrote:
> > > On Thu, Oct 19, 2017 at 11:07:01AM -0400, Celejar wrote:
> > > > On Thu, 19 Oct
Ron Leach wrote:
> On 19/10/2017 16:56, Dan Purgert wrote:
>> Brian wrote:
>>> [...]
>>> Isn't it sufficient to fix one end of the
>>> connection to dispose of the vulnerability?
>>>
>>
>> KRACK is an attack against the *client* side. It MUST (rfc2119) be that
>> device that is patched against
On 20/10/2017 21:09, Brad Rogers wrote:
On Fri, 20 Oct 2017 10:05:34 +0530
"tv.deb...@googlemail.com" wrote:
Hello tv.deb...@googlemail.com,
I sent that a day ago, but for some reason it didn't make it to the
list:
You're using google. It's well known that they
On Fri, 20 Oct 2017 10:05:34 +0530
"tv.deb...@googlemail.com" wrote:
Hello tv.deb...@googlemail.com,
>I sent that a day ago, but for some reason it didn't make it to the
>list:
You're using google. It's well known that they don't send your own list
posts back to you.
[OT] Breaking WPA2 by forcing nonce reuse
From: "tv.deb...@googlemail.com" <tv.deb...@googlemail.com> (resent from
debian-user@lists.debian.org)
To: debian-user@lists.debian.org
Date: Wed Oct 18 13:04:04 2017
I suspect that, like for many email users / clients, some combination of t
On Thu 19 Oct 2017 at 17:06:20 +0100, Ron Leach wrote:
> On 19/10/2017 16:56, Dan Purgert wrote:
> > Brian wrote:
> > > [...]
> > > Isn't it sufficient to fix one end of the
> > > connection to dispose of the vulnerability?
> > >
> >
> > KRACK is an attack against the *client* side. It MUST
On 19/10/2017 21:42, Celejar wrote
[...]
like the printer. Henrique recently noted that there is a setting
available on new OpenWRT and LEDE builds that can help, but it's
apparently not yet included in any release yet:
https://lists.debian.org/debian-user/2017/10/msg00593.html
Celejar
I
On Thu, 19 Oct 2017 13:46:08 -0500
David Wright wrote:
> On Thu 19 Oct 2017 at 18:07:20 (+0200), to...@tuxteam.de wrote:
> > On Thu, Oct 19, 2017 at 11:07:01AM -0400, Celejar wrote:
> > > On Thu, 19 Oct 2017 12:05:23 +0100
> > > Brian wrote:
> > >
On Thu 19 Oct 2017 at 18:07:20 (+0200), to...@tuxteam.de wrote:
> On Thu, Oct 19, 2017 at 11:07:01AM -0400, Celejar wrote:
> > On Thu, 19 Oct 2017 12:05:23 +0100
> > Brian wrote:
> >
> > > On Wed 18 Oct 2017 at 21:30:48 -0400, Celejar wrote:
>
> [...]
>
> > Yes, what I'm
On 19/10/2017 16:56, Dan Purgert wrote:
Brian wrote:
[...]
Isn't it sufficient to fix one end of the
connection to dispose of the vulnerability?
KRACK is an attack against the *client* side. It MUST (rfc2119) be that
device that is patched against the attack.
Dan, I'm not sure it's that
On Thu, 19 Oct 2017 16:39:34 +0100
Brian wrote:
> On Thu 19 Oct 2017 at 11:07:01 -0400, Celejar wrote:
>
> > On Thu, 19 Oct 2017 12:05:23 +0100
> > Brian wrote:
> >
> > > On Wed 18 Oct 2017 at 21:30:48 -0400, Celejar wrote:
> >
> > ...
> >
> > > >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Oct 19, 2017 at 11:07:01AM -0400, Celejar wrote:
> On Thu, 19 Oct 2017 12:05:23 +0100
> Brian wrote:
>
> > On Wed 18 Oct 2017 at 21:30:48 -0400, Celejar wrote:
[...]
> Yes, what I'm probably going to do is use the
Brian wrote:
> [...]
> That's a good idea, but thinking on: there two ends to the connection,
> the printer and the sending device. Fixing printers is unlikely to be
> high on vendors' lists of priorities, but a fix is available when the
> sending device uses Debian. Isn't it sufficient to fix one
On Thu 19 Oct 2017 at 11:07:01 -0400, Celejar wrote:
> On Thu, 19 Oct 2017 12:05:23 +0100
> Brian wrote:
>
> > On Wed 18 Oct 2017 at 21:30:48 -0400, Celejar wrote:
>
> ...
>
> > > developers, etc., but why should I not be worried and upset about the
> > > situation with
On Thu, 19 Oct 2017 12:05:23 +0100
Brian wrote:
> On Wed 18 Oct 2017 at 21:30:48 -0400, Celejar wrote:
...
> > developers, etc., but why should I not be worried and upset about the
> > situation with my phone, printer, etc.?
>
> Depends on the level of your concern.
On Wed 18 Oct 2017 at 21:30:48 -0400, Celejar wrote:
> On Tue, 17 Oct 2017 19:20:08 +0100
> Brian wrote:
>
> > On Tue 17 Oct 2017 at 10:57:15 -0400, Celejar wrote:
> >
> > > On Tue, 17 Oct 2017 08:43:00 +0530
> > > "tv.deb...@googlemail.com"
On Tue, 17 Oct 2017 19:20:08 +0100
Brian wrote:
> On Tue 17 Oct 2017 at 10:57:15 -0400, Celejar wrote:
>
> > On Tue, 17 Oct 2017 08:43:00 +0530
> > "tv.deb...@googlemail.com" wrote:
> >
> > > So using https or better for communications on the
On 18/10/2017 19:03, Henrique de Moraes Holschuh wrote:
On Mon, Oct 16, 2017, at 14:49, Alexander V. Makartsev wrote:
That is one smoking fast update release. Demo works in perfect
environment, but I wonder if there are some settings on AP that help
to prevent successful
Yes, there is. The AP
On Mon, Oct 16, 2017, at 14:49, Alexander V. Makartsev wrote:
> That is one smoking fast update release. Demo works in perfect
> environment, but I wonder if there are some settings on AP that help
> to prevent successful
Yes, there is. The AP may refuse to ever resent the third packet of the
On Tue 17 Oct 2017 at 10:57:15 -0400, Celejar wrote:
> On Tue, 17 Oct 2017 08:43:00 +0530
> "tv.deb...@googlemail.com" wrote:
>
> > So using https or better for communications on the local network is a
> > good idea, but is it the norm? Many router firmwares or
On Mon, 16 Oct 2017 15:42:09 + (UTC), Curt wrote:
>https://www.krackattacks.com/
>
> Our attack is especially catastrophic against version 2.4 and above of
> wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the client will
> install an all-zero encryption key
On Tue, 17 Oct 2017 08:43:00 +0530
"tv.deb...@googlemail.com" wrote:
> On 17/10/2017 00:49, Celejar wrote:
> > On Mon, 16 Oct 2017 21:27:30 +0530
> > "tv.deb...@googlemail.com" wrote:
...
> >> the world. After Bluetooth a few weeks ago, now
On 17/10/2017 00:49, Celejar wrote:
On Mon, 16 Oct 2017 21:27:30 +0530
"tv.deb...@googlemail.com" wrote:
On 16/10/2017 21:12, Curt wrote:
https://www.krackattacks.com/
Our attack is especially catastrophic against version 2.4 and above of
wpa_supplicant, a
On Mon 16 Oct 2017 at 15:42:09 +, Curt wrote:
> https://www.krackattacks.com/
>
> Our attack is especially catastrophic against version 2.4 and above of
> wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the client will
> install an all-zero encryption key instead of
On Mon, 16 Oct 2017 21:27:30 +0530
"tv.deb...@googlemail.com" wrote:
> On 16/10/2017 21:12, Curt wrote:
> > https://www.krackattacks.com/
> >
> > Our attack is especially catastrophic against version 2.4 and above of
> > wpa_supplicant, a Wi-Fi client commonly used
That is one smoking fast update release.
Demo works in perfect environment, but I wonder if there are some
settings on AP that help to prevent successful exploitation of this
vulnerability before(if ever) firmware updates are released by device
manufacturers.
Such as setting re-keying delay to one
On 16/10/2017 21:12, Curt wrote:
https://www.krackattacks.com/
Our attack is especially catastrophic against version 2.4 and above of
wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the client will
install an all-zero encryption key instead of reinstalling the real key.
27 matches
Mail list logo