"Überprüfung des Serverzertifikats OK", aber "ALPN, Server hat einem Protokoll nicht zugestimmt"

Ich mache einen Curl-Anruf

curl -v ... https://... 

und die ausführliche Ausgabe enthält

....
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
*    server certificate verification OK
....
* ALPN, server did not agree to a protocol
* Server auth using Basic with user 'api'
> POST /v3/pindertek.com/messages HTTP/1.1
> Host: api.mailgun.net
> Authorization: Basic sdfsdfsdfsadfsdfsdfsadfsadfsadfsdfsdfasdfsdf=
....
< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
......

Meine Fragen sind:

• Werden die Berechtigungsdaten verschlüsselt gesendet?
• Wird der Inhalt nach der Autorisierung verschlüsselt gesendet?

Ich kann sehen, dass die Überprüfung des TLS-Zertifikats erfolgreich war. Die Meldungen "ALPN, Server hat einem Protokoll nicht zugestimmt" und "Serverauthentifizierung mit Basic mit Benutzer 'api'" wecken jedoch kein volles Vertrauen.

Ich hoffe, es bezieht sich nur auf ein separates Schichtprotokoll, das unter / innerhalb / über dem TLS-Verschlüsselungsprotokoll verwendet wird, aber ich weiß es nicht.

Detailliertere ausführliche Ausgabe:

* Connected to api.mailgun.net (34.215.83.50) port 443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 1060 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
*    server certificate verification OK
*    server certificate status verification SKIPPED
*    common name: *.mailgun.net (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: C=US,ST=California,L=San Francisco,O=MAILGUN TECHNOLOGIES\, INC,OU=MAILGUN TECHNOLOGIES\, INC,CN=*.mailgun.net
*    start date: Thu, 18 Jan 2018 00:00:00 GMT
*    expire date: Wed, 18 Mar 2020 12:00:00 GMT
*    issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=Thawte TLS RSA CA G1
*    compression: NULL
* ALPN, server did not agree to a protocol
* Server auth using Basic with user 'api'
> POST /v3/pindertek.com/messages HTTP/1.1
> Host: api.mailgun.net
> Authorization: Basic sdfsdfsdfsadfsdfsdfsadfsadfsadfsdfsdfasdfsdf=
> User-Agent: curl/7.47.0
> Accept: */*
> Content-Length: 464
> Expect: 100-continue
> Content-Type: multipart/form-data; boundary=------------------------df265bf86c971664
> 
< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
......

TLS ist die Sicherheit der Transportschicht. Im obigen Fall ist das gelungen, kein Problem.

Aus Wikipedia :

Application-Layer Protocol Negotiation (ALPN) ist eine TLS-Erweiterung (Transport Layer Security) für die Protokollverhandlung auf Anwendungsebene. Mit ALPN kann die Anwendungsschicht aushandeln, welches Protokoll über eine sichere Verbindung ausgeführt werden soll, so dass zusätzliche Roundtrips vermieden werden und welches von den Protokollen der Anwendungsschicht unabhängig ist. Es wird von sicheren HTTP / 2-Verbindungen benötigt, was die Komprimierung von Webseiten verbessert und deren Latenz im Vergleich zu HTTP / 1.x verringert.

Da APLN eine ist Erweiterung von TLS , impliziert dies , dass TLS wird verwendet. Selbst wenn der Server nicht ALPN, sondern ein anderes früheres Protokoll verwendet, müssen beide Protokolle Erweiterungen von TLS sein , sonst können sie kommunizieren.

In der obigen ausführlichen Ausgabe ist "ALPN" ein Präfix, das angibt, dass der Rest der Zeile der Status der ALPN-Aushandlung durch die Clientseite ist.

Basic Auth bezieht sich lediglich auf das grundlegende API-Schlüssel- / Kennwortprotokoll . (Diese wurden in die Curl-Befehlszeile aufgenommen, aber nicht angezeigt). Hier ist guter Vergleich von Grund Auth vs OAuth :

Einer der beunruhigenden Trends, die ich in den letzten Jahren bemerkt habe, ist, dass immer mehr API-Dienste die Unterstützung für die HTTP-Basisauthentifizierung (auch bekannt als: Basic Auth) langsam zugunsten von OAuth einstellen. ... Basic Auth hat einen schlechten Ruf als "unsicher", aber das ist nicht unbedingt wahr. Sie können verschiedene Maßnahmen ergreifen, um sicherzustellen, dass Ihr API-Dienst (durch Basic Auth gesichert) so sicher wie möglich ist: Führen Sie alle Anforderungen immer über HTTPs aus. Wenn Sie kein SSL verwenden, sind Sie unabhängig vom verwendeten Authentifizierungsprotokoll niemals sicher. Sofern Sie keine HTTPs verwenden, werden alle Ihre Anmeldeinformationen im Klartext über das Netzwerk gesendet: eine schreckliche Idee. ...

Es gibt also keinen Beweis für ein Downgrade von TLS - und ich bezweifle, dass dies möglich ist. Das Hinzufügen des --tlsv1.2Flags zum Einrollen führt zur gleichen Ausgabe.

Genau das, was diese Linie

* ALPN, server did not agree to a protocol

Mittel ist immer noch ein Rätsel, aber ich vermute, es bedeutet entweder (1) nicht mit hhtp2 einverstanden zu sein oder weniger wahrscheinlich (2) der Client fragte, ob es ohne Autorisierung weitergeht und abgelehnt wurde, und verwendete daraufhin die Autorisierung. Eine wirklich schlechte Wahl der Sprache für die Diagnoseausgabe. Google gibt Tausende von Ergebnissen für diesen wörtlichen Ausdruck zurück.