"Verifica certificato server OK" ma "ALPN, il server non ha accettato un protocollo"

Sto facendo una telefonata

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

e l'output dettagliato 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
......

Le mie domande sono:

• I dati di autorizzazione inviati sono crittografati?
• Il contenuto post-autorizzazione viene inviato crittografato?

Vedo che la verifica del certificato TLS è riuscita. Ma poi i messaggi "ALPN, il server non ha accettato un protocollo" e "L'autorizzazione del server che utilizza Basic con l'utente 'api'" non ispira piena fiducia.

Spero si riferisca solo a un protocollo di livello separato utilizzato sotto / all'interno / sopra il protocollo di crittografia TLS, ma non lo so.

Output dettagliato più dettagliato:

* 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 è la riuscita del livello di trasporto. Nel caso sopra riportato, nessun problema.

Da Wikipedia :

La negoziazione del protocollo a livello di applicazione (ALPN) è un'estensione TLS (Transport Layer Security) per la negoziazione del protocollo a livello di applicazione. ALPN consente al livello applicazione di negoziare quale protocollo deve essere eseguito su una connessione protetta in modo da evitare ulteriori round trip e che è indipendente dai protocolli del livello applicazione. È necessario per connessioni HTTP / 2 sicure, che migliora la compressione delle pagine Web e ne riduce la latenza rispetto a HTTP / 1.x.

Poiché APLN è un'estensione di TLS , implica che TLS viene utilizzato. Anche se il server non utilizza ALPN, ma qualche altro protocollo precedente, entrambi i protocolli devono essere estensioni di TLS , altrimenti sarebbero in grado di comunicare.

Nell'output dettagliato sopra "ALPN" è un prefisso che indica che il resto della riga è lo stato della negoziazione ALPN dal lato client.

L'autorizzazione di base sta semplicemente facendo riferimento al protocollo chiave / password API di base . (Quelli erano inclusi nella riga di comando del ricciolo, ma non mostrati). Ecco un buon confronto tra Basic Auth vs OAuth :

Una delle tendenze inquietanti che ho notato negli ultimi anni è che sempre più servizi API stanno lentamente abbandonando il supporto per l'autenticazione di base HTTP (aka: Basic Auth) a favore di OAuth. ... Auth di base ha una cattiva reputazione per essere "insicuro", ma questo non è necessariamente vero. Esistono diverse cose che puoi fare per garantire che il tuo servizio API (protetto da Basic Auth) sia il più sicuro possibile: Esegui sempre tutte le richieste su HTTP. Se non stai usando SSL, non importa quale protocollo di autenticazione usi, non sarai mai sicuro. A meno che tu non stia utilizzando HTTPs, tutte le tue credenziali verranno inviate in chiaro via cavo: un'idea orribile. ...

Quindi non ci sono prove del downgrade da TLS - e dubito che sia possibile. Aggiungendo il --tlsv1.2flag per arricciare si ottiene lo stesso output.

Esattamente quello che questa linea

* ALPN, server did not agree to a protocol

significa che è ancora un mistero, ma suppongo significhi che (1) non accetta hhtp2 o che è meno probabile (2) che il cliente abbia chiesto se continua senza autorizzazione e che è stato rifiutato, e quindi utilizzato l'autorizzazione. Una scelta davvero sbagliata della lingua per l'output diagnostico. Google restituisce migliaia di risultati per quell'espressione letterale.