HTTPS, finally

Thursday, June 28th, 2018 10:34

In further news of updating my personal web presence, I have finally set up HTTPS for switchb.org. As I write this I'm working on updating all the links to it that I control.

The thing I found underdocumented in Let's Encrypt/Certbot is: if you want to (or must) manually edit the HTTP configuration, what should the edits be? What I concluded was:

<VirtualHost *:443>
  ServerName YOUR DOMAIN NAME
  Include /etc/letsencrypt/options-ssl-apache.conf
  SSLCertificateFile /etc/letsencrypt/live/YOUR DOMAIN OR CERT NAME/cert.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/YOUR DOMAIN OR CERT NAME/privkey.pem
  SSLCertificateChainFile /etc/letsencrypt/live/YOUR DOMAIN OR CERT NAME/chain.pem

  ...rest of configuration for this virtual host...
</VirtualHost>

Notes:

  • /etc/letsencrypt/options-ssl-apache.conf (which of course may be in a different location depending on your OS and package manager) contains the basic configuration to enable SSL (SSLEngine on) and certbot-recommended cipher options.
  • You have to have a separate VirtualHost entry for *:443 and *:80; there's no way to copy the common configuration as far as I heard.
  • By "CERT NAME" I mean the name assigned to a multi-domain-name certificate if you have requested one. You can find out the certificate names with the command certbot certificates. For a single domain it will be identical to the domain name.

  1. Premise: Any attack on a password — whether online (login attempts) or offline (hash cracking) — will be designed so that the more likely a given password is, out of the space of all possible passwords, the less work is required to recover that password (unless a trivial amount of work is required to discover any possible password).

  2. From (1), there exists a probability distribution of passwords.

  3. Premise: There is a (practical) maximum length for passwords.

  4. From (3), the set of possible passwords is finite.

  5. From (2) and (4), there is a minimum probability in that distribution.

  6. Use one of the passwords which has that minimum probability.

(There are at least two ways this doesn't work.)

(no subject)

Friday, August 5th, 2011 22:29

Never need to run a text editor as root: use sudo -e.

Whoa. They even called it a powerbox as we do.

Apple has chosen to solve this problem by providing heightened permissions to a particular class of actions: those explicitly initiated by the user. Lion includes a trusted daemon process called Powerbox (pboxd) whose job is to present and control open/save dialog boxes on behalf of sandboxed applications. After the user selects a file or directory into which a file should be saved, Powerbox pokes a hole in the application sandbox that allows it to perform the specific action.

Mac OS X 10.7 Lion: the Ars Technica review

It probably ain't capabilities (no bundling of designation of the resource with authority to access it, unless they've replaced file pathnames, which I doubt), but it's a big step in a good direction. UPDATE: Ivan Krstić says “The implementation uses actual capabilities under the hood.”

A data: URL directly contains its content; for example, data:text/plain,Hello%20World!. The main usefulness of this is that you can do things like including images inline in a document. But you can also use it to create 'anonymous' HTML documents, where any link to them or bookmark contains the entire document.

I originally did this in 2006 when I was in need of a URL-encoding tool and did not have one to hand; so I wrote out:

data:text/html,<form action="data:text/plain,"><input id=r>

Properly encoded, that's:

data:text/html,%3Cform%20action=%22data:text/plain,%22%3E%3Cinput%20name=r%3E

This produces a form with a single field which, when submitted, will generate a data URL for a plain text document containing “?r=” and then the text; the URL, then, will contain the entered text URL-encoded after the “?r=”.

Of course, that's a horrible kludge and JavaScript has an encodeURI function...

See my site for the rest of that thought and more examples. (I can't include any actual data URLs in this post because LiveJournal doesn't permit them, for necessary but unfortunate reasons — the origin, in the sense of same-origin policy, of a data URL is the origin of the page containing it.)

I'm on a wireless network which apparently has a firewall which is MITMing port 993 connections (IMAP-over-SSL); my mail client reported a certificate error (the presented certificate was from “FortiGate”). Now, I trust this network's provider, but that doesn't mean I'm going to give them my personal e-mail, much less the password for it; so I went looking for a solution. It turns out that Apple Mail supports SOCKS proxies, and if you have SSH access to another system it's trivial to set up; ssh -D somelocalport somehost, then go into Network Preferences → Advanced → Proxies, and enter localhost:somelocalport as the proxy, and you're done!

It's not clear to me, though, once I set this up how much of my traffic goes over the proxy — the setting is not specific to mail or Apple Mail. This might be testable by shutting down the proxy and seeing what fails.