gushi: (freebsd logo)

The problem:

  1. FreeBSD comes with Sendmail. Sendmail, in order to verify SSL certs, requires a CAPath (i.e. a bunch of split files, one cert per file), with a hash pointing at each file.

  2. The sendmail docs specifically warn against using too large a cafile, which is why you should use the path (arguably a hack, but what are you gonna do).

  3. FreeBSD's ports only contain ca_root_nss, which installs only a single, monolithic .crt file. (i.e. probably too large)

  4. I can't find a good script which will split this file apart (I mean, sure, I can write one) and generate those hashes.

  5. The tool that comes with openssl that does this is called c_rehash -- FreeBSD rips it out of their base OpenSSL install (probably because it's dependent on perl, which is no longer in base). I think the real solution here is that the port for ca_root_nss needs to just have a port-readme that gives you these commands.

The solution:

  1. Install ca-root-nss from pkg.

  2. cd into the /usr/local/share/certs directory

  3. Split up the certs into their requisite files, using the split command: split -d -p 'Certificate:' -a 3 ca-root-nss.crt foo

  4. Remove the first one: rm foo.000

  5. Use a quick for-loop to generate the hashes: for file in foo*; do ln -s "$file" "$(openssl x509 -hash -noout -in "$file")".0; done


pkg install ca-root-nss

cd /usr/local/share/certs

split -d -p 'Certificate:' -a 3 ca-root-nss.crt foo

rm foo.000

for file in foo*; do ln -s "$file" "$(openssl x509 -hash -noout -in "$file")".0; done

Testing it

I did the above, and restarted sendmail, and noticed that now, when I connect to gmail, I get:

Aug 28 22:54:20 <> prime sm-mta[76815]: STARTTLS=client,, version=TLSv1.2, verify=OK, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128 Which is great.

One thing we're still always going to hit is that SSL validation will always fail here:

Aug 28 22:54:18 <> prime sendmail[76809]: STARTTLS=client, relay=[], version=TLSv1.2, verify=FAIL, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256"

because our cert doesn't have "" or "localhost" as common names. No real fix for that, sadly.

gushi: (Default)

Hrmm, it seems that the not-maintained-since-2006 livejournal client I used to use doesn't work with Dreamwidth.

I've asked on a couple of communities what, if anything, has changed. I'm seeing this list claims that it works, but at the same time, on searching for "Dreamwidth Flat Interface" I'm seeing vague mumblings about the interface being deprecated.

Hopefully someone can help me out.

In the mean time, I'm just posting via web form, which is so blasé.

gushi: (Default)

Let's face it. Tokens are just cool to geeks.

While early on, working for a pi firm in 1999, I used Cryptocards, I was hooked.

Here was one of those little things that gave you a challenge, and you had to put into your cryptocard, get an answer back, and type out the response. A correct response couldn't be used more than once. On top of everything, the cryptocard itself had a PIN when you turned it on. It was, in a word, pretty foolproof. There's always the option of "put a gun to my head and ask for the pin", but I think the things even have a "duress pin", which bricks the device.

Cryptocards aren't user-friendly, tho. It gets annoying.

The most popular maker of this stuff on the market is a little company called RSA. They have a product that they call "SecuriD". These are still considered "two-factor" authentication (something you have, plus something you know), even though they aren't technically "challenge-response". These little dogtag-sized chips just print out a cyclic number every 60 seconds. They adapt themselves to applications by "supplanting" the password mechanism. If your password is "cookie", you would type "cookieNNNNNN" into whatever password dialog box you liked. Their server knows to chop the last six digits off, try that against its crypto algorithm, and try the rest of it against the password db.

The thing I hate in general about this kind of token is that if you get logged out, you're screwed and have to wait for the next token to come up. Even worse, if you're logging in over a slow session (think cases of extreme processor slog) it's entirely possible that by the time you're prompted for your password, or by the time the system gets around to calling the authenticator, it will have expired.

Any discussion about this stuff cannot ignore S/Key or OPIE, which stands for "Onetime Passwords in Everything". This IS totally open-source, and I use it, especially in places where I don't trust the computer or the network. But it's more complex than it needs to be. In my setup, opie can be used WITHOUT ever typing your real password, so it's not quite two-factor. It's not so much about making the auth stronger, as it is about making eavesdropping useless.

Ten years ago, this was james-bond kind-of stuff, or at the very least, large-enterprise and government-contractor grade. Now, with phishing and social engineering on the rise, and people just Not Getting Any Smarter, you can get one of these things to protect your paypal account, or even your World of Warcraft Account.

I should note that it's getting increasinly common to see this done as a cell-phone app. Either one that runs over sms, and generates a key on the fly, or an app that emulates a hardware token. In general, I'm not a fan of this because SMS is forgeable, and people never, ever, lock their cellphones. Besides, having my server require a magic tamagotchi for a login is still cooler in my brain than requiring Another Piece of Software.

I've wanted to do token-based auth of some kind with my systems for a while. The two problems with this are: A) the software is expensive and B) the tokens are expensive. About a year ago, I discovered a company called MyPW, that makes a simple third-party auth answer. There's no software to buy, and they basically "loan" you the tokens, in exchange for charging a very small fee for each auth request. The tokens (and ostensibly, the software) they use are made by a company I hadn't previously heard of, called Vasco. While the algorithm the tokens use is still not open, and it appears thus, impossible to write your own implementation, at least, at the entry cost of ten dollars, Anyone Can Do This.

I've ordered some tokens, and in my excitement, have started looking at implementation details. To quote taylor swift..."And then I wasn't excited anymore." In reading up on this, I've discovered the following:

  • Near as I can tell, not every SSH client implementation has the ability to display these kinds of challenges to users. However, there's an RFC for it, so that's cool. And apparently, that RFC does specify that multiple challenges can be presented, at least in ssh version two (which everyone should be using).

  • Looking over a few things, it seems as though I can do multiple prompts for a user, with ssh (I'll have to testbed this somewhere), but it's not clear to me how the mypw Pam Module prompts a user. However, some other systems, like Webmin, are only configured to do straight HTTP auth. And I rather like that a user cannot see any part of webmin without answering the http query. (I should also note that my webmin instances don't use system passwords, as a failsafe in case something mangles the password file).

  • I can't find a pam-wise way of doing things the "RSA Way" (i.e. with your password and your token-key mishmashed).
    Surprising, really.

  • I also can't find a way that Pam Module A can modify the user's supplied password on the stack before passing it to Module B. This may totally be possible, if coded into the module itself, I just don't see a config-wise way of doing it, and don't understand the pam api well enough.

  • I think the way openssh makes its calls to pam, there could be an issue. What happens if I am prompted for my password, and get it right, then my tokenid, but get it wrong? I believe the pam stack starts over from the top, which means I have to re-type my password. Look at this the other way around. Let's say my tokenid is first, and I type it right, but I mangle my password. I have to then wait, since the system won't accept the same id twice. Allowing the pam module to maintain a cache, and permit on subsequent auths doesn't help either, since pam has (as far as I know) no concept of ip addresses or sessions. (In other words, I don't think pam can differentiate between subsequent auths on the same session, and a completely different auth session from a different machine).

Finally, in the "readme" that mypw supplies, they say to implement your pam setup as follows:

auth       required service=system-auth
#auth       required service=system-auth
auth       required
account    required service=system-auth
password   required service=system-auth
session    required service=system-auth

I see at least a few things wrong here.

  1. The service=system-auth thing only applies to pam_stack, so it's probably a typo. It's a minor typo, but this is the documentation for how to let people securely log into your server, so I kinda expect a little polishing.

  2. To look at this, this basically appears to act ONLY on the token-based password, which is inherently LESS secure than anything else. After all, if you steal my car keys, there's my WHOLE password sitting in plain text, you just have to guess my username.

Other missing things include:

  1. A way to define from the pam.conf file where the config file lives.
  2. A list of what options the pam module supports.
  3. A manpage.
  4. A definition for how to determine what happens if the auth server can't be contacted.
  5. A neat way for users to manage their own tokens.
  6. A way to support user-tokens via home-directory file instead of one-big-system file.
  7. The one-big-system-file approach, since it's a text file, doesn't scale. It should probably get some kind of db-file support.
  8. A way to manage "drift", i.e. how far expired a token may be. (That is, for slow and laggy connections, I'd like to see the option to still make a password one-time-only, but allow its use up to five minutes past its prime).

I think I'm going to write to these guys and suggest that they try to push in a FreeBSD port, as well as bringing this blog post to them.

Thsi looks like a fairly basic project to work with C on, if I spoke it...but I'm not comfortable cutting my teeth on such a critical piece of software. I guess I'll see what they say.


Jun. 14th, 2005 01:45 pm
gushi: (Default)
Random Ideas I've been discussing with people.

1) I brought this up a while ago. Minimum wage == some percentage of the average price of a gallon of regular gasoline. The climbs in the past five years (minimum wage has gone up a dollar, gas prices have doubled) should illustrate both WHY minimum wage is ineffective. Gas prices control everything. Everything. Any industry that relies on people moving, people traveling, or any sort of inventory or product being transported. From our postage rates to the cost of heating our homes.

2) Fuck the IRS. Federal Sales Tax. Suddenly, enforcement doesn't become an issue anymore. And sure, this will drive up cost of living, but at least NOW 1/3 of your minimum wage paycheck isn't being divered to the feds for them to collect interest on until you (maybe) request it back. As a bonus, the big problem people have with "no sales tax on internet purchases" would go away. Admittedly, people who run internet businesses would immediately have to become responsible for sales tax collection, but that's part of due diligence anyway.

3) Totally random thing. When you log onto a foreign server via SSH, the server has a public key that it uses:

%ssh root@
The authenticity of host ' (' can't be established.
DSA key fingerprint is fe:9f:6a:6d:94:1b:6e:19:14:3b:8e:e9:b8:d9:c7:a4.
Are you sure you want to continue connecting (yes/no)?

The client then caches that key, says "okay, this is you" make sure future connections to that server are the "same" server, i.e. that some server isn't faking. The PROBLEM with this method is that most servers do not have an easy way of verifying that "yes, this server really does HAVE this key. I mean, sure, if someone started spoofing tomorrow, everyone who has my real key cached would get an error. However, anyone NEW who tried to connect would be non the wiser.

My thought on this: Publish the keys in DNS. The clients could then double check all that.

Hrmmm. It seems someone already had this idea. I think I'm going to try to implement this.

August 2017

678 9101112
27 28293031  


RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 26th, 2017 07:18 am
Powered by Dreamwidth Studios