“서버 인증서 확인은 정상”이지만“ALPN, 서버가 프로토콜에 동의하지 않았습니다”


11

나는 컬 콜을하고있다

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

자세한 출력에는

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

내 질문은 :

  • 인증 데이터가 암호화되어 전송됩니까?
  • 인증 후 내용이 암호화되어 전송됩니까?

TLS 인증서 확인이 성공했음을 알 수 있습니다. 그러나 "ALPN, 서버가 프로토콜에 동의하지 않았습니다"라는 메시지 와 " 'api'사용자와 함께 Basic을 사용하는 서버 인증"이라는 메시지 는 완전히 자신감을 얻지 못합니다.

TLS 암호화 프로토콜에서 / 내부 / 위에서 사용되는 별도의 계층 프로토콜을 참조하기를 바라고 있지만 모르겠습니다.


보다 자세한 상세 출력 :

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

답변:


10

TLS는 전송 계층 보안입니다. 위의 경우에 성공하면 아무런 문제가 없습니다.

에서 위키 백과 :

ALPN (Application-Layer Protocol Negotiation)은 응용 프로그램 계층 프로토콜 협상을위한 TLS (Transport Layer Security) 확장입니다. ALPN을 통해 응용 프로그램 계층은 추가 왕복을 피하고 응용 프로그램 계층 프로토콜과 무관 한 방식으로 보안 연결을 통해 수행 할 프로토콜을 협상 할 수 있습니다. 웹 페이지의 압축을 개선하고 HTTP / 1.x에 비해 대기 시간을 줄이는 안전한 HTTP / 2 연결이 필요합니다.

이후 APLN은 입니다 확장TLS , 그 의미 TLS가 되어 사용된다. 서버가 ALPN을 사용하지 않고 다른 이전 프로토콜을 사용하더라도 두 프로토콜 모두 TLS의 확장이어야합니다. 그렇지 않으면 통신 할 수 있습니다.

위의 자세한 출력에서 ​​"ALPN"은 나머지 행이 클라이언트 측의 ALPN 협상 상태임을 나타내는 접 두부입니다.

기본 인증 은 기본 API 키 / 암호 프로토콜을 참조합니다 . (이들은 curl 명령 행에 포함되었지만 표시되지 않았습니다). 다음Basic AuthOAuth를 잘 비교 한 것입니다 .

지난 몇 년 동안 내가 목격 한 트렌드 중 하나는 점점 더 많은 API 서비스가 OAuth에 찬성하여 HTTP 기본 인증 (일명 : 기본 인증)에 대한 지원을 서서히 버리고 있다는 것입니다. ... 기본 인증은 "안전하지 않은"평판이 나쁘지만 반드시 그런 것은 아닙니다. API 서비스 (Basic Auth로 보안 됨)를 최대한 안전하게 유지하기 위해 수행 할 수있는 몇 가지 작업이 있습니다. 항상 모든 요청을 HTTP를 통해 실행하십시오. SSL을 사용하지 않는 경우 사용하는 인증 프로토콜에 관계없이 안전하지 않습니다. HTTP를 사용하지 않는 한 모든 자격 증명은 유선으로 일반 텍스트로 전송됩니다. ...

따라서 TLS에서 다운 그레이드한다는 증거는 없습니다. --tlsv1.2컬하기 위해 플래그를 추가하면 동일한 출력이 발생합니다.

정확히이 라인

* ALPN, server did not agree to a protocol

즉, hhtp2에 동의하지 않거나 (2) 클라이언트가 권한 부여없이 계속하고 요청했는지 거부 한 후 권한 부여를 사용했음을 의미합니다. 진단 출력을위한 언어의 진정한 나쁜 선택. Google은 해당 리터럴 표현식에 대해 수천 개의 결과를 반환합니다.


4
ALPN은 서버가 h2와 같은 다른 프로토콜을 사용하기로 동의하지 않았다는 것을 의미한다고 생각합니다. 적어도 나는 HTTP / 2 협상의 맥락에서 그것을 보았다. 실제로 나쁜 표현이지만 걱정할 것은 없습니다.
Tobias K.

@Tobias 더 이해가 될 것입니다.
Craig Hicks

다음과 같은 문장에서 : "서버가 ALPN을 사용하지 않지만 이전의 다른 프로토콜을 사용하더라도 두 프로토콜은 모두 TLS의 확장이거나 통신 할 수 없습니다 "또는 "통신 할 수 없음" ? 다른 유용한 답변을 주셔서 감사합니다.
Sabuncu
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.