Mozilla는 문제가 있는 TLS 인증서를 확인하기 위해 CRLite를 구현합니다.

모질라 회사 발표했다. Firefox의 야간 빌드 테스트 시작에 대해 폐기된 인증서를 감지하는 새로운 메커니즘 - CRL라이트. CRLite를 사용하면 사용자 시스템에 호스팅된 데이터베이스에 대해 효과적인 인증서 해지 확인을 구성할 수 있습니다. Mozilla의 CRLite 구현 출판사 : 무료 MPL 2.0 라이센스에 따라. 데이터베이스 및 서버 구성 요소를 생성하는 코드는 다음과 같이 작성되었습니다. Python 그리고 가십시오. 데이터베이스에서 데이터를 읽기 위해 Firefox에 클라이언트 부분이 추가되었습니다. 준비된 러스트 언어로.

현재까지 사용되고 있는 프로토콜을 기반으로 외부 서비스를 이용한 인증서 검증 OCSP (온라인 인증서 상태 프로토콜)은 보장된 네트워크 액세스를 요구하고 요청 처리에 상당한 지연(평균 350ms)을 초래하며 기밀성 보장에 문제가 있습니다(요청에 응답하는 OCSP 서버는 특정 인증서에 대한 정보를 수신합니다. 이를 통해 인증서가 무엇인지 판단하는 데 사용할 수 있습니다). 사용자가 여는 사이트). 목록에 대한 로컬 검사도 가능합니다. C.R.L. (인증서 해지 목록), 그러나 이 방법의 단점은 다운로드한 데이터의 크기가 매우 크다는 것입니다. 현재 해지된 인증서 데이터베이스는 약 300MB를 차지하고 계속해서 증가하고 있습니다.

인증 기관에 의해 손상되거나 취소된 인증서를 차단하기 위해 Firefox는 2015년부터 중앙 집중식 블랙리스트를 사용해 왔습니다. 원CRL 서비스 요청과 함께 Google 안전 브라우징 가능한 악의적인 활동을 식별합니다. OneCRL, 좋아요 CRLS 세트 Chrome에서는 인증 기관의 CRL 목록을 집계하는 중간 링크 역할을 하며 폐기된 인증서를 확인하기 위한 단일 중앙 집중식 OCSP 서비스를 제공하므로 인증 기관에 직접 요청을 보내지 않을 수 있습니다. 온라인 인증서 확인 서비스의 신뢰성을 향상하기 위한 많은 노력에도 불구하고 원격 측정 데이터에 따르면 OCSP 요청의 7% 이상이 시간 초과되는 것으로 나타났습니다(몇 년 전 이 수치는 15%였습니다).

기본적으로 OCSP를 통해 확인할 수 없는 경우 브라우저는 인증서가 유효한 것으로 간주합니다. 네트워크 문제 및 내부 네트워크 제한으로 인해 서비스를 사용할 수 없거나 공격자에 의해 차단될 수 있습니다. MITM 공격 중 OCSP 검사를 우회하려면 간단히 검사 서비스에 대한 액세스를 차단하면 됩니다. 이러한 공격을 부분적으로 방지하기 위해 기술이 구현되었습니다. 필수품를 사용하면 OCSP 액세스 오류 또는 OCSP 비가용성을 인증서 문제로 처리할 수 있지만 이 기능은 선택 사항이며 인증서를 특별하게 등록해야 합니다.

CRLite를 사용하면 해지된 모든 인증서에 대한 전체 정보를 쉽게 업데이트할 수 있는 구조(크기가 1MB에 불과)로 통합할 수 있으므로 클라이언트 측에 전체 CRL 데이터베이스를 저장할 수 있습니다.
브라우저는 폐기된 인증서에 대한 데이터 사본을 매일 동기화할 수 있으며 이 데이터베이스는 어떤 조건에서도 사용할 수 있습니다.

CRLite는 다음의 정보를 결합합니다. 인증서 투명성, 발급 및 취소된 모든 인증서의 공개 로그, 인터넷에서 인증서 검색 결과(다양한 인증 기관의 CRL 목록이 수집되고 알려진 모든 인증서에 대한 정보가 집계됩니다). 데이터는 캐스케이딩을 사용하여 패키징됩니다. 블룸 필터, 누락된 요소의 잘못된 감지를 허용하지만 기존 요소의 누락을 제외하는 확률적 구조입니다(즉, 특정 확률로 올바른 인증서에 대한 거짓 긍정이 가능하지만 해지된 인증서는 식별이 보장됩니다).

잘못된 긍정을 제거하기 위해 CRLite는 추가 수정 필터 수준을 도입했습니다. 구조를 생성한 후 모든 소스 레코드를 검색하고 잘못된 긍정을 식별합니다. 이 검사 결과에 따라 추가 구조가 생성되어 첫 번째 구조에 계단식으로 연결되고 결과로 발생한 잘못된 긍정을 수정합니다. 제어 점검 중 잘못된 긍정이 완전히 제거될 때까지 작업이 반복됩니다. 일반적으로 모든 데이터를 완전히 포함하려면 7~10개의 레이어를 만드는 것으로 충분합니다. 주기적인 동기화로 인해 데이터베이스 상태가 현재 CRL 상태보다 약간 뒤처지기 때문에 CRLite 데이터베이스의 마지막 업데이트 이후에 발급된 새 인증서 확인은 OCSP 프로토콜을 사용하여 수행됩니다. OCSP 스테이플 링 (인증기관에서 인증한 OCSP 응답은 TLS 연결 협상 시 사이트를 서비스하는 서버에서 전송됩니다.)

Bloom 필터를 사용하여 100억 개의 활성 인증서와 750만 개의 취소된 인증서를 포함하는 WebPKI의 1.3월 정보 조각을 16MB 크기의 구조로 압축할 수 있었습니다. 구조 생성 프로세스는 리소스 집약적이지만 Mozilla 서버에서 수행되며 사용자에게 미리 만들어진 업데이트가 제공됩니다. 예를 들어 바이너리 형태로 생성 시 사용되는 원본 데이터를 Redis DBMS에 저장할 경우 약 6.7GB의 메모리가 필요하며, 40진수 형태로 하면 모든 인증서 일련번호를 덤프하는 데 약 20GB가 필요합니다. 해지된 인증서와 활성 인증서를 모두 집계하는 프로세스에는 약 XNUMX분이 소요되며, Bloom 필터를 기반으로 패키지 구조를 생성하는 프로세스에는 추가로 XNUMX분이 소요됩니다.

Mozilla는 현재 CRLite 데이터베이스가 하루에 4번 업데이트되도록 하고 있습니다(모든 업데이트가 클라이언트에 전달되는 것은 아닙니다). 델타 업데이트 생성은 아직 구현되지 않았습니다. 릴리스에 대한 델타 업데이트를 생성하는 데 사용되는 bsdiffXNUMX를 사용하면 CRLite에 적절한 효율성을 제공하지 않으며 업데이트가 비합리적으로 큽니다. 이러한 단점을 제거하기 위해 스토리지 구조의 형식을 재작업하여 불필요한 레이어 재구축 및 삭제를 제거할 계획입니다.

CRLite는 현재 Firefox의 수동 모드에서 작동하며 OCSP와 병렬로 사용되어 올바른 작업에 대한 통계를 축적합니다. CRLite는 메인 스캔 모드로 전환할 수 있으며, 이를 위해서는 about:config에서 security.pki.crlite_mode = 2 매개변수를 설정해야 합니다.

출처 : opennet.ru