영어가 모국어가 아니어서 불편을 끼쳐드려 죄송합니다.
hostsDNS가 오염되어 일부 웹사이트에 액세스하곤 합니다 .
내 질문은 www.google.com예를 들어 보겠습니다.
공격자에 의해 성공적으로 소셜 엔지니어링되어 번역이 hosts피싱 웹사이트로 변경된 경우.
을 사용하면 http완전히 망가지는 거죠?
을 사용하면 https내 PC가 손상되지 않은 경우 브라우저에서 경고를 표시합니다.
이 https경우 피싱 웹사이트가 단지통과하다www.google.com그것이 정품이라는 것을 증명하기 위해 나에게 보내는 인증서가 있습니까 ?
답변1
다음 진술을 고려하십시오.
모두
examplebank.com귀하의 웹 브라우저가 신뢰하는 인증 기관은 도메인 소유권 증명 없이 공격자에게 인증서 발급을 거부합니다 .모든 기관의 서명 키는 안전하게 저장되며 권한이 없는 사람이 스스로 인증서를 발급할 수 없습니다. (최근 참조코모도 침입.)
웹 브라우저는 서버의 SSL 인증서가 유효한 CA에서 발급되었는지, 취소되지 않았는지, 서버에서 사용할 수 있는지, 도메인에 대해 발급되었는지 올바르게 확인합니다
examplebank.com.이러한 검사를 우회하게 만드는 활성 악성 코드나 브라우저 버그가 없습니다.
https://examplebank.com웹사이트의 리디렉션에 의존하는 대신 항상 SSL을 명시적으로 요청하여 엽니다 .당신은 실제로읽다Ignore웹 사이트를 열 때 맹목적으로 클릭하는 대신 SSL 오류 메시지를 확인하세요 .
위의 사항이 모두 충족되면 HTTPS는경고합니다가짜 웹사이트에 연결을 시도했다는 것입니다. 그러나 HTTPS는 낮은 수준의 리디렉션(예: examplebank.comDNS 또는 에 의한 스푸핑 /etc/hosts)을 우회할 수 없으므로 경고를 무시하면 데이터가 실제 은행이 아닌 공격자에게 전달됩니다.
결론부터 말하면 위험하다.
편집된 질문에 대한 응답:
일반 HTTP를 사용하면 망할 것입니다.
HTTPS를 사용하는 경우 크고 빨간색 경고가 표시됩니다(답변의 첫 부분 참조).
모든 "인증서"에는 RSA(때때로 DSA, ECDSA) 키 쌍이 있습니다. 쌍의 공개 키는 인증서의 일부인 반면, 개인 키는 웹 서버에 잠겨 있으며 네트워크를 통해 전송되지 않습니다. TLS/SSL 핸드셰이크를 성공적으로 완료하려면 두 키가 모두 필요합니다.
공격자가 인증서를 제시했지만 관련 개인 키가 없는 경우 TLS를 통과하는 트래픽을 해독할 수 없습니다. 위키피디아에는TLS 핸드셰이크에 대한 설명.
답변2
SSL(HTTPS)은 클라이언트가 손상되지 않는 한만 보호합니다..
누군가 /etc/hosts를 수정하는 경우, 연결 중인 서버의 SSL 유효성 검사를 수행하지 않도록 브라우저를 수정하거나 사기 서버의 가짜 인증서를 시스템의 신뢰할 수 있는 인증서 데이터베이스에 추가할 수도 있습니다.
그러나 클라이언트가 손상되지 않았고 누군가가 귀하의 브라우저를 다른 IP 주소로 리디렉션하는 경우(예: 일종의 DNS 관련 해킹 또는 다른 작업 없이 /etc/hosts를 수정하도록 속이는 경우), 브라우저는 무언가가 있다는 경고를 표시합니다. 서버 인증서에 문제가 있으므로 경고를 무시하지 않고 계속 진행하면 안전합니다.
두 번째 질문에 대해:
https의 경우 피싱 웹사이트가 그것이 진짜임을 증명하기 위해 www.google.com의 인증서를 나에게 전달하는 것이 가능합니까?
아니요, 공격자가 서버의 정보를 획득하지 않는 한 불가능합니다.개인 키(예: 서버 자체를 해킹하여) 사기 서버가 서버의 인증서를 "전달"하더라도 해당 개인 키가 없으면 클라이언트에게 자신의 신원을 증명할 수 없습니다. 그렇게 하려고 하면 실패하고 브라우저에 경고가 표시됩니다.
답변3
단테, 귀하의 편집을 환영합니다. 그러나 대답은 남아 있습니다. 호스트 파일이 손상되면 해당 파일에 대해 사회적으로 엔지니어링된 도메인과 관련된 전체 보안이 손상될 수 있습니다.
HTTPS는 예외이며 현재 보고 있는 웹 사이트가 보이는 것과 다를 수 있음을 알려주는 인증서 시스템으로 인해 일종의 보호 기능을 제공합니다.