I'm using AmiSSL v4.3 with code and SSL certificates that work fine under Cygwin (with OpenSSL 1.1.1b). With AmiSSL, connections fail with:
TLS-error:SSL routines:tls_early_post_process_client_hello:no shared cipher
This happens with both RSA and EC certificates, and it's infuriating. No tweaks of the settings work. In fact, I get the same failure even if I use openssl's built-in s_server:
openssl s_server -key test.key -cert test.crt -verify 0 -accept 443 -WWW verify depth is 0
That also results in the same failure when a browser tries to connect.
So, has anyone had any success using AmiSSL v4.3 with their code? If so, what's the secret to getting it to work?
Hans
Okay, the connection does work successfully with Odyssey, but it's using out-of-date TLSv1. It fails with any browser/client that disables old protocol versions (including the openssl command's own built-in client).
So, for some reason TLS v1.2 or higher and related ciphers seem inaccessible, even when I explicitly enable them. Why?
Hans
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work
It looks like TLSv1.3 is broken. If I limit the max protocol to v1.2 and stick to RSA certificates, then it works. With an EC certificate or TLSv1.3, it fails. AmiSSL gives no indication that TLSv1.3 isn't available; it just fails.
Sigh. Why can't this stuff just work?
Suggestions on how to get TLSv1.3 working would be welcome.
Hans
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work
I probabaly will say obvious things, but try to not use amiga native libraries as much as possible if there is normal usuall originals present which can be compiled easy, which will be bugfixed right in next day when you report bug, and which ones mantainet all the time, and not in just some spare time.
In case with amigssl, just use original openssl and link with it your project statically , and you will have no problems ever. If anything will have needs to be changed, to recompile binary from your own side with new version of openssl, will be much faster than rely on when someone if/when/ever will update/change amissl.
In our current realms i always say that AmiSSL make no sense. Its just openssl with some additional work to have it as shared amiga library, and as bonus years for bug fixing or updating :) By using original openssl code everything will just works as should, and if not, reporting a bug, will mean waiting not months or years, but just day or few days maximum.
@kas1e
I knew you'd say that, and yes, I am considering going for the openssl static lib or *.so.
Using AmiSSL is actually quite simple, especially if you use its auto-init stub, which takes care of the loading procedure for you. The need to use raw bsdsocket.library sockets directly is avoided by using the BIO sub-library for handling network traffic, and that's a requirement for non-blocking I/O anyway.
There are a few reasons why I'd prefer to use AmiSSL, provided that they can keep it properly maintained:
- SSL/TLS is a moving target with new security flaws being discovered all the time that render protocols and ciphers obsolete. This means that a program with OpenSSL statically linked will need to be periodically rebuilt with newer OpenSSL versions, or it'll stop being able to communicate with the rest of the world sooner or later. Using a shared library means that only the library needs to be updated to remain current
- AFAIK, we have a problem with *.so shared objects and ABI compatibility between compilers. So using the *.so version to deal with the point above could potentially be problematic
- AmigaOS shared libraries are truly shared between applications, which makes better use of memory
EDIT: Added to the above, the current libopenssl on os4depot is way out of date and, unlike you, I'm not good at porting stuff from the *nix world. Especially anything that uses CMake, autoconf, etc. Writing original software is enough work without having to also port and maintain dependencies too.
Hans
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work
@Hans
I ask MickJT to update to the latest version on os4depot, so he probabaly will do it in next 2-3 days. Last one are from 28 may 2019 , 1.1.1c , so probabaly will cover all your needs .
@kas1e
Thanks.
Hans
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work
Are you writing a client or server ( I have the feeling from your description that you are writing a server but not 100% sure!)
Client wise I have AWeb working. And AOrganiser via the pythonssl module I "wrote" based on AmiSSL. Also have 68k client working. They all "just work" so I can't easily give advice, except that kas1es advice should be 'ignored' and you should submit a bug report or ask a question in a more visible forum or perhaps email 'futura' (Oliver Roberts) or Jens Maus directly. I've found Oliver in particular very helpful on AmiSSL related matters.
AmiSSL 4 is actively updated so it's good period to submit reports (unlike the amissl 3 era which was not so good).
It's a server.
Maybe it "just works" with clients, or maybe it's only working because most servers still have TLS 1.2 enabled and use RSA certificates. You may want to see if you can find a server using an Eliptic Curve (EC) certificate to test it with. Or maybe a server that only uses TLS 1.3, and has everything else disabled. That'll tell you if EC certificates are actually working, or if you're just lucky that most servers haven't migrated to EC certificates yet.
Really? I've submitted multiple bug reports that are just sitting there. Yes, that includes the problem that this ticket is about.
I only got a response to one bug report, and that was a "why don't you fix it yourself and send me a pull request" type response. Not helpful.
Hans
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work