Advanced Accounting has supported encrypted e-mail since February of 2014 (background details). In the ever-changing world we live in, nothing stays the same. Transport Layer Security (TLS) protocols are widely used over a wide spectrum of web communication services ranging from e-mail to web browsing to file transfer protocols (FTP) and more. Web sites with the https prefixes use these protocols, sometimes referred to as "secure" http (and similarly secure FTP for file transfer). Web socket calls used in securely communicating with web servers also utilize these transport layers. TLS is the more modern version of what was called SSL (Secure Socket Layer) which had the same goal of providing cryptographic protocols for securely connecting across computer networks. When sending e-mail, most Simple Mail Transfer Protocol (SMTP) providers now require secure communications using TLS.
TLS first came out in 1999 as an upgrade to SSL. TLS 1.0 continued to be the standard for a very long time. TLS 1.1 came out in 2006 with then 1.2 (2008) and 1.3 (2018). Mail and browser providers however have continued to support TLS 1.0 (until recently).
In October of 2018, Microsoft announced that it would be ending TLS 1.0 and 1.1. support in some of their browsers. This was planned for the first half of 2020 but has since been delayed, in part. Meanwhile other providers have started to end their support of TLS 1.0 and 1.1.
In August of this year, we had a custom project that was making secure HTTP socket calls in connection with which users suddenly started to receive messages that we traced to HTTP 1.1 426 upgrade required. The components used in part to make the secure connections were the same tools we use in other projects requiring secure communications, yet this was the first report of any issue and the custom application had previously worked continuously without issues.
At first, the web server provider of the application we were communicating with indicated that they had not made any changes. Based on some posts we had seen related to the plug-in components we use to make the secure calls, however, we realized that this was happening probably due to their dropping TLS 1.0 (which they later admitted was the case). While our program settings indicated that if one layer protocol failed then proceed to try the next available layer, it turns out that the third party component was failing after a refusal of TLS 1.0 to connect, and then would simply stop trying. The solution was to change the internal handler's SSL options to start with TLS 1.1 and then continue trying from there, which did solve the problem.
Other providers have since also started to drop at least TLS version 1.0. We realized this could happen when sending e-mail within standard Advanced Accounting, so we updated our encrypted e-mail "send" program with a change similar to that made in the custom project that brought out this issue in August. That update was made available in September and included in Adv 8 rel. 4 (see our prior blog where we also described this issue). E-mail can suddenly stop working for a variety of reasons typically related to issues such as required changes to passwords, or the requirement that the sender e-mail address match the authentication logon ID which is now typically the case, and these changes are often made by providers without any advance warning. This is also the case if a mail provider suddenly drops TLS 1.0 support: encrypted e-mail will then stop working.
While we've had almost no additional reports of this issue from our users so far, and while they don't manifest themselves always in the same way in terms of an error response, earlier this month we had an Advanced Accounting 7i user suddenly experience a problem sending e-mail and it turned out to be, in part, this issue. While Advanced Accounting 7i isn't being formally updated, we were able to solve the issue for this user using the newer components that are used with Advanced Accounting 8.
