Andreas Happe: tech
My LTE internet connection (70 Mbit downstream, 15 MBit upstream) came with a combined Huawei B315s LTE modem/access point. As I was using it for the last two to three years a couple of problems did arise: the internet connection was often shaky, oftentimes the uplink connection got lost and I had to power-cycle the modem/access point. Subjectively this got improved with the last system upgrade. while the internet down speed on the wired connection was good, the speed achieved through the wireless connection was atrocious (see measurements later in this blog post) the power supply is badly built and takes the space of two power outlets.
Wireguard is recently making a splash as human-configurable low-overhead alternative to OpenVPN and IPSec. As some privacy-centric VPN providers are planning to support it (e.g., PIA) or already have a beta running (e.g., IVPN, as tested by Ars Technica) it was time for me to look into it. The Setup To get a better feeling about the used technology I directly connected my laptop to my desktop (gigabit Ethernet with no switch/router in between) and setup OpenVPN with a minimalist configuration as well as with a more realistic TLS-configuration.
I have a quite simple setup: Fedora 23 on my Desktop, Ubuntu 16.04 on my Notebook and a YubiKey thrown into the mix. I do have my normal GnuPG key DD436203 that I’m using. There’s also an old and revoked key 3F5D00B6 with which I was testing my YubiKey with (note to myself: don’t use an YubiKey-crested private key as you cannot backup it). My main key offers an ElGamal 2048bit subkey – which does not work with the Yubikey (as that only supports 2048bit RSA).
Update 2017: Sadly I found out (thanks due to the comments on this blog post) that using port-share does not encapsulates subsequent traffic in normal TLS. So using this method will not fool Deep-Package Inspection Firewalls. If you need to mask all your traffic, this is not an option – you might need to investigate stunnel, information can be found here, here or here. I assume, that the higher success rate of this method could be related to some firewalls checking the target of the initial https request.
Firejail describes itself as a SUID program that reduces the risk of security breaches by restricing the running environment of running programs. We’ll just call it chroot or jail (for the BSDers out there).So, it’s SUID? First things first: it’s SUID, so if there’s an error within the firejail binary an attacker can gain root rights. This comes with the territory. How large is Firejail and how many dependencies does it have?
A project I’m involved with has a traditional distributed client-server architecture: multiple servers are interconnected, clients connect to one more servers. In this use-case we’re expecting around four to seven servers with long-running connections between them and approx. a dozen clients with short-lived connections to the server. Initially I had used plain Java networking but during 2013 I’ve switched over to netty.io as a communication layer. Benefits were more agile networking code, better concurrency, etc.
Pathogen was the first vim plugin management system that I’ve known of. The contender is Vundle which seems to be inspired in it’s configuration syntax (and name) by Ruby’s Bundler. So let’s compare those two. Pathogen Pathogen’s workings are quite easy to grasp: each plugin is a directory within “~/.vim/bundle/"; pathogen traverses through the plugin list and includes each one of them. Let’s see a sample directory: 1 2 3 4 5 6 7 [~/.
After a successful penetration test a re-test is performed. The common approach is that the customer fixes the code and I perform the necessary steps to confirm that that initial security breach was closed. Sometimes it takes the customer a couple of tries to achieve that. Most security problems (XSS, CSRF, SQLi) can easily be automated tested, but I had problems automating server-side authentication and authorization problems. The test would have to emulate multiple parallel user sessions.
My blog has a history of migrations. It started as wordpress, then was converted Octopress. After Octopress was missing update-love and jekyll started to be actively maintained again it switched over to jekyll. And now, it finally is based upon Middleman. Sorry for any inconvinient bugs or layout errors that will happen during the migration. Why have I switched to middleman? as I’m a RoR devleoper it seems better suited for me.
The basic idea is to move application servers into LXC containers while keeping the HTTP server part (which is also responsible for hosting static files) on the host system. Normally an incoming request would be handled by an HTTP server on the host as well as by an HTTP server on the virtualized client: 1 browser -> http server(host) -> http server (guest) -> app-server (guest) I’m configuring the host HTTP server to directly communicate with the app worker, thus: