Problems found and solved...
One of the big advantages of open source software is that a lot of people use it, and a lot of people ask for help with it, and their questions wind up getting cached somewhere public, and Google exists. So if you have a problem, chances are that if you can write the right Google query, you can find the solution.
One of the challenges in getting things to work securely is that most people aren't very security conscious. This includes most geeks. So the reason that, for example, a bunch of banks are now reissuing hundreds of thousands of debit cards is that somebody wrote a point-of-sale terminal software package that stores debit card information on the local computer system. Someone's writing software that's being trusted with peoples' debit card information - their card number and their pin, which together provide enough information to make and use a fake copy of the card. And they stash this information on disk, and never erase it. And then some time later, someone pops a USB drive into the USB port of the relevant computer, copies the files off onto the USB drive, walks away with tens or hundreds of thousands of bank accounts, and starts making cards and withdrawing cash from them.
This is every geeks' worst nightmare. In fact, the people wrote this software probably were conscious of security - they just forgot that the database engine they were using was written by people who didn't know that the people writing the point-of-sale software were going to temporarily store sensitive information in it. I'd like to say that I'll never make a mistake like this, but once when I was working in a very security-sensitive situation, I did make a mistake like this. The good news is that a co-worker noticed it before anything bad happened.
So anyway, I'm really paranoid about this sort of thing now. So today I'm working on getting an email server to talk to another email server. The second email server requires a username and password before it will accept mail from the first server. What it doesn't require is that you make any effort to keep the username and password confidential.
When you send data over the internet, it's like writing it on a postcard and sending the postcard. You wouldn't write your credit card number on a postcard and mail it - you'd put the information in an envelope, at the very least. So I've been trying to get my mail server to use an envelope. And I figured out how to configure it to do that, but it wasn't working. The metaphor breaks down here - the envelope is actually a clever algorithm that uses some fancy math to hide what's being sent; in order for it to work, both ends of the conversation have to have some pre-agreed-upon information that they use to make the math work. And my mail server couldn't find that information. So I was getting this error in my error log (I'm putting this here so if someone googles for it they'll see this message):
blah blah postfix blah: SSL3 alert write:fatal:unknown CA
CA stands for Certification Authority, which is an actual company that specializes in certifying the little bits of math in servers in a way that allows this envelope-making algorithm to work. The idea is that the CA is your friend, whom you trust. You know your friend's signature. So if your friend signs the certificate of a person you don't know, then you can trust that your friend checked this person out, and vouches for him. Very much like a letter of credit in Victorian times, only it's being done for machines.
Anyway, I spent an hour reading documentation and fiddling with parameters, and finally thought to google for the error message above. Five minutes later, I had it working. The fix? This is going to require another tortured metaphor. Imagine that your computer is a mountain. And you want to provide service on the network from your mountain. So if someone can get to the top of the mountain, they can see anything on the mountain, and if you make a mistake in how you set things up, they can modify anything on the mountain. You don't want that.
So you have a cliff on your mountain, and there's a ledge several hundred feet down, with nothing but air and cliff for another several hundred feet below it and to either side. And on that ledge you put the stuff you want people to be able to access. You can look at it and change it, because you're sitting at the top of the mountain. And you have a little agent sitting on the ledge. The agent can only see and touch what's on the ledge - you've isolate the agent from the rest of the mountain. So let's say some miscreant out on the internet figures out a way to get control of your agent, sitting there on the ledge. Well, they haven't gained much, have they? Maybe they can get the agent to chuck something over the ledge, or scribble on the cliffside where people can see it, but the agent can't get off that ledge, so anything not on the ledge is safe from the suborned agent.
That's what the mail server software I'm using, postfix, does. It just sits there on the ledge doing its thing, and if someone hacks it, they have control of the ledge. Big whoop. The trouble is, the certificates it needed to make the envelope weren't on the ledge - they were somewhere way up the mountain where it couldn't reach them. So when it tried to verify the other end of the connection, it couldn't, because it couldn't find the certificate that would validate the math that let the envelope be constructed.
The fix: make a copy of all the certificates and stash them on the ledge where postfix can get at them. By the way, this system of putting stuff on ledges is called chroot - change root. Effectively, you're saying "okay, for this guy, the top of the mountain is his ledge, and that's all he can see."
In specific terms, on ubuntu linux, I copied the contents of /etc/ssl/certs into /var/spool/postfix/etc/ssl/certs, like this:
% cd /var/spool/postfix
% (cd /; tar cfh - etc/ssl/certs) |tar xvf -
And I hacked /etc/postfix/main.cf to add the following:
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_auth_enable = yes
smtp_enforce_tls = yes
smtp_enforce_peername = yes
smtp_sasl_security_options =
#smtp_tls_loglevel = 2
smtp_tls_CApath = /etc/ssl/certs
This says "look in the hash /etc/postfix/sasl_password for the password to use to authenticate with the other mail server." And then "try to authenticate when connecting to other servers to deliver mail." And "when connecting, require that the connection be secured with SSL" (SSL is the envelope - it's what protects every transaction you make over the web with your credit card, or at least you'd better hope so). And then "make sure the guy I'm talking to has a certificate that proves he's who he claims to be." It turns out you don't need to set any sasl security options. The loglevel hack enables logging of SSL problems, which was helpful in that it led me down several entertaining blind alleys. And finally, you need the CApath to tell postfix where to look for those trusted certificates. CApath is relative to the chroot - the ledge. So the certs are really in /var/spool/postfix/etc/ssl/certs, but as far as the postfix smtp daemon is concerned, they're in /etc/ssl/certs, so everybody is happy.
Anyway, if you've made it down to here, you're probably hoping for another tortured metaphor, but I don't have one for you. Sorry.
In other news, if you want to get a Samsung t809 to sync to your Prius, you need to do two things. First, you need to get it to pair with the Prius. Then you need to go to the bluetooth security menu on your phone and make the Prius a trusted device. Then it will peer automatically every time you get into the car. Otherwise, it will only peer that first time, and then every other time the peering will fail. Funny how nobody ever actually writes down the detailed steps of this process anywhere obvious. That's the problem with getting two devices made by two different companies to talk to each other, when one of the companies has a marketing arrangement with cell phone providers other than the one you use. Not that I am bitter. Oh no.
Oh, BTW, we don't have a Prius. But Andrea's father-in-law is a very generous man, and has allowed us to use his this week.
One of the challenges in getting things to work securely is that most people aren't very security conscious. This includes most geeks. So the reason that, for example, a bunch of banks are now reissuing hundreds of thousands of debit cards is that somebody wrote a point-of-sale terminal software package that stores debit card information on the local computer system. Someone's writing software that's being trusted with peoples' debit card information - their card number and their pin, which together provide enough information to make and use a fake copy of the card. And they stash this information on disk, and never erase it. And then some time later, someone pops a USB drive into the USB port of the relevant computer, copies the files off onto the USB drive, walks away with tens or hundreds of thousands of bank accounts, and starts making cards and withdrawing cash from them.
This is every geeks' worst nightmare. In fact, the people wrote this software probably were conscious of security - they just forgot that the database engine they were using was written by people who didn't know that the people writing the point-of-sale software were going to temporarily store sensitive information in it. I'd like to say that I'll never make a mistake like this, but once when I was working in a very security-sensitive situation, I did make a mistake like this. The good news is that a co-worker noticed it before anything bad happened.
So anyway, I'm really paranoid about this sort of thing now. So today I'm working on getting an email server to talk to another email server. The second email server requires a username and password before it will accept mail from the first server. What it doesn't require is that you make any effort to keep the username and password confidential.
When you send data over the internet, it's like writing it on a postcard and sending the postcard. You wouldn't write your credit card number on a postcard and mail it - you'd put the information in an envelope, at the very least. So I've been trying to get my mail server to use an envelope. And I figured out how to configure it to do that, but it wasn't working. The metaphor breaks down here - the envelope is actually a clever algorithm that uses some fancy math to hide what's being sent; in order for it to work, both ends of the conversation have to have some pre-agreed-upon information that they use to make the math work. And my mail server couldn't find that information. So I was getting this error in my error log (I'm putting this here so if someone googles for it they'll see this message):
blah blah postfix blah: SSL3 alert write:fatal:unknown CA
CA stands for Certification Authority, which is an actual company that specializes in certifying the little bits of math in servers in a way that allows this envelope-making algorithm to work. The idea is that the CA is your friend, whom you trust. You know your friend's signature. So if your friend signs the certificate of a person you don't know, then you can trust that your friend checked this person out, and vouches for him. Very much like a letter of credit in Victorian times, only it's being done for machines.
Anyway, I spent an hour reading documentation and fiddling with parameters, and finally thought to google for the error message above. Five minutes later, I had it working. The fix? This is going to require another tortured metaphor. Imagine that your computer is a mountain. And you want to provide service on the network from your mountain. So if someone can get to the top of the mountain, they can see anything on the mountain, and if you make a mistake in how you set things up, they can modify anything on the mountain. You don't want that.
So you have a cliff on your mountain, and there's a ledge several hundred feet down, with nothing but air and cliff for another several hundred feet below it and to either side. And on that ledge you put the stuff you want people to be able to access. You can look at it and change it, because you're sitting at the top of the mountain. And you have a little agent sitting on the ledge. The agent can only see and touch what's on the ledge - you've isolate the agent from the rest of the mountain. So let's say some miscreant out on the internet figures out a way to get control of your agent, sitting there on the ledge. Well, they haven't gained much, have they? Maybe they can get the agent to chuck something over the ledge, or scribble on the cliffside where people can see it, but the agent can't get off that ledge, so anything not on the ledge is safe from the suborned agent.
That's what the mail server software I'm using, postfix, does. It just sits there on the ledge doing its thing, and if someone hacks it, they have control of the ledge. Big whoop. The trouble is, the certificates it needed to make the envelope weren't on the ledge - they were somewhere way up the mountain where it couldn't reach them. So when it tried to verify the other end of the connection, it couldn't, because it couldn't find the certificate that would validate the math that let the envelope be constructed.
The fix: make a copy of all the certificates and stash them on the ledge where postfix can get at them. By the way, this system of putting stuff on ledges is called chroot - change root. Effectively, you're saying "okay, for this guy, the top of the mountain is his ledge, and that's all he can see."
In specific terms, on ubuntu linux, I copied the contents of /etc/ssl/certs into /var/spool/postfix/etc/ssl/certs, like this:
% cd /var/spool/postfix
% (cd /; tar cfh - etc/ssl/certs) |tar xvf -
And I hacked /etc/postfix/main.cf to add the following:
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_auth_enable = yes
smtp_enforce_tls = yes
smtp_enforce_peername = yes
smtp_sasl_security_options =
#smtp_tls_loglevel = 2
smtp_tls_CApath = /etc/ssl/certs
This says "look in the hash /etc/postfix/sasl_password for the password to use to authenticate with the other mail server." And then "try to authenticate when connecting to other servers to deliver mail." And "when connecting, require that the connection be secured with SSL" (SSL is the envelope - it's what protects every transaction you make over the web with your credit card, or at least you'd better hope so). And then "make sure the guy I'm talking to has a certificate that proves he's who he claims to be." It turns out you don't need to set any sasl security options. The loglevel hack enables logging of SSL problems, which was helpful in that it led me down several entertaining blind alleys. And finally, you need the CApath to tell postfix where to look for those trusted certificates. CApath is relative to the chroot - the ledge. So the certs are really in /var/spool/postfix/etc/ssl/certs, but as far as the postfix smtp daemon is concerned, they're in /etc/ssl/certs, so everybody is happy.
Anyway, if you've made it down to here, you're probably hoping for another tortured metaphor, but I don't have one for you. Sorry.
In other news, if you want to get a Samsung t809 to sync to your Prius, you need to do two things. First, you need to get it to pair with the Prius. Then you need to go to the bluetooth security menu on your phone and make the Prius a trusted device. Then it will peer automatically every time you get into the car. Otherwise, it will only peer that first time, and then every other time the peering will fail. Funny how nobody ever actually writes down the detailed steps of this process anywhere obvious. That's the problem with getting two devices made by two different companies to talk to each other, when one of the companies has a marketing arrangement with cell phone providers other than the one you use. Not that I am bitter. Oh no.
Oh, BTW, we don't have a Prius. But Andrea's father-in-law is a very generous man, and has allowed us to use his this week.
posted by Ted Lemon at 8:47 AM
0 Comments:
Post a Comment
<< Home