이 "openssl s_client -connect"호출은 실제로 OCSP 응답자 서버에 질의하여 현재 인증서 유효성을 확인합니까?

Question

openssl 명령 줄 인터페이스의 한 줄을 호출 할 때 OCSP 확인 프로토콜을 완벽하게 수행 할 수 있는지 궁금합니다. 체인의 모든 OCSP 응답자 서버에 질의하여 인증서의 현재 유효성을 확인합니다. 서버바와 같이 @pepo의 대답에 설명이 너무있을 경우

참조하기 위해, 나는 는 조회 대신에 사용되는 캐시 된 인증서를 피할 것이라고을 기대하고, /dev/null로 -CAfile 옵션을 지정 인증서 체인 (아래 업데이트에 대한 자세한 내용을) RFC 5246에 지정된 기본 TLS1.2 핸드 쉐이크의 일부를 전송 출력했다

# openssl s_client -CAfile /dev/null -connect www.equifaxsecurity2017.com:443 

:

01,234,099,532,931,588,437을

그것은 캐시 파일에서 어떤 도움없이 체인의 세 가지 링크를 발견했다, 그래서 에이전트 (1) GeoTrust의 DV SSL의 CA와 인터넷을 통해 전달해야합니다 openssl 것처럼 보이는 - G3, 및 (2) GeoTrust Global CA, 체인을 만드십시오. 그 맞습니까? 아니요! 그것은 정확하지 않다!

openssl도 3 명의 OCSP 응답자 각각에게 적절한 OCSP 요청을하여 체인을 확인 했습니까?

(내 추측은 "아니오"입니다.) 또한 openssl ocsp ...을 인증서의 수동 텍스트 작업과 함께 사용하여 한 번에 하나의 링크만으로 OSCP 확인을 수행 할 수 있음을 알고 있습니다. openssl 전체 OCSP 검증을 수행하기 위해 기록 된 것, 내가 부탁하고 이유입니다)

UPDATE 2017년 9월 14일 :.

감사를 올바르게 구성하는 경우들 ("SSL 서버에 응답 '을 @pepo하기) 인증서 체인을 보낼 것입니다 (루트 CA 인증서 제외) ", 나는 RFC 5246을 찾아 섹션 을 찾았습니다"7.4.2 Se TLS1.2 핸드 쉐이크의 서버 인증서 "부분"의 내용을 설명 "rver 인증서 :

이 인증서의 순서 (체인)입니다. 보낸 사람의
인증서가 목록에 먼저 와야합니다. 각 후속 인증서 은 그 앞에 오는 인증서를 직접 인증해야합니다. 인증서 유효성 검사를 사용하려면 루트 키를 독립적으로 배포해야하므로 루트 인증서 권한을 지정하는 자체 서명 된 인증서는 이라는 유효성을 검사하기 위해 원격 끝이 이미 소유하고 있어야한다는 가정하에 체인에서 생략 될 수 있습니다 (MAY) 어떤 경우 든 허용됩니다.

또한, -crl_check_all 옵션에 대한 @의 pepo의 대답 덕분에, 나는 그것을 시도하고 다음과 같은 출력이있어 :

CONNECTED(00000003) 
depth=0 CN = www.equifaxsecurity2017.com 
verify error:num=3:unable to get certificate CRL 
verify return:1 
depth=1 C = US, O = GeoTrust Inc., OU = Domain Validated SSL, CN = GeoTrust DV SSL CA - G3 
verify error:num=3:unable to get certificate CRL 

그것은 오류 unable to get certificate CRL에 실패했습니다. 선택한 웹 사이트에 OCSP 스테이플러이 활성화되어 있기 때문에 중요하지 않습니다.을 확인 CRL을 수행하는 대신 -crl_check_all의 경우

, 우리는 대신을 스테이플 링 OCSP를 요청 add the option -status 는 다음 출력이 수신 :

CONNECTED(00000003) 
<stuff omitted omitted> 
OCSP response: 
====================================== 
OCSP Response Data: 
    OCSP Response Status: successful (0x0) 
    Response Type: Basic OCSP Response 
    Version: 1 (0x0) 
    Responder Id: CE2C8B1E8BD2300FD1B15446E9B594254949321B 
    Produced At: Sep 10 11:12:45 2017 GMT 
    Responses: 
    Certificate ID: ... 
    Cert Status: good 
    This Update: Sep 10 11:12:45 2017 GMT 
    Next Update: Sep 17 11:12:45 2017 GMT 
    Signature Algorithm: sha1WithRSAEncryption 
<stuff omitted> 

이는 OCSP 스테이플 링 서버에서 사용할 수 있습니다 보여줍니다 첫 번째 (리프) 인증서에만 사용할 수있는 것으로 나타나고 두 번째 인증서에는 사용할 수없는 것으로 보입니다. (자체 서명 된 세 번째 인증서는 독립적으로 유효성을 검사해야합니다). 따라서 두 번째 인증서를 확인하려면 CRL- 확인 또는 OCSP-request-response 중 하나를 사용해야합니다. 이 특정 인증 체인에서 CRL- 검사을 사용할 수 없으므로 OCSP- 요청 - 응답 만 남습니다. @pepo의 답장

감사합니다, 나는 (역사적 순서로 나열) openssl 사이의 관계는 TLS1.2 프로토콜 및 권한 부여를 검증하기위한 이러한 방법을 훨씬 더 잘 이해 :

• CRL (

그러나

OSCP 요청 및 응답

OCSP 스테이플 의하면 인증서 폐기리스트) 새로운 질문도 제기되었습니다

• 가에 관한 OCSP - 스테이플 링 "서버 인증서"메시지 단계에서 체인의 인증서와 함께 서버에서 전송 응답 -이 다음에서 서명 정보를 (이 레벨 업). openssl ... -status 처리 중에이 서명 정보가 실제로 확인 되었습니까?
는

UPDATE : 2017년 9월 15일

질문에 대한 안전 대답은? "실제로 openssl ... -status 처리하는 동안 확인이 서명 정보가"도이 answer 과에 따라, NO 것으로 보인다 @ dave_thompson_085 님의 의견은 아래에 있습니다 (그는 소스 코드를 살펴 보았습니다).

혼란스러운가요? 예! 이상하게도 "OpenSSL 요리 책 (feistyduck, Ivan Ristić)" 은 unusually unclear about this question, 으로 서명을 확인하는 명백한 방법이 없으며 명시 적으로 서명이 검증되었는지 여부도 명시하지 않습니다.반면, 대한 다른 종류의 해지 확인의 두 :

• CRL-checking
• and OCSP-request-response (find "submit OCSP request")

은 "OpenSSL이 요리 책은"명시 적 방법 (레시피) 여분의 거리를 가서 수동으로 확인을 완료하기를 보여줍니다 이미 openssl에 의해 산출 된 정보를 사용합니다. "OpenSSL Cookbok"에 스테이플 된 OCSP 응답의 전체 유효성 검사를위한 레시피가 포함되어 있지 않은 이유를 추론하는 것은 매우 인간적인 실수입니다. 필요하지 않기 때문입니다.

IMHO, 우선 다음과 같은 순서로, 최고 수준의 문서를 포함하는 OpenSSL을 (또는 유사한 라이브러리)의 매우 책임을 질 것입니다

• (1) 설명은 OpenSSL은 블랙 박스 솔루션을 제공하지 않습니다 TLS + 권한 부여에
는 가 제공됩니다 (예를 들어, 허가없이 TLS 핸드 쉐이크 검사)를 않는 솔루션의 일부를 제한 대해
• (2) 설명, OpenSSL이 구성 요소를 조립 조리법에
• (3) 문서는 인증 를 완료 해결책을 확인하십시오.

오해가 아주 쉽게 퍼집니다. 불과 며칠 전 제 리눅스 우분투 PC에서 알림 메일을 보내는 간단한 프로그램을 작성하려고했습니다. 표준 Python 릴리스 (버전 2와 3 모두)에는 TLS1.2를 "구현하는"SMTP 및 SSL 라이브러리가 포함되어 있습니다. 10 분 안에 프로그램을 작성하고 디버거에서 살펴볼 수 있습니다. 나는 파이썬 SSL 라이브러리에서 OpenSSL의 handshake() 함수에 대한 호출을 볼 수 있었으며, handshake()은 권한 검사를 포함하지 않고 SSL 라이브러리와 SMTP 라이브러리가 해제되지 않는다는 가정하에 모든 권한 검사를 처리해야한다고 가정했다. 이상하게도 SSL 라이브러리의 호출 코드에는 handshake()이라는 포스트가 포함되어 수신 된 인증서 이름이 호출 된 서버의 인증서 이름과 일치하는지 확인합니다. "handshake()이 이미 모든 서명 확인 등을 처리했다면 이러한 원시 검사가 필요한 이유는 무엇입니까?"라고 나는 생각했다. 그 의심은 TLS 보안 양파의 뒷면을 껍질을 벗기는 여행을 시작했고, 나는 그 이후로 울음을 멈출 수 없었습니다.

휠을 다시 발명하려고하지 않으려 고합니다. 어쨌든 흔들릴 수 있습니다. 그러나 나는 사용할 수있는 바퀴를 찾을 수없는 것 같습니다. 여기에서 어디로 가야합니까?

Answer 1

SSL 서버 (올바르게 구성된 경우)는 인증서 체인을 보냅니다 (루트 CA 인증서 제외). 당신은 그것을 here으로 확인할 수 있습니다.

Openssl이 (가) 이러한 인증서를 가져 오지 않았지만 SSL 연결을 시작할 때 해당 인증서를 가져 왔습니다. openssl documentation

OCSP 확인을 수행하는지는 모르지만 나는 의심 스럽습니다. 이럴 (The s_client utility is a test tool and is designed to continue the handshake after any certificate verification errors. 기준)은 전혀 기본적으로 유효성 검사를 수행하지 않지만 적어도 루트 CA 인증서를 제외하고 인증서 체인을 (보내드립니다 (제대로 구성된 경우) 인수를 -crl_check_all

openssl s_client -connect www.equifaxsecurity2017.com:443 -crl_check_all