Code Kills

Adventures in X.509: The Utterly Ignored nameConstraints

Sun, 08 Apr 2012 21:16:08 EDT

In yesterday's post looking at MintChip's hosted API's crypto, I noticed that MintChip's certificate authority does not have any name constraints. This was surprising, because this seemed like a simple and obvious issue with an otherwise well designed system... But after some experimentation, it seems that OpenSSL simply ignores nameConstraints, so they would be mostly worthless even if they were used.

Adding nameConstraints to MintChip's CA

This can be seen by adding some nameConstraints to MintChip's certificate authority and re-signing it using a new, trusted, certificate authority.

Note that all files referenced here can be found at /uploads/adventures_in_x509_ignored_nameconstraints/.

A new certificate authority is created and the add_name_constraints.py to add nameConstraints to MintChip's CA's certiificate, creating mintchip_with_constraints.crt, which will be signed by the new CA:

$ openssl req -new -x509 -keyout trusted_ca.pem -out trusted_ca.pem -nodes
...
Organizational Unit Name (eg, section) []: New Trusted Authority
...
$ ./add_name_constraints.py trusted_ca.pem mintchip_ca.crt > mintchip_with_constraints.crt
$ openssl x509 -noout -text -in mintchip_with_constraints.crt
Data:
    ...
    Issuer: OU=New Trusted Authority
    Subject: CN=Remote MintChip Certificate Authority, OU=Remote MintChip, O=Royal Canadian Mint, C=CA
    ...
    X509v3 extensions:
        ...
        X509v3 Name Constraints: critical
            Permitted:
              DNS:does_not_exist.com

Testing the Constraints

The constraints can now be tested using OpenSSL's s_client:

$ cat trusted_ca.pem mintchip_with_constraints.crt > ca_list.crt
$ openssl s_client -CAfile ca_list.crt -connect remote.mintchipchallenge.com:443
CONNECTED(00000003)
depth=2 /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/OU=New Trusted Authority
verify return:1
depth=1 /CN=Remote MintChip Certificate Authority/OU=Remote MintChip/O=Royal Canadian Mint/C=CA
verify return:1
depth=0 /CN=remote.mintchipchallenge.com/OU=Remote MintChip Server/O=Royal Canadian Mint/C=CA
verify return:1
...
SSL-Session:
    ...
    Verify return code: 0 (ok)
---

Note that:

Our "New Trusted Authority" is used to verify MintChip's Certificate Authority (first six lines).
The SSL session is successfully verified (the last line).

This suggests that OpenSSL is not checking name constraints.

Double Checking

To double check that our certificat authority is actually being consulted, the same test can be run, except using only the mintchip_with_constraints.crt certificate:

$ openssl s_client -CAfile mintchip_with_constraints.crt \
    -connect remote.mintchipchallenge.com:443
CONNECTED(00000003)
depth=1 /CN=Remote MintChip Certificate Authority/OU=Remote MintChip/O=Royal Canadian Mint/C=CA
verify error:num=2:unable to get issuer certificate
issuer= /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/OU=New Trusted Authority
verify return:0
...
SSL-Session:
    ...
    Verify return code: 2 (unable to get issuer certificate)
---

The verify now fails, so it's fairly certain that the certificate chain is working as expected.

Adding dirName nameConstraints

Applications conforming to this profile MUST be able to process name constraints that are imposed on the directoryName name form and SHOULD be able to process name constraints that are imposed on the rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name forms.

On closer inspection of RFC 5280, it turns out that applications are only required to check name constraints which are imposed on directory names.

This poses a slight challenge, as (for various reasons) pyOpenSSL cannot create a nameConstraints extension which imposes a dirName constraint[0].

The OpenSSL command line tools can be used to create a new certificate which does contain nameConstraints on a dirName (see the definition in name_constraints_on_dirNames.cfg), then pyOpenSSL can load that certificate and copy the constraints into the target:

$ openssl req -new -x509 -nodes -config name_constraints_on_dirNames.cfg \
>   -out dirName_constraints.crt
...
$ ./add_name_constraints.py trusted_ca.pem mintchip_ca.crt \
>   dirName_constraint.crt > mintchip_with_dirName_constraints.crt
...
$ openssl x509 -noout -text -in mintchip_with_dirName_constraints.crt
Certificate:
    ...
    X509v3 extensions:
        ...
        X509v3 Name Constraints: critical
            Permitted:
              DirName: CN = bad_common_name

Nifty!

[0]: OpenSSL expects the value of the dirName=... to be a name which is looked up in the configuration database (ex, nameConstraints = permitted;dirName=some_section_), but pyOpenSSL does not provide a configuration database.

Testing the dirName Constraint

Testing this new certificate with s_client:

$ cat trusted_ca.pem mintchip_with_dirName_constraints.crt \
>   > ca_list_with_dirName_constraints.crt
$ openssl s_client -CAfile ca_list_with_dirName_constraints.crt \
>   -connect remote.mintchipchallenge.com:443
CONNECTED(00000003)
depth=2 /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/OU=New Trusted Authority
verify return:1
depth=1 /CN=Remote MintChip Certificate Authority/OU=Remote MintChip/O=Royal Canadian Mint/C=CA
verify return:1
depth=0 /CN=remote.mintchipchallenge.com/OU=Remote MintChip Server/O=Royal Canadian Mint/C=CA
verify return:1
...
SSL-Session:
    ...
    Verify return code: 0 (ok)
---

Still no love. It sure looks like OpenSSL simply ignores the nameConstraints field on certificate authorities.

Post Script

On Twitter, Dan Kaminsky was kind enough to "confirm" my suspicions:

@wolever @hypatiadotca You can't rely on name constraints.There's a reason nobody will ever sell you a name constrained cert.
— Dan Kaminsky (@dakami) April 8, 2012

And suggests:

@wolever @hypatiadotca They might be checked by CryptoAPI and NSS, but it doesn't matter.
— Dan Kaminsky (@dakami) April 8, 2012

tl;dr

OpenSSL does not check nameConstraints. Yay.

A First Look at MintChip's Hosted API's Crypto

Sat, 07 Apr 2012 20:05:49 EDT

The Royal Canadian Mint announced a challenge last week, calling for developers to build software which uses MintChip. MintChip is a proposed digital currency which is decentralized, anonymous, and offline. The (currently scarce) details of the device and developer challenge can be found at mintchipchallenge.com.

A couple of friends and I have signed up to build something, and we just got the private keys and certificates necessary to interact with the "hosted MintChip" API.

Overview

Before I go into more detail, let me first explain: payments are processed by the "trusted"[0] MintChip hardware. This hardware can either be attached directly to the device facilitating a payment (for example, a smart phone), or hosted by a trusted 3rd party, allowing the MintChip to be used from any internet-connected device.

This is called the "hosted API", and this post deals with the cryptography used for authentication and privacy by the current implementation of the hosted API.

Once my physical devices arrive, I will write a post about them, provided they are sufficiently interesting.

[0]: at least, trusted in theory; if the hardware is compromised it would be possible to forge transactions (ex, double-spend, create new money, etc).

The Hosted API

Important notes:

Everything here is educated guesswork, based only on the sparse MintChip documentation and the PKCS12 file which is used to access the hosted API.

I am an x509 enthusiast but not an expert. If you are, I would very much appreciate it if you pointed out any inaccuracies or omissions.

This is a developer preview of a proof-of-concept. There is no guarantee that the security of the final system will look anything at all like the system I'm describing here.

The first thing you'll notice when trying to access the hosted HTTPS API is that it signed with an "invalid" certificate (although this is for a sensible reason; keep reading):

$ curl https://remote.mintchipchallenge.com
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html

And connecting anyway yields a 403 Forbidden (also, that they are running ASP.NET):

$ curl -Ik https://remote.mintchipchallenge.com
HTTP/1.1 403 Forbidden
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET

HTTPS Server Certificate

Grabbing and dumping the certificate they are using:

$ openssl s_client -connect remote.mintchipchallenge.com:443 -showcerts \
> | openssl x509 -noout -text
...
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=Remote MintChip Certificate Authority, OU=Remote MintChip, O=Royal Canadian Mint, C=CA
        Validity
            Not Before: Mar  6 08:25:42 2012 GMT
            Not After : Mar  7 08:25:42 2013 GMT
        Subject: CN=remote.mintchipchallenge.com, OU=Remote MintChip Server, O=Royal Canadian Mint, C=CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:8e:1c:52:2f:c7:62:7d:05:0b:4a:80:4f:cb:91:
                    ...
                    5a:90:60:58:f9:43:c8:bc:f1
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Key Encipherment, Key Agreement
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
    Signature Algorithm: sha1WithRSAEncryption
        58:34:a3:bd:f3:8d:17:b2:eb:4e:ed:f6:58:b0:13:3b:8c:79:
        ...
        91:0d:59:81
...

Note that the certificate is issued by "Remote MintChip Authority". I suspect that MintChip chose to use their own CA both for simplicity (they don't need to deal with a 3rd party) and security. Apart from that, this certificate looks fairly standard (although I don't fully understand the implications of the "Key Agreement" flag).

Developer Account PKCS12 Files

Next, once my developer account[0] was approved, I was sent two PKCS12 files (and the passwords used to decrypt them), corresponding to (I assume) two hosted MintChips.

[0]: actually, my friend's developer account - mine hasn't been approved yet.

Unpacking each of these PKCS12 files yields one private key and two certificates:

$ openssl pkcs12 -nodes -passin pass:hunter2 -info -in 1310000000008139.p12
MAC Iteration 1024
MAC verified OK
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 1024
Bag Attributes
    localKeyID: 82 8F 5D AD 42 DC C9 EA 25 2C 6E 65 C0 DB B8 20 52 7D 1D 15
    friendlyName: 1310000000008139 Remote MintChip Client (Developer Challenge)
Key Attributes: <No Attributes>
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 1024
Certificate bag
Bag Attributes
    localKeyID: 82 8F 5D AD 42 DC C9 EA 25 2C 6E 65 C0 DB B8 20 52 7D 1D 15
    friendlyName: 1310000000008139 Remote MintChip Client (Developer Challenge)
subject=/CN=1310000000008139/OU=Remote MintChip Client/O=Royal Canadian Mint/C=CA
issuer=/CN=Remote MintChip Certificate Authority/OU=Remote MintChip/O=Royal Canadian Mint/C=CA
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
Certificate bag
Bag Attributes
    friendlyName: Remote MintChip CA (Developer Challenge)
subject=/CN=Remote MintChip Certificate Authority/OU=Remote MintChip/O=Royal Canadian Mint/C=CA
issuer=/CN=Remote MintChip Certificate Authority/OU=Remote MintChip/O=Royal Canadian Mint/C=CA
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

The Private Key

As far as I can tell there is nothing noteworthy about the private key.

The Client Authentication Certificate

Inspecting the first of the two certificates yields:

$ echo "$FIRST_CERT" | openssl x509 -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1198 (0x4ae)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=Remote MintChip Certificate Authority, OU=Remote MintChip, O=Royal Canadian Mint, C=CA
        Validity
            Not Before: Mar  6 10:06:45 2012 GMT
            Not After : Mar  7 10:06:45 2013 GMT
        Subject: CN=1310000000008139, OU=Remote MintChip Client, O=Royal Canadian Mint, C=CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:a7:1b:d9:81:17:ce:ae:b7:e8:46:6c:51:6b:b8:
                    ...
                    62:20:0b:93:f7:02:4c:c5:dd
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
    Signature Algorithm: sha1WithRSAEncryption
        67:b9:d1:47:c2:62:82:60:1d:f9:01:04:de:c6:db:19:f3:3e:
        ...
        17:16:60:0f

As can be seen by the "Extended Key Usage" extension, this certificate will be used for client-side certificate authentication.

I think this is pretty cool. When password protected, client-side certificates provide a nifty and unobtrusive form of two-factor authentication. I've only ever seen them used "in the wild" by CACert, so it's fun to see someone else using them.

As before, this certificate is signed by the "Remote MintChip Certificate Authority".

Nothing else is particularly surprising.

The Certificate Authority's Certificate

Now, on to the second certificate:

$ echo "$SECOND_CERT" | openssl x509 -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=Remote MintChip Certificate Authority, OU=Remote MintChip, O=Royal Canadian Mint, C=CA
        Validity
            Not Before: Mar  6 08:25:36 2012 GMT
            Not After : Mar  7 08:25:36 2017 GMT
        Subject: CN=Remote MintChip Certificate Authority, OU=Remote MintChip, O=Royal Canadian Mint, C=CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:ab:d9:7b:dc:a8:eb:55:59:05:46:23:ef:4d:76:
                    ...
                    9a:c1
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:TRUE
            X509v3 Key Usage:
                Certificate Sign
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, TLS Web Server Authentication
    Signature Algorithm: sha1WithRSAEncryption
        41:95:6f:94:9a:3e:9d:03:af:a3:22:d6:0f:b6:7a:08:91:9d:
        ...
        b3:da:88:bf

This is the certificate of the "Remote MintChip Certificate Authority" that has signed all the other certificates we've looked at.

Unlike all the other certificates we've looked at, though, this certificate is surprising: this certificate needs to be[0] added to the list of trusted CAs on all the devices which will use the MintChip hosted API... But it doesn't include any name constraints! [1] This means that, if the CA's private key was compromised, it could be used to forge certificates that would be trusted by any device which trusts this CA.

I find this omission a bit surprising; the hosted API's security appears to be well designed, which makes it seem unlikely that this was accidental.

Because the system is otherwise intelligent, I'm inclined to give MintChip the benefit of the doubt here, and assume that there is a good reason for omitting the name constraints. This is a developer-only preview of a proof-of-concept system, so it's possible they will be changing domains or using this CA in as-of-yet unexpected ways.

Edit: after some experimentaton, it seems that there is a less mysterious reason for the CA's lack of name constraints: they are ignored. For more details, see "Adventures in X.509: The Utterly Ignored nameConstraints".

[0]: or, at least, "really should be"

[1]: RFC 2459 section 4.2.1.11, "Name Constraints".

tl;dr

The MintChip hosted API uses SSL client certificates for authentication, and both client and server certificates are signed by MintChip's own self-signed certificate authority.

In MySQL land, "latin1" isn't actually latin1

Tue, 20 Mar 2012 02:41:56 EDT

Lesson learned: in MySQL land, "latin1" isn't actually latin1 — it's cp1252[0].

The the consequence? Magic. Everything will appear to work until a connection character encoding is specified, a SELECT INTO OUTFILE is issued, or you start to realize that unicode data are taking up two or three times more disk space than they reasonably should.

More specifically: when no connection character set is specified, MySQL defaults to using "latin1". Additionally, programmers will occasionally send utf8 encoded data over a MySQL connection without setting the connections' character set… Which leads to unexpected results under the conditions described above.

For example, imagine that the string u"☃" is encoded as utf8 ("\xe2\x98\x83") and sent to MySQL over a connection using the cp1252 character set (the default if no SET CHARACTER SET command is issued). MySQL will receive these three bytes, then decoded them as cp1252, yielding three unicode code points: u"\xe2\u02dc\u0192". These three code points are then stored to disk using the column's character set (for example, if the column's character set is utf8, the bytes "\xc3\xa2\xcb\x9c\xc6\x92" will be written to disk):

>>> u"☃"
u'\u2603'
>>> _.encode("utf8")
"\xe2\x98\x83"
>>> _.decode("cp1252")
u"\xe2\u02dc\u0192"
>>> _.encode("utf8")
"\xc3\xa2\xcb\x9c\xc6\x92"

Next, when that string is sent back to a client, the bytes are read from disk and decoded using the column's character set: "\xc3\xa2\xcb\x9c\xc6\x92" decodes to u"\xe2\u02dc\u0192". This string is then encoded using the connections character set and the resulting bytes are sent back to the client: u"\xe2\u02dc\u0192" encodes to "\xe2\x98\x83" — the "correct" utf8 bytes:

>>> "\xc3\xa2\xcb\x9c\xc6\x92".decode("utf8")
u"\xe2\u02dc\u0192"
>>> _.encode("cp1252")
"\xe2\x98\x83"
>>> _.decode("utf8")
u'\u2603'
>>> print _
☃

And the client will continue to see the "correct" utf8 bytes until the last "encode as cp1252" step is omitted… For example, because the connection's character set has changed, or because the SELECT INTO OUTFILE command is issued[1].

In cases when the last "encode as cp1252" step is omitted, results will seem very strange. For example, if the SET CHARACTER SET binary command is issued (to simulate a SELECT INTO OUTFILE), the bytes "\xc3\xa2\xcb\x9c\xc6\x92" will be returned, and similar things will happen if the connection encoding is set to utf8.

Note also that six bytes are being used to store a three utf8 bytes.

With the luxury of planning and foresight, this madness could have been avoided by:

Issuing SET CHARACTER SET utf8 at the start of connections.
Ensuring that (unless there is a good reason not to), databases have DEFAULT CHARACTER SET utf8.
Ensuring that only utf8 bytes are sent to the database.

But, as is so often the case, the particular data which lead to this discovery were generated by a PHP application that is out of my control... So for now, I will be living with .decode("utf8").encode("cp1252").decode("utf8").

(thanks to Taavi Burns, who pointed out that MySQL assumes "latin1" means "cp1252", making it possible to solve my original problem)

[0]: as documented here: http://dev.mysql.com/doc/refman/5.0/en/charset-we-sets.html (fun fact: the at the top of the Wikipedia entry for 8859-1 (latin1), there is the notice: “For the character encoding commonly mislabeled as "ISO-8859-1", see Windows-1252”).

[1]: SELECT INTO OUTFILE uses the column's encoding, not the connection's: http://dev.mysql.com/doc/refman/5.0/en/select-into.html

Vim functions to change tab treatment

Sun, 22 Jan 2012 16:00:00 EST

I've gotten tired of doing the :setlocal tabstop=... dance every time I start editing a file from someone who has their own unique feelings about how wide tabs should be... So I've written two little functions which make it easy to change a buffer's tab mode:

For example, when I start editing something written by someone who believes spaces are evil and tabs should be five spaces wide, I just need to :call HardTabs(5).

In case of Wikimergency (removing Wikipedia's blackout)

Wed, 18 Jan 2012 02:06:12 EST

Here's a bookmarklet that will remove the SOPA blackout overlay from Wikipedia:


javascript:(function(){document.getElementById("mw-sopaOverlay").style.display = "none"; var ids = ["mw-page-base", "mw-head-base", "content", "mw-head", "mw-panel", "footer"]; for (var i = 0; i < ids.length; i += 1) document.getElementById(ids[i]).style.display = "block";})()

Or bookmark this link.

Loading Google Closure libraries from Node.js

Tue, 10 Jan 2012 01:24:42 EST

While developing remora (which will be released "soon") I had to load Google Closure libraries from Node.js. As it turns out, I'm the first one who has had to do this, so a blog post seemed in order.

I've loaded my Closure library in Node by creating a Node module which loads Closure's base.js, tells Closure how to load JavaScript files, loads my Closure library, then exports everything (the goog name space and my namespace) through module.exports.

First, an execfile function is needed, which will load and evaluate a JavaScript file using a particular namespace:

var vm = require("vm");
var fs = require("fs");

function execfile(path) {
  var data = fs.readFileSync(path);
  vm.runInThisContext(data, path);
}

Note: for various reasons (one of which being that you can't control the value of 'this' from the 'vm' module) vm.runInThisContext must be used to load the scripts into the global context. Trying to load the into a sandbox seems to fail for reasons I can't fully explain yet.

Next, the Closure base.js and deps.js files are loaded and CLOSURE_IMPORT_SCRIPT is set to a thin wrapper around execfile:

var base_basedir = "../src/browser/";
execfile(base_basedir + "base.js");
execfile(base_basedir + "deps.js");
goog.global.CLOSURE_IMPORT_SCRIPT = function(path) {
  execfile(base_basedir + path);
  return true;
};

Now Closure libraries which use goog.require(...) and goog.provide(...) can be loaded:

execfile("../src/remora.js");

(note: only the base library needs to be loaded; its dependencies will be taken care of by goog.require(...)).

Normal JavaScript packages can also be loaded:

execfile("../libs/underscore-1.2.3.js");

Finally, module.exports is set:

module.exports = {
    goog: GLOBAL.goog,
    remora: GLOBAL.remora,
};

Note: because Closure scripts expect that require/provide will inject items into the global namespace, the global names created (ex, goog and remora) cannot be deleted from the global namespace.

And that's all there is to it. This file can now be loaded like any other Node module (ex, var my_closure_library = require("./closure_compat.js")).

For a complete example, see remora/src/node/remora.dev.js.

Which SSD You Should Buy

Tue, 22 Nov 2011 19:32:25 EST

I'm thinking about buying a 200+ GB SSD for my laptop, and this post summarizes my research. Note that it is current as of November 22, 2011 and will likely be irrelevant by 2012.

tl;dr The Corsair Force GT seems to be the fastest choice with Crucial m4 coming in a fairly close second. Data on failure rates for these drives/controllers has been hard to find, though, and all signs point to Intel drives being the most reliable (but also most expensive and slowest).

TechReport's SSD performance review which @samstokes sent me, which seems to find the two aforementioned drives to have the best performance, with the Corsair Force Series 3 making a decent showing as well. It also suggests that the Intel 500 series is a bit slower and significantly more expensive than the competition.

Tom's Hardware investigation on SSD reliability suggests that Intel's SSDs are much more reliable (specifically their X25-M series; a sentiment I've read in other places too), but it doesn't compare their failure rates to other manufacturers because "those are the drives that big businesses currently trust the most".

Friends on Twitter and Facebook generally recommended the m4.

It's also worth noting that I've read quite a few posts similar to The Hot/Crazy Solid State Drive Scale which suggest that failures can be fairly common. These posts have mostly been more than six months old, though, so I'm hoping that most of these problems have been sorted out in newer drives (it seems that there are often issues which can be fixed by a software update).

The net result is that I'm probably going to get a Force GT or m4, which ever I can find for a reasonable price from a local retailer with a good return policy.

Disclaimer: what you see is what you get. I've done enough research to convince myself that an SSD isn't a terrible idea, but that's definitely far from enough research to objectively show that an SSD isn't a terrible idea. Also, I've included links to Amazon for two reasons: 1) because prices change so often that quoting them here wouldn't be that useful, and 2) I've just setup a fancy affiliate account, so I stand a small chance of making a small amount of money from them.

howto: running the wifi and power at medium sized tech events

Mon, 07 Nov 2011 13:32:36 EST

Because I've done it a few times now and picked up a few tricks, I thought I would write a checklist for anyone who needs (or wants) to run the wifi and power at a medium sized (10 - 100 people) tech event.

I hope that this checklist will be a useful for events like Software Carpentry or Ladies Learning Code, as it will give someone with some networking knowledge [0] the nuts-and-bolts they need to setup and run a great (or at least functional) network.

I've published this document as a Gist on GitHub to make updates easy.

The document: Wifi and power for medium sized tech events: https://gist.github.com/1346886

[0]	anyone who knows the function of DHCP and the meaning of "default gateway" should be fine.

Winter protip: hand warmers. Lots of them.

Mon, 31 Oct 2011 00:08:47 EDT

Now that winter is coming, I'd like to share a tip that has been the difference between a terrible and a great day: hand warmers. Lots of hand warmers.

Here's what you do:

Buy hand warmers. Lots of them. Like fifteen pairs of them. They are $1.20 for a pair, so no banks will be broken by having a few extras.
Put a pair (or two?) in the pocket of each of your winter jackets.
Use them! Next time you (or your friend/spouse/child) is uncomfortably cold, just rip a hand warmer open. Ten minutes later you'll have a warm little bundle of joy to stick in your boot/glove/jacket/hat.

There are a bunch of reasons I've found step three to be hard: I don't want to admit to myself that I'm actually cold, I don't want to use them now because I may need them even more in the future, or because I don't feel like the warmth is worth the $1.20 it will cost... But since I have never regretted using one, I feel like it's worth tricking myself into using them more liberally by keeping lots of spares around, using it "for a friend", and telling myself that each one only costs 60¢ (that's like two quarters!).

On Startups and Identity

Tue, 18 Oct 2011 15:18:42 EDT

A curious thing I've noticed recently is that a large number of startups don't include any information about the identity of the founders/employees.

I find this strange because, in my opinion, a big advantage of working with (or using the product of) a startup is that I can get to know the person (or people) behind the scenes. They might even be someone I know, or someone a friend knows.

I would go on, but I would just be repeating what Jason Cohen says in You're a little company, now act like one.

So, if you're part of a startup: please, include your identity and the identity of the other founders/employees somewhere on your website.