View Full Version : Self-certifying SSL or SSH?
I'm writing a front-end client that will connect to MySQL over the web. We need it to be secure, and MySQL supports SSL. However, reading the various documentations on self-certifying SSL (no point in getting a CA involved as this is for internal use anyhow), I can't help but think this seems insecure as the documentations says we need to save the key in plaintext in order to avoid prompting users for a password everytime they connect.
Furthermore, it seems that they will get a dialog warning that certificate is not valid, or so forth.
Can anybody elaborate on whether we can store the key securely enough without requiring an authenication from the users and see no dialogs at all (as the users will have already authenicated when opening the front-end client) when connecting? Also, I don't see anything that indicates whether I can require the client authenicate themselves?
Or should I use SSH instead (which I believe I can do totally transparently, and if I understand the documentation, without any keys exchanging at all)?
TIA for advices.
Use an SSH tunnel. SSL is horribly confusing (http://mpt.net.nz/archive/2006/02/20/certificates) and doesn't reliably achieve its intended effect. SSH delivers.
Okay, I suspected that was the case, and the last thing I need to do is annoy my users with dialogs they wouldn't have read or understood anyway.
This brings me to the next question- If a server is going to host multiple SSH connections from users, can I make it so each user is assigned its own 'workspace' (speaking generally) mainly for logging and audit trailing purposes. Perhaps by giving each user a unique localhost IP (e.g. 127.0.0.2 for user A, 127.0.0.3 for user B)? The idea is that both server and client should be authenticated while creating the connection so I need to be able to uniquely identify the user...?
Gargoyle
2007-11-15, 14:49
when you say you are writing a front end client, do you mean some kind of web app (ie, in a browser) or a desktop app that connects over tcp/ip?
Sorry- the latter (desktop client using TCP/IP protocol). AFAICT, this is the best way to go for a WAN-connection as we have remote offices/remote connections on the road.
This brings me to the next question- If a server is going to host multiple SSH connections from users, can I make it so each user is assigned its own 'workspace' (speaking generally) mainly for logging and audit trailing purposes.
Sure.
Perhaps by giving each user a unique localhost IP (e.g. 127.0.0.2 for user A, 127.0.0.3 for user B)?
You could do that with virtual interfaces, but it probably won't be necessary. Just make one Unix account per user on the machine hosting the MySQL server, and give all of them permission to access the MySQL server.
Then again, if you're doing it all through MySQL anyway, even that won't be needed: just give multiple MySQL accounts rights to the same database. You can then audit which MySQL user made which changes.
I should have made it clear that the reason I asked the questions about virtual interfaces was because I wanted to know whether I would want to 'whitelist' the connections that can be accepted, and if I'm not mistaken, that's a job for SSH client/server, rather than the MySQL server.
I will need to do more research before I know for sure if whitelisting makes more sense, though.
Right, but even so, you can probably do so on a Unix account level, such as using the DenyUsers and DenyGroups settings in sshd.
Ah, yes, forgot about that one; will definitely take a closer look at the SSH protocol.
Danke! :)
SSL is a good idea, requiring SSL certificates is NOT.
I believe it goes back to the idea that only online businesses would need to be verified since why would anyone else want a secure connection? You want to know you are giving your credit card information number to a legitimate business.
However, there are so many reasons that you should use a secure connection without being verified. In fact, there are probably quite a few good reasons to NOT use SSL. However, because of SSL certs, it makes it nearly impossible to use without the hassle of dealing with certs as chucker pointed out.
At least with SSL and web browsers, there should really be a way to get a secured connection without an SSL cert. Gosh, just give me a different header I can send or something if I want a SSL, but maybe not that little lock to show up that people have come to look for on e-commerce sites. Make a new icon, or no icon at all, just give me the ability!
I've lost at least a year from my life stewing over the situation web browsers are in today in terms of securely transmitting data.
I don't think there is such a thing as SSL without certificates. Its design relies fully on them.
The SSH public/private key variant is far easier to use, easier to understand, and works permanently (there's no need for the keys to expire). However, SSH is unfeasible for websites, at least when it comes to regular tunneling. Perhaps we'll one day have a transparent solution to tunneling.
I don't think there is such a thing as SSL without certificates. Its design relies fully on them.
The SSH public/private key variant is far easier to use, easier to understand, and works permanently (there's no need for the keys to expire). However, SSH is unfeasible for websites, at least when it comes to regular tunneling. Perhaps we'll one day have a transparent solution to tunneling.
My beef is SSL with websites. You are right there is no such thing as SSL without certificates, but what I mean is it should be perfectly fine to have self-signed certificates without warnings if you just want encryption. Allow me that, even if you don't show the little 'lock' icon most browsers show when you are on a SSL connection with a verified cert. But it seems like a BAD idea to require people to pay money to just encrypt data being transferred over the internet with an open protocol.
My beef is SSL with websites. You are right there is no such thing as SSL without certificates, but what I mean is it should be perfectly fine to have self-signed certificates without warnings if you just want encryption. Allow me that, even if you don't show the little 'lock' icon most browsers show when you are on a SSL connection with a verified cert. But it seems like a BAD idea to require people to pay money to just encrypt data being transferred over the internet with an open protocol.
I fully agree.
*bump*
I'd like to get a clarifiaction about public key-
I initially thought that if one wanted extra security, they could not exchange the keys across internet but rather get together face-to-face vis-a-vis so-called 'certificate party' for people who use PGP. However, reading the information, it seems that not making public key public does nothing to improve the security because the public key has no value in decryption. Am I misunderstanding something basic here?
It is my understanding that while SSH is reasonably secure once encrypted, it is most vulnerable when the keys are being exchanged because it is possible that keys may be intercepted midway and spoofed, and I wanted to close that, if such thing can be accomplished.
TIA.
The private keys must never be exchanged (and never are). The public keys have to get exchanged for the authentication to work.
Right, but my confusion is about why people who uses PGP, which I belives uses public-key cryptography needs to meet face-to-face to exchange the public key. Wasn't that supposed to protect from a man-in-middle attack where neither client or server knows each other (e.g. the very first time a connection is ever added, and the host key isn't on the known_host file?)
If I understand what you are asking banana, then yes you are correct. I don't know much about what you are talking about, but from what you said, knowing the public keys prior to starting to communicate would seem to save off a MIMA. Since the MIM never has a chance to give you deceitful keys, they would just be relaying encrypted information. At least I think, I'm sure chucker will clear this up.
Right. The pair of public keys assures both sides that they always correspond to the same host. So, if you exchange them in person, you know the host is the one it pretends to be.
(I hadn't responded because I didn't quite understand Banana's post without ast3r3x's response.)
Great. Now here's the $10,000 question. ;)
Can sshd be configured so it only accept connections from those that has the public file on the list? I couldn't find anything appropriate to that effect, except for this:
HostbasedAuthentication
Specifies whether rhosts or /etc/hosts.equiv authentication together with successful public key client host authentication is allowed (hostbased authentication). This option is similar to RhostsRSAAuthentication and applies to protocol version 2 only. The default is ``no''.
But that makes my head hurts.
Chucker, Sorry for earlier garfunkling.
Can sshd be configured so it only accept connections from those that has the public file on the list?
By default, the SSH client will do this:
1) if it hasn't connected to a particular machine before, it tells you its public key and asks if you consider it correct.
2) if it has connected to the machine before and the key is the same, it connects.
3) if it has connected to the machine before, but the key has changed, it refuses to connect and exits.
You can change this behavior, and you can manually edit the known-hosts file to fix 3) (when you know for sure that the key was supposed to have changed), but in general, I find this to be the most reasonable.
Right.
I'm trying to figure out whether it is possible for users to only need to carry the key to allow them to connect to the server from other machines other than their usual machine *and* refuse connections from anyone else that do not have the credential.
Maybe that isn't viable in the end, but I wanted to know all of my options before I move any further. :)
Ah, I see what you mean. No, I couldn't find such a possibility upon quick glance.
Just for references, this may be a possible solution (http://calypso.tux.org/pipermail/novalug/2007-May/005219.html).
Will have to try that.
Gargoyle
2007-11-26, 17:39
If you are installing the client program on the machines, then you can just install your self signed certificate as trusted... no more popups, etc...
Really? My earlier google search showed that even if I set the certification as trusted, they will still show up a warning dialog when I want complete transparency as users will already has authenicated themselves prior to connecting.
Maybe you could point me to a site that show how this can be accomplished?
One more thing...
Does anyone knows the scope of key? I ask because I wonder if it's possible to re-create the key when opening a connection and deleting it after it's been opened, or should it be only deleted after the connection has been closed?
vBulletin® v3.6.4, Copyright ©2000-2024, Jelsoft Enterprises Ltd.