Difference between revisions of "Mesh/Challenges"

From Sudo Room
Jump to navigation Jump to search
(Security)
 
(Comment about trust)
 
(2 intermediate revisions by 2 users not shown)
Line 4: Line 4:


Countermeasures might include regularly re-flashing nodes, not allowing nodes with changed root passwords, whitelisting applications?
Countermeasures might include regularly re-flashing nodes, not allowing nodes with changed root passwords, whitelisting applications?
It is a feature, not a bug. People should use end-to-end encryption with [https://www.eff.org/https-everywhere HTTPS Everywhere] and not relay on security of the network. [[User:Mitar|Mitar]] ([[User talk:Mitar|talk]]) 19:58, 9 August 2013 (PDT)
Hm. Yes, though some questions remain: Are we putting people in a situation where their lack of education about security (no fault of their own) and lack of p2p encryption in their software tools (definitely no fault of their own) will put them at risk? Certainly the risk is no greater than the risk of connecting to any other unknown public wifi access point. However, may people expect a higher level of security from an "official" organization? Second, how can we mitigate the security concerns? I suggest the following approaches:
# Provide instructions on how to create secure tunnels to one of our exit nodes.
# Dedicate some resources to help develop better and easier tools for p2p crypto.
# Provide training for how to use p2p tools, both online and offline.
[[User:Juul|Juul]] ([[User talk:Juul|talk]]) 02:38, 13 August 2013 (PDT)
: Why would they trust our exit nodes? Why should they? And it is not necessary to teach them P2P crypto. Just end-to-end HTTPS is probably enough. So some browser extensions which assure that they use HTTPS and that they detect man-in-the-middle attacks.

Latest revision as of 23:01, 22 August 2013

Security It's possible that malicious actors could install malicious software on mesh nodes they control such as sslstrip via Entware. This would allow them to capture sensitive information from less savvy users.


Countermeasures might include regularly re-flashing nodes, not allowing nodes with changed root passwords, whitelisting applications?

It is a feature, not a bug. People should use end-to-end encryption with HTTPS Everywhere and not relay on security of the network. Mitar (talk) 19:58, 9 August 2013 (PDT)

Hm. Yes, though some questions remain: Are we putting people in a situation where their lack of education about security (no fault of their own) and lack of p2p encryption in their software tools (definitely no fault of their own) will put them at risk? Certainly the risk is no greater than the risk of connecting to any other unknown public wifi access point. However, may people expect a higher level of security from an "official" organization? Second, how can we mitigate the security concerns? I suggest the following approaches:

  1. Provide instructions on how to create secure tunnels to one of our exit nodes.
  2. Dedicate some resources to help develop better and easier tools for p2p crypto.
  3. Provide training for how to use p2p tools, both online and offline.

Juul (talk) 02:38, 13 August 2013 (PDT)

Why would they trust our exit nodes? Why should they? And it is not necessary to teach them P2P crypto. Just end-to-end HTTPS is probably enough. So some browser extensions which assure that they use HTTPS and that they detect man-in-the-middle attacks.