it-swarm-korea.com

CA가 해킹되는 것이 얼마나 가능합니까? 어떤 기본 신뢰할 수있는 루트 인증서를 제거해야합니까?

이 질문은 원본 버전 이후 크게 수정되었습니다.

신뢰할 수있는 루트 저장소에서 각 신뢰할 수있는 인증서를 보면 얼마나 신뢰해야합니까?

로컬 저장소에서 잠재적으로 제거 될 수있는 각 루트 CA의 신뢰를 평가할 때 고려해야 할 요소는 무엇입니까?

추가 정보 :
CA가 잘못 검증 된 당사자에게 인증서를 발급하면 해당 CA를 신뢰하는 모든 컴퓨터가 MITM 공격에 취약합니다. 결과적으로 모든 CA는 주어진 SSL 인증서 요청의 요청자를 엄격하게 검증하여 CS 체인의 무결성을 보장합니다.

그러나이 CA 확인 프로세스의 많은 부분은 사람의 개입을받으며 잘못된 사람에게 인증서를 발급 할 수있는 기회를 제공합니다. 이것은 CA 운영자 오류, 정부 요구 또는 CA 운영자의 강제 (뇌물)에 의해 수행 될 수 있습니다.

어떤 기본 CA가 잘못된 당사자에게 인증서를 발행 할 가능성이 높은지에 대해 자세히 알고 싶습니다. 이 정보를 사용하여 신뢰할 수있는 인증서 저장소에서 해당 CA를 제거하도록 사용자에게 조언하려고합니다.

예 :
특정 CA를 통제하는 정부에 Microsoft.com의 신원을 가정하고 CA의 검증 프로세스에 대한 예외를 요구한다고 제안합니다. 그런 다음 정부는이 예외의 비밀을 유지해야합니다. 그런 다음 생성 된 키 페어는 MITM 공격에 사용됩니다.

Windows Azure 기본 트러스트

Windows Azure는 다음 링크 에 표시된대로 275 개의 CA를 지원합니다. 특정 CA의 사용에 따라 일부 CA는 특정 공격의 노출 영역을 증가시킬 수 있습니다. 실제로 일부 응용 프로그램이 올바르게 작동하려면 기술적으로 필요할 수 있습니다.

아마존 기본 트러스트

(사용할 수 없음) Amazon, Google 및 VMWare의 기본 CA 목록으로 연결되는 링크를 공유하십시오.

모질라

모든 인증서 및 감사 설명 목록 을 사용할 수 있습니다.

Apple iOS

이 # WWDC2017. video 에서 언급 한 모든 iPhone 루트 인증서 목록

84
goodguys_activate

Update 5 CA 모델의 근본 문제 (heh)는 일반적으로 모든 CA가 모든 도메인에 대해 인증서를 발급 할 수 있으므로 취약하다는 것입니다 가장 약한 연결로. 당신이 믿을 수있는 사람에 관해서는, 말뚝이 높고 보안이 어렵 기 때문에 목록이 매우 길다는 것을 의심합니다. 이 주제에 대한 Christopher Soghoian의 게시물을 추천합니다. 클라우드 서비스를 운영하는 회사, 도청 또는 점점 더 CA 강제를 통해 클라우드 서비스를 운영하는 회사에서 직접 요구하는 방식에 관계없이 전 세계 정부가 개인 사용자 데이터에 액세스하는 데 사용한 다양한 접근 방식을 설명합니다. 또는 핵 : 약간 편집증 : DigiNotar 핵을 일으킨 힘 .

여기서는 몇 가지 세부 사항을 제공하고 일부 잠재적 수정 사항에 대한 링크로 끝납니다.

2009 년, Etisalat (아랍 에미리트 정부 소유의 60 %)는 스파이웨어를 RIM 장치에 삽입하여 전자 메일을 모니터링 할 수있는 무해한 BlackBerry 패치를 출시하여 전자 메일을 모니터링 할 수 없었습니다. 그러나 신뢰할 수있는 많은 CA 목록에 있습니다 : http://arstechnica.com/business/news/2009/07/mobile-carrier-rolls-out-spyware-as-a-3g-update.ars

Update 1 Comodo에 대한 ComodoHacker 라는이란의 성공적인 공격 사례도 참조하십시오 : 불량 SSL 인증서 ( "case comodogate")-F-Secure Weblog . F-Secure는 Mozilla에 중국, 이스라엘, 버뮤다, 남아프리카, 에스토니아, 루마니아, 슬로바키아, 스페인, 노르웨이, 콜롬비아, 프랑스, ​​대만, 영국, 네덜란드, 터키, 미국, 홍콩, 일본의 CA에서 발급 한 인증서가 포함되어 있다고 언급했습니다. , 헝가리, 독일 및 스위스.

튀니지는 널리 신뢰받는 CA를 운영하는 또 다른 국가이며 프라이버시를 침해하는 정부의 조치에 대한 훌륭한 문서도 있습니다. 페이스 북이 튀니지 해킹에 어떻게 대응했는지에 대한 내부 이야기-Alexis Madrigal-기술-대서양

모질라는 또 다른 의심스러운 관행을 지적합니다. RA 파트너가 중개자가 아닌 루트에서 직접 인증서를 발급 할 수 있도록하는 CA : Comodo Certificate Issue – Follow Up at Mozilla Security Blog .
고독한이란 해커의 책임 주장에 대한 추측을 포함하여 자세한 내용도 참조하십시오. 웹 브라우저 및 Comodo, 성공적인 인증 기관 공격 공개,이란에서 자유에 이르기까지

업데이트 3 : ComodoHacker의 또 다른 성공적인 공격은 DigiNotar CA에 대한 것입니다. 그들의 웹 사이트는 2009 년부터 타협되었지만 2011 년에이란 인이 DigiNotar를 사용하여 Google, Yahoo !, Mozilla, WordPress 및 Tor 프로젝트 DigiNotar는 한 달 이상 사이트 침입에 대한 지식을 밝히지 않았습니다 DigiNotar Hack은 SSL 웹 보안 모델의 심각한 실패를 강조합니다. Freedom to Tinker 를 참조하십시오.

다양한 CA의 취약성 범위는 유틸리티와 마찬가지로 매우 다양합니다. 따라서 전략을 다시 세우는 것이 좋습니다. 보호하려는 특정 자산으로 범위를 좁힐 수 있으면 해당 자산 사용에 필요한 CA를 제외한 모든 CA를 삭제하십시오. 그렇지 않으면 공격 영역을 줄이기 위해 자산에 관심이 있거나 가장 인기가 적은 사람들에게 가장 취약하다고 판단되는 CA를 제거하는 것이 좋습니다. 그러나 가장 대중적이고 신중한 CA에 대해서도 정교한 공격에 취약하다는 사실을 인정하십시오.

업데이트 2 : Freedom to Tinker에서 위험한 CA 인프라를 수정하는 것에 대한 훌륭한 글이 있습니다 : 더 나은 CA 인프라 구축

다음과 같은 혁신에 대해 이야기합니다.

업데이트 4 2011 년 8 월 IT 보안 블로그 게시물 중 하나는 DNSSEC로 전환하는 경우도 다루고 있습니다. 고정의 위험 기반보고 인증 기관 문제"스택 교환 보안 블로그

업데이트 6 여러 인증 기관이 규칙을 위반하는 데 걸렸습니다. 여기에는 프랑스 사이버 방어 기관 (ANSSI)과 Trustwave가 포함되며 각각은 디지털 인증서의 스푸핑에 연결됨 입니다.

업데이트 7 2014 년 인도 인증 기관 컨트롤러 (인도 CCA)를 통한 또 다른 "실수 된 인증서"세트 : Google Online Security 블로그 : 디지털 인증서 보안 유지 관리

잘못된 인증서 및 정책 위반을 조기에 발견하는 데 도움이되는 인증서 투명성 에 대한 질문도 참조하십시오.

64
nealmcb

Matt Blaze가 한 번 썼 듯이, CA는 돈을 받고 싶지 않은 사람으로부터 당신을 보호합니다. CA의 인센티브가 어디에 있는지, 그리고 계약에 잠재적 인 위험이 무엇인지 알려줄 것입니다.

38
D.W.

이 질문에 대한 짧은 대답은 내가 볼 수있는 한 알 수 없다는 것입니다. 가장 일반적인 브라우저에는 많은 기본 CA가 설치되어 있으며 정부 또는 다른 조직에 인증서를 제공하는 관점에서 "신뢰할 수있는"가능성을 평가하는 것이 어렵습니다.

CA가 신뢰할 수없는 것으로 알려진 경우 브라우저 기본 설치 목록에서 제거 될 수 있습니다 (아래 @xce에 따라 Diginotar는 여기에서 좋은 예입니다).

자발적으로 인증서를 제공하는 조직 외에도 요청자에 대한 적절한 보안 검사를 수행하지 않고 인증서를 제공 할 위험이 있습니다. 몇 년 전 Defcon에서 인증없이 인증서를 얻을 수 있다는 주제에 대한 여러 프레젠테이션이있었습니다.

이것이 중요한 관심사 인 경우, 내가 생각할 수있는 유일한 방법은 검토하고 제공된 보안에 익숙한 CA 목록을 작성하는 것입니다. 분명히 사용하려는 사이트에 대해 인증서를 발급 한 CA를 제거 할 수 있으므로 일반 인터넷에 액세스하는 데는 효과가 없습니다.

18
Rory McCune

모든 CA는 자신의 키를 보호하고 인증서를 발급하기 전에 인증서 요청의 유효성을 검사하는 방법을 설명하는 인증서 연습 서를 게시합니다. 이 문서의 위치에 대한 URL은 일반적으로 CA에서 발급 한 각 인증서에 포함됩니다. 문제의 CA가 실제로이 정책 문서를 따른다고 가정하면 인증서를 요청하는 엔티티의 유효성을 확인하기 위해 필요한 길이를 표시해야합니다. 하드웨어 보안 모듈 또는 암호화 모듈을 사용하여 서명 키를 보호하기위한 다중 요소 인증 및 쿼럼 기반 권한 부여 등을 사용하여 CA 서명 키를 보호하는 효과에 대한 설명을 찾으십시오. 이러한 보호 방법은 훨씬 더 어렵고 비용이 많이 듭니다. 불량 제 3자가 서명 키를 훔칠 수 있습니다.

신뢰할 수있는 CA (내 Mac 시스템 루트 키 체인에는 175 개)의 거대한 목록이 있으며 이러한 질문을하지 않는 지구상의 모든 사용자와 HTTPS 시스템을 사용할 수 있도록 편의를 제공합니다. 물론 자신의 관행을 개인적으로 감사하지 않는 한이 목록에서 모든 CA를 쫓아 낼 수 있습니다. 모든 엔드 포인트를 제어하고 제한된 수의 신뢰할 수있는 당사자가있는 폐쇄 시스템의 경우 가능합니다. Subversion 버전 관리 시스템에는 신뢰할 수있는 루트 인증서가 포함되어 있지 않지만 모든 클라이언트에 자신의 인증서를 추가 할 수 있습니다. 웹을 전체적으로 사용할 수있는 것으로 밝혀진 유일한 방법은 대역 외 신뢰할 수있는 당사자 (운영 체제 또는 브라우저를 제공하는 회사)에 대해 신뢰할 수있는 목록을 제공하는 것입니다. 전 세계 거의 모든 SSL 지원 서버에 연결할 수있는 인증서.

신뢰할 수있는 목록에 해당 인증서가 모두 필요합니까? 아마 아닙니다. 그러나 OS/브라우저 공급 업체는 비즈니스를 수행하려는 사람을 예상 할 수 없으며 통제해서는 안됩니다. 큰 목록의 문제점은 모든 관할 구역에서 모든 종류의 검증 방법을 사용하여 모든 깃털의 CA를 정확히 동일하게 취급한다는 것입니다. 모든 CA가 동일하게 작동하는 것은 아닙니다. 리셀러 로그인 자격 증명이 손상되고 심지어 CA 키가 손상된 경우도 확인했습니다. 일부 CA는 설립 증명서와 born 아의 약속이 필요한 반면, 다른 CA는 인증서를 요청하는 도메인에서 전자 메일을받을 수 있는지 확인하기 만합니다. 그러나 각 CA는 브라우저에서 동일하게 취급됩니다.

동일한 공통 이름에 대한 악의적 인 인증서에 대한 방어선은 클라이언트에 원래 인증서를 캐시하는 것입니다. 다른 CA의 다른 인증서가 갑자기 나타나는 경우 이는 우려 할만한 원인이됩니다. 오늘의 브라우저가이 사례를 어떻게 다루는 지 모르겠습니다. 알아볼 수 없습니다.

9
Sander Temme

이런 종류의 토론은 항상 이 Mozilla 버그 새 CA의 포함을 요청한다는 것을 상기시킵니다. 꽤 재밌지 만 통찰력이 있습니다.

4
Steve Dispensa

Windows PC에서 제거 할 인증서를 조사 할 때는 먼저 시스템에 필요한 인증서를 제거하지 않아야합니다. 이렇게하면 다음과 같은 오류 메시지가 나타납니다.

error- you're deleting a system cert!!

이것은 Windows 시스템에서 절대로 삭제해서는 안되는 인증서 목록이있는 URL입니다. http://support.Microsoft.com/?id=293781

다음으로 중간 인증서는 " 순전히 레거시 이유로 "만 있기 때문에 제거 (제거 테스트)를 고려해야합니다.

나머지 모든 인증서의 제거를 평가할 때 Microsoft Root Certificate Program 은 CA가 다음 감사 표준 중 하나를 통과해야한다는 것을 고려하십시오.

  • ETSI 102 042
  • ETSI 101456
  • CA를위한 WebTrust
  • WebTrust EV 준비 감사
  • ISO 21188 (ISO 27001을 허용하지 않음에 유의)

MSFT 이외의 브라우저 (IE)에서 인증서를 제거하는 경우 이 CA 품질 지침 검토 를 원할 수 있습니다.

제한

이 프로그램에는 주요 사용법에 적용되는 추가 감사가 있습니다. 키 사용법은 다음으로 제한됩니다.

  • 서버 인증 (SSL) = 1.3.6.1.5.5.7.3.1

  • 클라이언트 인증 (SSL) = 1.3.6.1.5.5.7.3.2

  • 보안 이메일 (SMIME) EKU = 1.3.6.1.5.5.7.3.4

  • 코드 서명 EKU = 1.3.6.1.5.5.7.3.3

  • 타임 스탬프 EKU = 1.3.6.1.5.5.7.3.8

  • OCSP EKU = 1.3.6.1.5.5.7.3.9

  • 파일 시스템 암호화 EKU = 1.3.6.1.4.1.311.10.3.4

  • IPSec (터널, 사용자) EKU = 1.3.6.1.5.5.7.3.6, 1.3.6.1.5.5.7.3.7

금지 된 키 사용법

다음 키 사용은 프로그램에 의해 금지됩니다.

  • 스마트 카드 로그온 Active Directory 배포가 필요하고 루트를 Active Directory의 NTAuth 저장소에 추가해야하기 때문에 엔터프라이즈 전용 시나리오입니다. 자세한 내용은 다음 KB 기사를 참조하십시오. http://support.Microsoft.com/default.aspx?scid=kb;en-us;Q281245

  • 디지털 권리이 EKU는 더 이상 사용되지 않습니다. Windows Media DRM은 자체 XML 형식의 라이센스를 사용하며 X.509를 사용하지 않습니다.

  • 한정된 종속이 EKU는 더 이상 사용되지 않으며 Windows에서 무시됩니다.

  • 키 복구 엔터프라이즈 CA 시나리오.

  • 파일 복구이 EKU는 더 이상 사용되지 않으며 Windows EFS (Encrypting File System)에서 무시됩니다.

  • 모든 응용 프로그램 정책 "모든 사용"을 허용 할 수는 없습니다. 이는 엔터프라이즈 전용 및 기타 허용되지 않는 EKU를 반드시 인정하기 때문입니다.

  • 디렉토리 서비스 이메일 복제 엔터프라이즈 시나리오

  • 인증서 요청 에이전트

  • 엔터프라이즈 CA 시나리오

  • 키 복구 에이전트 엔터프라이즈 CA 시나리오

  • CA 암호화 인증서

  • 엔터프라이즈 CA 시나리오

수용 기준

또한 루트에 일반 목적 또는 정부 CA를 추가하기 전에 다음 기준을 충족해야합니다.

  1. CA는 아래에 요청 된 정보를 제공하고 ( 1 단계. Microsoft에 문의 참조) 프로그램 회원 자격에 대한 예비 승인을 받아야합니다.

  2. CA는 테스트 목적으로 CA의 루트 인증서에서 발급 된 테스트 인증서를 제공해야합니다. 선택적으로 CA는 루트 인증서에서 발급 된 인증서를 확인할 수있는 공개적으로 액세스 가능한 서버의 URL을 Microsoft에 제공 할 수 있습니다. (자세한 내용은 FAQ 참조)

  3. CA는 Microsoft CA 계약을 완료해야합니다. 계약은 신청 절차의 1 단계를 완료하고 신청에 대한 예비 승인을받은 후에 만 ​​제공됩니다.

  4. 루트 인증서는 아래 기술 요구 사항 섹션을 준수해야합니다. 특히 모든 루트 및 모든 발급 CA에 대해 RSA 2048 비트 모듈러스의 최소 암호화 키 크기가 필요합니다. Microsoft는 더 이상 RSA 1024 비트 모듈러스가 만료 된 루트 인증서를 허용하지 않습니다. 새로운 루트는 제출 날짜로부터 최소 8 년 동안 유효하지만 특히 2048 비트 RSA 계수가있는 경우 2030 년 전에 만료되는 것이 좋습니다.

  5. 루트 인증서에서 발급 된 인증서는 CRL 배포 지점 확장을 지원해야합니다. CRL 배포 지점은 공개적으로 액세스 할 수있는 위치를 가리켜 야합니다.

  6. CA에는 문서화 된 해지 정책이 있어야하며 CA는 발급 한 인증서를 해지 할 수 있어야합니다.

  7. CA는 감사를 완료하고 12 개월마다 Microsoft에 감사 결과를 제출해야합니다. 감사는 EKU (확장 키 사용) 할당을 통해 Microsoft가 활성화 할 전체 PKI 계층을 포함해야합니다. 우리가 사용하는 모든 인증서 사용은 정기적으로 감사되어야합니다. 감사 보고서는 감사가 적용되는 특정 유형의 인증서를 발행하는 하위 CA를 포함하여 PKI 계층의 전체 범위를 문서화해야합니다. 적격 감사에는 다음이 포함됩니다.

현재 비정부 CA에 대해 승인 된 감사입니다. 우리는 위에 나열된 감사를 변경하거나 향후 다른 유사한 감사를 수락 할 권리가 있습니다.

기술 요구 사항

새 루트 인증서는 다음 기술 요구 사항을 충족해야합니다.

  • 루트 인증서는 x.509 v3 인증서 여야합니다.

  • 주체 이름에는 의미있는 CA 이름이 포함되어야합니다 (예 : "Root"또는 "CA1"일 수 없음)

  • 기본 구속 조건 확장 : cA = true

  • 키 사용법 (있는 경우) : keyCertSign 및 cRLSign 만

  • 루트 키 크기 요구 사항은 NIST SP 800-57 :

         RSA greater or equal to 2048-bit modulus
    
         ECC greater or equal to P256 modulus
    
  • 해시 알고리즘은 SHA1 이상이어야합니다. MD2, MD4 또는 MD5 해시가 허용되지 않습니다.

  • 루트 키 크기가 RSA 2048 비트 계수보다 크거나 같은 경우, 루트 인증서는 제출 후 8 년 이상 2030 년까지 만료되지 않아야합니다. 더 긴 만료는 더 큰 루트 키 크기로 제공 될 수 있습니다.

  • 중간 CA 인증서는 루트 CA 프로그램에서 제외됩니다 (자세한 내용은 자주 묻는 질문 참조).

  • CA는 2009 년 1 월 15 일부터 본 프로그램에 의해 배포 된 루트 인증서에서 MD2, MD4 또는 MD5 하위 또는 최종 엔터티 인증서를 발급하지 않습니다.

  • 기존 ( "레거시") 1024 비트 RSA 루트 인증서는 Microsoft에서 제공 한 경우를 제외하고 2010 년 12 월 31 일 NIST 마감일까지 프로그램에 의해 배포 된 상태로 유지 될 수 있습니다.

  • CA는 2010 년 12 월 31 일 NIST 마감일까지 본 프로그램이 배포 한 루트 인증서에서 1024 비트 RSA 인증서를 발급 할 수 있습니다.

3

저는 미국 정부가 몇 년 전에 법안을 통과시켜 CA가 도청을위한 유효한 타사 인증서를 생성 할 수있는 권리를 부여했다고 생각합니다. 나는 이것에 대한 증거를 찾을 수 없었기 때문에 Rory가 언급 한 DefCon 회담의 내용을 기억하고 있을지도 모른다.

3
Steve

일부 나쁜 정부가 기계의 SSL 트래픽을 보길 원한다고 가정하십시오. 기본 CA를 새 인증서 발급으로 강제 적용하는 것은 얼마나 가능합니까?

술어와 질문은 관련이 없습니다. CA가 새 인증서를 발급하는 것이 얼마나 쉬운 지 또는 자주 문제가되지는 않습니다. 도청자가 이미 설치 한 인증서의 개인 키를 가지고 있지 않으면 도청자가 데이터를 볼 수 없습니다. IIRC (그러나 이것을 확인하는 것이 좋습니다) CSR에는 개인 키가 포함되어 있지 않으므로 CA는 그렇게 할 수 없습니다. 컴퓨터에서 사용하는 키를 변경할 수 없습니다.

그러나 불량 CA가 위조 된 인증서를 발급 할 수 있으며 사이트에 MITM 공격이 발생할 가능성이 있습니다. MD5 형식 및 Etisalat의 최근 문제는 불가능하지 않다고 제안합니다.

3
symcbean

두 번째 질문에 집중하려고합니다.

"어떤 기본 신뢰할 수있는 루트 인증서를 제거해야합니까?" 당신이 누구를 상대하는지에 따라 다릅니다.

연결하는 웹 사이트에 서명하는 모든 CA를 "신뢰"해야합니다.

항상 같은 소수의 사이트를 방문하는 할머니 유형 사용자의 경우 소수의 CA만으로 충분할 수 있지만 인터넷 사용자가 많을수록 목록이 그렇게 빨리 증가하지는 않습니다.

빠르지 않은 ? 반 직관적으로, 일부 CA는 너무 많이 사용되지 않는 CA를 포함하여 많이 사용되는 반면 다른 CA는 거의 지리학 적으로 사용되는 인터넷과 같은 인터넷에서는 거의 사용되지 않습니다.

SSLCop from securitybydefault 도구는 신뢰할 수없는 국가에서 차단하는 데 도움이 될 수 있습니다. 해당 CA의 기본 사용자 인 경우) : http://www.security-projects.com/?SSLCop

그러나 너무 많은 CA를 신뢰하지 않으면 사용자가 필요로하는 웹 사이트에 대한 신뢰 앵커를 얻지 못하게됩니다 (그리고 그 사용자 will ). 어쨌든 보안 경고에도 불구하고) 똑같이 나쁩니다.

1
Ángel

MD5 취약점을 사용하여 불량 CA를 생성하는 데모 :

1
Bradley Kreider

2012 년 6 월 12 일부터 Microsoft는 신뢰할 수없는 루트 인증서 및 Microsoft에 신뢰할 수없는 것으로보고 된 다른 인증서를 비활성화하는 새로운 업데이터를 출시했습니다.

이 업데이트는 여기에서 구할 수 있으며이 업데이트가 Windows 업데이트를 통해 이미 배포되었는지 아니면 업데이트가 아닌지 확실하지 않습니다.

http://support.Microsoft.com/kb/267707

0