Version 29 (modified by 11 years ago) (diff) | ,
---|
OpenVPN Hackathon 2013
who
This is organized by Gert Döring (cron2) and sponsored by Spacenet AG (http://www.space.net/).
We have space for about 10 people in the conference room I have booked so far, so I'd limit this to "active developers that are also regularily contributing to #openvpn-devel or the mailing list". If there is overwhelming interest, I can get a larger room, but then the address listed below would change (still in Munich, but not as centrally located).
who is coming?
Name | Topics | Arrival | Departure |
---|---|---|---|
Gert Döring | no particular topics | Fri morning-ish | Sun, late night |
Heiko Hund | OpenVPN Windows Interactive Service General OpenVPN for Windows architecture | Fri. ~15h | Sun. ~18h |
David Sommerseth | Maintainer Plug-in API GUI on Linux | Fri, 15-ish | Sun afternoon/evening |
Arne Schwabe | OpenVPN Dual Stack OpenVPN for Android | Fri noo-ish | Monday |
Steffan Karger | PolarSSL 1.3, elliptic curve crypto | Friday noon-ish | Sunday afternoon |
Adriaan de Jong | tbd, probably some PolarSSL/Elliptic curve work, open crypto trac tickets | Friday | Sunday |
Samuli Seppänen | Ticket review, CLA, OpenVPN 2.4/3.0, NSIS | Friday 11:00 | Sunday 18:20 |
James Yonan | OpenVPN 2.4/3.0 | Thursday morning | Monday morning |
where?
We'll meet in one of the office locations of Spacenet. The address is:
SpaceNet AG Landsberger Strasse 155 80687 München (Munich) Germany
see google maps. The entrance is in the upper left corner on the inside of the "#" formed building.
Inside the "#", there are 4 entries in each of the corners, marked as "Haus 1" to "Haus 4". Take the entry "Haus 4". There is a reception for Cable&Wireless and SpaceNet? there. Tell the security guy that you want to visit SpaceNet?, and he'll call me or one of my colleagues and we'll pick you up (SpaceNet? is on the 1st floor of Haus 4). The guard will require some sort of deposit - ID card, driver license, etc - to ensure people properly check out at leaving.
This location is easy to reach by car or by public transport (Tram from central station).
Specifically:
- if you arrive by plane, take S-Bahn S1 or S8 (it's a circle, S1 goes left, S8 goes right) and exit after about 45 minutes at "Hirschgarten" or "Donnersbergerbrücke". About 10 minutes walk from there, or take the Tram 18/19 for the remainder.
- if you end up near the central station (either arriving by train, or with the S-Bahn), exit the central station on the south side, take Tram 18 or 19 towards Willibaldplatz / Gondrellplatz (westwards), and exit at "Lokschuppen". Landsberger Strasse is the street the Tram travels, 155 is across the street next to the "Bauhaus" market
- if you come by car, parking in the vicinity is a bit problematic. You can park in the "Bauhaus" garage but that's "for their customers only", so you'd need to relocate to the SpaceNet? parking garage when the SpaceNet? crew has left (no guest parking there, unfortunately). We'll find something.
If you get lost, call me: +49 177 2160221
when?
The hackathon will take place from Nov 15 (Friday), 2013 to Nov 17 (Sunday). The room is ours for the full 3 days, and I (cron2) will be there at Friday 09:30-ish. I have no confirmed arrival dates from anyone else yet...
food
I'll sponsor soft drinks and snacks, and the conference room, and I'll sponsor a "Weisswurstfrühstück" for Saturday.
For lunch, there's lots of nice small restaurants in the area, so we'll find something better than in Brussels.
Dinner on Friday is international fingerfood at Cafe Westend, nice TexMex? food and not too loud (19:00, 8-10 persons, reservation for "Döring")
For dinner on Saturday we booked a table at Augustinerkeller for some serious Bavarianism.
what?
So what is the goal of the Hackathon?
- meet in person, talk about things
- contributors agreement (CLA) for OpenVPN 3
- future development of 2.x and 3.x
- GPL violation on multiple apps on the play store
- hack on the 2.4 codebase - there's a number of "large" things we could try to tackle
- dual-stack patches
- openvpn interactive service
- work on open trac issues
- lots of things to review and bugs to fix
I'm all open for additions here - I think the meetings in Brussels have shown that "just being able to sit together and hack" is a useful excercise. Add reasonable food, air condition, etc. and things should be even better.
Internet
of course there will be free WiFi? available, and for bandwidth junkies, wired Internet as well :-) - Spacenet is an Internet service provider, and that's one of their core locations, connected with multiple 10Gbit links to the world...
accomodation
- "Motel One Munich City West" has been recommended as "being close, reasonably priced, and generally OK"
results
This is just a sort of unordered list of things we agree on, to avoid thoughts getting lost
- push-peer-info of IV_OPENVPN_GUI_VERSION -> go there in the core, gui writers can add --setenv line if they want. Format for the content = "<gui_identifier><space><version>"
- GPL violations - "we should go after them, to strengthen the GPL" - but making money out of GPL software means you have to accept that people will use your software without paying for it
- --float with TLS HMAC
- the code looks good (syzzer), but it opens the server for CPU usage DoS attacks (walking a potentially long list of clients for each unknown packet)
- put a big warning label there
- plaisthos: if we do that, send a notice to the client that the server can do it, so a mobile client can handle network changes "floating" instead of "full reconnect"
- OpenVPN 3
- it's proven itself as a mobile client
- more work is needed for desktop client
- even more work needed for server
- it's the base for the iOS client, which must have a closed license (Apple requirement), so a contributor agreement is needed to enable dual-license distribution
- what to do with "occasional contributors" that do not want to sign the agreement?
- dazo needs to check with redhat whether he can sign such a CLA
- formal text not yet finalized, James looking at stuff like the Google Android code agreement for guidance
- process for android: sign and scan an e-mail, or sign electronically on a web page
- would dual-license GPL/BSD work?
- what to do about zealots that will not accept closed license? are we in a risk of forking the project? can we do anything about it, if we accept the need to have an iOS client? (cron2 says "no")
- separate openvpn 3 into "core" (dual-licensed, with CLA) and "users of the core" (GPLed, like platform-specific for non-apple platforms, authentication related, crypto library interfaces, etc.)? "that sounds like a plan (and it sends the right signals to the community etc)" :-) - more work is needed to make good APIs for that
- mattock: timeline for releasing a git repo of 3? james: "I'll publish a git repo in the next few weeks", it's a good time, the code has been fairly quietly recently
- plan for the technical development of 2.4 and 3?
- "we will have 2.x around for quite a while, at least for the server"
- 3 will eventually be "a general client", and we might remove "client-only bits" from 2.x
- move over to 3 will take a while...
- dazo: linux, network manager, talking to openvpn 3 as a client would be a great thing - james: that's what the 3 core is good at, being API driven
- james: openvpn 3 is really meant to be used as a library, not so much as a command line client (even if it exists)
- 2.4: d12fk: the interactive service should be in. It's being shipped in the Astaro UTM provided client for a while, and works good for IPv4 routes today, but some bits are still being added (DNS, winbind, IPv6, ...)
- 2.4: dual stack cleanup (plaisthos)
- behaviour about as openvpn 3 does regarding talk to dual-stack servers
- well-tested in the android client, still needs review
- as a side note: socket.c in 3 replaced by boost ASIO library "which is brilliant and bug free"
- 2.4: handshake crypto parameters?
- "what is the best way to go there"?
- we have TLS handshaking - use that to define data-link cipher?
- reason for independent TLS and data layer crypto: SSL library might not expose symmetric crypto algorithms that are used for SSL/TLS handshake inside the library
- client pushes list of supported ciphers+hmac digest, server picks, pushes back?
- GOAL: reduce extent of incompatibilities in config file settings ("1000 clients that use MD5 and you want to switch to SHA2 on the server side")
- for compression handshake: client sends "flags" (IV_LZO=1, IV_SNAPPY=1, ...) in the TLS control channel (at authentication phase), server decides via mgmt interface or client-connect script
- we can not use DTLS - it's a different on-the-wire protocol, and there are issues with it - not recommended anyway
- 2.x code currently will not handle per-client cipher and HMACs yet, because the code assumes that cipher/HMAC is known at connection time, and not changing later on - so it cannot be pushed server->client, and the server will not handle different ciphers either. TBD ("historic design defect"). OpenVPN 3 does it right.
- so 1st step: handle per-client cipher on server and pushable cipher on client
- 2nd step: handle negotiation
- 2.4 (cron2): IPv6 enhancements
- handle overlapping IPv6 server address and pushed IPv6 routes ("2001:608::/32 and server inside 2001:608::/32 -> recursive routing"). This is done for IPv4 but not IPv6 yet. Ask OS for default gateway, install route to OpenVPN server to that gateway, then install pushed routes. Cleanup on exit.
- --block-ipv6 for mobile clients (blocking inside OpenVPN)
- windows and the interactive service
- privileged service running
- GUI talks to service, service runs openvpn process with user rights, but restricted permissions against access from elsewhere
- routes get installed by having openvpn signal the service that routes should be installed/removed/...
- gain: users do not need to run gui with admin rights, and openvpn process does not run with admin rights
- remaining attack angle: install unauthorized routes
- it can be locked down by only permitting .ovpn profiles from a given non-user-writeable path (registry setting at installation)
- on XP, this is actually not needed (only Vista and up), so the installer could decide to not install the service at all, as network programming on XP needs "netsh" while Vista and up have a decent API for that.
- "do not put any extra effort on XP, but do not break it on purpose"