Xác minh chứng chỉ máy chủ của Nhật Bản OK nhưng nhưng ALP ALPN, máy chủ không đồng ý với một giao thức

Tôi đang thực hiện một cuộc gọi curl

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

và đầu ra dài dòng chứa

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

Câu hỏi của tôi là:

• Là dữ liệu ủy quyền được gửi mã hóa?
• Là nội dung sau ủy quyền đang được mã hóa?

Tôi có thể thấy rằng xác minh chứng chỉ TLS đã thành công. Nhưng sau đó, các thông báo "ALPN, máy chủ không đồng ý với giao thức" và "Máy chủ xác thực sử dụng Basic với người dùng 'api'" không truyền cảm hứng cho sự tự tin hoàn toàn.

Tôi hy vọng nó chỉ đề cập đến một giao thức lớp riêng biệt được sử dụng bên dưới / bên trong / trên giao thức mã hóa TLS, nhưng tôi không biết.

Đầu ra chi tiết hơn:

* 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 là sự thành công của lớp vận chuyển. Trong trường hợp trên đã thành công, không có vấn đề.

Từ Wikipedia :

Đàm phán giao thức tầng ứng dụng (ALPN) là một phần mở rộng TLS (Transport Layer Security) để đàm phán giao thức lớp ứng dụng. ALPN cho phép lớp ứng dụng đàm phán giao thức nào sẽ được thực hiện qua kết nối an toàn theo cách tránh các chuyến đi khứ hồi bổ sung và độc lập với các giao thức của lớp ứng dụng. Nó cần thiết bởi các kết nối HTTP / 2 an toàn, giúp cải thiện việc nén các trang web và giảm độ trễ so với HTTP / 1.x.

Vì APLN là một phần mở rộng của TLS , nên nó ngụ ý rằng TLS đang được sử dụng. Ngay cả khi máy chủ không sử dụng ALPN, nhưng một số giao thức khác trước đó, cả hai giao thức phải là phần mở rộng của TLS , hoặc chúng sẽ có thể giao tiếp.

Trong đầu ra dài dòng ở trên, "ALPN", là tiền tố chỉ ra rằng phần còn lại của dòng là trạng thái đàm phán ALPN của phía khách hàng.

Basic Auth chỉ đề cập đến giao thức khóa / mật khẩu API cơ bản . (Chúng được bao gồm trong dòng lệnh curl, nhưng không được hiển thị). Dưới đây là so sánh tốt về Basic Auth vs OAuth :

Một trong những xu hướng đáng lo ngại mà tôi nhận thấy trong vài năm qua là ngày càng có nhiều dịch vụ API đang dần bỏ hỗ trợ cho Xác thực cơ bản HTTP (còn gọi là Auth cơ bản) có lợi cho OAuth. ... Auth cơ bản bị mang tiếng xấu là không an toàn, nhưng điều này không hẳn đúng. Có một số điều bạn có thể làm để đảm bảo rằng dịch vụ API của bạn (được bảo mật bởi Basic Auth) an toàn nhất có thể: Luôn chạy tất cả các yêu cầu qua HTTP. Nếu bạn không sử dụng SSL, hơn bất kể bạn sử dụng giao thức xác thực nào, bạn sẽ không bao giờ được an toàn. Trừ khi bạn đang sử dụng HTTP, tất cả thông tin đăng nhập của bạn sẽ được gửi bằng văn bản đơn giản qua dây: một ý tưởng khủng khiếp. ...

Vì vậy, không có bằng chứng về việc hạ cấp từ TLS - và tôi nghi ngờ điều đó là có thể. Thêm --tlsv1.2cờ để cuộn kết quả trong cùng một đầu ra.

Chính xác những gì dòng này

* ALPN, server did not agree to a protocol

có nghĩa là vẫn còn là một bí ẩn, nhưng tôi đoán nó có nghĩa là (1) không đồng ý với hhtp2, hoặc ít có khả năng (2) khách hàng hỏi nếu nó tiếp tục mà không có sự cho phép và đã bị từ chối, và sau đó đã sử dụng ủy quyền. Một lựa chọn thực sự xấu của ngôn ngữ cho đầu ra chẩn đoán. Google trả về hàng ngàn kết quả cho biểu hiện theo nghĩa đen đó.