Enabling TLS v1.3 results in "no shared cipher" error (AmiSSL 4.3) about amissl

[ksdhans]

Not sure if it's related, but using an elliptic curve server certificate also gives me the "no shared cipher" error. Only RSA certificates work. I can generate the elliptic curve certificate, but can't use it.

[Futaura]

I couldn't really tell what you were ultimately trying to accomplish, from your comments, but somebody pointed me to your thread on os4coding.net. So, you're using AmiSSL in your ZitaFTP server software. Did you ever get this working? I'm thinking you perhaps missed a call to set up the ciphers (IIRC, it needs to be done differently for TLSv1.3). And I'm not so sure the OpenSSL s_server command is a good test.

[ksdhans]

Yes, I'm using AmiSSL in ZitaFTP Server. No, I didn't get it working. Instead I downgraded to TLS 1.2.

The same code works with Cygwin on Windows, so it's not a coding error on my part. Likewise, the s_server test works just fine with Cygwin.

[Futaura]

Ok. Could you let me know the commands that you are using to create test.key and test.crt? I'll then rerun your test here with AmiSSL 4.3 and my current dev build which uses OpenSSL 1.1.1d (4.3 uses 1.1.1a). Could be something that was fixed In OpenSSL - if not, I'll find out what's going wrong.

I only had a quick look, but would I be right in saying that the current ZitaFTP on os4depot is statically linked against OpenSSL 1.1.1c?

[ksdhans]

Sure, the following generates a key using an elliptic curve cipher:
openssl ecparam -name secp521r1 -genkey -param_enc named_curve -out key.pem
openssl req -new -x509 -key key.pem -out cert.pem -days 730 -subj "/CN=localhost"

NOTE: You may need to add -config to the last line, with an AmiSSL config file because the default installation doesn't come with a config file.

I only had a quick look, but would I be right in saying that the current ZitaFTP on os4depot is statically linked against OpenSSL 1.1.1c?

Yes and no. The actual FTP server uses AmiSSL, but the licensing code relies on libcurl and therefore statically links in OpenSSL (it's a third-party lib that I adapted).

I'm hoping to build an OpenSSL => AmiSSL stub lib at some point so that I can remove the redundant OpenSSL. I haven't figured out how to generate that yet...

[Futaura]

Ok - quick update. I am seeing the problem here too - works ok on Windows, but not in AmiSSL - both are using OpenSSL 1.1.1d, and same cert/key/config files. I've traced the problem and am working on a solution.

[Futaura]

@ksdhans Took a while to pinpoint the cause, but ultimately it has led to the discovery a baserel related bug in GCC 4.0.4 on OS4. Fortunately, it can be easily worked around, but I've got to check if it gets triggered anywhere else in the OpenSSL code. FYI, your test case works on OS3.

Also, it is bugging me that trying to Ctrl-C s_server triggers a busy loop somewhere, so hope to fix that too. Do you know if there is some other way to tell s_server to exit?

[ksdhans]

Good to hear that you've found the root cause.

I don't know any other method than Ctrl+C to exist s_server.

[Futaura]

I'm hoping to build an OpenSSL => AmiSSL stub lib at some point so that I can remove the redundant OpenSSL. I haven't figured out how to generate that yet...

@ksdhans Is that related to #31? I'd like to move discussion on this to that ticket if it is, as I'm going to close this one soon.

[ksdhans]

@ksdhans Is that related to #31? I'd like to move discussion on this to that ticket if it is, as I'm going to close this one soon.

True, they are related, but still slightly different. The solution I'm suggesting there wouldn't help in this case because inline stubs are only of use at compile time. An already compiled library such as libcurl would need stubs in another static library.

Let's move the discussion to that ticket.