wiki:MunichHackathon2013

Version 37 (modified by Samuli Seppänen, 10 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:00Sunday 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
    • don't go for DCMA/cease-and-desist letters (bad press)
    • be open about it - "we have contacted these people for this-and-that reason, and are waiting for a resonse"
    • use help (templates?) from gpl-violations.org people?
  • --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"
    • james: why not do the service in a way that it implements a "VPN API", as on Android, iOS, ...? That would nicely adapt itself to OpenVPN 3
      • access control to VPN API?
    • end result: while not in full agreement on details, we'll go forward with what d12fk already has ("working code" trumps "perfect world").
  • dual-stack patches
    • agree on: use all addresses returned by getaddrinfo() in the order the OS gives it to us, making a separate connection block out of each
    • timeout handling will be reworked to be identical for tcp and udp connections
    • --proto udp will mean "v4+v6" from now on, "--proto udp4" will mean "only ipv4", "--proto upd6" will mean "only ipv6"
    • OCC etc. will have "udp", not "udp4" or "udp6"
    • same for TCP
    • plaisthos will rework patches and re-send to list
    • for the server side and "proto udp" (no AF specified)
      • without --bind, we bind to "AF_INET6" and "INADDR_ANY" (and use setsockopt() to enable a dual-stack socket <- code needs to be written)
      • with --bind, if the hostname resolves to a single IPv4/IPv6 address, we use that. If it resolves to multiple addresses, we fail with a clear error message "we can not handle that, specify a single address"
    • for the record: on windows: use setsockopt() IPV6_ONLY = 0
    • --ip-remote-hint stays in, as there is usage in certain GUIs environments ("I have a profile that has DNS lookups in, but I need to force a certain hosts on a certain IP address").
    • new feature: --presolve-ipaddress --> resolve addrinfo() right away, before connecting, because after tun establishment DNS might no longer work, with an optional parameter "ip" that is "use resolve everything to *that* address"
    • implementation-wise, --ip-remote-hint would be an alias to --presolve-ipaddress, so UIs would not have to adapt
  • window elevated privileges patch (manifest patch from pekster)
    • d12fk is worried that people might upgrade to 2.4 and then have a gui running as "administrator" which would defeat the whole interactive service approach
  • packet format and alignment (James/--tls-float patch)
    • HMAC and encrypted data is not 32bit aligned today due to the opcode
    • propose to byte-swap the opcode with the last byte in the packet, so after swapping back the HMAC is 32bit aligned
    • can be done by sending IV_PROTO=<supported max version> by the client (server can then immediately turn it on) and pushing "wire-proto <x>" from the server to the client (and then the client can immediately turn it on)
    • slightly related: include session ID in the data packet, "if you feel like it might be needed"? (to handle --float in TLS-mode without opening ourselves to UDP->HMAC CPU DoS)
    • "don't send it more than 1/second, don't send it unless you have heard from the server for more than <n> seconds"...
    • watch out for MTU jumps -> "set aside that amount of space even if not used"
    • TODO:
      • define opcodes for "wire-protocol 2" for "short/swapped mode" and "swapped mode with session id"
      • add "wire-protocol 2" to option.c etc
      • add push-peer-info IV_PROTO=2
      • add logic to server to read IV_PROTO and push "wire-protocol <x>" to the maximum supported by client and server