SSL 시나리오의 중간자 공격

Question 1

이전 답변에서 언급했듯이귀하의 질문, 중간자 공격(성공할 경우)은 암호화된 채널에 대해 주고받는 모든 데이터를 소유할 수 있습니다.

자체 서명되고 신뢰할 수 있는 루트에서 발급된 인증서는 위조될 수 있으므로 신뢰할 수 있는 루트에서 사용자에게 인증서를 발급하는 경우 보안에 대한 잘못된 인식에 빠지지 마십시오. 신뢰할 수 있는 루트에서 발행한 문제로 극복해야 할 유일한 문제는내가 그들의 컴퓨터에 arp를 중독시켰을 때 당신의 사용자가 내 것을 받아들이도록 하는 것. 대부분의 최종 사용자를 생각한다면 이것이 얼마나 쉬울까요?

이제 문제가 보이시나요?

최종 사용자가 내 인증서를 수락하면 해당 시점부터 연결을 소유하고 모든 데이터가 내 컴퓨터를 통과합니다.

Answer

이전 답변에서 언급했듯이귀하의 질문, 중간자 공격(성공할 경우)은 암호화된 채널에 대해 주고받는 모든 데이터를 소유할 수 있습니다.

자체 서명되고 신뢰할 수 있는 루트에서 발급된 인증서는 위조될 수 있으므로 신뢰할 수 있는 루트에서 사용자에게 인증서를 발급하는 경우 보안에 대한 잘못된 인식에 빠지지 마십시오. 신뢰할 수 있는 루트에서 발행한 문제로 극복해야 할 유일한 문제는내가 그들의 컴퓨터에 arp를 중독시켰을 때 당신의 사용자가 내 것을 받아들이도록 하는 것. 대부분의 최종 사용자를 생각한다면 이것이 얼마나 쉬울까요?

이제 문제가 보이시나요?

최종 사용자가 내 인증서를 수락하면 해당 시점부터 연결을 소유하고 모든 데이터가 내 컴퓨터를 통과합니다.

Question 2

기본적으로 발생하는 일은 인증서에 자체 서명했기 때문에 그것이 유효하다는 것을 증명할 방법이 없다는 것입니다. 따라서 트래픽을 잘 암호화하지만 그것이 귀하의 것임을 증명할 수는 없습니다. 해커가 귀하의 사이트와 사용자의 컴퓨터 사이에 침투하여 트래픽을 가로챌 수 있다면 그는 트래픽을 해독하고 무슨 일이 일어나고 있는지 읽을 수 있습니다. (그는 또한 귀하와 유사한 도메인 이름을 등록하고 오타를 기다리거나 귀하의 사이트가 아닌 자신의 사이트로 연결되는 이메일을 보내는 등의 방법으로 이를 수행할 수 있습니다.)

User ****** Hacker **** Your website

그가 이렇게 할 수 있는 이유는 자체 서명된 인증서도 제시할 수 있기 때문입니다. 그러면 사용자는 실제로 귀하가 아닌 해커와 통신하는 것입니다. 사용자는 차이점을 알 수 없습니다. 실제로 해커가 원하는 경우 트래픽을 다시 암호화하여 귀하의 사이트로 다시 보내고 사용자 자격 증명을 사용하여 귀하의 사이트와 자체 통신 스트림을 시작할 수 있습니다. 아니면 그냥 공허한 곳에서 앞뒤로 움직이는 교통 상황을 지켜보세요.

Answer

기본적으로 발생하는 일은 인증서에 자체 서명했기 때문에 그것이 유효하다는 것을 증명할 방법이 없다는 것입니다. 따라서 트래픽을 잘 암호화하지만 그것이 귀하의 것임을 증명할 수는 없습니다. 해커가 귀하의 사이트와 사용자의 컴퓨터 사이에 침투하여 트래픽을 가로챌 수 있다면 그는 트래픽을 해독하고 무슨 일이 일어나고 있는지 읽을 수 있습니다. (그는 또한 귀하와 유사한 도메인 이름을 등록하고 오타를 기다리거나 귀하의 사이트가 아닌 자신의 사이트로 연결되는 이메일을 보내는 등의 방법으로 이를 수행할 수 있습니다.)

User ****** Hacker **** Your website

그가 이렇게 할 수 있는 이유는 자체 서명된 인증서도 제시할 수 있기 때문입니다. 그러면 사용자는 실제로 귀하가 아닌 해커와 통신하는 것입니다. 사용자는 차이점을 알 수 없습니다. 실제로 해커가 원하는 경우 트래픽을 다시 암호화하여 귀하의 사이트로 다시 보내고 사용자 자격 증명을 사용하여 귀하의 사이트와 자체 통신 스트림을 시작할 수 있습니다. 아니면 그냥 공허한 곳에서 앞뒤로 움직이는 교통 상황을 지켜보세요.

Question 3

그가 트래픽을 수정할 수 있는 것은 아닙니다. SSL 핸드셰이크는 암호화되지 않은 상태로 시작되고 서버는 클라이언트가 해당 시점부터 사용할 SSL 인증서를 보냅니다. 공격자가 처음부터 존재했다면 그는 이 초기 인증서를 자신의 인증서로 교체한 다음 서버에서 보낸 인증서를 사용하여 서버와의 트래픽을 암호화/해독하고 자신의 인증서를 사용하여 사용자에게 보낼 수 있습니다.
인증서가 인증 기관에서 서명한 경우 CA에서도 서명한 가짜 인증서로 교체하기가 조금 더 어렵습니다. 그러나 공격자는 이 인증서를 자체 서명된 인증서로 쉽게 교체할 수 있으므로 경고가 표시됩니다.

Answer

그가 트래픽을 수정할 수 있는 것은 아닙니다. SSL 핸드셰이크는 암호화되지 않은 상태로 시작되고 서버는 클라이언트가 해당 시점부터 사용할 SSL 인증서를 보냅니다. 공격자가 처음부터 존재했다면 그는 이 초기 인증서를 자신의 인증서로 교체한 다음 서버에서 보낸 인증서를 사용하여 서버와의 트래픽을 암호화/해독하고 자신의 인증서를 사용하여 사용자에게 보낼 수 있습니다.
인증서가 인증 기관에서 서명한 경우 CA에서도 서명한 가짜 인증서로 교체하기가 조금 더 어렵습니다. 그러나 공격자는 이 인증서를 자체 서명된 인증서로 쉽게 교체할 수 있으므로 경고가 표시됩니다.

Question 4

인증서를 확인할 때 고려해야 할 두 가지 사항은 다음과 같습니다.

귀하가 신뢰하는 엔터티에 의해 발행되었는지 확인하고,
연결하려는 서버의 ID와 일치하는지 확인하세요.

CA 발급 인증서

그만큼X.509 인증서를 사용하는 공개 키 인프라. 사양이를 위해 배치할 구조를 정의합니다. 이는 루트가 CA(인증 기관)이고 리프가 최종 엔터티 인증서(특히 서버 인증서)인 트리를 얻는 계층적 모델입니다.

루트 CA 인증서는 자체 서명되는 경향이 있습니다. 이들 중 다수는 기본적으로 OS 또는 브라우저에 포함되어 있습니다. 이것이 "신념의 도약" 부분입니다. OS/브라우저 공급업체가 CA가 제대로 작업을 수행하는지 검사했다고 신뢰하는 부분입니다. 대형 상용 CA로는 Verisign, Thawte 등이 있습니다.

그런 다음 CA는 다른 인증서에 서명할 수 있습니다. 한 번도 본 적이 없는 인증서도 신뢰하는 CA에서 서명했는지 확인하여 확인할 수 있습니다. 중간 CA도 있을 수 있습니다. 예를 들어, 에 대한 인증서는 https://www.google.com/"Thawte SGC CA"는 "에 의해 서명되었습니다.VeriSign, Inc./클래스 3 공공 기본 인증 기관" (단순화하기 위해 여기서는 이름을 줄였습니다.) CA의 임무는 인증서를 발급한 사람/기관이 해당 호스트 이름의 적법한 소유자인지 확인하는 것입니다(PKI 외부 수단을 통해). www.google.com이 대역 외 확인 방식은 EV가 아닌 인증서의 경우 도메인 이름을 등록한 주소(여기에서 사용 가능)로 간단히 이메일을 보내는 방식으로 수행되는 경우가 많습니다.후이즈예배 규칙서).

이 작업이 완료되면 신뢰 여부를 모른다고 가정하면 https://www.google.com/클라이언트는 보유한 신뢰 앵커(종종 OS/브라우저 공급업체에서 미리 가져온 CA)와 비교하여 이 인증서를 확인합니다. 에 연결하면 www.google.com브라우저는 인증서를 얻은 다음 신뢰하는 발급자(이 경우 Verisign의 발급자)를 찾을 때까지 최상위 발급자(모든 인증서에 발급자 항목이 있음)까지 체인을 처리할 수 있습니다. 지금까지는 매우 훌륭하여 인증서를 신뢰할 수 있습니다. 두 번째 단계는 이 인증서가 실제로 이 시스템에 대한 것인지 확인하는 것입니다. HTTPS의 경우 호스트 이름이 인증서의 주체 대체 이름 확장에 있는지 확인하거나 대체 방법으로 주체 고유 이름의 "일반 이름"(CN) 항목에 있는지 확인하면 됩니다. 이에 대한 설명은 다음과 같습니다.RFC 2818(서버 ID).

여기서 가능한 공격 시도는 다음과 같습니다.

공격자는 자체 CA를 사용하여 해당 호스트 이름에 대한 인증서를 위조합니다. 해당 CA가 브라우저에서 인식되지 않으므로 인증서가 확인되지 않습니다. 발급자 이름을 위조하더라도 서명을 위조할 수 없습니다(이미 신뢰하는 CA 인증서를 사용하여 공개 키를 사용하여 확인하기 때문입니다). 여기서 가장 큰 문제 중 하나는 서명의 강도였습니다. 충돌 공격은 MD5 다이제스트 알고리즘을 사용하여 시연되었으므로 CA는 이제 보다 강력한 것으로 간주되는 SHA-1을 대신 사용합니다. RSAwithSHA1 또는 DSAwithSHA1이 충분히 강력하다고 생각하면 문제가 발생하지 않습니다.
공격자는 잘 알려진 CA로부터 합법적인 인증서를 받지만 호스트 이름은 다릅니다(CA는 다른 사람에게 발행해서는 안 되기 때문). 그들이 www.example.com. 에 연결하려고 하면 www.google.com트래픽이 자신의 상자로 리디렉션됩니다. 그러면 신뢰하는 CA에서 확인할 수 있는 인증서가 표시됩니다 www.example.com. 여기서 호스트 이름 확인이 중요합니다. 브라우저는 의도한 호스트에 연결되지 않았다는 경고 메시지를 표시합니다.

이 시스템은 MITM이 트래픽을 해당 시스템으로 리디렉션하는 경우 클라이언트가 연결을 수락하지 않도록 설계되었습니다. 물론 이는 사용자가 브라우저에 표시되는 경고를 무시하지 않는 경우에만 유효합니다.

자체 서명된 인증서

귀하가 CA이고 이 자체 서명된 인증서가 직접 서버 인증서일 수도 있다는 점을 제외하면 동일한 원칙입니다. 자체 서명된 인증서를 생성하여 컴퓨터에 저장하는 경우 브라우저에서 이를 신뢰할 수 있는 기관으로 가져올 수도 있습니다. 이 경우 위에서 설명한 것과 동일한 절차를 따릅니다.

Firefox와 같은 일부 브라우저에서는 이러한 규칙에 영구적인 예외를 추가할 수 있습니다. 다른 방법(예: 관리자가 직접 인증서를 제공)을 통해 연결하려는 컴퓨터의 인증서가 무엇인지 알고 있는 경우 해당 인증서가 서명되지 않은 경우에도 명시적으로 신뢰하도록 선택할 수 있습니다. 신뢰하는 CA이거나 이름이 일치하지 않는 경우. 물론 이를 위해서는 이 특정 인증서가 무엇인지 선험적으로 명시적으로 알아야 합니다.

두 경우 모두 사용자가 경고를 무시하고 신뢰할 수 없는 인증서가 있는 연결로 리디렉션되는 것을 수락하면 MITM(신뢰할 수 없는 인증서가 있는)이 트래픽을 확인/리디렉션/변경할 수 있습니다.

Answer

인증서를 확인할 때 고려해야 할 두 가지 사항은 다음과 같습니다.

귀하가 신뢰하는 엔터티에 의해 발행되었는지 확인하고,
연결하려는 서버의 ID와 일치하는지 확인하세요.

CA 발급 인증서

그만큼X.509 인증서를 사용하는 공개 키 인프라. 사양이를 위해 배치할 구조를 정의합니다. 이는 루트가 CA(인증 기관)이고 리프가 최종 엔터티 인증서(특히 서버 인증서)인 트리를 얻는 계층적 모델입니다.

루트 CA 인증서는 자체 서명되는 경향이 있습니다. 이들 중 다수는 기본적으로 OS 또는 브라우저에 포함되어 있습니다. 이것이 "신념의 도약" 부분입니다. OS/브라우저 공급업체가 CA가 제대로 작업을 수행하는지 검사했다고 신뢰하는 부분입니다. 대형 상용 CA로는 Verisign, Thawte 등이 있습니다.

그런 다음 CA는 다른 인증서에 서명할 수 있습니다. 한 번도 본 적이 없는 인증서도 신뢰하는 CA에서 서명했는지 확인하여 확인할 수 있습니다. 중간 CA도 있을 수 있습니다. 예를 들어, 에 대한 인증서는 https://www.google.com/"Thawte SGC CA"는 "에 의해 서명되었습니다.VeriSign, Inc./클래스 3 공공 기본 인증 기관" (단순화하기 위해 여기서는 이름을 줄였습니다.) CA의 임무는 인증서를 발급한 사람/기관이 해당 호스트 이름의 적법한 소유자인지 확인하는 것입니다(PKI 외부 수단을 통해). www.google.com이 대역 외 확인 방식은 EV가 아닌 인증서의 경우 도메인 이름을 등록한 주소(여기에서 사용 가능)로 간단히 이메일을 보내는 방식으로 수행되는 경우가 많습니다.후이즈예배 규칙서).

이 작업이 완료되면 신뢰 여부를 모른다고 가정하면 https://www.google.com/클라이언트는 보유한 신뢰 앵커(종종 OS/브라우저 공급업체에서 미리 가져온 CA)와 비교하여 이 인증서를 확인합니다. 에 연결하면 www.google.com브라우저는 인증서를 얻은 다음 신뢰하는 발급자(이 경우 Verisign의 발급자)를 찾을 때까지 최상위 발급자(모든 인증서에 발급자 항목이 있음)까지 체인을 처리할 수 있습니다. 지금까지는 매우 훌륭하여 인증서를 신뢰할 수 있습니다. 두 번째 단계는 이 인증서가 실제로 이 시스템에 대한 것인지 확인하는 것입니다. HTTPS의 경우 호스트 이름이 인증서의 주체 대체 이름 확장에 있는지 확인하거나 대체 방법으로 주체 고유 이름의 "일반 이름"(CN) 항목에 있는지 확인하면 됩니다. 이에 대한 설명은 다음과 같습니다.RFC 2818(서버 ID).

여기서 가능한 공격 시도는 다음과 같습니다.

공격자는 자체 CA를 사용하여 해당 호스트 이름에 대한 인증서를 위조합니다. 해당 CA가 브라우저에서 인식되지 않으므로 인증서가 확인되지 않습니다. 발급자 이름을 위조하더라도 서명을 위조할 수 없습니다(이미 신뢰하는 CA 인증서를 사용하여 공개 키를 사용하여 확인하기 때문입니다). 여기서 가장 큰 문제 중 하나는 서명의 강도였습니다. 충돌 공격은 MD5 다이제스트 알고리즘을 사용하여 시연되었으므로 CA는 이제 보다 강력한 것으로 간주되는 SHA-1을 대신 사용합니다. RSAwithSHA1 또는 DSAwithSHA1이 충분히 강력하다고 생각하면 문제가 발생하지 않습니다.
공격자는 잘 알려진 CA로부터 합법적인 인증서를 받지만 호스트 이름은 다릅니다(CA는 다른 사람에게 발행해서는 안 되기 때문). 그들이 www.example.com. 에 연결하려고 하면 www.google.com트래픽이 자신의 상자로 리디렉션됩니다. 그러면 신뢰하는 CA에서 확인할 수 있는 인증서가 표시됩니다 www.example.com. 여기서 호스트 이름 확인이 중요합니다. 브라우저는 의도한 호스트에 연결되지 않았다는 경고 메시지를 표시합니다.

이 시스템은 MITM이 트래픽을 해당 시스템으로 리디렉션하는 경우 클라이언트가 연결을 수락하지 않도록 설계되었습니다. 물론 이는 사용자가 브라우저에 표시되는 경고를 무시하지 않는 경우에만 유효합니다.

자체 서명된 인증서

귀하가 CA이고 이 자체 서명된 인증서가 직접 서버 인증서일 수도 있다는 점을 제외하면 동일한 원칙입니다. 자체 서명된 인증서를 생성하여 컴퓨터에 저장하는 경우 브라우저에서 이를 신뢰할 수 있는 기관으로 가져올 수도 있습니다. 이 경우 위에서 설명한 것과 동일한 절차를 따릅니다.

Firefox와 같은 일부 브라우저에서는 이러한 규칙에 영구적인 예외를 추가할 수 있습니다. 다른 방법(예: 관리자가 직접 인증서를 제공)을 통해 연결하려는 컴퓨터의 인증서가 무엇인지 알고 있는 경우 해당 인증서가 서명되지 않은 경우에도 명시적으로 신뢰하도록 선택할 수 있습니다. 신뢰하는 CA이거나 이름이 일치하지 않는 경우. 물론 이를 위해서는 이 특정 인증서가 무엇인지 선험적으로 명시적으로 알아야 합니다.

두 경우 모두 사용자가 경고를 무시하고 신뢰할 수 없는 인증서가 있는 연결로 리디렉션되는 것을 수락하면 MITM(신뢰할 수 없는 인증서가 있는)이 트래픽을 확인/리디렉션/변경할 수 있습니다.

SSL 시나리오의 중간자 공격

답변1

답변2

답변3

답변4

CA 발급 인증서

자체 서명된 인증서

관련 정보