'신뢰 인증서' 및 기타 속성이 있는 경우 .. 이것이 얼마나 중요합니까?
OpenSSL이 지금 구현합니까? 그렇지 않다면 OpenSSL이 구현하지 않는 이유는 무엇입니까?
답변1
SSL을 사용하는 대부분의 프로토콜/애플리케이션에서 클라이언트는 (1) 서버가 유효한 인증서, 즉 신뢰할 수 있는 CA에서 발행하고 만료, 취소 또는 변조되지 않은 인증서를 제공하는지, 그리고 (2) 인증서가 원하는 서버에 대한 것인지, 실수나 고의적인 공격으로 귀하의 연결이 라우팅된 다른 사람이 아닙니다. (서버 인증에만 기밀성이 필요하지 않은 경우가 드물지만 명시적으로 인증하지 않는 "anon" 또는 "aNULL" 암호 제품군을 사용하는 것이 더 나을 것입니다.)
현재까지 OpenSSL은 (1)을 수행하지만 (2)는 수행하지 않습니다., 일반적으로 신뢰 저장소에서는 CA 루트 인증서만 지원합니다. 하나의 CA 루트가 수천 또는 수백만 개의 서버 인증서를 '책임'할 수 있으며, 예를 들어 Verisign이 두 인증서 모두에 인증서를 발급했다고 해서 bigbank.com내 localdiner.combigbank 계정을 localdiner에 제공하고 싶다는 의미는 아닙니다. 따라서 애플리케이션은 verify_callback에서 또는 핸드셰이크가 완료된 후 (민감한) 데이터를 전송하기 전에 (2)를 수행해야 합니다. 다음 주요 릴리스 1.0.2에는 인증서 체인 유효성 검사에 대한 향상된 기능이 포함될 계획이며 적어도 일부 경우에는 이름 유효성 검사도 포함된다고 생각합니다. RFC 2818을 사용하는 HTTPS 또는 RFC 6125를 사용하는 기타 TLS 기반 프로토콜의 경우 제목의 CommonName과 SubjectAlternativeNames 확장(있는 경우)을 모두 확인해야 합니다.
모르겠습니다왜 OpenSSL인가?(그리고 SSLeay 이전에도)하지 않습니다이미. 일부 특이한 SSL/TLS 애플리케이션은 표준 CN/SAN 이외의 것을 원한다고 말할 수도 있지만 OpenSSL이 일반적인 경우를 처리하고 드문 경우에 대한 콜백이나 옵션을 제공하는 다른 영역도 있습니다. 내 생각엔 아마도 일이 너무 많았고 사람이 부족했기 때문일 것입니다(아주 최근까지는).