I do not see many books for toddlers about economics. So the other day I wrote, printed, laminated, and ring-bound one for my toddler. "Will You Trade?" focuses on the concept of exchange. It hints at other important economic principles including subjective value, marginal utility, property ownership, the mutual benefit of voluntary exchange, and more.
You are welcome to download and print "Will You Trade?" yourself. The design is such that you can print it on US legal paper and fold it into a booklet. You can color it as well, but that might disrupt the homogeniety of the stock of goods in question depending on how you do it.
My one-and-a-half year old did not respond as enthusiastically as I hoped. However, I caught him "reading" it to himself a couple days after I introduced it. Let me know how your toddlers respond! My email address is "jesse" at this domain name.
Browser plugins and add-ons
What browser should be used and what add-ons will protect the user from the myriad disrespect out there on the web? What follows is one possible set-up.
Use Firefox.
Disable all plugins. Exceptions: if you know you need one, simply set it as Ask to Activate.
SHOULD: Add-on uBlock Origin. Note: uBlock Origin may break some sites, but seems to be mostly unobtrusive.
MAY: Add-on SSLeuth. SSLeuth displays a scale of TLS strength in location bar for your curiosity's sake.
OPTIONAL (web-savvy only): Add-on NoScript Security Suite. NoScript Security Suite will break some sites, requires some understanding of how the web works, and requires some configuration if you want it to work for you. Can be used in place of Disconnect.me and uBlock Origin if you set a strict policy and delete everything from the whitelist.
VERY OPTIONAL (web-savvy only): Add-on RequestPolicy Continued. RequestPolicy Continued will break sites, requires some understanding of how the web works, and requires some set-up. Basically you can set a very harsh policy toward third-party requests. Use in conjunction with NoScript and instead of Disconnect.me and uBlock Origin.
Neither of the EFF's (MUST) extensions require configuration. They just work for you. Basically if you are not a programmer or web developer, you can use the first three or four add-ons listed without worry. If you are interested to see the strength of the TLS connection to a server, you can use SSLeuth to colorize your whole location bar.
If you are a programmer or web developer with some idea of how HTTP and JavaScript work, and are interested in taking a strict approach, and don't mind pages looking different (or missing lots of content without some clicking), use NoScript Security Suite and RequestPolicy Continued in place of Disconnect.me and uBlock Origin.
Try it out and let me know how it goes. Email address is jesse at the-address-in-your-browsers-location-bar.
Some of you may be thinking there are even stricter options out there, and you're right. Sending links2 through proxychains and Tor is a nice option for you. The recommendation above is for the rest of us.
Using GnuTLS certtool to create and sign your own server certificates
Suppose you want to run a TLS-secured service such as a web server. Suppose you don't need the certificates to be signed by a widely trusted authority, but you do want authenticity, i.e. to have some evidence that the server is who it says it is, and not some other party listening in. Furthermore suppose you may in the future wish to create client certificates for the server to validate when a client connects. When you start searching the web for how to generate the keys and x.509 certificates required, you will probably find outdated advice. Check the date of the post you are reading first. If it is before June, 2013, you can immediately move to the next post. There are still bad examples created after 2013, so here I'm going to attempt a decent example.
The goal is by the end of the exercise to have the following:
A server key and certificate suitable for TLS-secured communications on the server
A Certificate Authority key and certificate suitable to sign the above certificate
Reasonable confidence that we didn't just leave our doors wide open
Get GnuTLS certtool
Step one is verify you have a supported version of GnuTLS's certtool by visiting gnutls.org/download.html and examining the version numbers there. On your machine, run the command certtool -v for comparison. If you don't have certtool installed, in Debian-based (or aptitude-managed) GNU/Linux distributions the command apt-get install gnutls-bin will install certtool and its dependencies. If your distribution gives you an ancient version, download from gnutls.org.
Think about keys
Step two is decide where keys should live. The security of your keys is a ceiling on the security of the communications that use them. Ideally we would create our Certificate Authority key material on an offline, air-gapped computer with the best kind of random number generator available. But maybe we don't have time for such luxuries and just need to get moving without being too sloppy. In either case: keep the keys where they were generated. Do not move keys, and use the protections available to you on your operating system to limit access to those keys. Your Certificate Authority's key could be on your personal computer, for example, and the server's key should be on the server. And nowhere else.
Generate keys
Step three is generate private keys in the appropriate places. Suppose your only use for the certificate authority is a one server or handful of servers and the service is named "mydomain". Suppose you have a terminal open on your offline computer in your underground lair, you might create a directory for your certificate authority:
Then you might check that permissions are correct, only the current user should have any access to this file. ls -l *.pem
Suppose now you have a terminal open on your server computer. On your server computer, you also would generate the server's private key in a directory devoted to the domain:
mkdir ~/mydomain_certs
cd ~/mydomain_certs certtool --generate-privkey --outfile mydomain_server_private_rsa_key.pem
Also check that permissions are correct, i.e. only the current user should have any access to the file. If not, in either case you can do chmod 400 *private_rsa_key*
if you followed the naming above.
Use descriptive filenames
Descriptive filenames may help you keep track of what each file is. Since the file format does not tell you what is in the file (mostly these are pem), and since it is easy to forget which is which, I find it helpful to name files after what is in them. Descriptive names help especially if the file contains private key material. If I then ever see the words "private" or "key" in a filename and it has anything other than read-only-by-one-user permissions, I can double check my work and either correct the name or correct the permissions. The rest of the examples will follow the pattern of having the filename contain the name of the type of stuff that's in the file. The only downside I can think of is having a mistaken name of a file, e.g. labeling a file the wrong way, and fooling yourself later about what's in it. But then again, a discovered mistaken name could indicate an error along the way, and signify the need to delete the files and start over, which is helpful.
Create the Certificate Authority
Step four is create the Certificate Authority which is to say, generate a self-signed x.509 certificate controlled by the certificate authority private key generated in step three. For background information on TLS' use of x.509 certificates and certificate authorities, look up Moxie Marlinspike's SSL and the Future of Authenticity. But I digress. On the offline underground lair terminal (or your personal computer), in the directory next to the certificate authority's private key:
A large number of requests for information are presented. Which ones should be changed or are necessary? The following fields should be changed from default values and some recommended values follow (choose your own names for Common name and Organization name):
Common name: MyDomain Certificate Authority
Organization name: Authority, Ltd.
The certificate will expire in (days): 365
Does the certificate belong to an authority? (y/N): y
Path length constraint (decimal, -1 for no constraint): 0
Will the certificate be used to sign other certificates? (y/N): y
The Common name and Organization name can be arbitrary names. They are tied to your certificate authority, which will be used for signing other certificates, so they do not need any DNS names or IP names in them. Just make up some fun names.
How long should I set my CA to expire? Getting these things set up is a pain in the butt, so should it be a long, long time? No, follow the "if it hurts, do it more" principle. Given the pace of discovery in the security universe and given that you want keys to be rotated frequently anyway, do something like a year, 365 days.
Yes, your certificate "belongs to an authority", that authority being you and your control of the private key generated earlier in step 1.
Do set Path length constraint to 0, or at worst, 1. What does this mean? Path constraints are supposed to be a way of limiting the use of a certificate beyond the intent of the issuer. If you set it to 0, you effectively disallow intermediate authorities to be created by this certificate authority, assuming that clients actually check the constraints. When set to 0, the maximum chain length is 2 certificates: the root certificate (your certificate authority certificate) and a server certificate. The authority can still be used to generate many certificates, but no intermediate certificates. To see an example of a certificate chain, visit a TLS-secured web site in your browser and click the little lock that appears in the location bar.
Yes, the certificate will be used to sign other certificates. By signing a certificate, the authority is communicating "this server certificate has been issued by whoever is saying issued it", providing evidence of authenticity to the client.
Oh, by the way, the following fields in the Certificate Authority do not need to be changed from defaults, which are either blank, randomly generated, or "No" answers:
UID:
Organizational unit name:
Locality name:
State or province name:
Country name (2 chars):
Enter the subject's domain component (DC):
E-mail:
Enter the certificate's serial number in decimal (default: ...):
Is this a TLS web client certificate? (y/N):
Will the certificate be used for IPsec IKE operations? (y/N):
Is this a TLS web server certificate? (y/N):
Enter a dnsName of the subject of the certificate:
Enter a URI of the subject of the certificate:
Enter the IP address of the subject of the certificate:
Enter the e-mail of the subject of the certificate:
Will the certificate be used to sign CRLs? (y/N):
Will the certificate be used to sign code? (y/N):
Will the certificate be used to sign OCSP requests? (y/N):
Will the certificate be used for time stamping? (y/N):
Enter the URI of the CRL distribution point:
After answering all the questions, list files and you will see the x509 certificate file specified a moment ago. Congratulations. You have a certificate authority: an x509 certificate along with the RSA key behind it.
Create a server certificate request
Step five is create a request for a certificate to be used to authenticate the server when a client connects. In a terminal on the server (that is not the same terminal you were using to create the certificate authority), in the terminal and directory where your server private key generated in step three is, generate a pkcs10 certificate (signing) request: certtool --generate-request --load-privkey mydomain_server_private_rsa_key.pem --outfile mydomain_server_pkcs10_request.pem
Again the question comes, how should I fill the myriad fields presented? My suggestion is to only answer three (but please double-check your default values against mine):
Common name: mydomain
Organization name: Servers, Ltd.
Is this a TLS web server certificate? (y/N): y
Common name in this case is the domain name of your server, if you have one. It is what you would put in your address bar to visit the server.
Organizational unit name, leave this blank. Organization Name you may want to fill in.
If you don't have a domain name, you could put the IP address in the field where requested. If you have multiple domain names, you could put the first name in the "Enter a dnsName of the subject..." field, and it will prompt you for another. When finished entering names, just leave the field blank and the prompts will move on to other fields.
Why not enter a passphrase? Because all it does is add pain to an already too-painful process. Assuming this will be used for serving http, the same process needing access to the key will need access to a plaintext version of this passphrase. But do what you will.
Is this a TLS web server certificate? Yes, assuming we will be serving http with this certificate.
The following responses in the PKCS #10 certificate request can remain the defaults, but double-check that your defaults are the same as shown below:
Organizational unit name:
Locality name:
State or province name:
Country name (2 chars):
Enter the subject's domain component (DC):
UID:
Enter a dnsName of the subject of the certificate:
Enter a URI of the subject of the certificate:
Enter the IP address of the subject of the certificate:
Enter the e-mail of the subject of the certificate:
Enter a challenge password:
Does the certificate belong to an authority? (y/N):
Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)? (Y/n):
Will the certificate be used for encryption (RSA ciphersuites)? (Y/n):
Is this a TLS web client certificate? (y/N):
Now you have a PKCS #10 request in a file. It is a formal request for a certificate authority to create and sign an x509 certificate to be presented by this server to clients as evidence of who the server is. Bear in mind the certificate authority does not have to abide any requested fields, it could override them. For example, if the requestor said "yes" to "Does the certificate belong to an authority?", the signing certificate authority would override with "no" so that the issued certificate could not arbitrarily create more certificates.
Send the request
Step six is move the certificate request from the server to the certificate authority. The request need not be kept secret, it is just a request for a certificate, and contains only public information. Using your preferred delivery method, copy the request file from the server to the certificate authority. For example, on a personal computer you could pull it from the server:
And then you could use removable media to transfer the pkcs10 file to the offline certificate authority machine.
Create and sign the server certificate
Step seven is create and sign the certificate requested by the server. On the certificate authority machine, generate a certificate using the private key of the authority and the pkcs10 request of the server: certtool --generate-certificate --load-request mydomain_server_pkcs10_request.pem --load-ca-certificate mydomain_ca_x509_cert.pem --load-ca-privkey mydomain_ca_private_rsa_key.pem --outfile mydomain_server_x509_cert.pem
(At this point it should be clear why I have been putting "what it is" in the filenames.)
Again come the requests for answers by certtool. If you followed the advice above, say "yes" to "Do you want to honour the extensions from the request?", and blank or "no" to the rest of the questions. This is a little unintuitive but if you duplicate "yes"es, you may end up with duplicate fields in your certificate. Ideally, after you said "y" to the honoring extensions question, that would be the end of questions. Anyway, what follows are example answers that worked for me:
Enter the certificate's serial number in decimal (default: ...):
The certificate will expire in (days): 365
Do you want to honour the extensions from the request? (y/N): y
Does the certificate belong to an authority? (y/N):
Is this a TLS web client certificate? (y/N):
Will the certificate be used for IPsec IKE operations? (y/N):
Is this a TLS web server certificate? (y/N):
Enter a dnsName of the subject of the certificate:
Enter a URI of the subject of the certificate:
Enter the IP address of the subject of the certificate:
Enter the e-mail of the subject of the certificate:
Will the certificate be used for signing (required for TLS)? (Y/n): n
Will the certificate be used for encryption (not required for TLS)? (Y/n): n
Now you have an x.509 certificate ready for use by the server, which the server can present to the clients as evidence that it is who it says it is. If you don't like the resulting certificate, simply re-run the above command.
Create a chain file. Why? What is that? Most clients as of this writing expect the server to send not only the leaf (server) x.509 certificate, but also the x.509 certificate of the certificate authority that issued it. It is usually a simple matter of concatenating the two files together, server certificate first:
The resulting file is what is usually presented by the server to its clients.
Move the signed certificate
Step eight is move the certificate from the certificate authority to the server. The certificate need not be kept secret. In fact, the certificate is going to be presented to every client that connects to the server. It is intended to be public. For example, copy it to your personal computer via portable media, then you could use scp to push it to the server:
At this point, your server should have the x509 certificate chain next to its corresponding private key, ready to be used by a server, for example nginx. Edit your server configuration to use the certificate.
Trust the Certificate Authority
So you have a certificate authority that issued a certificate, but your browser and your friends' browsers will not be amused. In fact they will flash scary messages about it saying that the issuer is not trusted. In your browser, find in the advanced options or security options the list of trusted certificates, then find the certificate authorities trusted for web servers, and add the x.509 certificate of the ca, the file that we created in step four. Have your friends do the same.
Test the connection
Restart your server, restart your client, and test out making a connection. Most of the steps can be done over if you messed up. In general, if you redo one of the steps, you'll need to redo the rest of the steps after them. Set an alarm for however many days you made your certificates valid for, and revisit this post when that alarm goes off. Before the certificates expire, re-generate your keys, re-generate certificates, and update your servers and clients.
If you have feedback about this article please send it via electronic mail to jesse-AT-the_domain_in_your_browser_location_bar.
I still have HTML for the World Wide Web, Fourth Edition on my bookshelf. The course in which Liz's book was used helped me decide to study Computer Science instead of what I was doing at the time.
Installing Trisquel 6.0, a free operating system, instead of Dell's Ubuntu 12.04 on my XPS 13 was a problem because of the Intel wireless chip Dell put in the XPS. I should have checked before ordering from Dell. Regardless, if you also have a USB drive with Trisquel and have a Dell XPS 13 you want liberated, you might succeed like I did after completing these steps:
Use the text-based install because otherwise Dell's recovery goo seems to take over.
Two-finger-touch scrolling does work after enabling it in the touchpad settings.
Cheers.
Why I threw away three classic American board games
I just threw away three classic board games that I used to love:
Monopoly
Risk
Axis & Allies
Did it hurt a little? Couldn't I have sold them for a few bucks? What if someone else wanted to play them?
These games teach values and fallacies that I don't wish to encourage.
Monopoly: the primary economic fallacy in this game is that the way one gains is by taking from someone else.
Risk: not only does Risk portray gain as taking from someone else, but it portrays gain as utterly dominating and destroying other people.
Axis & Allies: this game not only portrays gain as taking from someone else and by destroying other people, but it also glorifies nationalism.
All three games emphasize control over other people.
The three games I'm keeping instead teach entirely different values, and I'm glad to play these instead: Settlers of Catan, Agricola, and Carcassonne. They also don't require blocking off half a day to finish one game.
What I underestimated
Here are a few things I've found to be more important than I previously thought. Some of these I may still value less than I ought to.
Spreadsheet software
More business is accomplished using spreadsheet software than I thought.
Shell or batch scripting
Software depends on this.
Managers
Managing cannot be easy.
Appearance
Most people do judge books by their covers.
Attention
Focus, listening, and minding details can prevent a lot of trouble.