When configuring or programming SSL/TLS servers, at some point a SSL/TLS cipher suite and a list of supported protocols have to be chosen. Unfortunately, not all configuration options are safe. :(

Meet sslsecure.vim! A plugin for the Vim editor, that marks insecure SSL/TLS cipher suites and protocols as errors. See all potentially insecure options right in your editor!

Features #

• Mark insecure SSL ciphers as errors
• Mark insecure SSL protocols as errors
• Works with all configuration files (web servers, mail servers, …)
• Works with all source code (independently on the used programming language)
• Works on top of regular syntax highlighting

I’m editing nginx configuration files. A lot. Naturally, I’ve tried several plugins for my favorite editor vim - but ran around a lot of problems:

• Most of the plugins available are outdated.
• Even syntax highlighting of the current vim plugin distributed with the nginx release has some deficits.
• I’ve been tired of copying around secure ssl_cipher directives, etc.

So, I’ve created a new, super-cool and mega-advanced vim plugin for nginx!

Ladies and gentlemen: Please welcome, chr4/nginx.vim!

Edit: This plugin was integrated into Vim and Neovim upstream!

Features #

The plugin is based on the recent vim plugin distributed with nginx-1.12.0 and additionally features the following syntax improvements:

• Highlight IPv4 and IPv6 addresses
• Mark insecure ssl_protocols as errors
• Inline template syntax highlight for ERB and Jinja
• Inline syntax highlight for LUA
• Improve integer matching
• Syntax highlighting for proxy_next_upstream options
• Syntax highlighting for sticky options
• Syntax highlighting for upstream server options
• More to come!

Furthermore:

• Remove annoying delimiters, resulting in strange word boundaries

I recently co-founded an email SaaS for developers called developermail.io where tech-savy people can configure their email mailboxes using git. We just released a new feature, which enables you to use high-entropy passwords with our services.

In this blogpost I’ll quickly show you howto generate more secure passwords for your developermail.io account and mailboxes.

Since OpenSSH 6.x came out, a lot of new ciphers where introduced. I was wondering, which ones where the best and what I should use, and I read a few articles on the internet to find out.

I’m certainly not a cryptographer, so if you have any suggestions howto further improve the configuration below, feel free to contact me.

As a general statement, one should avoid ECDSA and use Ed25519 instead, and due to the fixed key length of DSA that ssh-keygen uses, DSA should also be avoided. RSA keys should be at least 2048 bits long, perhaps 4096 bits is the better choice.

Today, I released iptables-ng, a cookbook to maintain iptables rules on different machines using chef.

But why another cookbook? There are two fairly often used around

• iptables from Opscode
• simple_iptables from Dan Crosta

Well, I wanted a tool which can do all the following:

• Configure iptables rules in a consistent and nice way for all distributions
• Be configured by using LWRPs only
• Be configured by using node attributes only
• Respect the way the currently used distribution stores their rules
• Provide a good-to-read and good-to-maintain way of deploying complex iptables rulesets
• Provide a way of specifying the order of the iptables rules, in case needed
• Only run iptables-restore once during a chef run, and only if something was actually changed
• Support both, ipv6 as well as ipv4
• Be able to assemble iptables rules from different recipes (and even cookbooks), so you can set your iptables rule where you actually configure the service

By default, the connections between the chef-client and the chef-server are not secured. This is a short post on howto encrypt and verify your connections.

As of chef-11 (unlike chef-10), SSL is enabled by default. But (naturally, as Opscode cannot create trusted certificates for your domain) the certificates are not verified. This essentially means that the connection is not secure at all.

Unless you only use chef in a trusted network, you should invest some time in securing your clients connections.