SSL precertificate 이란 CT (Certificate Transparency)의 일부분으로 사용되는 특수한 SSL 인증서입니다. SSL Pre-Certificate와 일반 SSL 인증서와 다른점은, SSL Pre-Certificate는 서버인증 혹은 HTTPS등에 사용되지 않는다는 점입니다.
SSL precertificate의 목적은 인증서가 인증서에 직접 삽입되도록 기록하는 것입니다. 즉, precertificate은 정식 인증서 전에 존재하며, 일반 사용자들에게도 거의 노출되지 않습니다. 그렇기 때문에 일반사용자들은 SSL precertificate을 받아도 이 존재자체를 모르는 경우가 많습니다.
SSL precertificate은 CT RFC중 정의되어 있습니다.
SSL precertificate이 왜 필요할까?
SSL precertificate은 인증서 CT값을 최종 인증서에 삽입시키기 위해 존재합니다.
SSL precertificate은 SCT의 인증서가 제출되었다는 것을 증명하는 몇가지 방법 중 하가지 입니다. 이 방법의 좋은점은, 단독 데이터를 제공하는 것이 아니라(다른 방식들은 handshake 과정에서 SCT를 단독 파일로 전송) CT데이터가 SSL인증서 자신에 삽입되는 것을 허용합니다.
CTlog는 이 인증서의 데이터를 위하여 SCT를 필요로 합니다. 하지만 CA는 로그중의 SCT가 있어야만 최종 인증서를 발급해줍니다. 그렇기 때문에 SSL precertificate을 통해 이런 문제를 해결할 수 있습니다.
SSL precertificate가 필요한 상황은 다음과 같습니다.
1) CA가 고객에게 서명 및 인증서를 발급할 때, 그들은 브라우저 CT조건에 만족하도록 해야하기 때문에, 인증서를 CT Log에 제출한다.
2) CA가 인증서가 이미 기록되어있다는 증거를 제공하는 방법은 여러가지가 있다. 만약 그들이 그 증명을 인증서에 직접 삽입하고 싶다면 SSL precertificate가 필요하다.
3) CA의 최종 인증서에 서명하기 전, 그들은 SSL precertificate를 생성하는데 그 안에는 동일한 데이터가 포함되어 있다. 하지만 형식이 특이한 방식으로 되어있기 때문에, 유효한 SSL인증서로 간주되지 않는다.
4) CA는 SSL precertificate를 CT Log 및 SCT에 제출한다. 이는 로그 파일에 의해 암호를 사용하여 클라이언트의 인증서가 이미 기록되어 있음을 증명한다.
5) CA는 최종 인증서를 발급하고, SCT를 그 안에다 삽입한다.
6) 클라이언트 사용자는 그들의 인증서를 설치하며, 그들의 인증서에 포함된 CT가 합법하다는 것을 증명한다. 여기에는 SCT의 최적방식도 포함된다.
만약 당신이 SCT를 검색하는 과정에서 SSL Pre-Certificate를 마주칠 수도 있습니다. 하지만 관련된(유효한) 인증서를 찾을수는 없을 것입니다. 그것은 CA가 로그에 후속 제출을 하지 않아도 되기 때문입니다. 비록 사용자에게는 유효하지 않아 보여도, 여전히 동일한 발급 기준이 적용됩니다.
CT RFC규정에는, "precertificate의 오류는 결국 최종 인증서의 오류이다"라고 정의되어 있습니다.
어떻게 동작하는가?
precertificate은 X.509 v3 형식의 확장으로 알려진 데이터 필드에 의해 일반 인증서와 구별됩니다. 확장 기능은 X.509 형식에 유연성을 제공하며 새로운 형식의 형식을 요구하지 않고도 새로운 기능을 채택 할 수 있습니다. SSL 인증서는 여러 기능에 확장 기능을 사용합니다.
Precertificates에는이 목적을 위해 특별히 만들어진 "poison extension"이 포함되어 있습니다. 이는 매우 중요(올바른 구문 분석이 불가능한 경우 인증서가 유효하지 않은 것으로 간주 됨)하고 클라이언트 소프트웨어에서 지원되지 않도록 설계되었기 때문에 이러한 이름이 붙은것입니다.
즉, 클라이언트 (예 : 웹 브라우저 또는 운영 체제)가 Precertificates을 받으면 알수없는 확장자를 처리할 수 있다는 것이며, 이는 매우 중요합니다. Precertificates는 이해하지 못하는 critical extension이 있기 때문에 무효로 처리합니다.
그렇기 때문에 이 "poison extension"는 일반 인증서와 Precertificates의 유일한 차이점입니다.
poison extension은 고유한 값인 OID로 표시합니다. 1.3.6.1.4.1.11129.2.4.3. OID 또는 개체 식별자는 특정 목적에 할당되고 컴퓨터에서 구문 분석 가능한 형식을 지정하는 데 사용되는 표준화 된 문자열입니다. 예를들어, OID 번호를 검색하면 "Certificate Transparency precertificate poison extension"이라는 목적을 알 수 있습니다. 또 다른 OID 1.3.6.1.5.5.7.48.1은 SSL인증서에서 OCSP URL을가리킬 때 사용하는 것을 알 수 있습니다.
Windows에서 사전 인증을 다운로드하여 여는 경우 일반 SSL 인증서와 매우 유사하게 보입니다. 그러나 Windows의 인증서 뷰어의 일반 창에는 “A certificate contains an unknown extension that is marked ‘critical.’”라는 메시지가 나타납니다. 세부 정보에는 아래쪽에 poison extension이 표시됩니다 (OID 찾아보기).
<이미지 출처 : https://www.thesslstore.com/blog/ssl-precertificates/>
이 확장이 있기 때문에 Windows는 사전 인증을 유효하지 않은 것으로 처리하게 되는 것입니다. 이렇게되면 SSL 인증서가 사용될 상황 (예 : HTTPS 연결)에서 사용되지 않습니다. macOS에서 인증서 뷰어는 "This certificate cannot be used (unrecognized critical extension))"라고 표시됩니다..
인증서 투명성 프로토콜 버전 2.0 (아직 개발 중이며 RFC6962)에서는 사전 설정 형식이 X.509에서 CMS (암호화 메시지 구문)로 변경됩니다. 이는 사전 형식의 기술 형식 및 인코딩이 크게 변경되어 더 이상 일반 SSL 인증서와 동일한 형식이 아닐 것이라는 것을 의미합니다.
즉, 유효 X.509 SSL 인증서와 사전 인증을 구별 할 필요가 없으므로 CT 2.0을 배포 할 때 poison extension이 더 이상 필요하지 않습니다.
출처 :
WP Statistics플러그인, SQL 인젝션 취약점 발견! (0) | 2017.07.03 |
---|---|
“Phoenix Talon”in Linux Kernel 취약점 (0) | 2017.07.03 |
Karo 랜섬웨어 분석 (0) | 2017.06.30 |
악성 DNS 응답 하나로 원격으로 리눅스 머신 해킹 가능해 (0) | 2017.06.30 |
SharePoint Reflected XSS 취약점(CVE-2017-8514) 분석 (0) | 2017.06.29 |
댓글 영역