3

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

TLS is transport layer sucurity. 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 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 is just referring 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 hhtp2, 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.

  • 1
    I think the ALPN thing means that the server did not agree to use another protocol like h2. At least I've seen it before in the context of HTTP/2 negotiation. Bad wording indeed, but nothing to be concerned about. – Tobias K. Jul 14 '18 at 22:16
  • @Tobias That would make more sense. – Craig Hicks Jul 14 '18 at 22:22

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.