I have a request to setup "mutual SSL Authentication" using SFTP. They want to have a ProFTPd SFTP server authenticate the client by certificate. Is this even possible using SFTP? I assume because SFTP is key based SSH rather than cert based, it is not easily done. I suspect what they really want would be FTPS but they insist SFTP. Is anyone doing anything like this? Thanks!
As already mentioned, the question does not make sense in several points:
SFTP is file transfer protocol over SSH, which does not support any "SSL authentication" (unless you use X.509 patch, thought it might be your target)
ProFTPd might support SFTP (not natively as mentioned in comments) and certainly not with different authentication than the one supported by SSH.
You can set up openssh with sftp-server and set up CA for signing host keys and client keys (not X.509, but openssh), which might suit your needs, except it is not "SSL".
Or the other way around, use ProFTPd, use real SSL, but give up SFTP in favour of FTPS.
Both solutions are valid and reasonable, but making some mutant between them does not seem like a good future-proof solution.
Related
I'm trying to modify my Go client and server code to use TLS. In Python I can do ssl.create_default_context(purpose=ssl.Purpose.SERVER_AUTH)
which will automatically load the system's trusted CA certs and uses secure settings. I'm wondering if there's something similar in Go where it will automatically load trusted CA certificates. I'm not sure exactly what to put for the client's certificates.
I think you're looking for tls.Config. But keep in mind that Python's ssl.create_default_context exposes a lot of SSL internals that most people don't need, and you might not need a tls.Config in your application at all. For instance, net/http has a http.ListenAndServeTLS() function which starts a TLS web server with sensible defaults and whatever certificates you provide.
I'm looking to configure wcf to transport data from one web server to another web server with exactly one service host and exactly one client.
Is there a simple security configuration available that does not require x509 certificates?
Additional info:
I may be looking for a simple configuration (message is okay) that could use a predetermined username / pw / enc, etc. I'd also like to avoid sending a password in cleartext.
If by "simple security configuration" you mean encrypting the transmissions between the end points, there's no simple, easy way without using x509 certificates, short of creating some kind of elaborate VPN connection point to point.
But using certificates with WCF doesn't have to be painful or expensive. Using message-level encryption (xml based) is easy enough to configure and get running, and since the communication is always between points "A" and "B", the obvious problems associate with using message encryption (distributing the certificates) isn't a problem at all.
The steps would be:
-Generate a self-signed x509 cert with public and private keys and copy to both servers
-Configure your clients and host to use message security
-install certs on both servers (plenty of documentation available, like this one)
-Configure your host and clients to find the certificates during startup
-run and test
After you've got everything running, you'd obviously replace your self-signed cert with a commercial version.
You didn't mention your platform. Are you on Windows? If so, you can use Windows credentials with message-level encryption and no need for certificates. Here is a step by step guide on how to do it.. Hope this helps!
I don't really know much about IT and have been working in software development for 3 years. I have used version control with Github and Bitbucket, but I really don't know how SSH, SSL, HTTPS works. Can anyone explain them in the context of version control with a cloud service like Github? Why is TLS not used? A user case example would be most helpful. High-level is fine.
Firstly, while a number of people think SSH relies on SSL, it doesn't: it's an entirely different protocol. The fact OpenSSH relies on OpenSSL might be one of the causes of this confusion (whereas in fact OpenSSL can do much more than SSL).
Secondly, TLS is essentially a newer version of SSL, and HTTPS is HTTP over SSL/TLS. You can read more about this in "What's the difference between SSL, TLS, and HTTPS?" on Security.SE, for example.
One of the major differences (in the context of GitHub and Bitbucket) has to do with the authentication mechanisms. Technically, both password and public-key authentication can be used with or on top of SSL/TLS and SSH, but this is done rather differently. Existing libraries and tool support also matters.
GitHub (with Git) relies on an SSH public key for authentication (so that you don't have to store or use a password every time).
Public key authentication in SSH uses "bare keys", whereas you'd need a certificate for SSL/TLS (and in 99.9% cases that's going to be an X.509 certificate). (A certificate binds an identity to a public key by signing them together.) GitHub would have to use or set up a CA, or perhaps use various tricks to accept self-signed client certificates. All of this might be technically possible, but this would add to the learning curve (and may also be difficult to implement cleanly, especially if self-signed cert tricks were used).
At the moment, GitHub simply lets you register your SSH public key in your account and uses this for authentication. A number of developers (at least coming from the Git side) would have been familiar with SSH public keys anyway.
Historically, Git over SSH has always worked, whereas support for HTTP came later.
In contrast, Mercurial was mainly an HTTP-based protocol initially. Hence, it was more natural to use what's available on HTTPS (which would rule out using X.509 certificates if they're deemed too complicated). AFAIK, SSH access for Mercurial is also possible.
In both cases (Git and Hg), the SSH public key presented during the connection is what lets the system authenticate the user. On GitHub or Gitlab, you always connect as SSH user git, but which key you use is actually what determines the user in the system. (Same with Hg on Bitbucket: ssh://hg#bitbucket.org/....)
I doubt if it is a good question for StackOverflow, however.
All these protocols are used as (secured) channel for Git data exchange. And, when you see 'SSL' most likely SSL/TLS is meant - just to not type both abbreviations. TLS is a further development of SSL protocol.
Would like to write SSL Socket client server application on the same machine (both server and clients are running same machine). Should I use SSL certificate file (.pem file ) or not required.
Just I want encrypt the data before sending via socket.
Can we encrypt the data without .pem file?
Please advice me.
-Bala
SSL has two major steps:
check the identity of the peer, e.g. make sure you talk to the right one and not an imposter (e.g. man in the middle). This is done with certificates.
encrypt the connection, so that anybody listening on the wire cannot understand what's going on. Obviously encryption helps nothing if somebody is actively listening on the wire, because you failed in step#1. In this case you have no end-to-end encryption but an end-to-imposter and imposter-to-end encryption :)
Considering these arguments: do you still want to skip checking the certificate?
If you want it is doable, just look for anonymous authentication, e.g. ADH or aNULL with openssl.
Im working on a project that is currently using goftp found in goftp to upload some files into a website directory where it is used and viewed by the website.
I am know questioning the security of this setup, so I have looked into ssh and sftp for golang, but I'm running into problems and it's just a big headache, since I'm new with golang.
My question is, what are the security threats or problems of just using goftp and are there more secure alternatives?
Thanks in advance!
All plain FTP servers are inherently insecure as they authenticate using plain text over an unencrypted link. This means that anyone on the same network (in particular WiFi networks) can sniff the network traffic and easily extract the username and password used to authenticate.
You've already mentioned some of the recommended alternatives, SSH and SFTP. SSH provides the means to use SCP to transfer files securely. SFTP also uses the underlying transport provided by SSH. There is also FTPS which uses standard FTP over an SSL encrypted connection.
Have a look at this link for more information on the differences between the protocols.
In researching Go libraries for FTP I came across a mention that the github.com/jlaffaye/goftp library breaks on multi-line responses.
It's highly recommended to use a more secure protocol than plain FTP so you would be better served by looking at SCP/SFTP/FTPS solutions. Here's a Github Gist claiming to be an example of using SCP in Go. That could be a good starting point.