rhombus has quit [Quit: KVIrc KVIrc Aria 4.9.2, revision: aa9a7c70cc4064e5ed97c7a6d21fa010f7292680, build type: release, sources date: 20160102, built on: 2017-09-14 19:13:24 UTC http://www.kvirc.net/]
jcarpenter2 has quit [Quit: Leaving]
pi-face has joined #neo900
knttl has quit [Ping timeout: 255 seconds]
knttl has joined #neo900
ArturShaik has joined #neo900
Kabouik has quit [Ping timeout: 240 seconds]
paulk-gagarine has quit [Ping timeout: 246 seconds]
paulk-gagarine has joined #neo900
preview has joined #neo900
<preview>
hallo, will this device use conflict free or fair trade minerals? further, are there ay assurances around the working conditions for manufacturers? union / living wage etc?
<preview>
thanks!
<galiven>
I don't know 100% but I believe the boards and assembly will be done in Germany, so no sweat-shop labor involved. As far as I know there haven't been any commitments to conflict free minerals though.
<galiven>
Likely something that a small project like this couldn't feasibly commit to. We have to source from the only people that will sell parts in the relatively small quantities we need.
<preview>
thanks galiven, after later reading I saw tehy were gonna use the openmoko parts, and they had already claimed it was outside of their scope.
<Joerg-Neo900>
we try to avoid components with problematic elements, and if we need to use components that contain those, we try to get them as "conflict free" as available, but there's just not much info at all about the element sources for rare earths the component manufacturers use and they won't do any audit for us
<galiven>
It's not actually Openmoko parts, but somewhat based on the mainboard in the GTA04 that Golden Delicious computers (Nikolaus Schaller) and a few others were working on.
<galiven>
The GTA04 was reusing case, screen, &c from the Openmoko Neo Freephone. This project is reusing the case, screen, &c from the Nokia N900.
<Joerg-Neo900>
that too, so we recycle razher than use new, in that regard
jcarpenter2 has joined #neo900
<Joerg-Neo900>
main problem component are Tantalum capacitors and we managed to avoid using those for 99.9%
<sn0wmonster>
galiven, GTA04 was good, but i liked GTA05 better
* sn0wmonster
giggles
<Joerg-Neo900>
we have no info and no choice about what's used in chips
<sn0wmonster>
Joerg-Neo900, working on it right now!
<Joerg-Neo900>
we don't use any source of rare earth for our LCD since they are recycled from N900
illwieckz has quit [Ping timeout: 246 seconds]
illwieckz has joined #neo900
illwieckz has quit [Ping timeout: 252 seconds]
illwieckz has joined #neo900
illwieckz has quit [Ping timeout: 240 seconds]
Beaches has quit [Ping timeout: 240 seconds]
illwieckz has joined #neo900
xmn has joined #neo900
_whitelogger has joined #neo900
_whitelogger has joined #neo900
jonsger has joined #neo900
xmn1 has joined #neo900
xmn has quit [Ping timeout: 248 seconds]
jonsger has quit [Quit: jonsger]
jonsger has joined #neo900
jonsger has quit [Ping timeout: 264 seconds]
PeperPots____ has quit [Ping timeout: 255 seconds]
XDS2010|AFK has quit [Ping timeout: 246 seconds]
xmn1 has quit [Quit: Leaving.]
ArturSha1 has joined #neo900
ArturShaik has quit [Ping timeout: 255 seconds]
tkok has quit [Read error: Connection reset by peer]
jkepler has joined #neo900
jonsger has joined #neo900
Kabouik has joined #neo900
freemangordon_ has joined #neo900
knttl has quit [Ping timeout: 248 seconds]
knttl has joined #neo900
ravelo has joined #neo900
jonsger has quit [Quit: jonsger]
ArturShaik has joined #neo900
ArturSha1 has quit [Ping timeout: 240 seconds]
ravelo has quit [Quit: Connection closed for inactivity]
ecloud_ has joined #neo900
ecloud has quit [Read error: Connection reset by peer]
jonsger has joined #neo900
ArturSha1 has joined #neo900
jonwil has quit [Quit: ChatZilla 0.9.93 [SeaMonkey 2.48/20170707010522]]
ArturShaik has quit [Ping timeout: 246 seconds]
Beaches has joined #neo900
ecloud_ is now known as ecloud
Kabouik has quit [Ping timeout: 260 seconds]
freemangordon_ has quit [Ping timeout: 240 seconds]
Kabouik has joined #neo900
qwazix has quit [Ping timeout: 240 seconds]
qwazix has joined #neo900
jonsger has quit [Remote host closed the connection]
Pali has joined #neo900
Tsutsukakushi has quit [Ping timeout: 240 seconds]
<Joerg-Neo900>
a vulnerability in the protocol itself
* Joerg-Neo900
ponders "downgrading" to WEP with a new shared secret every 5 minutes
<enyc>
is there a clearly defined fixe ??? (protocol-wise) ? or different approaches/workarounds being used???
<Hodges>
Everyone needs to build everything with the assumption that any security implemented will fail with sufficient effort.
<Joerg-Neo900>
enyc: the glitch is in the protocol spec. And a particularly nasty additional oopsie in wpa-supplicant. However the vuln seems to "only" establish a MITM attack, not a full disclosure of the login credentials
<Joerg-Neo900>
fix: disallow session key re-use
<enyc>
Joerg-Neo900: yes, but is that *the* *ONE* universally-agreed fix?
<Joerg-Neo900>
yes, aiui
<Joerg-Neo900>
just it needs to get implemented on protocol level
<Joerg-Neo900>
when WPA2 is done on WLAN chip hardmac, you are facing trouble to fix it. However I *hope* a fix in APs suffices, clients probably don't need a protocol fix to be compatible with fixed APs
<Joerg-Neo900>
so, in simple words (and aiui): attacker can read and modify your traffic, but they can't connect to your AP on their own
<Joerg-Neo900>
not that this would mitigate the problem in any way
* enyc
yawns!
<Joerg-Neo900>
confirmed. patching either AP or client fixes the issue
Hodges has quit [Ping timeout: 260 seconds]
Hodges has joined #neo900
arnaudj has joined #neo900
louisdk has joined #neo900
<Zero_Chaos>
Joerg-Neo900: fixing the AP is *not* enough
<Zero_Chaos>
Joerg-Neo900: most of the bugs are on the client side
<Joerg-Neo900>
[2017-10-16 Mon 21:23:44] <DocScrutinizer05> is the communication "fixed" when only one of both has the patches? [2017-10-16 Mon 21:24:05] <fromport> DocScrutinizer05: yes <fromport> it is a man in the middle attack and you have to convince both sides to re-use a previous key. <fromport> if one of the sides refuses, you are already safe
<Joerg-Neo900>
[2017-10-16 Mon 21:31:13] <DocScrutinizer05> is the MITM related to signal strength or time of arrival? IOW wouldn't you need to jam the original signal to hide it from far end? I guess that's a tricky question, as long as no details or PoC implementation of the attack are known
<Zero_Chaos>
you can believe whoever you want, but using a fake AP you can toast a vuln client all day
<Zero_Chaos>
their one and only public demo even shows that
<Hodges>
Apparently android/linux devices can be fooled or coaxed into switching over to a specific client without much difficulty.
<Joerg-Neo900>
a fake AP however would not establish a MITM, only .. a fake AP
<Zero_Chaos>
Joerg-Neo900: please watch the video, it is full mitm, not even difficult
<Joerg-Neo900>
you're right. Thanks
<Hodges>
Specifically targeted, commercial equipment using WPA2 are going to be comically easy to intercept.
<Hodges>
I've worked with medical equipment that use WPA2
<Joerg-Neo900>
wait, I still don't see why a fixed AP could get cracked via a fake AP when the client is not patched
<Zero_Chaos>
Joerg-Neo900: because the client will no longer be connected to the fixed ap
<Joerg-Neo900>
sure your client remains fulnerable as soon as it connects to other WLANs
<Joerg-Neo900>
*sigh* but you didn't say how you conect your fake AP to the regular AP
<Zero_Chaos>
Joerg-Neo900: nor does the video they released
<Zero_Chaos>
Joerg-Neo900: although, it's not like most users would notice as long as they have internet
<Joerg-Neo900>
which in my book clearly indicates that this wasn't a fixed AP
<Zero_Chaos>
Joerg-Neo900: are you famliar with the ap side vuln? afaik, it's only in 802.11r and they don't even mention that in the video
<Joerg-Neo900>
Zero_Chaos: how does that matter?
<Zero_Chaos>
Joerg-Neo900: some of the video is explained well, like using sslstrip, some of it isn't explained at all, like exactly how they get mitm
<Zero_Chaos>
Joerg-Neo900: so it's hard to say exactly what they are demoing, but since 802.11r isn't even mentioned, I suspect that's not it
<Joerg-Neo900>
when I got a vilnerable client connected to a patched AP, I don't see how any attacker would intercept that connection
<Zero_Chaos>
Joerg-Neo900: I fail to see how your lack of imagination factors in here
<Hodges>
They appear to be demo-ing a script that is not yet released.
<Zero_Chaos>
correct
<Joerg-Neo900>
Zero_Chaos: my lack of imagination?
<Zero_Chaos>
Joerg-Neo900: "I don't see how"
<Joerg-Neo900>
please prove >> it is a man in the middle attack and you have to convince both sides to re-use a previous key. <fromport> if one of the sides refuses, you are already safe<< wrong
<Joerg-Neo900>
since that's exactly what I'd expect a MITM to work like
<Zero_Chaos>
Joerg-Neo900: it's not my vuln, I only know what I've read, but I can confirm what I've read doesn't match with that PoC video they released, so I'm going to reserve judgement rather than tell everyone who doesn't run 802.11r that they are safe
<Joerg-Neo900>
err wut?
<Zero_Chaos>
Joerg-Neo900: the released video of the attack doesn't match up with what the paper describes. something funny is going on. I'm not sure what yet.
<Joerg-Neo900>
A<-1->MITM<-2->B. To establish that you need to get connection 1 and 2 established. When A is not vulnerable how will you establish connection 1?
<Zero_Chaos>
Joerg-Neo900: my lack of ability to understand the unreleased details of this attack don't prove you are correct in suggesting everyone is magically safe.
<Joerg-Neo900>
you can have MITM impersonate A towards B, but only until B wants to access data on A that MITM has no idea about
<Joerg-Neo900>
I didn't suggest any such nonsense
<Joerg-Neo900>
I particularly said A<->B is safe as long as _either_ A or B are patched
<Zero_Chaos>
Joerg-Neo900: and I'm saying that based on the video it's not possible to say that
<Joerg-Neo900>
this is not based on any video, this is based on mere logic of how a MITM works
<Joerg-Neo900>
see above
jonwil has joined #neo900
<Zero_Chaos>
Joerg-Neo900: I decline to argue with someone who is not familiar with the attack by their own admission.
hexamod has joined #neo900
<Zero_Chaos>
Joerg-Neo900: I'm still trying to better understand how this works, but your questions appear to be answered in section 3.2 of the paper.
<Zero_Chaos>
Joerg-Neo900: it's pretty clever it seems. it's not a mitm in the traditional sense, more like a relay
<Joerg-Neo900>
doesn't defeat the logic that an attacked can't exploit a patched AP and thus can't establish a communication to it
<Zero_Chaos>
Joerg-Neo900: if you actually care, feel free to read about it, if not, feel free to make more comments without knowledge
<Joerg-Neo900>
I git enough knowledge to assume that re-using a key needs to agreed upon by both involved parties. If one party disagrees on doing that, then the key re-use fill fail between the two
<Hodges>
Am I understanding this right. On the client end, the solution is to remove the re-transmission of 'packet 3' and that such a change would only work for as long as the client refuses to function with any client that doesn't abide by the change in protocol?
<Joerg-Neo900>
that's client side. How do you convince a patched AP to use that retransmitted key?
<Joerg-Neo900>
unless of course the key and connection is already established and you can avoid the AP noticing the re-transmission so it could tear down the connection
<Hodges>
You don't? If it were patched you'd be using an updated wireless protocol.
jonsger has joined #neo900
<Hodges>
No matter what, it doesn't seem like what you patch on the APs end matters because it'll still be up to the client to know better.
louisdk has quit [Ping timeout: 260 seconds]
<Hodges>
If you were to whitelist clients that don't exhibit this behavior they'd just go somewhere else unless they know better than to use a faulty protocol.
<Joerg-Neo900>
>>More precisely, we first establish a man-in-the-middle (MitM) position between the supplicant and authenticator. We use this MitM position to trigger retransmissions of message 3 by preventing message 4 from arriving at the authenticator.<< seems they need to intercept arrival of direct message 4 from client at AP.
<Joerg-Neo900>
so you need a) a PHY layer MITM situation that allows intercepting of direct communication, and b) you need intercept and exploit a re-authentication. No way to intercept an established connection
<Hodges>
It does seem like chance affects the likelihood of this vulnerability being exploited but many devices exhibit known behavior that can be exploited with varying success rates.
<Hodges>
Unifi equipment for example listens to other networks (even if it has a connection) for should something in the network change that needs to be acted on.
<Hodges>
I think it's nice that they built this in
<Hodges>
But in my experience - with a large network - they aren't the best at provisioning themselves
<Hodges>
And I still feel like you'd need a device to second-guess the client and refuse to connect (or instead switch to another client)
<Joerg-Neo900>
can't follow
<Hodges>
Which should already be baked into their devices that have their improved roaming
<Hodges>
The APs, Cameras, PVRs, etc# are all controlled by their own proprietary base-station software.
<Joerg-Neo900>
yep
<Joerg-Neo900>
though i'm not sure about "proprietary"
<Hodges>
The software updates for the base-station and the clients themselves isn't very elegant.
<Hodges>
They frequently stop reporting to the base-station while continuing to function.
<Hodges>
And often need physically reset and "adopted" using a second software (formerly at least) to stay synchronized.
<Joerg-Neo900>
anyway for a more on-topic question: on which level (wpa-supplicant in userland, or HardMAC) is the WPA2 protocol handled in TI's WL18xx?
<Joerg-Neo900>
or, for N900, WL12xx
<Joerg-Neo900>
IOW what needs patching - the firmware or the linuxland "drivers"
<Joerg-Neo900>
no wpa-supplicant in maemo
<Joerg-Neo900>
or it just has a different name :-S
<Hodges>
I assume you are thinking aloud. My money is on the drivers, although I feel like a software fix would be sufficient. I trust an easy to implement solution will be publicized in the next few days.