New nPOPuk Release + OpenSSL / CE Testers Needed!

I tried auto and 1.2. I still wonder if it was user error on my part with settings.

That is a problem of nPOPuk. When STARTTLS option is used, nPOPuk tries to connect to a server over TLS1.0, which office365 doesn't support. Please replace nPOPuk.exe with this special build which uses TLS1.2 for STARTTLS.
https://www.dropbox.com/sh/tn8ektm7rftu07j/AACUvIoX6h0hQGOx6m_ObMdna...

Yesss!! Send and receive works with this version you just posted. Thank you!!!

Edited by torch 2023-01-02 2:17 AM

> gjcoram
Here is the configure line I used for OpenSSL.
perl Configure no-idea no-mdc2 no-rc5 no-ssl3 no-weak-ssl-ciphers no-async no-engine VC-CE

Okay got another report, recieving mail works fine on v015. Sending, like others have posted:

Initialization of SSL failed.
error:0A0C0103:SSL routines: internal error.

Likely a memory address but thought I'd just post the whole messagebox.
In the log:

STARTTLS
220 2.0.0 SMTP server ready
SSL connect...
SSL method requested TLS 1.0
Send error
Initialisation of SSL failed
error:0A0C0103:SSL routines::internal error

Edit: Didn't notice the build to remedy this, yes that one works fine now. Problem solved.

Edited by DutchComputerKid 2023-01-02 11:35 AM

Thanks for reporting. Then it's perfect for ARMv4.

On the Sylvania netbook. I don't have a wifi card for the 820 (I used to use dial-up), so I have no way to test actual send/receive on the 820.

Thanks.

What do people think: should I disable ssl2 and ssl3 support because they're insecure/deprecated? Or is there a chance that someone is using nPOPuk to talk to an old server.
If I disable those options, what should nPOPuk do if it loads an ini file with one of them selected?
a) silently switch to TLS-1.2
b) pop a dialog box to confirm (or exit)?
c) ?

I see where nPOPuk is selecting TLS1.0 (ssl_type=1) for STARTTLS. Did you just change that to use TLS1.2 always? How would a user choose TLS1.0 or 1.1 if their server needed it, or TLS1.3 if they wanted to use that?

EDIT: I found this page
https://mailtrap.io/blog/starttls-ssl-tls/
which says STARTTLS should be more of an option to use (or not) with any of the SSL or TLS versions.

Edited by gjcoram 2023-01-02 1:19 PM

SSL 1.0, 2.0, 3.0 and TLS 1.0 and 1.1 are all deprecated and should not be used - it would be better to rename the module npoptls or npopencryption over npopssl.
No one is going to get a non-SHA2 public key certificate now, so the only people who plausibly could still be using SSL/older versions of TLS are using privately issued public keys

Generally speaking crypto negotiates the highest supported protocol, so start on TLS 1.3 then back-off to 1.2, 1.1 etc. My initial thought would be to try 1.3 and 1.2 then to ask the user if they want to try "insecure cryptographic providers" i.e. 1.1 and 1.0.
If you encounter a disabled option in an ini, I would retry the protocol stack from 1.3 downwards and then fail to the user. Having said that, for the time being. I would be inclined to leave the code in there but pop up a notification of intended deprecation to the user if SSLx or TLS 1.0/1.1 are actually selected/used. Then see how many people complain to you about it over the next release or two - having your forums working would be useful there. You could do a user poll too. There aren't going to be that many mail servers out there which do not have a functional path to TLS support/SHA2 support.

Yes, I changed there to always use TLS1.2 (ssl_type = 5) instead of TLS1.0 because TLS1.2 is widely used and regarded secure enough today. However I think it would be better if nPOPuk itself figures out the highest avaliable TLS version and use it. In this way users are not required to select TLS version.

SSL_CTX_set_min_proto_version() sets minimum supported TLS version : https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_min_proto_ver...

I don't know the logic that went into the original setup, but there is an "auto" option which selects the highest version supported on both ends. It's just that the ssl setup dialog also provides other options, and a user may have selected one of the deprecated options at some point. This option is saved in the ini file. I was thinking that nPOPuk should look at this setting when it loads the ini file and fix it then (not when it tries to make a connection).
Perhaps I'm being too cautious: most likely, no one really wants the old/insecure protocols, and maybe they have forgotten that they chose the old one at some point in the past. In which case, automatically upgrading them is the right thing to do.

The thing is that if the client is forcing SSL3 and the server is looking for TLS 1.2, the connection will not work - it is why they usually cascade during negotiation. There won't be any public key issuances with valid SSL any more and I imagine the same is true for SHA1 based TLS at this point. So if someone is still using SSL3, then it's because the server won't talk TLS and needs some attention over its configuration.

If you force change the SSL to TLS and they want to keep SSL, your idea presumably will force TLS every single time the ini is parsed and break their ability to connect.

The only advantage of having the ability to manually select the encryption mechanism is to fuse the negotiation loop so that it doesn't have to go TLS 1.3, 1.2, 1.1, 1.0, SSL3 in sequence.

If I disable SSLv2 and v3, then anyone who needed those would have to use an older version of nPOPuk. And, if they had selected this in the ini file, then the new nPOPuk would need to do something about the fact that the user requested something that it can't do. If it automatically switches to TLS1.2, and saves the new setting to the ini file, then if the user went back to an older version of nPOPuk (esp. one that doesn't support TLS1.2!) then they would be upset that the setting had been changed.
I like your suggestion of a pop-up of "intended deprecation". nPOPuk does have a Version setting in the ini file, so I can do the notification once on the first run, but then if they leave the setting, it won't complain again.

Edited by gjcoram 2023-01-02 5:48 PM

It may not necessarily be a bad thing though to deprecate SSL with a view to remove it. It will make the app more robust. However I'd give your user community a change to feedback about it over a few releases.