More and more connections fail

[--IP--]

As of late, more and more people are unable to connect to my server. The server itself runs FileCOPA and everyone using it have converted to the FlashFXP doctrine.

Everyone uses the latest version of FlashFXP. Some get an error with some strange <implicit> tag in the log, which i don't get myself. I am not sure it's just a FlashFXP bug so i won't create a ticket just yet. However, trying to connect with a different tool, WinSCP, allows them to connect right away. We all prefer FlashFXP obviously, so we would like to have that working.

I was hoping some experienced people here would have an idea what the issue may be.
The server runs SSH2 - SFTP v5 with public key authentication.
No settings were changed on the server nor client side since it stopped working for some. I have verified their settings myself via VNC, so all should be good.

Fail Log:

[11:35:00] [R] Connecting to Server -> DNS=files.server.com IP=0.0.0.0 PORT=22
[11:35:00] [R] Connected to Server
[11:35:01] [R] Host key algorithm ssh-rsa, size 4096 bits.
[11:35:01] [R] Fingerprint (MD5): 74:ea:65:26:f0:93:e7:4b:12:e6:e5:69:4d:ef:26:7f
[11:35:01] [R] Key exchange: diffie-hellman-group-exchange-sha1. Session encryption: aes256-gcm, MAC: <implicit>, compression: none.
[11:35:02] [R] Connection failed

Success Log:

[R] Connecting to Server -> DNS=files.server.com IP=0.0.0.0 PORT=22
[R] Connected to Server
[R] Host key algorithm ssh-rsa, size 4096 bits.
[R] Fingerprint (MD5): 74:ea:65:26:f0:93:e7:4b:12:e6:e5:69:4d:ef:26:7f
[R] Key exchange: diffie-hellman-group-exchange-sha1. Session encryption: aes256-cbc, MAC: hmac-sha1, compression: none.
[R] Auth Type: Public Key
[R] Authentication succeeded
[R] SSH Connection open
[R] Connection established with FileCOPA (SFTP v5)
[R] SFTP Connection Ready
[R] Retrieving directory listing...
[R] List Complete: 876 bytes in 0,19 seconds (0,9 KB/s)

What differs seem to be the MAC: <implicit> / hmac-sha1. I'm not an expert on this yet, so I'm hoping for some bright minds :) I just find it odd when the settings are identical to mine, but the result is different.

[bigstar]

The problem is caused by the SecureBlackBox library used by FlashFXP and FileCOPA

When SecureBlackBox added support for AES-GSM encryption they added it using the RFC standard, then they added support for AES-GSM@openssh.com which is a variant of the RFC standard, at the same time they back-tracked on the original AES-GSM encryption code and changed it to use the @openssh.com variant breaking interpolation between the client and server.

The issue was quickly resolved in the next SecureBlackBox update.

The problem is that last time I checked FileCOPA was still using an older edition of the SecureBlackBox library. I attempted to contact the developer of FileCOPA to discuss this serious issue but they never responded.

You can work around the problem in FlashFXP by unchecking the aes256-gsm and aes128-gsm ciphers via the Site Manager / SFTP tab. Or if you prefer to turn it off globally you can via the Preferences dialog / SFTP Encryption. This will turn off these bugged ciphers and allow FlashFXP to use another compatible cipher.

GCM mode ciphers provide both privacy (encryption) and integrity (MAC), Since the MAC is defined by the cipher its implicit. Other ciphers only provide encryption and the MAC is calculated in a separate step.

[--IP--]

Thanks bigstar.

Sorry, I did not understand it to full last time then. I'll uncheck those as a workaround. I had simply assumed that it was a sorted issue by now and didn't think more of it. The strange thing to me is just that it's not everyone who has the issue of connecting.

I'll also try to contact the authors of FileCOPA and ask them to reply to you if you would agree to that. I've asked some features of them before and they replied every time.

If you agree, then how would you want to be contacted, directly by mail?

I'll accept if you don't want to go into this any further. But you would probably have far better luck at explaining it to them than I.

[bigstar]

You can just reference this forum thread as it explains the issue. And all they have to do is upgrade to the latest version of secureblackbox.

I own a life-time license the best investment I ever made so but they may not and that may be a factor for them.

Sent from my SAMSUNG-SM-G920A using Tapatalk

[--IP--]

Ok I have mailed back and forth with InterVations (FileCOPA).

They say that you talked back and forth and attached the mails.

Basically what they told me was that v10 of FileCOPA which isn't out yet, will have the updated SecureBlackBox. But they also said that 9.01, while using the older version, it also doesn't advertise that it supports the gcm cipher. They say it's a FlashFXP issue that FlashFXP attempts to use this cipher when it's not advertised as supported.

We did indeed reply to Charles DeWeese, twice. We looked into this problem
quite deeply. I have attached his original email to us and our two replies.

There was a problem in both software. The problem in FileCOPA was fixed
and is in the current release. As we got no reply from Charles we do not
know if he fixed the problem on his end.

V9 uses SBB V12. However, if you read the email closely, that is not the
problem.

An SFTP server advertises the ciphers that it supports. A client should
pick from one of those ciphers to use. FileCOPA does not support
AES256-GCM and it doesn't advertise the fact in the query packet, however
FlashFXP *still* chooses to use that cipher. It is wrong. It doesn't
matter what SBB FileCOPA is using, FlashFXP is attempting to use a cipher
that is not supported, it shouldn't be doing that.

So is there anything that can be improved upon?
I can forward you the whole mail correspondence if you wish.

[bigstar]

For whatever reason I never not get their reply, otherwise I would of replied.

Here's the thing about SBB, unless you explicitly disable a cipher/hmac/kex/etc its most likely allowed by default.

I installed FileCOPA on a VM to show you what I mean, Using the the default configuration with no changes

Below is the handshake info sent from the FileCOPA server to the client.

Cipher list:
3des-cbc,blowfish-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,aes256-cbc,aes192-cbc,aes128-cbc,serpent256-cbc,serpent192-cbc,serpent128-cbc,arcfour,idea-cbc,cast128-cbc,des-cbc,arcfour128,arcfour256

MAC list:
hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160,hmac-ripemd,hmac-ripemd160@openssh.com,hmac-sha256@ssh.com,hmac-sha256-96@ssh.com,umac-32@openssh.com,umac-64@openssh.com,umac-96@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,aes128-gcm,aes256-gcm

Now the FileCOPA server is indicating to the client that it supports (via the MAC) aes128-gsm and aes256-gsm, now because gsm ciphers are implicit this also means the cipher is supported too, the way this is handled could also be a bug in SBB too but I am not sure.

But based on this logic SBB comes to the conclusion that aes128-gsm and aes256-gsm are in fact supported.

[--IP--]

Thank you for elaborating. I forwarded this detail to InterVations, and they got back to me yesterday with an update to the server software. Now it works as intended. Even though the error was with their software, you helped fix it. I would like to thank you for providing valuable support. It's just awesome.

[bigstar]

You're welcome