Skip to main content

ADOBE CONNECT – WHAT NEXT?

As you know, the ICANN organization took down its Adobe Connect service midway through the ICANN61 meeting in response to reported issues with this service. Concurrently, we began to conduct our own forensic analysis of the reported incident and began working with our Adobe cloud service provider, CoSo Cloud LLC, and through them with Adobe to learn more. Shortly thereafter, we rolled out instances of Zoom and WebEx for the community to support remote participation (RP) and collaboration. Here's where we are now:

The Forensics Investigation

With respect to our forensics work, we received application logfiles from CoSo Cloud, going back for a period of one year. ICANN Engineering and Security teams have examined these application log files and the results of our investigation clearly show "fingerprints of incursion" by the researcher who reported the issue. We were unable to find any other indication that anyone else either identified or exploited this issue. Thanks to the person who found the bug again.

Working closely with CoSo Cloud, we were able to recreate the reported issue, and understand the conditions required to trigger it. This information has been communicated to Adobe, and Adobe is working on a software fix to address the root cause of the issue.

We have also been working with CoSo on options to re-enable Adobe Connect in the shorter term. We have determined there are two viable paths to accomplish this goal. They are:

  1. Deploy a hardened configuration to eliminate "man-in-the-middle" exploitations by encrypting relevant traffic, or
  2. Implement a programmatic fix from CoSo Cloud to substantially reduce the window during which the issue can be exploited.

With respect to the first option, we attempted to hack the hardened configuration in a test environment last week, and were not able to do so over the course of 7 hours. Separately, CoSo Cloud and Adobe conducted similar tests and confirmed that this configuration is protected from exploitation of the issue.

Community Feedback and Next Steps

For the last three weeks, we have been gathering limited feedback regarding users' experiences with WebEx and Zoom. So far, we have input from about 200 people, including ICANN org meeting organizers and the ICANN community. Our analysis of this feedback indicates a desire to revert back to an Adobe Connect, providing the security of the service is ensured.

Accordingly, we would like to propose the following plan to the broader community for consideration:

  1. We would like to restore Adobe Connect services with both the new hardened configuration and the programmatic fix discussed above. Our intent would be to restore service by 3 May. This would allow us to use Adobe Connect during several upcoming events including the Board Workshop, the GDD Industry Summit, and ICANN62.
  2. Once Adobe releases a new version of the software with a fix for this issue from their perspective, and provides assurance the update has been adequately tested, we will move toward that release of Adobe Connect in a prudent manner, with the help of CoSo Cloud.

We believe that this approach will ensure the security of our content, and of our community interactions, while also enabling our community to use the collaboration tools of their choice.

Before we make these changes, we want to hear from you. What do you think? Please submit your thoughts on this contemplated move before May 2nd here: RP-tool@icann.org

Meanwhile, we will continue to offer WebEx and Zoom for RP and collaboration purposes. We will also continue to follow industry developments, including the research ALAC is doing on the RP and collaboration space, to ensure we are using secure and cost-effective tools that are appropriate for our needs.

I look forward to your comments!

Comments

    Ken Stubbs  13:02 UTC on 20 April 2018

    Your solution looks good to me.

    Cheryl Langdon-Orr  16:36 UTC on 20 April 2018

    I appreciate this update, thank you, Ash, I also am pleased to read that efforts are being made to return the use of Adobe Connect (AC) to those of us attending meetings (especially our WG ones) in RP mode. I do use both Zoom and WebEx quite extensively in other non-ICANN circumstances, and each have good and not so good features, but I welcome some of the special features AC has to offer us especially when we lead and manage meetings and calls.

    Darran James Hubbard  20:48 UTC on 22 April 2018

    Its a great idea..peace and security of the most important things in life

    Nigel Roberts  02:54 UTC on 23 April 2018

    I, among many people, was keen to see the return of Adobe Connect. But you have to understand that this is almost certain due to familiarity, and the many hours invested in autodidactic training and many hours experience of it. It is a serious risk that we have such a dependent on a single supplier, which, as we have seen, can fail us at the time we needed it most. And I think that it's more than mildly hasty to return to Adobe before the evaluation of the others is completed, and before Adobe has confirmed the security level of the proposed changes. Notwithstanding that, if the proposed modifications fully secure Adobe, we will be pleased to see the return of it as an option. However, it is clear that ICANN *must* provide an alternative that we could choose to use in some circumstances, in order that we are not dependent on a single point of failure. I submit therefore that ICANN should continue to make one of the temporary alternatives available to SOs, ACs and WGs. And I strongly submit that the choice of that 'second-string' product has to be Zoom, which, quite clearly provides equivalent (and, in a number of circumstances, better) facilities to those offered by Adobe. (Under no circumstances would I be able to recommend WebEx.)

    Marcus Fauré  03:07 UTC on 23 April 2018

    I appreciate you are working on remote participation issues, a service which many of us rely on. However, if you are already looking into alternatives precisely because of security issues I'd like to suggest to use an alternative web conference software. Adobe has a long track record of major security flaws in their softwares, particularly Flash. As a result most major companies abandoned Flash and it became a niche product. Personally, I only use Flash on one didicated machine that does not hold any important data. I think it would be a good move to show makers of insecure products that they have to do better and encourage ICANN to send the right signal

    Dirk Krischenowski  23:01 UTC on 23 April 2018

    Let's start with this solution and then observe if everything works to our expectations.

    Winthrop YU  04:34 UTC on 25 April 2018

    I strongly agree with Marcus Fauré above -- Adobe has had, and will continue to have major security problems. Flash, in particular, is itself a major vulnerability, but Adobe insists on its installation in order to use Connect. All these put ICANN's Connect users at continuous risk, despite recent remediation. I also note Nigel Roberts' comment above, particularly the point that endorsements of continued use of Connect may be primarily attributed to familiarity. I would be more inclined towards continued use of Connect, if Adobe disconnected the platform from Flash. Else it seems that Adobe is not really serious about addressing Security and Privacy risks, and instead insists on tying a dead product to an otherwise usable platform.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."