Profile cover photo
Profile photo
Phil Pennock
Semi-Recovering Grumpy Troll
Semi-Recovering Grumpy Troll
About
Phil's posts

Irony: Gotip "Executable is not supported on [..] OpenBSD (unless procfs is mounted.)"

Wasn't OpenBSD first to put `_progname` guaranteed in process's symbol table, via crt0 linkage? Okay, Golang isn't using crt0 but the same mechanism crt0 uses should be available.

I don't care enough to file bugs and submit patches, I just shake my head at how things change. OpenBSD can be awkward. Eg, they're a security-focused OS and they rewrote DNS stub client routines; the result, ASR is very clean and beautiful, but doesn't support EDNS0 and so doesn't support DNSSEC/AD. It seems unmaintained and so stale.

I think even in its current state, ASR is probably the right choice though: most tools don't care about DNSSEC AD-or-not and if you do care, just put a filtering validating resolver in the resolution path. No need to load down every DNS-using tool with extra logic for the very few apps which care, those apps can use another stub library. It's just annoying.

Latest version of Chrome seems to have removed the ability to see a site's HTTPS cert by clicking on the padlock. Not just "buried under developer tools, click a few more buttons" but no link to even that.

:(

Post has attachment
Funky dnsviz graph to a TLSA record via a DNAME into a different zone. The red exclamation marks are because of UDP timeouts for a couple of servers and not significant unless they persist.

The TLSA record of interest is for `25.tcp.hummus.csx.cam.ac.uk` (underscore 25 dot underscore tcp dot ...) which DNAME delegates at the _tcp level into exim.org because that machine is the MX host for @exim.org

Tagging +Exim
Photo

xpost to G+ for obvious reasons; enjoy the hilarity and schadenfreude.

Google Maps no longer finds my street address, instead picking something in a different ZIP, half an hour away. Tonight's food order has gone astray as a result.

When I go to my "Home" location, it's showing up as a range, in descending order, and has moved the Star to be in the middle of this block. The street is right. But just searching for the street, in this ZIP, gives the street miles away in another ZIP with the different ZIP being buried. I absolutely do not blame the delivery driver for not catching that.

I just gave the driver my neighbor's address, on a different cross-street (I'm on a corner lot) because that works and the driver is now on the way.

Life when Google Maps can't find your home ... this is going to get interesting.

(and yes, I filed it as a bug in Maps)

Chrome / TLS / PKI / Certificate Transparency question, seeking informed comments/answers from the brain-trust here since I can't think of an appropriate forum where this is not going to get shouted out as off-topic.

Ryan Sleevi announced in October 2016 that certificates issued in October 2017 or later would be required to be listed in public Certificate Transparency logs to be considered valid in Chrome.

CA/Browser Forum is explicitly about Public CAs; as is the IETF group, etc; the OSes I'm most familiar with (*nix, macOS) do not distinguish readily in the trust stores between "public CA" and "private CA". Also, public CAs are not allowed to issue certs for hostnames resolving to RFC1918 private address space, for which the latest CA/Browser guidance I can find explicitly lists private CAs as a good solution).

Thus: as someone running a private CA for security local network resources on non-public IPs, what is the correct approach to ensure that these continue to work from October 2017 onwards? Is there, or will there be, any way to mark a CA anchor as "trusted to not need CT"?

For now, I've gone with this, on MacOS:
defaults write com.google.Chrome CertificateTransparencyEnforcementDisabledForUrls -array .field.spodhuis.org .lan

After clicking "Reload policies" in chrome://policy I see that array show up. I somewhat assume that it works in the obvious way. Is this the "correct" way, to enumerate all domains which are used in such a manner? Because this approach makes me distinctly uncomfortable.

If I have a domain, "example.com", with sites like "www.example.com" using public certs, those should be in CT. If the site "beta3.example.com" exists and is used for a small group on less routed IP space, I might use an internal CA instead (a couple of other scenarios come to mind too). And only that CA. Not any other public CA which might be issuing certs. It should be "CT/public or this trusted other CA", not exposing those domains to unaudited certs from any other CA public or private at a time when the expectation of issuance integrity has shifted to stronger assumptions.

(It's not like most CAs are honoring CAA records in DNS at this time, after all, so even the public ones could be tricked).

So: is it "enumerate the domains to weaken trust for, better isolate public site domains from internal site domains"? Is there another approach?

Thanks for any constructive comments offered.

Well that was a FreeBSD/ZFS mistake on my part.

Had a FreeBSD 10.1 Release series install, with many Jails on it, running on my remote colo box. Successfully used ZFS boot environments to create a 10.3 base image, copy files across, reboot into it and be running with a 10.3 base outside the jails.

Realize when getting "freebsd-update" running that I'd installed 10.3-STABLE not 10.3-RELEASE and I couldn't get binary updates. Ponder, decide to zfs send/receive the current base to a new one, so that I can unpack base.tgz and kernel.tgz in that, before rebooting into it.

Carefully create a new ZFS FS, canmount=noauto mountpoint=/ ... and that was supposed to be mountpoint=none
Don't notice the mistake, zfs send/receive the content and ... wow those are some impressive system failures.
"mount" shows that I do indeed have the root filesystem mounted twice.

Reboot [reboot -q] single-user, set the newer FS to canmount=off mountpoint=none, reboot again and ... phew

Post has attachment

Mails from Apple Support starting:

$req_productName
Serial number: $req_productSerialNumber
Hi $req_firstName,
Thanks,
Apple Support

Post has attachment
Tech folks: CRITICAL OpenSSH security hole in the client, in the implementation of an undocumented feature, allowing private key disclosure but after the server has been verified.  There's a workaround available.  http://undeadly.org/cgi?action=article&sid=20160114142733

(edited to remove flawed speculation)
Wait while more posts are being loaded