개요
HTTPS (SSL /TLS) 사용 공개 키 암호화 인터넷을 통해 브라우저 통신을 읽거나 수정하지 못하도록 보호합니다. 서버는 모든 후속 데이터 교환을 위해 암호화 된 연결을 설정하는 데 사용되는 공개 키를 방문 브라우저에 제공합니다.
그러나 단지 일하는 공개 키만으로도 (그리고 확장하여 서버가) 올바른 원격 장치를 소유하고 있음을 보증하지 않습니다 제목 (예 : 사람, 회사 또는 조직). 중간자 공격자는 자신의 키를 제공하도록 네트워크를 조작하여 모든 통신을 손상시킬 수 있습니다.
브라우저는 다음을 통해이를 방지합니다. 인증 를 사용하는 HTTPS 서버 인증디지털 문서 인 바인딩 개별 주제에 대한 공개 키. 바인딩은 신뢰할 수 있음을 통해 주장됩니다. 인증 기관 (CA) 등 SSL.com 자격을 갖춘 데이터베이스에 대해 자동 및 수동 검사를 통해 예상 인증서 소유자의 신원을 확인합니다.
이 신뢰 관계는 웹 사용자 보안이 절대적이지 않다는 것을 의미합니다. 오히려 사용자가 보안을 보호하기 위해 브라우저와 CA를 신뢰해야합니다. 따라서 인증서 유효성 검사가 작동하는 방식에 대한 기본적인 이해가 모든 사용자의 이익에 있다고 생각합니다.
인증서 유효성 검사 프로세스 (표준 문서에 자세히 설명 됨) RFC 5280)는 상당히 복잡합니다. 이 기사에서는 한 경로 (호스트의 SSL /TLS 대부분의 사용자에게 중요하지 않은 복잡한 세부 정보를 탐색합니다.
인증서 및 X.509 형식
인증서는 모든면에서 디지털 파일이므로 정보 (예 : 서명, 키, 발급자 등)를 저장하려면 파일 형식을 따라야합니다. 사적인 동안 PKI 구성은 공개적으로 신뢰할 수있는 인증서의 모든 형식을 구현할 수 있습니다. PKIs (예 : 브라우저에서 신뢰하는 것)은 RFC 5280을 준수해야합니다. X.509 v3 형식입니다.
X.509 v3을 사용하면 인증서에 다음과 같이 사용 제한 또는 정책 정보와 같은 추가 데이터를 포함 할 수 있습니다. 확장, 각 확장은 임계 or 중요하지 않은. 브라우저는 유효하지 않거나 인식 할 수없는 중요하지 않은 확장명을 무시할 수 있지만 모든 중요 확장명을 처리하고 유효성을 검사해야합니다.
인증 경로 및 경로 처리
CA는 개인 키를 사용하여 발급 된 모든 인증서에 암호로 서명합니다. 이러한 서명은 특정 CA가 인증서를 발급했으며 서명 한 후에 인증서가 수정되지 않았 음을 증명할 수 있습니다.
CA는 자체 발급 인증서를 보유하여 서명 키의 소유권을 설정합니다 ( 뿌리해당 공개 키에 대해 CA는 루트를 생성, 관리 및 활용하기 위해 엄격하게 통제되고 감사 된 절차를 준수해야하며 노출을 최소화하기 위해 일반적으로 루트를 사용합니다. 중간의 인증서. 그런 다음 이러한 중간체를 사용하여 고객의 인증서를 발급 할 수 있습니다.
브라우저는 신뢰할 수있는 루트의 내장 목록과 함께 제공됩니다. (이는 브라우저의 엄격한 포함 기준을 통과 한 CA의 루트입니다.) 인증서를 확인하기 위해 브라우저는 인증서 시퀀스를 얻습니다. 각 인증서는 다음 인증서에 서명하고 서명 CA의 루트를 서버의 루트에 연결합니다. 증명서.
이 일련의 인증서를 인증 경로. 경로의 루트는 트러스트 앵커 서버의 인증서는 잎 or 최종 실체 증명서.
경로 구성
종종 브라우저는 주어진 인증서에 대해 유효한 경로를 찾을 때까지 여러 인증 경로를 고려해야합니다. 경로에 알려진 앵커에 적절히 "연결"되는 인증서가 포함되어 있더라도 경로 길이, 도메인 이름, 인증서 사용 또는 정책에 대한 제한으로 인해 경로 자체가 거부 될 수 있습니다.
가능한 모든 경로를 구성하고 평가하는 것은 브라우저에서 발생하는 모든 새 인증서에 대해 비싼 프로세스입니다. 브라우저는 거부 된 후보 경로의 수를 최소화하기 위해 다양한 최적화를 구현했지만 이러한 세부 사항을 자세히 살펴 보는 것은이 기사의 범위를 벗어납니다.
경로 검증
후보 인증 경로가 생성 된 후 브라우저는 인증서에 포함 된 정보를 사용하여이를 검증합니다. 브라우저가 트러스트 앵커가 직접 서명 한 인증서에서 시작하여 각 인증서의 해당 개인 키가 리프 인증서까지 경로에서 다음 인증서를 발급하는 데 사용되었음을 암호화 방식으로 증명할 수있는 경우 경로가 유효합니다.
인증 경로 검증 알고리즘
RFC 5280은 표준 알고리즘 브라우저는 X.509 인증서의 인증 경로를 확인합니다.
기본적으로 브라우저는 트러스트 앵커 (예 : 루트 인증서)로 시작하는 경로의 모든 인증서를 반복하여 각 인증서의 기본 정보와 중요한 확장을 확인합니다.
절차가 오류없이 경로의 마지막 인증서로 완료되면 경로가 유효한 것으로 수락됩니다. 오류가 발생하면 경로가 유효하지 않은 것으로 표시됩니다.
기본 인증서 처리
확장명에 관계없이 브라우저는 항상 서명 또는 발급자와 같은 기본 인증서 정보를 확인해야합니다. 다음 섹션에서는 브라우저가 수행하는 검사 순서를 보여줍니다.
1. 브라우저가 인증서의 무결성을 확인합니다.
XNUMXD덴탈의 서명 인증서에서 일반 공개 키 암호화를 사용하여 확인할 수 있습니다. 서명이 유효하지 않은 경우, 인증서는 발급 후 수정 된 것으로 간주되어 거부됩니다.
2. 브라우저가 인증서의 유효성을 확인합니다.
인증서 유효 기간 서명 CA가 상태에 대한 정보를 유지한다는 것을 보증하는 시간 간격입니다. 브라우저는 유효성 검사 날짜 및 시간 이전 또는 이후에 만료되는 유효 기간이있는 인증서를 거부합니다.
3. 브라우저가 인증서의 해지 상태를 확인합니다.
인증서가 발급되면 전체 유효 기간 동안 사용 중일 것으로 예상됩니다. 물론 다양한 상황으로 인해 인증서가 자연스럽게 만료되기 전에 유효하지 않게 될 수 있습니다.
이러한 상황에는 주체가 이름을 변경하거나 개인 키의 손상이 의심되는 경우가 포함될 수 있습니다. 이 경우 CA는 해당 인증서를 해지해야하며 사용자는 인증서의 해지 상태를 브라우저에 알리기 위해 CA를 신뢰합니다.
RFC 5280 CA는이 목적으로 해지 목록을 사용하는 것이 좋습니다.
인증서 해지 목록 (CRL)
CA는 주기적으로 서명 된 해지 된 인증서의 서명 된 타임 스탬프 목록을 발급합니다. 인증서 해지 목록 (CRL). CRL은 공개적으로 사용 가능한 저장소에 배포되며 브라우저는 인증서 유효성을 검사 할 때 CA의 최신 CRL을 획득하고 참조 할 수 있습니다.
이 방법의 한 가지 결점은 해지 시간 단위가 CRL 발급 기간으로 제한된다는 것입니다. 브라우저는 현재 발급 된 모든 CRL이 업데이트되도록 예약 된 후에 만 해지 알림을받습니다. 서명 CA의 정책에 따라 XNUMX 시간, 하루 또는 최대 XNUMX 주일까지 걸릴 수 있습니다.
OCSP (온라인 인증서 상태 프로토콜)
해지 상태 정보를 얻는 다른 대안이 있는데, 가장 많이 사용되는 방법은 온라인 인증서 상태 프로토콜 (OCSP).
표준 문서에 설명 RFC6960OCSP를 사용하면 브라우저가 온라인 OCSP 서버에서 특정 인증서의 해지 상태를 요청할 수 있습니다 (또는 응답자). 올바르게 구성된 OCSP는 훨씬 더 즉각적이며 위에서 언급 한 CRL 업데이트 대기 시간 문제를 방지합니다. 게다가, OCSP 스테이플 링 성능과 속도를 향상시킵니다.
4. 브라우저가 발급자를 확인합니다
인증서는 일반적으로 다음 두 엔티티와 연관됩니다.
브라우저는 인증서가 발행자 필드는 제목 경로에서 이전 인증서의 필드 보안 강화를 위해 대부분 PKI 구현은 또한 발급자의 키가 현재 인증서에 서명 한 키와 동일한 지 확인합니다. (트러스트 앵커에는 해당되지 않습니다. 루트는 자체 발급되기 때문입니다. 즉, 동일한 발급자와 주체가 있습니다.)
제약 사항 처리
X.509 v3 형식을 사용하면 CA는 각 인증서의 유효성을 검사하고 중요한 확장명으로 사용하는 방법에 대한 제약 조건을 정의 할 수 있습니다. 경로의 모든 인증서는 모든 후속 인증서가 준수해야하는 추가 제약 조건을 부과 할 수 있습니다.
인증서 제약은 일반 인터넷 사용자에게 거의 영향을 미치지 않지만 엔터프라이즈 SSL 솔루션에서는 일반적입니다. 기능적 제약 조건은 여러 가지 운영 목적을 제공 할 수 있지만 가장 중요한 용도는 알려진 보안 문제를 완화하는 것입니다.
5. 브라우저는 이름 제약 조건을 확인합니다
적절한 개인 소유 (그러나 공개적으로 신뢰할 수있는) 중개 CA 이름 제약 조직에 인증서 관리 및 발급에 대한 세밀한 제어를 제공 할 수 있습니다. 인증서는 회사 또는 조직의 도메인 이름에 대한 특정 도메인 또는 도메인 트리 (예 : 하위 도메인 포함)로 제한 될 수 있습니다. 이름 제약 조건은 공개적으로 신뢰할 수있는 CA에서 구입 한 중간 CA 인증서에 자주 사용되어 중간 CA가 타사 도메인에 대해 완벽하게 유효한 인증서를 발급하지 못하도록합니다 (예 : google.com).
6. 브라우저는 정책 제약 조건을 확인합니다
인증서 정책은 인증서를 발급하고 관리하기 위해 따르는 절차를 공식적으로 설명하는 CA가 발행 한 법적 문서입니다. CA는 하나 이상의 정책에 따라 인증서를 발급 할 수 있으며 해당 인증서에 대한 링크는 발급 된 각 인증서에 포함되어 신뢰 당사자가 해당 인증서를 신뢰하기로 결정하기 전에 이러한 정책을 평가할 수 있습니다.
법적 및 운영상의 이유로 인증서는 적용 할 수있는 정책에 제한을 둘 수 있습니다. 인증서에 중요한 정책 제약 조건이 포함되어 있으면 브라우저는 계속하기 전에 인증서의 유효성을 검사해야합니다. 그러나 실제 정책에서는 중요한 정책 제약이 거의 발생하지 않으므로이 기사의 나머지 부분에서는 무시됩니다.
7. 브라우저는 기본 제약 조건 (일명 경로 길이)을 확인합니다.
X.509 v3 형식을 사용하면 발급자가 인증서가 지원할 수있는 최대 경로 길이를 정의 할 수 있습니다. 이를 통해 각 인증서를 인증 경로에 배치 할 수있는 거리를 제어 할 수 있습니다. 이것은 실제로 중요합니다. 2009 년에 연구원이 증명할 때까지 인증 경로 길이를 무시하는 데 사용되는 브라우저 프레젠테이션, 그는 자신의 웹 사이트의 리프 인증서를 사용하여 대규모 전자 상거래 웹 사이트에 대한 유효한 인증서를 위조 한 방법입니다.
8. 브라우저는 주요 사용법을 확인합니다
"키 사용"확장은 인증서에 포함 된 키의 용도를 나타냅니다. 이러한 목적의 예로는 암호화, 서명, 인증서 서명 등이 있습니다. 브라우저는 CRL 서명 전용 키가있는 서버 인증서를 발견하는 것과 같이 키 사용 제약 조건을 위반하는 인증서를 거부합니다.
9. 브라우저는 남아있는 모든 중요 확장명을 계속 처리합니다.
위에서 언급 한 확장을 처리 한 후 브라우저는 다음 단계로 이동하기 전에 현재 인증서가 중요로 지정한 나머지 모든 확장의 유효성을 검사합니다. 브라우저가 오류없이 경로의 리프 인증서에 도달하면 경로가 유효한 것으로 허용됩니다. 오류가 발생하면 경로가 유효하지 않은 것으로 표시되고 보안 연결이 설정되지 않습니다.
결론
World Wide Web은 상호 연결되고 끊임없이 진화하는 움직이는 부품의 복잡한 시스템입니다. 따라서 브라우저 보안은 해결 된 문제가 아니며이 기사가 여기에서 살펴본 구성 요소 하나의 복잡성에 대한 통찰력을 제공하기를 바랍니다. 신뢰는 온라인에서 귀하를 안전하게 유지하는 데 중요한 역할을하므로 CA의 인증서 정책에 대해 더 많이 문의하시기 바랍니다. (리뷰를 자유롭게 여기에 SSL.com의 정책, 사실로.)
SSL.com을 선택해 주셔서 감사합니다. 안전 인터넷은 더 인터넷.
