“verificação do certificado do servidor OK” mas “ALPN, o servidor não concordou com um protocolo”

Question

Estou fazendo uma chamada curl

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 de autorização estão sendo enviados criptografados?
• O conteúdo da pós-autorização está sendo enviado criptografado?

Eu posso ver que a verificação do certificado TLS foi bem-sucedida. Mas então as mensagens "ALPN, o servidor não concordou com um protocolo" e "A autenticação do servidor usando Basic com usuário 'api'" não inspiram total confiança.

Espero que esteja apenas se referindo a um protocolo de camada separado sendo usado em / dentro / por meio do 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
......

    

Answer 1

TLS é a sucessão da camada de transporte. No caso acima que foi bem sucedido, não há problema.

Em Wikipédia :

Application-Layer Protocol Negotiation (ALPN) is a Transport Layer Security (TLS) extension for application layer protocol negotiation. ALPN allows the application layer to negotiate which protocol should be performed over a secure connection in a manner that avoids additional round trips and which is independent of the application layer protocols. It is needed by secure HTTP/2 connections, which improves the compression of web pages and reduces their latency compared to HTTP/1.x.

Como APLN é uma extensão de TLS , isso significa que TLS é sendo usado. Mesmo que o servidor não esteja usando ALPN, mas algum outro protocolo anterior, ambos os protocolos devem ser extensões de TLS , ou eles poderiam se comunicar.

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

Autenticação básica está apenas se referindo ao protocolo básico API key / password . (Esses foram incluídos na linha de comando curl, mas não mostrados). Aqui é uma boa comparação entre Basic Auth vs OAuth :

One of the disturbing trends I’ve noticed over the past few years is that more and more API services are slowly ditching support for HTTP Basic Authentication (aka: Basic Auth) in favor of OAuth. ... Basic Auth gets a bad reputation for being “insecure”, but this isn’t necessarily true. There are several things you can do to ensure that your API service (secured by Basic Auth) is as secure as possible: Always run all requests over HTTPs. If you’re not using SSL, than no matter what authentication protocol you use, you’ll never be secure. Unless you’re using HTTPs, all of your credentials will be sent in plain-text over the wire: a horrible idea. ...

Portanto, não há prova de downgrade de TLS - e duvido que seja possível. Adicionar o sinalizador --tlsv1.2 para enrolar resulta na mesma saída.

Exatamente o que esta linha

* ALPN, server did not agree to a protocol

significa que ainda é um mistério, mas eu estou supondo que significa (1) não concordar com hhtp2, ou menos provável (2) o cliente perguntou se ele continuava sem autorização e foi recusado, e então 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.