ChaosVPN:geekend1

This page is about an event in the past. Please do not edit/add content without good reason.
Diese Seite beschreibt ein Event der Vergangenheit. Bitte füge ohne triftigen Grund keine neuen Inhalte hinzu.

what?

Lets do a geekend and get things done on the chaosvpn.

where

Hamburg. In the new Hackerspace of attraktor and CCC Hamburg.

when

The Geekend will be on January 28th - 30th.

participants

• arrived:

 + mc.fly 
 + guus
 + crest

• still missing

 + Jens
 + hc
 + nomaam
 + wopot
 + zocker

Issues

monitoring

User:mc.fly wants to build a munin / nagios server for chaosvpn.

• the server itself is up and running.
  • munin running, but no chaosvpn node configured so far
  • nagios installed but not configured.
    • Haegar recommends icinga

dns

Improve dns usage in ChaosVPN.

• which dnsd (pro and con. discusion)
• anycast

connect people

connect the router at some spaces

packages

build debian and openwrt packages

• debian
  • build Packages
  • get in squeeze?

• OpenWRT
  • package
  • image with tinc and config for fonera 2.0n

Goals

• Set up warzone properly
• Get dns in the default images and improve dns use by adding nodes to the zonefile
• rework the Doku

infrastructure

lodging

• best western queens hotel hamburg around the corner
• limited sleeping in the hackerspace is possible

suggested topics

• a) maintaining the chaosvpn.net content
• b) making chaosvpn more secure - hc's nonroot changes alone are not enough
• c) (re)define a joining policy/policies
• d) getting rid of the spof vpn.hamburg.ccc.de by allowing multiple urls to be specified in chaosvpn.conf and by replicating the info on vpn.hamburg... to other nodes
• e) getting a very reliable dns that works with chaosvpn up and with chaosvpn temporarily down

Update Policy for the client

I would like to suggest the following policy:

• The central configuration is signed and encrypted
• The Signature and/or the signed configuration contains the signing timestamp
• The configuration is signed automatically at least once within 24 hours
• The signed configuration is pushed to multiple servers

When a client downloads the configuration, he executes the following steps:

• Get a list l of (ip-adresses) of servers via the local configuration and/or DNS
• Sort l randomly
• c = local config
• t = age of local config
• for (i = 0; i < l.length; i++)
  • d = get config from server l[i]b
  • check signature of d
  • if signature is correct:
    • u = now - timestamp of d
    • if u < t
      • c = d
      • t = u
      • if c < 24h + delta, then break for-loop
• if t > 24h + delta
  • Warn the user

In short words, get a configuration from a random mirror, if it is older than 24 hours, try all other mirrors, until you have found a configuration not older than 24 hours. If all mirrors have been tried, use the newest available configuration with a correct signature, and warn the user.

Suggestion by hc: warning the user won't help; if the configuration is older than, say, 7 weeks, disconnect from chaosvpn till situation resolved.

chaosvpn util run mode

hc's opinion: chaosvpn should run all the time. I consider the run by cron method obsolete; let me explain:

Users are lazy; if they get into chaosvpn they will not necessarily set up cron and/or check if the set up cron actually works as intended. They might not notice that something is wrong until months pass, and even then the incentive to fix it might be low - especially if the setup is running on embedded hardware.

Memory: Sure, chaosvpn is one tool that needs to run once a day or so, so why run it all the time? Well, it needs a certain amount of memory once a day, so that amount of memory must be reserved all day anyway. So we might as well keep it running; that way, we ensure the needed memory is reserved and stays reserved.

Also, currently chaosvpn uses a very efficient way to check if a new configuration file needs to be fetched: HTTP's If-Modified-Since:-header. fefe's blog makes heavy use of that feature, and look how fast fefe's blog is ;-) When chaosvpn is run via cron, it restarts tinc every time invoked, whereas when using the If-Modified-Since-method, tinc is only restarted when something actually did change.

Ah yes, by using the rather efficient method of checking for updates it is possible to check for updates a lot more often, like every two hours. This is really good not only for when new nodes have to be added, but it is especially useful when doing an emergency disconnect of a (compromised) node.

Also, we're currently thinking of doing some cryptographically sound way of 'pushing' changes to the chaosvpn utility; more on this one to follow. For this, we'd need an extra open port. The extra open port could also be used to query all nodes on what version of the config file they are running. Now, when everyone runs chaosvpn in daemon mode, the need to check for the config file version would not really exist anymore. So the only reason to have a port open to query the version of the configuration file would be if people were running chaosvpn in cron mode. Since in that case, you'd need an additional service just to keep that port open, it's a lot easier to use chaosvpn in daemon mode.

questions? answers!

join the irc #chaosvpn @ spaceboyz.net