Dieses Wiki ist ein Archiv bis 2023. Das aktuelle Wiki findet sich unter https://wiki.hamburg.ccc.de/
Difference between revisions of "ChaosVPN:geekend1"
m (remove wrong external link) |
|||
(17 intermediate revisions by 8 users not shown) | |||
Line 1: | Line 1: | ||
+ | {{Vergangenheit}} | ||
= what? = | = what? = | ||
Line 7: | Line 8: | ||
= when = | = when = | ||
− | The Geekend will be on | + | The Geekend will be on January 28th - 30th. |
− | + | = participants = | |
− | + | * arrived: | |
− | |||
− | |||
− | * | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+ mc.fly | + mc.fly | ||
+ guus | + guus | ||
+ | + crest | ||
+ | * still missing | ||
+ Jens | + Jens | ||
+ hc | + hc | ||
+ nomaam | + nomaam | ||
+ wopot | + wopot | ||
+ | + zocker | ||
= Issues = | = 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 == | == dns == | ||
− | Improve dns usage in ChaosVPN. | + | |
− | + | Improve dns usage in ChaosVPN. | |
+ | |||
+ | * which dnsd (pro and con. discusion) | ||
+ | * anycast | ||
== connect people == | == connect people == | ||
Line 47: | Line 51: | ||
** package | ** package | ||
** image with tinc and config for fonera 2.0n | ** image with tinc and config for fonera 2.0n | ||
− | |||
= Goals = | = Goals = | ||
Line 56: | Line 59: | ||
= infrastructure = | = infrastructure = | ||
== lodging == | == lodging == | ||
− | * | + | * best western queens hotel hamburg around the corner |
* limited sleeping in the hackerspace is possible | * limited sleeping in the hackerspace is possible | ||
Line 63: | Line 66: | ||
== suggested topics == | == suggested topics == | ||
− | a) maintaining the chaosvpn.net content | + | * a) maintaining the chaosvpn.net content |
− | b) making chaosvpn more secure - hc's nonroot changes alone are not enough | + | * b) making chaosvpn more secure - hc's nonroot changes alone are not enough |
− | c) (re)define a joining policy/policies | + | * 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 | + | * 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 | + | * 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! = | = questions? answers! = | ||
join the irc #chaosvpn @ spaceboyz.net | join the irc #chaosvpn @ spaceboyz.net | ||
+ | |||
+ | [[Category:ChaosVPN]] |
Latest revision as of 23:18, 22 December 2013
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.
Contents
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
attendes
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