나는 이러한 모든 Man-In-The-Middle Attack 예방에 대해 들었고 중간에있는 사람이 스트림을 수신하고 메시지 자체를 변경하고 싶지 않은 경우 이것이 어떻게 작동 할 수 있는지 궁금합니다.
중간에있는 사람은 상대방이 교환 한 키를 가져 와서 키를 변경 한 다음 메시지를 다시 해독하고 암호화 할 수 있습니까?
인증서가 어떻게 이것을 방지 할 수 있습니까?
편집하다:
인증 기관에서 일반적으로 "그렇습니다. 다른 키입니다"라고 말합니다. 그러나 인증서의 서명이 확정되지 않았다는 것을 어떻게 확신 할 수 있습니까?
답변:
중간에있는 사람은 상대방이 교환 한 키를 가져 와서 키를 변경 한 다음 메시지를 다시 해독하고 암호화 할 수 있습니까?
네, 그들은 할 수 있어요.
( "텍스트 북"버전) DH 와 같은 키 교환 프로토콜 은 도청 (예 : 채널에서 전송되는 내용을 관찰하는 것)에 대해 안전하지만 MITM (Man-in-the-Middle) 공격에 대해 완전히 분류됩니다. 당신은 진술했다.
인증서는이를 해결하려는 시도이지만 다른 문제가 발생합니다. 두 당사자가 올바른 인증서를 어떻게받을 수 있습니까? MITM 공격에 취약하기 때문에 안전하지 않은 채널을 통해 인증서를 보낼 수는 없습니다.
해결책은 대안적인 (완전히) 안전한 채널 의 존재입니다 . 이는 양 당사자가 직접 만나서 인증서를 물리적으로 또는 신뢰할 수있는 다른 대체 채널 (예 : 신뢰할 수있는 경우 전화를 통해)로 교환하는 것입니다.
컴퓨터 네트워크에서 대체 채널은 일반적으로 PKI ( 공개 키 인프라 )입니다. 이는 운영 체제 또는 브라우저에 다른 인증서가 서명 된 사전 구성된 루트 인증서 세트 (및 중간 인증서 로 사용하는 추가 인증서 )가 있음을 의미합니다. 따라서 일부 웹 사이트를 방문 하면 이미 신뢰하는 (체인) 인증서를 사용하여 서명 된 서명 된 인증서가 제공 됩니다. 그런 다음이 인증서를 사용하여 인증 된 키 교환이 가능합니다 (예 : 일반 대칭 암호화와 함께 사용하기 위해 임시 키 에 동의 ).
중간자 공격에서 Bob에게 키를 요청하지만 Eve는 메시지를 가로 채고 대신 키를 보냅니다. 그녀는 Bob에게 자신의 키를 요청한 다음 사용자와 Bob 사이에 메시지를 전달하여 암호를 해독하고 프로세스에서 메시지를 읽거나 변경합니다.
문제는 실제로 Bob의 키가 있는지 여부를 모른다는 것입니다. 인증 기관 (CA)이 Bob에게 "Bob 's key is 12345"라는 디지털 서명 된 메시지를 제공하기 때문에 인증서가이 문제를 해결합니다. CA가 많지 않기 때문에이 인증서를 확인할 수 있으므로 브라우저에는 유효한 CA 키 목록 만 포함되어 있습니다. 이제 Eve가 Bob과의 암호화 된 통신을 시작하려는 시도를 가로 채면 두 가지 선택이 있습니다. 그녀가 Bob의 키가 67890이라고 말하면 인증서를 제공하지 않고 "죄송합니다, 증명해야합니다"라고 말하거나 가짜 인증서를 제공하고 "그 인증서가 유효하지 않습니다"라고 말합니다. 또는 밥의 키는 12345이며 유효한 인증서를 제공한다고 알려 주지만