Forum Replies Created
-
Posts
-
Hello. Guyo. We have moved, please see our new community page.
https://support.cerberusftp.com/hc/en-us/community/topics You can also contact the Cerberus support team @
https://cerberusllc.zendesk.com/agent/dashboard Thanks.
I’m not an expert on cryptology but from what I understand this is how things work. When a connection is made by a client, Cerberus responds with the protocol versions it supports. If the client can match one of the acceptable protocol versions, the connection continues. The server also provides its public host key (RSA), which the client can use to check whether this was the intended host.
The status you see on the summary (RSA 2048) is the generated from the server’s SSL certificate and private key.
It’s used to prove the server’s identity.
2048 is the standard right now when creating your CSR for your SSL certificate you could double it to 4096.
https://www.cerberusftp.com/wp-content/uploads/2016/07/help-08.png It is true that a longer key provides better security, the increase in bits of security is pretty small.
Going with a larger key also translates to increased CPU usage and higher power consumption.
After the host key is trusted, both parties negotiate a session key using a version of something called the Diffie-Hellman algorithm. This algorithm (and its variants) make it possible for each party to combine their own private data with public data from the other system to arrive at an identical secret session key.
The session key will be used to encrypt the entire session. The public and private key pairs used for this part of the procedure are completely separate from the SSH keys used to authenticate a client to the server.
Cerberus FTP allows the administrator to specify the algorithms that should be chosen during the handshake via the advanced security settings in the Server Manager.
Therefore, it is possible to require the Cerberus FTP Server to use either 128-bit or 256-bit encryption as the default. By default, Cerberus FTP Server is configured to require a minimum 128-bit encryption as the default.
128-bit encryption is one of the most secure encryption methods used in modern encryption algorithms and technologies. Furthermore, 128-bit encryption is considered to be logically unbreakable and it is also the minimum required encryption level for HIPAA compliance.
256-bit encryption, on the other hand, is considerably stronger than 128-bit and delivers an even higher level of protection. Therefore, you should consider using 256-bit encryption if you are looking for the highest available encryption strength to keep your data safe. Furthermore, as technology continues to progress, it is expected that the industry standard will likely shift to 256-bit encryption for secure sockets layer protection.
Sorry for the delayed reply. If security is truly a concern, I would recommend upgrading Cerberus.
That alone will make sure that you are protected against any security vulnerabilities in older releases.
Quote:How can I prove them what is the connection strength?
It’s posted on the summary page from your screenshot you support at minimum 128-bitQuote:How can I show what kind of alorithm is used for the key exchange
Your Cerberus log will display that information and you also configure the settings under Security>AdvancedExample:
CONNECT [ 28757] – SSH SFTP connection request accepted from XX.XXX.17.122
INFO [ 28757] – Client Identification: SSH-2.0-phpseclib_0.2 (mcrypt, bcmath)
CONNECT [ 28757] – Algorithm negotiation complete: Proceeding with key exchangeCONNECT [ 28757] – Kex: ‘diffie-hellman-group1-sha1’ Host Key: ‘ssh-rsa’ C2S : ‘aes128-cbc, hmac-sha1-96, none’ S2C : ‘aes128-cbc, hmac-sha1-96, none’
ssh-rsa is just the host key type
C2S is client to Server, client -> server its supported ciphers and HMAC; S2C is server to client, it’s the info from Server.
Diffie-Helman is the key exchange protocol. The other 3, in order, are cipher, HMAC, and compression.
Quote:If I were to purchase a certificate from a CA, what kind should I look for?
You will just a want a single domain certificate, they are pretty much the same wherever you get it from.Managing Active Directory (AD) and LDAP users work very differently and aren’t easily done at this time using the SOAP API. AD and LDAP users are authenticated directly against their respective AD and LDAP server using the default configuration specified on the AD Users and LDAP Users pages. They don’t exist as user accounts in Cerberus.
You can customize individual AD and LDAP users by mapping them in the Cerberus UI to a Cerberus group. That would override the default AD or LDAP configuration and apply the settings and virtual directories from that mapped Cerberus group to the AD user.
We don’t have a SOAP API call to manage these mappings at this time. There are only the GetAuthenticationList and SetAuthenticationList calls that retrieve an XML block of those sources and mappings. Our application can easily manipulate that data, but it would have to be parsed and manipulated at the XML level by an API user.
We have plans to add individual APIs to manage mapping AD and LDAP users to Cerberus groups through the API, but those calls aren’t in place yet.
I wish I had a better answer for you. It’s certainly possible using the XML set and retrieval methods, but not at all ideal.
Hi You may want to access the WSDL and XSD directly on disk and not use the URL.
It’s in this folder:
C:Program FilesCerberus LLCCerberus FTP Serverwebadminadminwsdl
You can always copy that to your local development machine and process it that way.
The above link has some pretty good information about PowerShell and Cerberus
9.0.7.1 has been released. Fixed: The contents of folders with an ampersand in the name are always empty in the HTTP/S web client
Hi. We are working out some things but geolocation blocking should be included in our next major release 10.0.0
We plan on having version 10 ready before the end of the year.
Update: This has been fixed, the fixed is included in the upcoming 9.0.6 release. 9.0.6 is scheduled for release in the next few days, if not sooner.
