Recent comments on posts in the blog:

Taking a sledgehammer to an egg?

That pwned list of a password is a fantastic resource. Thanks for posting a pointer to it.

But Egad! - using postgres to index and search it?? You must have the patience of a saint.

Given a false positive isn't a death sentence, a bloom filter is a better choice. Setting the parameters to give a false positive range of 1e-9 (roughly 50/50 chance of getting 1 false positive if I checked a password with it every second for my entire life), the resulting filter occupies 2.6G - about 1/2 the size of the compressed original. Creating the filter takes about 3 hours on my laptop (please forgive the butt ugly inline python):

sudo apt-get install python, python-pybloomfilter
wget http://.../pwned-*.txt.7z; for f in *.7z; do 7z x $f; done
python -c "import pybloomfilter, sys; b = pybloomfilter.BloomFilter(500000000, 0.000000001, ''); [b.update(open(f)) for f in sys.argv[1:]]" pwned-passwords-*.txt

Querying it:

python -c 'import hashlib,sys,pybloomfilter; b =""); sys.stdout.write("".join("%s is pwned: %r\n" % (p, hashlib.sha1(p).hexdigest().upper() + "\r\n" in b) for p in sys.argv[1:]))' password1 password2 ...
Comment by Russell Stuart
magnet URL for data
If it helps, I can vouch that this torrent magnet URL corresponds to the initial release of the password list. I found it the most convenient way to obtain the data. magnet:?xt=urn:btih:88145066d8d89cf426a22cfbeb1983dacb2a45d7&dn=pwned-passwords-1.0.txt.7z&
Comment by Jonathan

Thanks to this discussion, i just opened a bug report on irssi to try to resolve the second issue above by sending client certificates in a renegotiated handshake.

I've tested irssi, and it definitely does leak the user's public certificate to a passive network monitor.

I haven't tested ZNC yet -- If someone wanted to open a similar report for ZNC, i'd appreciate it.

If you want to test to see whether it's dumping traffic, you can do this with tshark:

tshark -O ssl  -Y 'ssl.handshake.certificates_length > 1 && ssl.record.content_type == 22'  -o http.ssl.port:6697 port 6697

I don't have a patch to propose for either irssi or ZNC yet, and don't have much time to work on it myself. I'd be happy to see that happen, because it would remove one of the major downsides to using certificates for IRC.

Comment by Daniel Kahn Gillmor
problems with certificate-based TLS authentication for IRC

I used to use this approach myself, but i stopped using it a few years ago, for two reasons:

  • certificate expiration -- when my registered certificate expires, i still need to update the server with my new certificate. to do that, i need my password. so my password still works, and i still have to retain it and send it to (what i hope is the correct) nickserv service at each cert renewal time. so this doesn't actually remove either my needing to remember/retain/record a password, and it doesn't make my remembered/recorded password less powerful.

  • client certificate leakage -- in TLS versions 1.2 and earlier (all deployed versions of TLS), the client certificate is exchanged in the clear, during the handshake. (TLS 1.3 will fix this, but it is not yet fully standardized or in deployed production). This means that client cert authentication actually leaks your identity to any passive network observer, whereas password-based authentication to nickserv does not.

This pains me, because i generally strongly prefer pubkey-based authentication over password-based authentication. But in this case, i think it's not enough of a win overall to make the transition.

What do you think about these tradeoffs? Are there mitigating factors that i should know about that makes them less troubling?

Comment by Daniel Kahn Gillmor

I figured it out.

In order for OpenVPN to use the locally installed Unbound DNS resolver, do this:

First check for the IP we should use with: sudo ifconfig

The IP we need is the one listed at

tun0: inet


Add this to /etc/unbound/unbound.conf:

    access-control: allow
    access-control: allow

Then restart Unbound with: sudo service unbound restart

Test with: dig @

(SERVER should read: SERVER:


Add this to (or modify) /etc/openvpn/server.conf:

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS"
push "register-dns"

Then restart OpenVPN with: sudo service openvpn restart

OpenVPN clients should now be using Unbound. Test at

Eldin Hadzic

Comment by Eldin Hadzic
debian/rules target work-around


We worked on a debian/rules target to download upstream tarball and signature. But I don't know if my debian sponsor is happy about it.

# Gets the name of the source package
DEB_SOURCE_PACKAGE := $(strip $(shell egrep '^Source: ' debian/control | cut -f 2 -d ':'))

# Gets the full version of the source package including debian version
DEB_VERSION := $(shell dpkg-parsechangelog | egrep '^Version:' | cut -f 2 -d ' ')
DEB_NOEPOCH_VERSION := $(shell echo $(DEB_VERSION) | cut -d: -f2-)

# Gets only the upstream version of the package
DEB_UPSTREAM_VERSION := $(shell echo $(DEB_NOEPOCH_VERSION) | sed 's/-[^-]*$$//')
DEB_SOURCE_PACKAGE := $(strip $(shell egrep '^Source: ' debian/control | cut -f 2 -d ':'))
DEB_UPSTREAM_MINOR_VERSION := $(shell echo $(DEB_UPSTREAM_VERSION) | sed -r 's/([0-9]+).([0-9]+).([0-9]+)/\1.\2.x/')

# Sets tarball-dir if not provided by command line
TARBALL_DIR ?= ../tarballs

# Sets export-dir if not provided by command line
EXPORT_DIR ?= ../build-area

  mkdir -p $(TARBALL_DIR)
  mkdir -p $(EXPORT_DIR)
Comment by Joël Krähemann
Re: OpenVPN settings

What changes need to be made to /etc/openvpn/server.conf in order to use Unbound from within the VPN tunnel when connected to the server from an external client?

I haven't yet figured out how to do that, but it's something I'd really like to add to my OpenVPN setup.

Comment by francois
OpenVPN settings

Dear Fran├žois,

Thank you so much for this! What changes need to be made to /etc/openvpn/server.conf in order to use Unbound from within the VPN tunnel when connected to the server from an external client?

Thanks for your help, Fran├žois!

Comment by Anonymous
comment 1
Not sure why, but on my freshly installed Stretch I have ntpd installed in /usr/sbin/ntpd and systemd-timesyncd seems to be running fine. Actually it looks like both are running in top?
Comment by EVD
enable UEFI
Also, you need to enable UEFI boot, so the usb or cd can boot... and plug in the AC power
Comment by Anonymous