it-swarm-korea.com

SSL 서버는 어떻게 ID를 증명합니까?

이 문서 는 챌린지 응답 인증이 서버 ID를 증명한다고 말합니다. 그러나 클라이언트가 도메인 이름을 확인하지 않으면 중간 공격의 사람이 여전히 가능합니까? 이것을 이해하도록 도와주세요.

11
user1157

SSL 핸드 셰이크는 인증서 사용을 의미합니다. 서버에는 클라이언트가 확인해야하는 인증서가 있습니다 (알려진 트러스트 앵커와 관련하여 "루트 CA"). 인증서에는 공개 키와 SSL에 사용되는 암호화 알고리즘이 포함되어 있으며 다음과 같은 방식으로 연결이 안전합니다.

  1. 클라이언트는주고받은 모든 데이터가 (인증서 내에서) 수신 한 공개 키와 관련된 개인 키를 소유 한 서버에서만 사용할 수 있다는 것을 알고 있습니다.

  2. 인증서는 해당 개인 키가 인증서에 이름이 기록 된 일부 엔티티에 의해 소유 (제어)되었음을 클라이언트에게 증명합니다. SSL의 경우 이름은 "www.example.com"과 같은 DNS 이름입니다.

인증서의 이름이 클라이언트가 처음에 연결하려는 서버의 이름인지 확인하는 것은 여전히 ​​클라이언트의 책임입니다.

유추 : 당신은 그의 이름이 밥이라고 말하는 사람을 만납니다. 그에게 신분증을 보여달라고 부탁합니다. ID 카드가 정품 ID 카드인지 확인하는 것만으로는 충분하지 않습니다. 또한 ID 카드의 이름이 "Bob"인지 확인해야합니다. 그렇지 않으면 Charlie가 "I am Bob"이라고 말하고 이름이 "Charlie"인 ID 카드를 보여줄 수 있습니다.

20
Thomas Pornin

토마스의 대답은 굉장히 훌륭합니다. 시스템에 여전히 구멍이 있으며주의를 기울이는 것이 좋습니다.

가장 큰 문제는 기본적으로 아마도 많은 수의 "신뢰할 수있는"루트 인증서를 가지고 있다는 것입니다. 그 중 하나는 DNS 이름을 인증 할 수 있습니다. 나는 그들 모두를 실제로 신뢰하지 않는 이유가 있다고 생각합니다.

예를 들어, 2009 년 아랍 에미리트 정부 소유의 Etisalat (60 %)는 스파이웨어를 RIM 장치에 삽입하여 전자 메일을 모니터링 할 수있는 무해한 BlackBerry 패치를 출시하여 전자 메일을 모니터링 할 수 없었습니다. 그러나 신뢰할 수있는 많은 CA 목록에 있습니다 : http://arstechnica.com/business/news/2009/07/mobile-carrier-rolls-out-spyware-as-a-3g-update.ars

도메인 이름을 소유하고 있음을 확인하기 위해 많은 CA에서 사용하는 메커니즘은 다양한 공격에 취약하므로 사람들은 자격 증명을 얻지 않아야합니다.

또한 stuxnet 개발자가 두 번 수행 한 것처럼 인증서를 훔칠 수 있습니다.

공개/개인 키 퍼즐의 정책 관련 부분은 암호화 자체보다 훨씬 어렵습니다.

Update : Freedom to Tinker에서 위험한 CA 인프라를 수정하는 방법에 대한 훌륭한 게시물도 참조하십시오. 더 나은 CA 인프라 구축

7
nealmcb

서버는 브라우저가 신뢰하는 루트 (또는 중개자) 인증 기관에 의해 서명되어 ID를 증명합니다.

루트 CA (예 : Verisign)는 사이트의 인증서 요청에 디지털 서명합니다. 디지털 서명은 Verisign이 원본 웹 사이트의 신원을 인증하는 방법입니다. Verisign에는 저와 같은 누군가가 일반적으로 개인 등록을 통해 또는 신원 증명 조합을 통해 ebay에 대한 인증서를 생성하지 못하게하는 방법이 있습니다.

루트 CA 목록은 시간이 지남에 따라 업데이트 및 취소되며, Windows 업데이트에서이를 확인할 수 있습니다.

즉, 누군가 기계에 실제로 액세스 할 수 있다면 항상 가짜 루트 인증서를 설치할 수 있습니다 ... 이는 경고없이 중간에 사람을 다시 가능하게합니다.

1
oreoshake