Gegenseitige TLS-Authentifizierung

Der von Dialogflow für Webhook-Anfragen initiierte Netzwerkverkehr wird über ein öffentliches Netzwerk gesendet. Dialogflow unterstützt optional die gegenseitige TLS-Authentifizierung (mTLS), um sicherzustellen, dass der Traffic in beide Richtungen sicher und vertrauenswürdig ist. Während des standardmäßigen TLS-Handshakes von Dialogflow stellt Ihr Webhook-Server ein Zertifikat bereit, das von Dialogflow validiert werden kann. entweder der Zertifizierungsstellenkette folgen oder durch Vergleichen des Zertifikats mit einem benutzerdefinierten CA-Zertifikat. Wenn Sie mTLS auf Ihrem Webhook-Server aktivieren, kann das von Dialogflow bereitgestellte Google-Zertifikat an Ihren Webhook-Server gesendet, um die Validierung vertrauenswürdig sind.

mTLS anfordern

So fordern Sie mTLS an:

1. Sie konfigurieren Ihren Webhook-HTTPS-Server so, dass er während des TLS-Handshakes das Clientzertifikat anfordert.
2. Der Webhook-Server sollte das Clientzertifikat beim Empfang bestätigen.
3. Sie installieren für den Webhook-Server eine Zertifikatskette, die sowohl vom Client als auch vom Server als vertrauenswürdig eingestuft werden kann. Anwendungen, die eine Verbindung zu Google-Diensten herstellen, sollten allen von Google Trust Services aufgeführten Zertifizierungsstellen vertrauen. Sie können Root-Zertifikate von https://pki.goog/ herunterladen.

Beispielaufruf an einen Webhook-Server mit mTLS

In diesem Beispiel wird der in der Kurzanleitung gezeigte Agent mit einem Webhook-Server verwendet, auf dem openssl ausgeführt wird.

1. Beispieleinrichtung
   1. Ein Dialogflow ES-Agent, der den Endnutzer begrüßt und einen Webhook, der auf einen eigenständigen Webserver verweist.
   2. Ein privater Schlüssel für die TLS-Kommunikation in einer Datei mit dem Namen key.pem.
   3. Eine Zertifikatskette, die von einem öffentlich vertrauenswürdig Zertifizierungsstelle in einer Datei mit dem Namen fullchain.pem.
2. Führen Sie das Programm openssl s_server auf dem Server aus.

   sudo openssl s_server -key key.pem -cert fullchain.pem -accept 443 -verify 1

3. Eine Anfrage wird von einem Clientcomputer an den Agenten gesendet. In diesem Beispiel lautet die Anfrage: „Hallo“. Diese Anfrage kann über die Dialogflow-Konsole gesendet werden. und zwar durch einen API-Aufruf.
4. Ausgabe von openssl s_server auf dem Server

   verify depth is 1
   Using default temp DH parameters
   ACCEPT
   depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
   verify return:1
   depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1D4
   verify return:1
   depth=0 CN = *.dialogflow.com
   verify return:1
   -----BEGIN SSL SESSION PARAMETERS-----
   MII...
   -----END SSL SESSION PARAMETERS-----
   Client certificate
   -----BEGIN CERTIFICATE-----
   MII...
   -----END CERTIFICATE-----
   subject=CN = *.dialogflow.com
   
   issuer=C = US, O = Google Trust Services LLC, CN = GTS CA 1D4
   
   Shared ciphers:TLS_AES_128_GCM_SHA256:...
   Signature Algorithms: ECDSA+SHA256:...
   Shared Signature Algorithms: ECDSA+SHA256:...
   Peer signing digest: SHA256
   Peer signature type: RSA-PSS
   Supported Elliptic Groups: 0x6A6A:...
   Shared Elliptic groups: X25519:...
   CIPHER is TLS_AES_128_GCM_SHA256
   Secure Renegotiation IS NOT supported
   POST /dialogflowFulfillment HTTP/1.1
   authorization: Bearer ey...
   content-type: application/json
   Host: www.example.com
   Content-Length: 1011
   Connection: keep-alive
   Accept: */*
   User-Agent: Google-Dialogflow
   Accept-Encoding: gzip, deflate, br
   
   {
     "responseId": "96c0029a-149d-4f5d-b225-0b0bb0f0c8d9-afbcf665",
     "queryResult": {
       "queryText": "Hi",
       "action": "input.welcome",
       "parameters": {
       },
       "allRequiredParamsPresent": true,
       "outputContexts": [{
         "name": "projects/PROJECT-ID/agent/sessions/58ab33f3-b57a-aae9-fb23-8306242d4871/contexts/__system_counters__",
         "parameters": {
           "no-input": 0.0,
           "no-match": 0.0
         }
       }],
       "intent": {
         "name": "projects/PROJECT-ID/agent/intents/399277d6-2ed7-4329-840d-8baa0f60480e",
         "displayName": "Default Welcome Intent"
       },
       "intentDetectionConfidence": 1.0,
       "languageCode": "en",
       "sentimentAnalysisResult": {
         "queryTextSentiment": {
           "score": 0.2,
           "magnitude": 0.2
         }
       }
     },
     "originalDetectIntentRequest": {
       "source": "DIALOGFLOW_CONSOLE",
       "payload": {
       }
     },
     "session": "projects/PROJECT-ID/agent/sessions/58ab33f3-b57a-aae9-fb23-8306242d4871"
   }ERROR
   shutting down SSL
   CONNECTION CLOSED
         

Best Practice

Damit die Webhook-Anfragen von Ihren eigenen Dialogflow-Agents initiiert werden, sollten Sie das Bearer-Dienstidentitätstoken im Autorisierungsheader der Anfrage prüfen. Alternativ können Sie eine Sitzung bestätigen -Parameter, der zuvor von einem Authentifizierungsserver auf Ihrer Seite bereitgestellt wurde.

Fehler

Wenn die Clientzertifikatsvalidierung fehlschlägt (z. B. weil der Webhook-Server das Clientzertifikat nicht vertraut), schlägt der TLS-Handshake fehl und die Sitzung wird beendet.

Häufige Fehlermeldungen:

Fehlermeldung	Erklärung
Failed to verify client's certificate: x509: certificate signed by unknown authority	Dialogflow sendet das Clientzertifikat an den externen Webhook, der es jedoch nicht bestätigen kann. Das kann daran liegen, dass der externe Webhook die CA-Kette nicht korrekt installiert hat. Alle Stamm-CAs von Google sollten vertrauenswürdig sein.