"Verificação de certificado do servidor OK", mas "ALPN, servidor não concordou com um protocolo"

Estou fazendo uma ligação

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

e a saída detalhada contém

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

Minhas perguntas são:

• Os dados da autorização estão sendo criptografados?
• O conteúdo da pós-autorização está sendo criptografado?

Percebo que a verificação do certificado TLS foi bem-sucedida. Mas as mensagens "ALPN, servidor não concordaram com um protocolo" e "Autenticação de servidor usando o Basic com o usuário 'api'" não inspiram confiança total.

Espero que esteja apenas se referindo a um protocolo de camada separada sendo usado sob / dentro / sobre o protocolo de criptografia TLS, mas não sei.

Saída detalhada mais detalhada:

* 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 é a sucessão da camada de transporte. No caso acima que foi bem sucedido, não há problema.

Da Wikipedia :

A negociação de protocolo de camada de aplicativo (ALPN) é uma extensão TLS (Transport Layer Security) para negociação de protocolo de camada de aplicativo. O ALPN permite que a camada de aplicativo negocie qual protocolo deve ser executado em uma conexão segura de uma maneira que evite viagens adicionais e que seja independente dos protocolos da camada de aplicação. É necessário para conexões HTTP / 2 seguras, o que melhora a compactação de páginas da web e reduz a latência em comparação com o HTTP / 1.x.

Como o APLN é uma extensão do TLS , isso implica que o TLS está sendo usado. Mesmo se o servidor não estiver usando o ALPN, mas algum outro protocolo anterior, ambos os protocolos deverão ser extensões do TLS ou poderão se comunicar.

Na saída detalhada acima, "ALPN", é um prefixo que indica que o restante da linha é o status da negociação de ALPN pelo lado do cliente.

A autenticação básica está apenas referindo o protocolo básico de chave / senha da API . (Esses foram incluídos na linha de comando curl, mas não mostrados). Aqui está uma boa comparação entre o Basic Auth e o OAuth :

Uma das tendências perturbadoras que notei nos últimos anos é que mais e mais serviços de API estão lentamente abandonando o suporte à Autenticação Básica HTTP (aka: Autenticação Básica) em favor do OAuth. ... A autenticação básica tem uma má reputação por ser "insegura", mas isso não é necessariamente verdade. Há várias coisas que você pode fazer para garantir que seu serviço de API (protegido por autenticação básica) seja o mais seguro possível: sempre execute todas as solicitações por HTTPs. Se você não estiver usando SSL, não importa qual protocolo de autenticação use, nunca estará seguro. A menos que você esteja usando HTTPs, todas as suas credenciais serão enviadas por texto sem fio: uma ideia horrível. ...

Portanto, não há provas de desatualização do TLS - e duvido que seja possível. Adicionar o --tlsv1.2sinalizador para curvar resulta na mesma saída.

Exatamente o que esta linha

* ALPN, server did not agree to a protocol

meios ainda é um mistério, mas suponho que isso signifique (1) não concordar com o hhtp2 ou menos provável (2) que o cliente perguntou se ele continuava sem autorização e foi recusado e, em seguida, usou a autorização. Uma escolha realmente ruim de idioma para saída de diagnóstico. O Google retorna milhares de resultados para essa expressão literal.