What TLS version does Amiga support?

I just received this message from Comcast/Xfinity:
Quote:

I'm currently unable to send (SMTP server) messages via Simplemail.I have all of the settings in Simplemail set just as Comcast lists the requirements.

Is it because our TLS (SSL?) is too old?

Paul

@Paul

Are you using the latest version of SimpleMail? IIRC, older versions used OpenSSL. That changed in v0.44, when the AmigaOS 4.x version started using AmiSSL v4.

The statically compiled version may become too old, and stop working. AmiSSL is getting updated, but AmiSSL 5.4 & 5.5 currently have some problems.

You can get older versions of AmiSSL here.

Hans

Maybe there is a need to compile SimpleMail again with the newer 5.x versions of AmiSSL, because I am not sure that is possible to use it automatically.

@walkero

That's for certain, but as SimpleMail 0.45 was compiled to use AmiSSL v4, that should be fine too as AmiSSL 4.12 supports TLS 1.3. Just need to make sure AmiSSL 4.12 is installed, obviously, before installing AmiSSL v5.

@all: thanks you for your responses. Now I know it shouldn't be an issue for my email usage. I found an input error (my fault) in the configuration file for simplemail. I've now been able to send messages again.

@Hans: I have v.0.45 of Simplemail here. Lookiing on Sourceforge, I was surprised to see how old this is!
Thanks for your other links here also. Now I know why Zita stopped working for me. I was rummaging through my router settings trying to open ports to get it working again. Now I'll just wait for a new AmiSSL.

Paul

No need to wait: https://amissl.org/download/5.6

@Futaura

Thank you for all the hard work and solving this nasty bug!!

@Futaura

Wow! That was fast. Thank you. Zita is working again.

Paul

@Futaura

Hi,
I was trying to get IBrowse 2.58 to work with Browservice
via TlSv 1.3
The navigation tab opens successfully, but then you don't see the "Browservice" toolbar
https://github.com/ttalvitie/browservice

My copy of AmigaOS (4.1FE) is regularly purchased and registered.
As well as all updates such as IBrowse 2.58 and SSL 5.6 are directly updated with my account.
All datatypes are also up to date.

I made a short video a few minutes, to understand if I'm wrong or IBrowse 2.58 does not support "Browservice"

Do you have any suggestions, is there any modification I could do?
or it is not compatible and therefore it is useless to try ?

Thank you.

Here the little video to explain myself better:

https://youtu.be/dG8JpbyewgM

@white

My guess is that iBrowse is just not compatible.

@Skateman
Yes, I believe too
I see now that you have used "Browservice"
If I had known, I would have used it sooner

I did not know him.

Let's see what "@Futaura" can possibly answer

And if it's easy to fix.

So IBrowse could be exploited better, at least from my point of view.

I report here the .log of "Browservice"
maybe it's useful for the purpose.

Thank you.

INFO @ C:\build\src\src\server.cpp:50 -- Got request for new window from vice plugin
INFO @ C:\build\src\src\window.cpp:531 -- Creating window 1
INFO @ retrojsvice.dll C:\build\src\viceplugins\retrojsvice\src\window_manager.cpp:328 -- Creating window 1
INFO @ C:\build\src\src\window.cpp:168 -- CEF browser for window 1 created
[1217/184948.821:WARNING:spdy_session.cc(3502)] Received HEADERS for invalid stream 5
INFO @ C:\build\src\src\bookmarks.cpp:190 -- Bookmarks successfully read from 'C:\Users\lowlevel\AppData\Roaming\Browservice\bookmarks'
[1217/184949.108:INFO:CONSOLE(1)] "The Cross-Origin-Opener-Policy header has been ignored, because the URL's origin was untrustworthy. It was defined either in the final response or a redirect. Please deliver the response using the HTTPS protocol. You can also use the 'localhost' origin instead. See https://www.w3.org/TR/powerful-feature ... tially-trustworthy-origin and https://html.spec.whatwg.org/#the-cros ... ener-policy-header.", source: https://www.google.it/?gws_rd=ssl (1)
[1217/184949.109:INFO:CONSOLE(1)] "The Cross-Origin-Opener-Policy header has been ignored, because the URL's origin was untrustworthy. It was defined either in the final response or a redirect. Please deliver the response using the HTTPS protocol. You can also use the 'localhost' origin instead. See https://www.w3.org/TR/powerful-feature ... tially-trustworthy-origin and https://html.spec.whatwg.org/#the-cros ... ener-policy-header.", source: https://www.google.it/?gws_rd=ssl (1)
INFO @ retrojsvice.dll C:\build\src\viceplugins\retrojsvice\src\window.cpp:480 -- Closing window 1 due to inactivity timeout
INFO @ C:\build\src\src\window.cpp:575 -- Closing window 1
INFO @ C:\build\src\src\window.cpp:210 -- Cleanup of CEF browser for window 1 complete

I tried setting IBrowse as:
192.168.1.83:8080/goto/https://www.google.it/?gws_rd=ssl

OR

192.168.1.83:8080/goto/http://www.google.it/?gws_rd=ssl

but it doesn't seem to work, maybe I need to see better what kind of request to forward to Google

although I think it won't work anyway.

@white

Not going to work, I'm afraid. It appears to rely unnecessarily heavily on JavaScript, failing even at the first hurdle. If you check the source code in IBrowse it attempts to redirect the page by setting window.onload, which IBrowse doesn't yet support. It could be done using meta refresh instead, or by setting the onload attribute in <body> (which was the "classic" way of using onload).

That said, even with that working in IBrowse, I fear it may then display the site, but nothing much else would work due to the heavy JavaScript usage required (for example, to read user input).

So, for now, not much that can be done. Perhaps there are other solutions out there. Privoxy is the only one that I remember from days gone by.

@Futaura

Thanks for the reply,
you have been very kind.

So I won't do any more testing.
I had suspected that "java" had something to do with it.