When examining the cURL verbose output, we can confirm secure communication through several indicators:

* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* server certificate verification OK
* common name: *.mailgun.net (matched)
* certificate public key: RSA

The encryption remains active throughout the entire session, including during Basic Auth transmission. The ALPN warning doesn't affect this security layer.

ALPN (Application-Layer Protocol Negotiation) is a TLS extension for protocol selection. The message simply indicates:

* ALPN, offering http/1.1
* ALPN, server did not agree to a protocol

This occurs because:

1. The server doesn't support ALPN negotiation
2. HTTP/1.1 becomes the fallback protocol
3. No impact on encryption security

All HTTP headers (including Authorization) are encrypted when using HTTPS. You can verify this through Wireshark captures - you'll see encrypted TLS packets rather than clear-text headers.

To explicitly set HTTP/1.1 and verify encryption:

curl -v \
--http1.1 \
-H "Authorization: Basic $(echo -n 'api:your-api-key' | base64)" \
https://api.mailgun.net/v3/yourdomain.com/messages

For deeper analysis, use these OpenSSL commands:

openssl s_client -connect api.mailgun.net:443 -alpn http/1.1
openssl s_client -connect api.mailgun.net:443 -status

This will show the complete TLS handshake and certificate chain.

The Mailgun API properly implements TLS 1.2+ security. Their endpoints:

• Support perfect forward secrecy (ECDHE)
• Use strong cipher suites (AES_128_GCM)
• Maintain valid certificates from DigiCert

Only worry if you see:

* SSL connection using SSLv3
* server certificate verification FAILED

Combined with ALPN warnings, these would indicate actual security issues.

* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* server certificate verification OK
* ALPN, server did not agree to a protocol

When examining cURL's verbose output, we see three critical TLS handshake elements:

1. Successful certificate verification (chain of trust validated)
2. Established TLS 1.2 connection with strong cipher suite
3. ALPN negotiation failure (but this doesn't affect encryption)

All data transmitted after the TLS handshake - including Basic Auth headers and POST body - is encrypted:

POST /v3/pindertek.com/messages HTTP/1.1
Authorization: Basic sdfsdfsdfsadfsdfsdfsadfsadfsadfsdfsdfasdfsdf=

The ALPN warning simply indicates the server didn't support HTTP/2 negotiation, falling back to HTTP/1.1. This is unrelated to encryption security.

To confirm encryption is working, try these verification techniques:

# Method 1: Packet capture verification
tcpdump -i any -s 0 -w output.pcap port 443 and host api.mailgun.net

# Method 2: SSL Labs test
openssl s_client -connect api.mailgun.net:443 -showcerts

For maximum security in production environments:

curl -v \
--tlsv1.2 \
--proto =https \
--cacert /path/to/ca-bundle.crt \
-H "Authorization: Basic $(echo -n 'api:your-api-key' | base64)" \
-H "Content-Type: application/json" \
-d '{"param":"value"}' \
https://api.mailgun.net/v3/yourdomain/messages

Key security parameters included:
- Explicit TLS 1.2 enforcement
- Certificate pinning via --cacert
- Proper base64 encoding of credentials