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. Dialogflow unterstützt optional die gegenseitige TLS-Authentifizierung (mTLS). Während des standardmäßigen TLS-Handshakes von Dialogflow präsentiert Ihr Webhook-Server ein Zertifikat, das von Dialogflow validiert werden kann. Dazu wird entweder die Zertifizierungsstellenkette verwendet oder das Zertifikat mit einem benutzerdefinierten CA-Zertifikat verglichen. Wenn Sie mTLS auf Ihrem Webhook-Server aktivieren, kann er das Google-Zertifikat, das von Dialogflow Ihrem Webhook-Server zur Validierung präsentiert wird, authentifizieren und so das gegenseitige Vertrauen herstellen.

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.

Beispiel für einen Aufruf an einen Webhook-Server mit mTLS

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

1. Beispielkonfiguration
   1. Ein Dialogflow ES-Agent, der den Endnutzer begrüßt und einen Webhook abfragt, 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 einer öffentlich vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) signiert wurde, in einer Datei mit dem Namen fullchain.pem.
2. Führen Sie das openssl s_server Programm 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 Agent gesendet. In diesem Beispiel lautet die Anfrage „Hallo“. Diese Anfrage kann über die Dialogflow-Konsole oder über einen API-Aufruf gesendet werden.
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 aus dem Authorization-Header der Anfrage prüfen. Alternativ können Sie einen Sitzungsparameter prüfen, der zuvor von einem Authentifizierungsserver auf Ihrer Seite bereitgestellt wurde.

Fehler

Wenn die Validierung des Clientzertifikats fehlschlägt (weil der Webhook-Server dem Clientzertifikat beispielsweise 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.