1. Home
  2. Software security & privacy
  3. Important changes to external integrations with Engaging Networks

Important changes to external integrations with Engaging Networks

Does this change apply to me?

This article only applies to you if you are using an integration for your Engaging Networks data that uses an external service that isn’t provided by Engaging Networks.

The changes we are making will not affect Payment Gateways, our Salesforce connector, or browser-based data exports and imports.

Who should read this?

Share this with your IT team, network engineers or integration partner if you are using any of our APIs to pull or sync data to your database or elsewhere.

Introduction

We will be deprecating all weak ciphers used by TLS 1.2. These weak ciphers might be used by your organisation to move data between Engaging Networks and other systems. As part of our ongoing commitment to maintain the highest security standards and to comply with the Payment Card Industry Data Security Standard (PCI-DSS) we will be making this change on August 31, 2023. (Note that even though this compliance refers to Payment Cards, the weak ciphers might be used in your integrations to sync other kinds of data).

If you are an Engaging Networks client using any of our APIs to pull data or sync data to your database or elsewhere, then you need to ensure that your IT team or network engineers read and understand this document. 

The deadline to carry out the necessary changes is August 31, 2023. After then, we will begin deprecating the weak ciphers. If you do not make these changes, then your integrations may no longer work after that date.

Transport Layer Security is a cryptographic protocol that secures the connection between a web server and a web application using data encryption. TLS selects from available ciphers to encrypt the data.

Ciphers, also known as encryption algorithms, encrypt and decrypt data between systems. It is a way of securely moving data, for example when syncing Engaging Networks data with another database.

As ciphers are cracked by hackers, they no longer provide the necessary security to protect your data, leaving you vulnerable to data loss. We are deprecating several ciphers from use on our servers to further protect your data.

While most servers and applications which use TLS will select from a commonly available cipher, some applications may be hard-coded to use a specific cipher which is no longer considered secure. For this reason, you must be surethat your applications which access your Engaging Networks data do not use any ciphers which are being deprecated.

If your applications are using deprecated ciphers, your integrations will fail and you will not be able to retrieve data with your applications.

What about TLS 1.3?

You may have heard that we are no longer supporting TLS 1.2 and moving to TLS 1.3. Due to client and partner feedback, we are not making this change and are instead deprecating some individual ciphers that have been identified as weak.

Do I need to make any changes?

Components where Engaging Networks calls other systems internally, like Salesforce Connectors, or jobs that push data to client systems via SCP (i.e. our automated export to an FTP server), or payment gateways will remain unaffected by this change.

Integrations that are fully supported

The following integrations are fully supported so no changes need to be made in these cases:

  • All Payment gateways for your Engaging Networks pages
  • All other Engaging Networks pages and functions like emails
  • Automated exports to an FTP server via SCP
  • Salesforce sync V2 (the native integration within the Engaging Networks platform)
  • Salesforce sync V1 (the legacy connector)
  • All Extensions listed under Account Settings > Extensions (Twilio, Okta, Zoom, Double the Donation, Regulations.gov, Facebook, Revolution Online CRM)
  • Exports and imports used via a browser, such as the Bulk export/import webforms or the Query Builder
  • ImportOmatic Raiser’s Edge Connector for Engaging Networks – Omatic Software
  • Frakture – data integration
  • Care2 Petition posting
  • Engaging Connections for Microsoft Dynamics – NDP Studio
  • Data Co-op – MissionWired
  • Velocity for Blackbaud CRM – Zuri Group
  • DataLink for Blackbaud CRM from Brightvine Solutions
  • Portfolio from Amergent
  • Super Importer Exporter (SIE) from JMG Solutions

Integrations that are not yet confirmed to be supported

If you have other integrations, check with your provider to see if they must make changes to the integrations which they manage on your behalf. These include integrations to databases of record and other tools, including:

  • GiftEase
  • Actually Data integrations
  • Other bespoke integrations not listed here

If you have integrations in place not listed as fully supported, that (a) move data between Engaging Networks and your Database of Record or (b) post data into an Engaging Networks form from another source, then you should pass this information on to the agencies or teams that developed them.

Can I test whether I need to make any changes?

Yes, you can test your connection to determine if changes are needed by using the EN test environment test.politicalnetworks.com

If you run the following cURL command and get back an OK response from the server/integration you use to connect to Engaging Networks, it will let you know if you need to make any further changes.

				
					$ curl -X GET 'https://test.politicalnetworks.com/page/health'
$ OK
				
			

If you run the same command as -v (verbose), it also displays what cipher the connection is using. This will tell you if you are using a weak cipher. The line below in yellow indicates the cipher being used for the connection (ECDHE-ECDSA-AES128-GCM-SHA256)

				
					$ curl -v -X GET 'https://test.politicalnetworks.com/page/health'
*   Trying 172.67.206.35:443...
* Connected to test.politicalnetworks.com (172.67.206.35) port 443 (#0)
* ALPN: offers h2,http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
*  CApath: none
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* ALPN: server accepted h2
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=Cloudflare, Inc.; CN=politicalnetworks.com
*  start date: Jul 22 00:00:00 2023 GMT
*  expire date: Jul 20 23:59:59 2024 GMT
*  subjectAltName: host "test.politicalnetworks.com" matched cert's "*.politicalnetworks.com"
*  issuer: C=US; O=Cloudflare, Inc.; CN=Cloudflare Inc ECC CA-3
*  SSL certificate verify ok.
* using HTTP/2
* h2h3 [:method: GET]
* h2h3 [:path: /page/health]
* h2h3 [:scheme: https]
* h2h3 [:authority: test.politicalnetworks.com]
* h2h3 [user-agent: curl/8.0.1]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x168ae40)
> GET /page/health HTTP/2
> Host: test.politicalnetworks.com
> user-agent: curl/8.0.1
> accept: */*
>
< HTTP/2 200
* Connection #0 to host test.politicalnetworks.com left intact
$ OK
				
			

Below is a connection test to the ENS (rest) API to validate a token. If this comes back with a valid json response, then your connection is good

				
					$ curl -X GET 'https://test.politicalnetworks.com/ens/service/authenticate/f472b605-bae1-4e26-ad5b-829c91735f63'
{"valid":false,"ens-auth-token":"f472b605-bae1-4e26-ad5b-829c91735f63"}
				
			

I think I need to make some changes. What do I need to do?

We are unable to provide any further assistance with updating your systems to only use strong ciphers. Every system and software component is different, e.g. operating system, server, software, language that was used, etc.

Eliminating the use of weak ciphers is a best practice that anyone running technology systems and software should be doing on a regular basis. If you are unsure what to do, anyone with a technical background should understand what it means, so please pass this information on to your IT team, network engineers or integration partner.

What ciphers will be deprecated?

The following ciphers will be deprecated after August 31, 2023

				
					
TLS 1.2 Weak Ciphers
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)
				
			

The following are acceptable:

				
					TLS_AES_128_GCM_SHA256 (0x1301) ECDH x25519
TLS_AES_256_GCM_SHA384 (0x1302) ECDH x25519
TLS_CHACHA20_POLY1305_SHA256 (0x1303) ECDH x25519
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH x25519
OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13) ECDH x25519
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) ECDH x25519
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH x25519

				
			
Updated on August 23, 2023

Was this article helpful?

Need More Help?
Can't find the answer you're looking for?
Contact Support