TLS Coding
글쓴이: twins99 / 작성시간: 화, 2006/03/21 - 11:10오전
gnuTLS를 사용해 Coding을 하고 있는데요,
verification과정을 구현하기가 힘드네요.
서버에서 certificate를 받으면, 이 certificate를 검증하는 단계가 verification과정인데
이 과정이 어떻게 진행되면 되는 것인지 잘 모르겠습니다.
일단 내가 가지고 있는 Trusted CA의 파일이 있는경우 이 파일로 인증을 시도하고, 만약 내가 가진 Trusted CA파일이 없다면, Issuer
를 보고 이를 통해 인증을 시도하는걸로 알고 있습니다만, 구현이 쉽지 않네요..
또 Certificate를 여러개 보내는 경우도 있다고 하는데, 이경우 cert_list를 만들어 처음부터 마지막-1 까진 issuer를 통해 검증하고,
마지막 파일은 trusted CA파일을 통해 검증하는것은 왜그런건가요?
그리고 Revoke의 의미도 잘 모르겠습니다. 왜 Revokation list를 관리하죠? 필요없는것 아닌가요?
설명이 필요합니다.
가능하다면 이해를 위해 간단한 코드도 부탁드립니다.
그럼 답변 기다리겠습니다.
Forums:
gnuTLS를 사용해 본
gnuTLS를 사용해 본 적이 없기에 개념적인 면에서 말씀드리자면... (X.509 가정입니다. PGP면 낭패;;)
1. 인증서의 검증
신뢰하는 CA의 인증서만으로 검증하는 것이 가장 기본적이겠지요. 신뢰하는 CA가 발급한 인증서가 아닌 경우에는 인증해 주지 않는 것이 맞지 않나 싶습니다. 혹은 그 인증서를 발급한 CA를 신뢰하는 CA 목록에 추가해 주든가요. "Issuer를 보고 이를 통해 인증을 시도"하는 것이 어떤 내용을 말씀하시는 건지 궁금합니다.
2. 줄줄이 인증서 목록
신뢰하는 CA로부터 몇 단계의 인증 경로를 거쳐서 서버의 인증서가 발급된 경우가 아닐까 추측해 봅니다. 그래서 서버는 자신의 인증서로부터 루트 인증서까지의 인증 경로에 있는 모든 인증서를 보내 주는 것이지요. 물론 그 경우에도 인증서의 Issuer 필드만으로 검증을 하면 안 됩니다. 인증서 A의 Issuer 필드가 인증서 B의 Subject 필드와 동일한지 확인하고, 인증서 B의 공개키로 인증서 A의 서명을 검증해 주어야 겠지요.
3. Certificate Revocation List
발급한 인증서의 유효기간이 끝나기 전에 그 인증서의 사용을 금지하고자 할 때 필요합니다. 물론 OCSP 같은 방법을 이용해서 그때 그때 CA에게 인증서의 유효성을 물어볼 수도 있겠지만, CA가 OCSP 서비스를 제공하지 않는 경우에는 인증서의 폐기 여부를 알아낼 수 있는 유일한 방법이 CRL입니다.
----
$PWD `date`
$PWD `date`
한가지 더 여쭤보겠습니다.
줄줄이 인증서 목록이 맞는것 같습니다. 보니까 순서대로 나오네요.
그런데, 궁금한것은 root CA가 올바른 것인지 어떻게 알 수 있죠?
제 생각엔 server로 부터 온 certificate를 보고 해당 root CA라고 적혀 있는 놈에게 접근해 certificate를 다운 받고, 이를 가지고 server를 인증하는것이 아닌가 싶은데, 이 과정이 맞는건가요?
혹 이 인증과정을 잘 설명하고 있는 사이트같은게 있으면 좀 알려주세요. 제가 잘 이해하지 못하고 있는 듯 싶습니다.
한가지 더요.
client가 trusted ca의 list가 담긴 file을 가지고 있어야 하는건가요?
만약 없다면 어떻게 진행되나요? Issuer와 Trusted CA의 차이점은 무엇인지요?
한 가지가 아니군요
한 가지가 아니군요 ;)
이미 살펴보신 자료일 수도 있겠지만, gnuTLS 문서의 한 예제가 도움이 되지 않을까 합니다. 두 개의 코드 중 아래쪽이 좀더 '제대로' 검증하는 것 같습니다.
"root CA"라는 말로 가리키신 대상이... 서버가 보낸 인증서 목록 중 가상 상위에 있는 self-signed(즉, Subject와 Issuer가 동일한) 인증서를 말씀하시는 거라면, 딱히 신뢰할 만한 이유가 없습니다. 샘플 코드에서도 보면 verify_certificate_chain() 함수의 초반에 gnutls_x509_crt_check_issuer() 함수로 목록 마지막 인증서의 self-signed 여부를 확인하여, 그런 경우에는 self-signed 인증서를 무시합니다. 그 self-signed 인증서가 이미 클라이언트가 관리하고 있던 신뢰하는 CA 인증서들 중 하나였다면 어차피 이후 verify_last_cert()에서 인증에 성공하겠죠.
글쎄요, CA에 접근해서 인증서를 다운로드 받는 과정이 검증 과정에 포함되는 게 일반적인 것은 아닌 듯 합니다. 신뢰할 수 있는 root CA의 인증서를 클라이언트가 이미 확보하고 있는 게 보통입니다.
맞습니다. 클라이언트는 자신이 신뢰하는 CA의 인증서를 파일 등의 형태로 가지고 있거나, 혹는 언제든지 가져올 수 있는 곳에 두어야 합니다. 그래야 CA의 인증서를 가지고 서버의 인증서를 즉시 검증할 수 있을 테니까요.
만약 없다면... 글쎄요, 있는 게 모두에게 행복한 일 아닐까 싶습니다.
Issuer는 말 그대로 '발급자'입니다. 그 인증서를 발급한 개체(보통은 CA)가 Issuer일 뿐입니다. Trusted CA는 (내가) 신뢰하는 CA입니다. 그 많고 많은 CA들 중, "이 CA는 믿을 수 있고, 따라서 이 CA가 발급한 인증서의 내용 역시 믿을 수 있어"라고 할 수 있는 CA가 trusted CA입니다.
그리고 어떤 인증서를 그 신뢰하는 CA가 발급했는지를 알려면 그 CA의 인증서가 필요하기에 PC에 어떤 형태로든 미리 설치를 해두는 것이 일반적입니다. 더불어 그 CA가 검증하려는 인증서를 만료기간 전에 폐기했는지 여부도 확인하는 것이 안전하기에 CRL을 사용하며, CRL을 받아올 수 있는 방법은 CA의 인증서에 포함되어 있는 경우가 많고, 이를 주기적으로 받아서 저장해 두거나 했다가 필요할 때 사용할 수 있습니다.
----
$PWD `date`
$PWD `date`
댓글 달기