A partire dal 20 giugno 2018, verrà interrotto il supporto per diverse categorie di traffico di rete non sicuro per Adobe Sign. Tale modifica è necessaria per conformità ai requisiti PCI.

Domande frequenti

Che tipo di traffico di rete è interessato dalle nuove regole di crittografia?

Tutto il traffico:

IN ENTRATA

Traffico in entrata fa riferimento alle connessioni effettuate da un client ai nostri server. Verrà interrotto il supporto di connessioni non crittografate alle nostre API, ossia alle richieste che utilizzano “http:” anziché “https:”.

Una volta implementata tale modifica, le applicazioni di clienti e partner non potranno stabilire connessioni non crittografate. Verranno generati errori specifici per l’applicazione.

Messaggi di errore:

L’errore sarà specifico per l’applicazione, ma potrebbe segnalare un errore di connessione di rete.

Per correggere questo errore, i clienti devono modificare le loro applicazioni in modo da specificare URL di tipo “https:”. Inoltre i loro client devono supportare TLS v1.2. Dal 9 aprile, questa è infatti la sola versione di SSL/TLS accettata dai nostri server.

 

IN USCITA

Traffico in uscita fa riferimento alle connessioni effettuate dai nostri server ai server specificati dal cliente. Sono disponibili due categorie:

• Callback di caricamento per il caricamento di documenti (descritto qui per le nostre API REST, ma applicabile anche alle precedenti API SOAP)

• Callback di stato per informare il cliente di un cambiamento nello stato del documento (descritto qui per le nostre API REST, ma applicabile anche alle precedenti API SOAP)

 

Per entrambe le categorie di callback, non verranno più supportate:

a. Le connessioni non crittografate (che utilizzano URL con “http:” anziché “https:”)

b. Le connessioni ai server che non supportano TLS v1.2 (quindi TLS v1.0 e TLS v1.1 non saranno più supportati)

c. Le connessioni a server con certificati non validi. Questo comprende i certificati autofirmati o scaduti, nonché i casi in cui un URL utilizza un indirizzo IP anziché un nome host.

Messaggi di errore:

• Callback di caricamento: il caricamento dovrebbe restituire un errore API. 

• Callback di stato: 

Per correggere tali errori:

• Nelle applicazioni Sign dei partner o clienti, gli URL specificati per i callback devono utilizzare “https:” anziché “http:”.  Inoltre gli url devono utilizzare un nome host anziché un indirizzo IP.

• I server a cui fanno riferimento tali URL devono supportare TLS v1.2 e disporre di certificati validi.


Come si può sapere se la connessione ad Adobe Sign è sicura?

Stiamo generando dei rapporti per individuare i clienti attualmente con traffico in entrata o in uscita non sicuro. Tali clienti verranno notificati direttamente.

I clienti che desiderano verificare se il loro server è compatibile possono utilizzare diversi strumenti gratuiti o a pagamento, incluso Qualys SSLLabs Server Test, per verificare se il loro server accetta TLS v1.2 e se dispone di un certificato valido.


Adobe ha pubblicato un elenco dei metodi supportati?

La tabella seguente riporta tutti i casi in cui si verifica questo problema:

  • Casi che verranno bloccati a partire dal 20 giugno (in grassetto)
  • Casi già bloccati a partire da aprile (in corsivo)
  • Casi che verranno bloccati nel 3° trimestre (Q3) di quest’anno (tutti gli altri)

Categoria

Tipo di richiesta

Non crittografata

TLS 1.0

TLS 1.1

Certificato non valido

Richieste API in entrata

Tutte le richieste

Bloccato il 20 giugno

Bloccato in aprile 2018

Bloccato in aprile 2018

N/A

Richieste API in uscita

Callback per caricamento documenti

Bloccato il 20 giugno

Verrà bloccato in Q3 2018

Verrà bloccato in Q3 2018

Verrà bloccato in Q3 2018

Callback di stato

Bloccato il 20 giugno

Bloccato il 20 giugno

Bloccato il 20 giugno

Bloccato il 20 giugno


C’è altro da sapere sulle modifiche relative agli standard di crittografia?

Callback di stato

Per i callback di stato, oltre a supportare TLS 1.2 il server del cliente deve supportare una delle seguenti suite di crittografia:

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_RSA_WITH_AES_128_CBC_SHA256

TLS_RSA_WITH_AES_128_GCM_SHA256

TLS_RSA_WITH_AES_256_CBC_SHA256

TLS_RSA_WITH_AES_256_GCM_SHA384

Questo prodotto è concesso in licenza in base alla licenza di Attribuzione-Non commerciale-Condividi allo stesso modo 3.0 Unported di Creative Commons.  I post su Twitter™ e Facebook non sono coperti dai termini di Creative Commons.

Note legali   |   Informativa sulla privacy online