SSL과 man-in-the-middle 오해

이 문제와 관련된 많은 문서를 읽었지만 여전히 모든 조각을 모을 수는 없으므로 몇 가지 질문을하고 싶습니다.

1. 우선 내가 이해하는대로 인증 절차를 간략히 설명하겠습니다. 그 점에서 착각 할 수 있습니다. 클라이언트는 연결을 시작합니다.이 연결은 서버가 공개 키, 일부 메타 데이터 및 디지털 서명의 조합으로 응답합니다. 신뢰할 수있는 권위. 그런 다음 클라이언트는 서버를 신뢰하는지 여부를 결정하고 공개 키로 임의의 세션 키를 암호화하여 다시 보냅니다. 이 세션 키는 서버에 저장된 개인 키로 만 해독 할 수 있습니다. 서버가이 작업을 수행 한 다음 HTTPS 세션이 시작됩니다.

2. 따라서 위의 내용이 맞다면 중간자 공격이 이러한 시나리오에서 어떻게 발생할 수 있는가? 누군가가 공개 키로 서버 (예 : www.server.com) 응답을 가로 채서 그가 www.server.com이라고 생각하게 만드는 수단이 있어도 여전히 내 세션 키를 해독 할 수 없습니다. 개인 키없이.

3. 상호 인증에 대해 말하자면, 클라이언트 ID에 대한 서버 신뢰에 관한 것입니까? 클라이언트는 이미 올바른 서버와 통신하고 있는지 확인할 수 있지만 이제 서버는 클라이언트가 누구인지 알고 싶어합니다.

4. 마지막 질문은 상호 인증의 대안에 관한 것입니다. 설명 된 상황에서 클라이언트 역할을하는 경우 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가 손상되지 않는 한 쿼리 문자열은 표시되지 않습니다.

1. 옳은
2. 별로 맞지 않습니다. 그런 종류의 공격에서 itermediate 서버는 귀하의 요청을 받아 귀하를 대신하여 목적지로 보냅니다. 그런 다음 결과로 응답합니다. 실제로 통신하려는 실제 서버가 아닌 사용자와 안전하게 연결하는 중간자 서버입니다. 그렇기 때문에 인증서가 유효하고 신뢰할 수 있는지 항상 확인해야합니다.
3. 맞을 수있다
4. 보안 연결이 신뢰할 수 있다고 확신하면 사용자 이름 / 암호를 보내도 안전합니다.

세션 키에 관한 부분을 제외하고 말한 모든 것이 정확합니다. CA의 요점은 중간자 (man-in-the-middle) 공격을 물리 치는 것입니다. 다른 모든 것은 SSL 자체에서 수행됩니다. 클라이언트 인증은 사용자 이름 및 암호 체계의 대안입니다.