"Verificación del certificado del servidor OK" pero "ALPN, el servidor no aceptó un protocolo"

Estoy haciendo una llamada curl

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

y la salida detallada contiene

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

Mis preguntas son:

• ¿Los datos de autorización se envían cifrados?
• ¿El contenido posterior a la autorización se envía cifrado?

Puedo ver que la verificación del certificado TLS fue exitosa. Pero luego los mensajes "ALPN, el servidor no aceptó un protocolo" y "La autenticación del servidor usando Basic con el usuario 'api'" no inspiran plena confianza.

Espero que solo se refiera a un protocolo de capa separado que se usa bajo / dentro / sobre el protocolo de cifrado TLS, pero no lo sé.

Salida detallada más detallada:

* 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 es la seguridad de la capa de transporte. En el caso anterior que ha tenido éxito, no hay problema.

De Wikipedia :

La negociación del protocolo de la capa de aplicación (ALPN) es una extensión de seguridad de la capa de transporte (TLS) para la negociación del protocolo de la capa de aplicación. ALPN permite que la capa de aplicación negocie qué protocolo debe realizarse a través de una conexión segura de una manera que evite viajes de ida y vuelta adicionales y que sea independiente de los protocolos de la capa de aplicación. Lo necesitan las conexiones HTTP / 2 seguras, lo que mejora la compresión de las páginas web y reduce su latencia en comparación con HTTP / 1.x.

Dado que APLN es una extensión de TLS , implica que se está utilizando TLS . Incluso si el servidor no usa ALPN, sino algún otro protocolo anterior, ambos protocolos deben ser extensiones de TLS , o podrían comunicarse.

En el resultado detallado anterior, "ALPN" es un prefijo que indica que el resto de la línea es el estado de la negociación ALPN por parte del cliente.

La autenticación básica solo hace referencia al protocolo básico de clave / contraseña de API . (Se incluyeron en la línea de comando de curl, pero no se muestran). Aquí hay una buena comparación de Basic Auth vs OAuth :

Una de las tendencias perturbadoras que he notado en los últimos años es que cada vez más servicios API están abandonando lentamente el soporte para la autenticación básica HTTP (también conocida como autenticación básica) a favor de OAuth. ... La autenticación básica tiene una mala reputación por ser "insegura", pero esto no es necesariamente cierto. Hay varias cosas que puede hacer para asegurarse de que su servicio API (protegido por la autenticación básica) sea lo más seguro posible: ejecute siempre todas las solicitudes a través de HTTP. Si no está utilizando SSL, no importa qué protocolo de autenticación use, nunca estará seguro. A menos que esté utilizando HTTP, todas sus credenciales se enviarán en texto plano por cable: una idea horrible. ...

Por lo tanto, no hay pruebas de degradación de TLS, y dudo que sea posible. Agregar la --tlsv1.2bandera al rizo da como resultado la misma salida.

Exactamente lo que esta línea

* ALPN, server did not agree to a protocol

significa sigue siendo un misterio, pero supongo que significa (1) no aceptar hhtp2, o menos probable (2) el cliente preguntó si continuaría sin autorización y fue rechazado, y luego utilizó la autorización. Una mala elección de idioma para la salida de diagnóstico. Google devuelve miles de resultados para esa expresión literal.