"server certificate verification OK" but "ALPN, server did not agree to a protocol"

Question

I am making a curl call

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

and the verbose output contains

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

My questions are:

• Is the authorization data being sent encrypted?
• Is the post-authorization content being sent encrypted?

I can see that the TLS certificate verification succeeded. But then the messages "ALPN, server did not agree to a protocol" and "Server auth using Basic with user 'api'" don't inspire full confidence.

I'm hoping it's just referring to a separate layer protocol being used under/within/over the TLS encryption protocol, but I don't know.

---

More detailed verbose output:

* 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 is transport layer security. In the above case that has succeeded, no problem.

From Wikipedia:

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.

Since APLN is an extension of TLS, it implies that TLS is being used. Even if the server is not using ALPN, but some other earlier protocol, both protocols must be extensions of TLS or they would not be able communicate.

In the above verbose output, "ALPN," is a prefix indicating that the rest of the line is the status of ALPN negotiation by the client side.

Basic Auth just refers to the basic API key/password protocol. (Those were included in the curl command line, but not shown). Here is good comparison of 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. ...

So there is no proof of downgrading from TLS - and I doubt it is possible. Adding the --tlsv1.2 flag to curl results in the same output.

Exactly what this line

* ALPN, server did not agree to a protocol

means is still a mystery, but I'm guessing it means either (1) not agreeing to HTTP/2, or less likely (2) the client asked if it continue without authorization and was refused, and thereupon used authorization. A truly bad choice of language for diagnostic output. Google returns thousands of results for that literal expression.