[nSLUG] Chebucto Security
draker at gmail.com
Thu Jan 22 00:59:15 AST 2009
2009/1/21 Jason Kenney <jdkenney at gmail.com>:
> In the third case, I was referring to using any (Chebucto or
> otherwise) PPP (or high speed - anything directly connected to the
> Internet through IP networking of some kind, NAT'd or not) connection
> to access the shell on Chebucto (via telnet or ssh).
OK, I understand.
> Note: There are still levels of trust involved in the first case I
> believe - you do inspect the certificate offered when visiting an
> https site, right? And would be able to distinguish between one that
> has been faked/forged? Without being capable of that, you are
> trusting that the end point really is the end point you believe it is.
No, I don't examine site certificates unless my browser flags them as
having a problem, and even then I probably wouldn't be able to tell a
forged one myself. But... I believe this is not necessary, is it?
What I really should check is that the latest download of firefox has
only got certificate authorities listed that I approve of. Do I really
trust "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı"? I've no
idea. The list seems to get longer every day. And yet in the days
when it seemed to be a Verisign monopoly I wasn't happy either.
But assuming I trust the listed certificate authorities, my
understanding is that their job is simply to guarantee to me that the
site certificate being presented is genuinely associated with the
domain listed in my URL nav bar. They guarantee that the endpoints
are who they think each other are.
So if I see 'www.royalbank.com' on some printed documentation given to
me by RBC, I can type that into my browser, then see the switch to
https before I type my username and password, and feel comfortable
that some big company (heh) has certified that this site really does
belong to the owners of 'royalbank.com', who printed the piece of
paper I picked up in their brick & mortar edifice.
Furthermore, I can see that I spent $27.34 at my local food store this
afternoon, using my bank card. Or withdrew money from an ATM. This
confirms me for me that I really am talking to my financial
After that, all I care about is the second part of 'a secure
connection', which is that the traffic is unreadable by others and
unmolested during its transit.
Any misdirection by manipulating certificates, certificate
authorities, DNS, or malicious network administration can never
convince my browser to accept an SSL certificate as valid if it
doesn't match what is required by one of my trusted certificate
authorities. There are only three ways to get around this:
1) subvert an entire existing certificate authority
2) subvert the web browser, either before download (e.g. on the
firefox servers) or by manipulating the browser installed on the
computer in front of me to insert a rogue certificate authority
3) convince me, the user, to click 'accept' regardless of the browser's warning
Note: I've been talking a lot about "accepting certificates that are
presented" as though it's like showing a backstage pass, or some ID.
It's actually more complicated then that. Essentially, the remote
endpoint does not show the secret -- that would be giving the game
away! Instead the remote endpoint shows that it can perform some
action that proves that they are in possession of the secret without
actually revealing the secret to me. This is done in some
cryptographic way that I have no clue about, but I believe that it
works :) I just wanted to say that to forestall someone correcting
me, or someone else saying: why can't a baddie just copy the presented
certificate and then play games with DNS?
ssh uses the same principle. The key difference (hehe, pun there) is
that with ssh there is no central key authority. This is why the
first time you connect to a new server with ssh, it asks if you want
to accept the key as belonging to this host. If you don't recognize
the key, you should say no. Does anybody ever say no?
By the way, this raises a problem I have which I wonder if anyone can
help me with.
I have a single IP, behind which I use NAT to house multiple systems.
I can port-forward ssh from the external IP to the main system, then
connect from an remote location no problem. Now I port-forward a
different port from the external IP to the ssh service on a second
system. Connecting to this alternate port from remote causes a key
warning, because I've "connected" to the same IP address as far as the
client knows, only on a different port.
Is there any way to tell ssh to store separate host keys for the same
IP address but on different ports? I'm suspect the answer is no...
Other ideas would be to copy the same host keys to all the NATted
systems, so they all appeared to be the same system; that's not an
ideal solution. The other "not a solution" is to allow ssh only to
one system, then 'hop' from it to the rest. But I'm prepared for the
eventuality that there is not much choice in this situation.
Alright, I've figured out how to do it. Just like me. Take the time
to ask the question and in so doing, figure it out.
The solution is to store the different keys in separate user host key
database files using the UserKnownHostsFile config file option.
I put into my ~/.ssh/config file something like:
Now when I type 'ssh mainsystem', ssh does the equivalent of:
ssh mainuser at 126.96.36.199
I accept the host key, and it is stored in my default ~/.ssh/known_hosts file.
When I type 'ssh secondsystem', ssh does:
ssh -p 2201 -o UserKnownHostsFile=~/.ssh/known_hosts_secondary
seconduser at 188.8.131.52
for me. I accept the key and it is stored in my special known_hosts
file that is used only for this particular host.
Yay, it works. Congratulations if you read this far...
More information about the nSLUG