참고 : 나는 원래의 답변을 매우 성급하게 작성했지만 그 이후로 상당히 인기있는 질문 / 답변으로 바뀌 었으므로 조금 확장하고 더 정확하게 만들었습니다.
TLS 기능
"SSL"은이 프로토콜을 나타내는 데 가장 자주 사용되는 이름이지만 SSL은 90 년대 중반 Netscape가 설계 한 독점 프로토콜을 나타냅니다. "TLS"는 SSL을 기반으로하는 IETF 표준이므로 TLS를 사용하겠습니다. 요즘 웹의 거의 모든 보안 연결이 실제로 SSL이 아닌 TLS를 사용하고있을 가능성이 높습니다.
TLS에는 몇 가지 기능이 있습니다.
- 응용 프로그램 계층 데이터를 암호화하십시오. (귀하의 경우 응용 프로그램 계층 프로토콜은 HTTP입니다.)
- 서버를 클라이언트에 인증하십시오.
- 클라이언트를 서버에 인증하십시오.
# 1과 # 2는 매우 일반적입니다. # 3은 덜 일반적입니다. 당신은 # 2에 집중하고있는 것 같습니다. 그래서 그 부분을 설명하겠습니다.
입증
서버는 인증서를 사용하여 클라이언트에 자신을 인증합니다. 인증서는 웹 사이트에 대한 정보를 포함하는 데이터 블랍 [1]입니다.
- 도메인 이름
- 공개 키
- 그것을 소유 한 회사
- 발행되었을 때
- 만료되면
- 누가 발행
- 기타.
인증서에 포함 된 공개 키를 사용하여 해당 개인 키로 만 해독 할 수있는 메시지를 암호화하여 해당 서버에 안전하게 저장해야 기밀성을 확보 할 수 있습니다. [2] 이 키 페어 KP1을 호출하여 나중에 혼동하지 않도록합시다. 인증서의 도메인 이름이 방문하는 사이트 (위의 2 번)와 일치하는지 확인할 수도 있습니다.
그러나 공격자가 서버와주고받는 패킷을 수정할 수 있다면, 공격자가 제시 한 인증서를 수정하고 자신의 공개 키를 삽입했거나 다른 중요한 세부 정보를 변경 한 경우 어떻게해야합니까? 이 경우 공격자는 안전하게 암호화되었다고 생각되는 모든 메시지를 가로 채서 수정할 수 있습니다.
이러한 공격을 막기 위해 인증서는 해당 공개 키를 가진 사람이 서명을 확인할 수있는 방식으로 다른 사람의 개인 키로 암호화되어 서명됩니다. 이 키 페어 KP2를 호출하여 서버와 동일한 키가 아님을 분명히하자.
인증 기관
누가 KP2를 만들었습니까? 인증서에 누가 서명 했습니까?
인증 기관 이 조금 단순화하면 KP2가 생성되며 개인 키를 사용하여 다른 조직의 인증서에 서명하는 서비스를 판매합니다. 예를 들어 인증서를 만들고 Verisign과 같은 회사에 개인 키로 서명하도록 비용을 지불합니다. [3] Verisign 외에 아무도이 개인 키에 액세스 할 수 없으므로이 서명을 위조 할 수 없습니다.
그리고 그 서명을 확인하기 위해 KP2의 공개 키를 어떻게 개인적으로 얻을 수 있습니까?
우리는 이미 인증서가 공개 키를 보유 할 수 있고 컴퓨터 과학자들은 재귀를 좋아한다는 것을 이미 알고 있습니다. 그렇다면 KP2 공개 키를 인증서에 넣어서 배포하는 것은 어떻습니까? 처음에는 약간 미친 소리로 들리지만 실제로는 정확히 작동합니다. Verisign 예제를 계속하여 Verisign은 자신이 누구인지, 서명 할 수있는 유형 (기타 인증서) 및 공개 키에 대한 정보를 포함하는 인증서를 생성합니다.
이제 해당 Verisign 인증서 사본이 있으면이를 사용하여 방문하려는 웹 사이트의 서버 인증서에서 서명의 유효성을 검사 할 수 있습니다. 쉬운가요?!
글쎄요. 나는 어딘가 에서 Verisign 인증서를 얻어야했다 . 누군가가 Verisign 인증서를 스푸핑하고 자체 공개 키를 거기에 넣으면 어떻게됩니까? 그런 다음 서버 인증서에서 서명을 위조 할 수 있으며, 우리가 시작했던 바로 중간자 공격입니다.
인증서 체인
재귀 적으로 생각하기 위해 우리는 물론 세 번째 인증서와 세 번째 키 페어 (KP3)를 소개하고이를 사용하여 Verisign 인증서에 서명 할 수 있습니다. 이를 인증서 체인이라고합니다. 체인의 각 인증서는 다음 인증서를 확인하는 데 사용됩니다. 이 재귀 접근 방식이 거북 / 인증서라는 것을 이미 알 수 있기를 바랍니다. 어디서 멈춰요?
우리는 무한한 수의 인증서를 만들 수 없기 때문에 인증서 체인은 분명히 어딘가 에서 중지 해야하며 자체 서명 된 체인에 인증서를 포함시켜 수행됩니다 .
나는 당신이 당신의 머리 폭발에서 뇌 물질 조각을 집어 들으면 잠시 잠시 멈출 것입니다. 자기 서명?!
예, 인증서 체인의 끝 부분 ( "루트")에는 자체 키 쌍을 사용하여 자체 서명하는 인증서가 있습니다. 이렇게하면 무한 재귀 문제는 제거되지만 인증 문제는 해결되지 않습니다. 정치, 이론 물리학을 전공하고 엉덩이를 걷어차는 것을 삼중이라고 말하고 맨 아래에 내 이름을 서명하는 가짜 프린스턴 졸업장을 만들 수있는 것처럼 누구나 자체 서명 인증서를 만들 수 있습니다.
이 문제에 대한 [언젠가 흥분되지 않은] 해결책은 명시 적으로 신뢰하는 자체 서명 된 인증서 세트를 선택하는 것입니다. 예를 들어 " 이 Verisign 자체 서명 인증서를 신뢰 합니다." 라고 말할 수 있습니다 .
이러한 명시적인 신뢰를 바탕으로 전체 인증서 체인의 유효성을 검사 할 수 있습니다. 체인에 몇 개의 인증서가 있더라도 루트까지 각 서명의 유효성을 검사 할 수 있습니다. 루트에 도달하면 해당 루트 인증서가 내가 명시 적으로 신뢰하는 인증서인지 확인할 수 있습니다. 그렇다면 전체 체인을 신뢰할 수 있습니다.
부여 된 신뢰
TLS의 인증은 부여 된 신뢰 시스템을 사용합니다 . 자동차 정비사를 고용하고 싶다면 내가 찾은 임의의 정비사를 신뢰하지 않을 수 있습니다. 그러나 내 친구가 특정 기계공을 보증합니다. 친구를 믿기 때문에 그 기계공을 믿을 수 있습니다.
컴퓨터를 구매하거나 브라우저를 다운로드 할 때 명시 적으로 신뢰하는 수백 개의 루트 인증서가 제공됩니다. [4] 해당 인증서를 소유하고 운영하는 회사는 인증서에 서명하여 다른 조직에 신뢰를 부여 할 수 있습니다.
이것은 완벽한 시스템과는 거리가 멀다. 때때로 CA가 인증서를 잘못 발행 할 수 있습니다. 이 경우 인증서를 해지해야 할 수도 있습니다. 발급 된 인증서는 항상 암호화 적으로 정확하기 때문에 해지하기가 까다 롭습니다. 이전에 유효한 인증서 중 어느 것이 취소되었는지 확인하려면 대역 외 프로토콜이 필요합니다. 실제로 이러한 프로토콜 중 일부는 안전하지 않으며 많은 브라우저가이를 확인하지 않습니다.
때때로 전체 CA가 손상 될 수 있습니다. 예를 들어, Verisign에 침입하여 루트 서명 키를 훔치는 경우 세계의 모든 인증서를 스푸핑 할 수 있습니다. 이는 Verisign 고객에게만 영향을 미치지 않습니다. 내 인증서가 Thawte (Verisign의 경쟁 업체)에 의해 서명 된 경우에도 중요하지 않습니다. Verisign의 손상된 서명 키를 사용하여 인증서를 위조 할 수 있습니다.
이것은 단지 이론적 인 것이 아닙니다. 야생에서 일어났다. DigiNotar는 유명하게 해킹 되어 파산했습니다. 코모도는 해킹 당 했지만, 오늘날까지도 사업을 계속하고있다.
CA가 직접 손상되지 않더라도이 시스템에는 다른 위협이 있습니다. 예를 들어, 정부는 법적 강제를 사용하여 위조 된 인증서에 서명하도록 CA를 강요합니다. 고용주는 직원 컴퓨터에 자체 CA 인증서를 설치할 수 있습니다. 이러한 다양한 경우에 "안전한"것으로 예상되는 트래픽은 실제로 해당 인증서를 제어하는 조직에 완전히 표시 / 수정 가능합니다.
Convergence , TACK 및 DANE를 포함한 일부 대체품이 제안되었습니다 .
미주
[1] TLS 인증서 데이터는 X.509 표준 에 따라 형식이 지정됩니다 . X.509는 ASN.1 ( "Abstract Syntax Notation # 1")을 기반으로 하며 이진 데이터 형식 이 아님 을 의미 합니다. 따라서 X.509는 이진 형식 으로 인코딩 해야 합니다. DER과 PEM 은 내가 아는 가장 일반적인 인코딩입니다.
[2] 실제로, 프로토콜은 실제로 대칭 암호로 전환되지만 질문과 관련이없는 세부 사항입니다.
[3] CA는 실제로 인증서에 서명하기 전에 사용자를 확인합니다. 그들이 그렇게하지 않으면 google.com에 대한 인증서를 만들어서 CA에 서명하도록 요청할 수 있습니다. 인증을 통해 google.com에 대한 "안전한"연결을 중간에 배치 할 수있었습니다. 따라서 유효성 검사 단계는 CA 운영에서 매우 중요한 요소입니다. 불행히도,이 검증 프로세스가 전 세계 수백 개의 CA에 얼마나 엄격한 지 명확하지 않습니다.
[4] Mozilla의 신뢰할 수있는 CA 목록을 참조하십시오 .
