Self signed SSL/TLS generator and its use???

I'm trying to setup a relatively secure FTP site and want to use SSL/TLS since I believe it is much more secure than stardard FTP. The number of users will be small and very managable, this process is running on an NAS using proftpd and allows for the importing of a secure certificate (see pic)

So, I have 2 questions.

1 - Since a self signed Certificate has a key does this mean that unless you have the "Key" the server will not allow a connection?

2 - Are there recommend applications for generating such a self signed Certificate?

Any other suggestions or recommendations?

Thanks for any help.

NG,

screenshot.167.jpg
LVL 13
nike_golfAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

nike_golfAuthor Commented:
Great link! very well thought out guide and a good read...

This leaves me with still the question about FTP, FTPES, FTPS, there are a lot of protocols... and SSL/TLS. Do I assume that the private.key file is sent to those users that I want to have access to FTP on the server and that this is used from the FTP client, is that how it's supposed to work?

I see the concept on a web page since its mostly information being sent to the client for reading, etc. so I can see why it loads automagically after prompting the end user.

Thanks.

NG,


0
Hey MSSPs! What's your total cost of ownership?

WEBINAR: Managed security service providers often deploy & manage products from a variety of solution vendors. But is this really the best approach when it comes to saving time AND money? Join us on Aug. 15th to learn how you can improve your total cost of ownership today!

Dave HoweSoftware and Hardware EngineerCommented:
no, there is a lot of difference between clientside TLS (where the client has the private key, and the server verifies the public certificate) and serverside TLS (where the server has the private key, and the client verifies the public certificate)

In both cases, it is usually advised not to use self signed Certs at all, but to create an overall CA cert (in something like http://sourceforge.net/projects/xca) and to send the CA cert to each user in advance so that they can verify your server cert properly (without getting the error)

Where clientside certs are required, it is best practice to generate those ON the client; most clients that support clientside certs also support generating certificate signing requests; they can then send you the request, and you can use your own CA to sign them and return them to the client. The standard rule with SSL is that the secret key never leaves the control of the party asserting their identity; the relying party uses only the public certificate, and verifies that based on its signature from a CA (or for self signed certs, a copy of the cert already acquired).

Note that the screen you show there is for the administration interface, I have no idea if that same cert will be used for FTPS too.
0
nike_golfAuthor Commented:
Thanks for the posts.

DaveHowe,

I hadn't thought about the key from the client side or server side, still trying to grasp all the concepts of keys and certificates.

I can see the point that if the key falls into the wrong hands it would defeat the purpose of a key, the exception is that this would potentially be a small group of individuals (hacked box) and then you would still need credentials (usernmae/password) to be able to login, am I following that correctly?

So, your also saying the client can create a key that can then be sent to the server used for reverse authentication or did I missunderstand your comment?

NG,
0
Dave HoweSoftware and Hardware EngineerCommented:
Ok, from the top then.

Normally, only servers have private keys - each private key is matched with a public key, the public key is embedded in a certificate (which has a date range and a domain name to match) and the certificate signed with ANOTHER private key, which is that of the CA. The CA's public key is in (again, another) certificate, which is self-signed - normally, working server certs are signed by a CA, and the CA certificate is in the root store of the application using the secure link (so that it can be used to verify the certificate offered by the server)

optionally, some clients can also have a private key and cert. in those cases, usually the private key is generated by the client, but the certificate is not - instead, a certificate signing request (containing the public key and desired user identifier) is sent to the owner of the server, who signs it (with his CA private key) and returns it to the client as a certificate.

However, usage of clientside keys as a user identifier is unusual, not particularly flexible (as you can't usually select which key to offer from your keystore) and more often used as a client host identifier (and supplemented with a conventional user/pass combo).  most web browsers will support client side certificates, but most secure ftp or mail clients don't.  the exception would be sftp - as sftp is essentially ssh and not SSL, certificates are not used at all, but PKI is often a substitute for the password stage of authentication, and frequently a required substitution (many ssh servers do not support any other form, so passwords can't be used)

where ftps is concerned, almost exclusively clients will do normal FTP over TLS - encrypting control and data channels using the same server-ended but client verified SSL scheme that HTTPS webservers use.  It is also a nightmare to get working properly though firewalls, but that's a different issue :)
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
nike_golfAuthor Commented:
Very enlightening DaveHowe... above and beyond wehat I was expecting.

So, if you were going to allow a few select users to perform FTP to your server how would you implement a secure transfer?

NG,



0
Dave HoweSoftware and Hardware EngineerCommented:
Pretty much how you would with normal FTP - assign a username and password for each user. Filezilla server and FreeSFTP are free packages with FTPS support.

The certificate should be checked at the client side (Filezilla client is good for that) so ideally you should use a commercial certificate if you have one (otherwise, issue your own). You should use the username and password to authenticate the user and direct them to the resources that usename and password are given access to (which can be different per user, and of course allow the usual range of read, write, create and delete rights)
0
nike_golfAuthor Commented:
I actually meant "you" personally since you appear to deal with the technology on a larger scale, I could be wrong but your opinion would be persuasive.

NG,
0
Dave HoweSoftware and Hardware EngineerCommented:
Actually, we mostly either use
a) normal ftp for stuff where security isn't an issue or
b) SFTP (using http://www.freesshd.com/ on windows)
SFTP is preferred over FTPS as it uses just a single TCP port, is supported by the same programs (filezilla, winscp) that support FTPS, and goes though firewalls easily (while port mapping a FTPS server in pasiv requires active co-operation by the ftps server, and in activ mode often the clientside firewall will bug out on it. This is because most firewalls "fix up" the ftp data channel stuff based on their view of the control channel, and with encryption, they can't SEE the control channel.

SFTP is also native to linux, where it can be run on a chroot jail. native SFTP can be a security issue though, as it is in fact a full shell account on SSH, and most sites frown a bit on giving those out :)
0
nike_golfAuthor Commented:
SFTP requires an SSH connection correct, not sure if the NAS supports that? It seems SSH is only for administrators on the device...

Thanks,
0
Dave HoweSoftware and Hardware EngineerCommented:
sftp is a special case of ssh, yes. but you did ask me what *I* used, and that's it. That said though, many NAS solutions do support sftp, you would need to check the feature set on the one you use.  The fact you have proftpd (pretty much a standard linux daemon) implies its linux based though, which also means you could use sftp on "unprivileged" accounts (but if you wanted security, you would probably want to run a sftp-specific listener on 22 such as http://mysecureshell.sourceforge.net/ and shift admin ssh to another port)
0
nike_golfAuthor Commented:
Many thanks for your input and insight, Happy Holidays!

NG,
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
SSL / HTTPS

From novice to tech pro — start learning today.