"Vérification du certificat du serveur OK" mais "ALPN, le serveur n'a pas accepté un protocole"

Je fais un appel curl

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

et la sortie détaillée contient

....
* 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
......

Mes questions sont:

• Les données d'autorisation envoyées sont-elles cryptées?
• Le contenu post-autorisation envoyé est-il crypté?

Je peux voir que la vérification du certificat TLS a réussi. Mais alors les messages "ALPN, le serveur n'a pas accepté un protocole" et "Authentification du serveur utilisant Basic avec l'utilisateur 'api'" n'inspirent pas une confiance totale.

J'espère que cela fait simplement référence à un protocole de couche séparé utilisé sous / dans / sur le protocole de cryptage TLS, mais je ne sais pas.

Sortie détaillée plus détaillée:

* 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 est la sucurité de la couche de transport. Dans le cas ci-dessus qui a réussi, aucun problème.

De Wikipédia :

La négociation de protocole de couche application (ALPN) est une extension TLS (Transport Layer Security) pour la négociation de protocole de couche application. ALPN permet à la couche application de négocier quel protocole doit être exécuté sur une connexion sécurisée d'une manière qui évite les allers-retours supplémentaires et qui est indépendant des protocoles de la couche application. Il est nécessaire aux connexions HTTP / 2 sécurisées, ce qui améliore la compression des pages Web et réduit leur latence par rapport à HTTP / 1.x.

Puisque APLN est une extension de TLS , cela implique que TLS est utilisé. Même si le serveur n'utilise pas ALPN, mais un autre protocole antérieur, les deux protocoles doivent être des extensions de TLS , sinon ils pourraient communiquer.

Dans la sortie détaillée ci-dessus, "ALPN", est un préfixe indiquant que le reste de la ligne est l'état de la négociation ALPN par le côté client.

Basic Auth fait simplement référence au protocole de base de clé / mot de passe API . (Celles-ci étaient incluses dans la ligne de commande curl, mais non représentées). Voici une bonne comparaison de Basic Auth vs OAuth :

L'une des tendances inquiétantes que j'ai remarquées au cours des dernières années est que de plus en plus de services API abandonnent lentement la prise en charge de l'authentification de base HTTP (aka: Basic Auth) au profit d'OAuth. ... Basic Auth a la mauvaise réputation d'être «peu sûr», mais ce n'est pas nécessairement vrai. Il y a plusieurs choses que vous pouvez faire pour vous assurer que votre service API (sécurisé par Basic Auth) est aussi sécurisé que possible: Exécutez toujours toutes les requêtes via HTTP. Si vous n'utilisez pas SSL, quel que soit le protocole d'authentification que vous utilisez, vous ne serez jamais en sécurité. À moins que vous n'utilisiez HTTP, tous vos identifiants seront envoyés en texte brut sur le fil: une idée horrible. ...

Il n'y a donc aucune preuve de rétrogradation de TLS - et je doute que ce soit possible. L'ajout de l' --tlsv1.2indicateur pour boucler donne la même sortie.

Exactement ce que cette ligne

* ALPN, server did not agree to a protocol

moyen est toujours un mystère, mais je suppose que cela signifie soit (1) de ne pas accepter hhtp2, soit moins probable (2) le client a demandé s'il continuait sans autorisation et a été refusé, et a ensuite utilisé l'autorisation. Un vraiment mauvais choix de langue pour la sortie de diagnostic. Google renvoie des milliers de résultats pour cette expression littérale.