Mesh/Challenges - Revision history

Mitar: Comment about trust

2013-08-23T06:01:57Z

Comment about trust

← Older revision		Revision as of 23:01, 22 August 2013
Line 14:		Line 14:

	[[User:Juul\|Juul]] ([[User talk:Juul\|talk]]) 02:38, 13 August 2013 (PDT)		[[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.

Juul at 09:38, 13 August 2013

2013-08-13T09:38:59Z

← Older revision		Revision as of 02:38, 13 August 2013
Line 6:		Line 6:

	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)		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)

Mitar at 02:58, 10 August 2013

2013-08-10T02:58:17Z

← Older revision		Revision as of 19:58, 9 August 2013
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)

Sjackisch: Security

2013-08-09T20:32:15Z

Security

New page

'''Security'''
It's possible that malicious actors could install malicious software on mesh nodes they control such as [http://www.thoughtcrime.org/software/sslstrip/ sslstrip] via [https://github.com/RMerl/asuswrt-merlin/wiki/Entware 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?