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
......
Best Answer
TLS is transport layer security. In the above case that has succeeded, no problem.
From Wikipedia:
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:
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
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.