Häufig gestellte Fragen zum unsicheren ausgehenden Traffic

Der gesamte Traffic:

EINGEHEND

Der eingehende Traffic bezieht sich auf Verbindungen, die von einem Client mit unseren Servern hergestellt werden. Unverschlüsselte Verbindungen mit unseren APIs, d. h., Anforderungen mit "http:" anstelle von "https:", werden nicht mehr unterstützt.

Nachdem wir diese Änderung vorgenommen haben, schlagen Kunden- und Partneranwendungen beim Versuch, unverschlüsselte Verbindungen herzustellen, fehl. Das Fehlerverhalten ist anwendungsspezifisch.

Fehlermeldungen:

Der Fehler richtet sich nach der Anwendung, könnte jedoch als Netzwerkverbindungsfehler gemeldet werden.

Um dieses Problem zu beheben, müssen Kunden ihre Anwendungen so ändern, dass URLS mit "https" angegeben werden. Die Clients der Kunden müssen außerdem TLSv1.2 unterstützen. (Seit dem 9. April ist dies die einzige Version von SSL/TLS, die unsere Server akzeptieren.)

AUSGEHEND

Der ausgehende Traffic bezieht sich auf Verbindungen, die von unseren Servern mit vom Kunden angegebenen Servern hergestellt werden. Es gibt zwei Kategorien:

• Upload-Rückrufe für Uploads von Dokumenten (eine Beschreibung für unsere REST-API finden Sie hier, dies gilt jedoch auch für die Legacy-SOAP-API)

• Status-Rückrufe zur Benachrichtigung des Kunden über eine Änderung im Vereinbarungsstatus (eine Beschreibung für unsere REST-API finden Sie hier, dies gilt jedoch auch für die Legacy-SOAP-API)

Für beide Rückrufkategorien wird Folgendes nicht mehr unterstützt:

a. Unverschlüsselte Verbindungen (mit "http:" anstelle von "https:"-URLs)

b. Verbindungen mit Servern, die TLSv1.2 nicht unterstützen (mit anderen Worten werden TLSv1.0 und TLSv1.1 nicht mehr unterstützt)

c. Verbindungen mit Servern, die ungültige Zertifikate haben. Dazu gehören selbst signierte oder abgelaufene Zertifikate und die Fälle, in denen eine URL eine IP-Adresse anstelle eines Hostnamens verwendet.

Fehlermeldungen:

• Upload-Rückruf: Der Upload sollte einen API-Fehler zurückgeben. 

• Status-Rückrufe: 

Korrektur:

• In Sign-Anwendungen für Partner/Kunden muss für die für Rückrufe angegebenen URLs "https:" anstelle von "http:" verwendet werden. Für die URLs muss zudem anstelle einer IP-Adresse ein Hostname verwendet werden.

• Die von diesen URLs referenzierten Server müssen TLSv1.2 unterstützen und gültige Zertifikate haben.

Wir generieren Berichte, um Kunden zu identifizieren, deren bestehender eingehender oder ausgehender Traffic unsicher ist. Diese Kunden werden direkt benachrichtigt.

Kunden, die testen möchten, ob ihr Server konform ist, können mithilfe einer Reihe von kostenlosen oder kommerziellen Werkzeugen, einschließlich des Qualys SSLLabs-Servertests, sicherstellen, dass ihr Server TLSv1.2 akzeptiert und ein gültiges Zertifikat hat.

Hier finden Sie eine Tabelle, in der alle Problemfälle aufgeführt sind:

• Instanzen, die am 20. Juni blockiert werden (fett markiert)
• Instanzen, die bereits ab April blockiert sind (kursiv markiert)
• Instanzen, die im 3. Quartal dieses Jahres blockiert werden (alles andere)

Status-Rückrufe

Für Status-Rückrufe muss der Server des Kunden zusätzlich zu TLS 1.2 eine der unten aufgeführten Verschlüsselungssammlungen unterstützen:

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