이 문제와 관련된 많은 문서를 읽었지만 여전히 모든 조각을 모을 수는 없으므로 몇 가지 질문을하고 싶습니다.
-
우선 내가 이해하는대로 인증 절차를 간략히 설명하겠습니다. 그 점에서 착각 할 수 있습니다. 클라이언트는 연결을 시작합니다.이 연결은 서버가 공개 키, 일부 메타 데이터 및 디지털 서명의 조합으로 응답합니다. 신뢰할 수있는 권위. 그런 다음 클라이언트는 서버를 신뢰하는지 여부를 결정하고 공개 키로 임의의 세션 키를 암호화하여 다시 보냅니다. 이 세션 키는 서버에 저장된 개인 키로 만 해독 할 수 있습니다. 서버가이 작업을 수행 한 다음 HTTPS 세션이 시작됩니다.
-
따라서 위의 내용이 맞다면 중간자 공격이 이러한 시나리오에서 어떻게 발생할 수 있는가? 누군가가 공개 키로 서버 (예 : www.server.com) 응답을 가로 채서 그가 www.server.com이라고 생각하게 만드는 수단이 있어도 여전히 내 세션 키를 해독 할 수 없습니다. 개인 키없이.
-
상호 인증에 대해 말하자면, 클라이언트 ID에 대한 서버 신뢰에 관한 것입니까? 클라이언트는 이미 올바른 서버와 통신하고 있는지 확인할 수 있지만 이제 서버는 클라이언트가 누구인지 알고 싶어합니다.
-
마지막 질문은 상호 인증의 대안에 관한 것입니다. 설명 된 상황에서 클라이언트 역할을하는 경우 SSL 세션이 설정된 후 HTTP 헤더에 로그인 / 암호를 보내면 어떻게됩니까? 내가보기에이 정보는 연결이 이미 보안되어 있고 서버가 내 식별을 위해이를 신뢰할 수 있기 때문에 가로 챌 수 없습니다. 내가 잘못? 상호 인증과 비교할 때 그러한 접근 방식의 단점은 무엇입니까 (구현 복잡성이 아니라 보안 문제 만 중요 함)?
답변
SSL에 대한 중간자 (man-in-the-middle) 공격은 SSL의 전제 조건 중 하나가 손상된 경우에만 가능합니다. 여기에 몇 가지 예가 있습니다.
-
서버 키가 도난당했습니다. 즉, 공격자가 서버 인 것처럼 보일 수 있으며 클라이언트가 알 수있는 방법 이 없습니다 .
-
클라이언트는 신뢰할 수없는 CA (또는 루트 키를 훔친 CA)를 신뢰합니다. 신뢰할 수있는 CA 키를 가진 사람은 누구나 서버 인 것처럼 가장하여 인증서를 생성 할 수 있으며 클라이언트는이를 신뢰합니다. 오늘날 브라우저에 이미 존재하는 CA의 수가 실제 문제가 될 수 있습니다. 즉, 서버 인증서가 다른 유효한 인증서로 변경되는 것처럼 보이며, 이는 대부분의 클라이언트가 숨길 것입니다.
-
클라이언트는 신뢰할 수있는 CA 목록에 대해 인증서를 올바르게 검증하지 않아도됩니다. 누구나 CA를 만들 수 있습니다. 유효성 검사가 없으면 “Ben의 자동차 및 인증서”는 Verisign만큼 유효한 것처럼 보입니다.
-
클라이언트가 공격을 받고 가짜 CA가 신뢰할 수있는 루트 권한에 삽입되었습니다. 공격자가 원하는 인증서를 생성 할 수 있으며 클라이언트는이를 신뢰할 수 있습니다. 악성 코드는 예를 들어 가짜 뱅킹 사이트로 리디렉션하기 위해이를 수행하는 경향이 있습니다.
특히 # 2는 다소 불쾌합니다. 신뢰할 수있는 인증서에 대해 비용을 지불하더라도 사이트가 어떤 식 으로든 해당 인증서에 잠기지 않을 것 입니다. 클라이언트 브라우저에서 모든 CA 를 신뢰 해야 합니다. 유효한 사이트입니다. 또한 서버 또는 클라이언트에 대한 액세스가 필요하지 않습니다.
답변
먼저 내가 이해 한대로 인증 절차를 간략하게 설명하겠습니다. 아마도 그 단계에서 오해 할 수도 있습니다. 따라서 클라이언트는 연결을 시작하고 서버는 신뢰할 수있는 기관의 공개 키, 일부 메타 데이터 및 디지털 서명의 조합으로 연결에 응답합니다.
서버는 X.509 인증서 체인과 자체 개인 키로 서명 된 디지털 서명으로 응답합니다.
그런 다음 클라이언트는 서버를 신뢰하는지 결정합니다.
옳은.
공개 키로 임의의 세션 키를 암호화하고 다시 보냅니다.
아니요. 클라이언트와 서버는 세션 키 자체가 전혀 전송되지 않는 상호 세션 키 생성 프로세스에 참여합니다.
이 세션 키는 서버에 저장된 개인 키로 만 해독 할 수 있습니다.
아니.
서버는 이것을한다
아니.
그런 다음 HTTPS 세션이 시작됩니다.
TLS / SSL의 세션이 시작됩니다,하지만 더 많은 단계가 먼저가 있습니다.
따라서 위의 내용이 맞다면 이러한 시나리오에서 man-in-the-middle 공격이 어떻게 발생할 수 있습니까?
서버로 가장하고 SSL 끝점으로 작동합니다. 클라이언트는 인증 단계를 생략해야합니다. 안타깝게도 대부분의 HTTPS 세션에서 유일한 인증 단계는 호스트 이름 확인입니다.
누군가가 공개 키로 서버 (예 : www.server.com) 응답을 가로 채고 어떤 수단으로 그가 www.server.com이라고 생각하게하더라도 그는 여전히 내 세션 키를 해독 할 수 없습니다. 개인 키없이.
위 참조. 해독 할 세션 키가 없습니다. SSL 연결 자체는 안전합니다. 당신이 말하는 사람이 안전하지 않을 수 있습니다.
상호 인증에 대해 말하자면, 클라이언트 ID에 대한 서버 신뢰에 관한 것입니까? 내 말은, 클라이언트는 이미 자신이 올바른 서버와 통신하고 있는지 확인할 수 있지만 이제 서버는 클라이언트가 누구인지 알고 싶어합니다.
옳은.
마지막 질문은 상호 인증의 대안에 관한 것입니다. 설명 된 상황에서 클라이언트 역할을하는 경우 SSL 세션이 설정된 후 HTTP 헤더에 로그인 / 암호를 보내면 어떻게됩니까? 보시다시피이 정보는 연결이 이미 보안되어 있고 서버가 내 식별을 위해이를 신뢰할 수 있기 때문에 가로 챌 수 없습니다. 내가 잘못?
아니.
상호 인증과 비교할 때 그러한 접근 방식의 단점은 무엇입니까 (구현 복잡성이 아니라 보안 문제 만 중요 함)?
사용자 이름 / 암호만큼 안전하며 개인 키보다 유출하기가 훨씬 쉽습니다.
답변
클라이언트와 서버 사이를 오가는 사람이라면 누구나 https에서 중간자 공격을 할 수 있습니다. 이것이 드물거나 드물다고 생각하는 경우 인터넷 게이트웨이를 통해 모든 SSL 트래픽 을 체계적으로 해독, 스캔 및 다시 암호화하는 상용 제품이 있음을 고려하십시오.. 클라이언트에게 “실제”SSL 인증서에서 복사 한 세부 정보를 사용하여 즉석에서 생성되었지만 다른 인증서 체인으로 서명 된 SSL 인증서를 전송하여 작동합니다. 이 체인이 브라우저의 신뢰할 수있는 CA로 종료되면이 MITM은 사용자에게 표시되지 않습니다. 이러한 제품은 주로 회사 네트워크를 “보안”(경찰)하기 위해 회사에 판매되며 사용자의 지식과 동의를 얻어 사용해야합니다. 기술적으로는 ISP 나 다른 네트워크 사업자의 사용을 중단 할 수 없습니다. (NSA에 신뢰할 수있는 루트 CA 서명 키가 하나 이상 있다고 가정하는 것이 안전합니다 .)
페이지를 제공하는 경우 페이지에 서명해야하는 공개 키를 나타내는 HTTP 헤더 를 포함 할 수 있습니다 . 이는 사용자에게 “보안”연결을 MITM에 알리는 데 도움이 될 수 있지만 처음 사용시 신뢰하는 기술입니다. Bob이 “실제”공개 키 핀에 대한 레코드가없는 경우 Mallory는 문서에서 pkp 헤더를 다시 작성합니다. 이 기술 (HPKP)을 사용하는 웹 사이트 목록은 매우 짧습니다. 여기에는 Google과 Dropbox가 포함됩니다. 일반적으로 https-intercepting 게이트웨이는 HPKP를 사용하는 몇 개의 신뢰할 수있는 대규모 사이트의 페이지를 통과합니다. 예상하지 못한 HPKP 오류가 표시되면주의하십시오.
암호와 관련하여 https 연결의 모든 것은 https로 보호됩니다. 단, 도메인 이름은 요청이 라우팅 될 수 있도록 명확하게 표시되어야합니다. 일반적으로 로그, 북마크 등에 사용할 수있는 쿼리 문자열에 암호를 넣지 않는 것이 좋습니다.하지만 https가 손상되지 않는 한 쿼리 문자열은 표시되지 않습니다.
답변
- 옳은
- 별로 맞지 않습니다. 그런 종류의 공격에서 itermediate 서버는 귀하의 요청을 받아 귀하를 대신하여 목적지로 보냅니다. 그런 다음 결과로 응답합니다. 실제로 통신하려는 실제 서버가 아닌 사용자와 안전하게 연결하는 중간자 서버입니다. 그렇기 때문에 인증서가 유효하고 신뢰할 수 있는지 항상 확인해야합니다.
- 맞을 수있다
- 보안 연결이 신뢰할 수 있다고 확신하면 사용자 이름 / 암호를 보내도 안전합니다.
답변
세션 키에 관한 부분을 제외하고 말한 모든 것이 정확합니다. CA의 요점은 중간자 (man-in-the-middle) 공격을 물리 치는 것입니다. 다른 모든 것은 SSL 자체에서 수행됩니다. 클라이언트 인증은 사용자 이름 및 암호 체계의 대안입니다.