안녕하세요. 소들입니다 :D
저번 시간에 TLS의 정의, 암호화 방식에 대해 알아봤죠?
이번엔 TLS 인증서에 대해 공부해볼 거예요. •'-'•)و✧
복습을 하자면 TLS의 암호화 방식은
대칭키 방식 + 비대칭키 방식을 혼용하여 사용한다 하였어요.
그렇다면 TLS의 동작은 이 암호화 방식을 거쳐 통신하는 게 전부일까요?
땡~~ 아니예요!
먼저, TLS가 제공하는 3가지 이점에 대해 알아볼 거예요.
1. TLS가 제공하는 이점들
① 기밀성 (암호화)
이전 포스팅에서 공부했던 암호화에 해당하는 항목입니다.
서버와 주고 받는 데이터가 스니핑👀 되는 것을 방지합니다.
패킷이 오가는 것을 훔쳐 볼 순 있어도 안전하게 암호화 된 패킷이라 복호화 할 수 없기 떄문에
데이터는 훔쳐볼 수 없겠죠!?
② 데이터 무결성
통신 도중 데이터가 제 3자에 의해 악의로 변경될 일이 없습니다 :D
1번 기밀성과 같은 선상에서 보시면 됩니다.
서로의 대칭키를 RSA 알고리즘을 통해 안전하게 공유한 후에 암호화하여 통신하기 때문에
제 3자가 대칭키를 알아내지 않는 한 중간에서 암호화된 데이터를 임의로 수정하지 못하겠죠.
③ 서버 인증
1, 2번은 지난 포스팅에 공부했던 암호화 알고리즘을 통해 가능하다고 보여져요. 그쵸?
근데 만약 위의 암호화 방식으로만 서버와 클라이언트가 통신을 한다고 가정해보아요.
서버와 나는 암호화를 통해 통신하기 때문에 아무도 데이터를 훔쳐볼 수도 건들 수도 없겠지!!
그래, 여기까진 좋아! 근데 만약 서버가 신뢰할 수 없는 서버라면요..!?
요즘 보이스피싱 많이 당하잖아요.
보이스피싱범들이 웹사이트를 실제 검찰 사이트와 똑같이 만들어두고 주민번호로 뭐 조회하라 해요.
여기서 내가 주민번호를 치면 보이스피싱범들이 만들어 놓은 서버에 내 주민번호를 보내는 겁니다. 끔찍.
이처럼 내가 데이터를 서버에 아무리 암호화 하여 보낸다 한들,
서버가 가짜로 만들어 놓은 쓰레기통 서버라면 큰 문제가 되겠죠?
이처럼, 서버와 클라이언트 간 통신을 할 때는
서버가 신뢰할 수 있는 서버라는 것을 확인하는 작업이 필요해요.
이럴 때 사용하는 것이 바로 '인증서' 입니다!!!
이번에 공부할 포스팅에서 왜 인증서라는 것에 대해 공부하는지 이제 아시겠죠? :D
자 그럼 이제 시작해 봅시당!
2. 인증서란?
인증서라는 것이 무엇일까요? 이름부터 이미 감이 오지 않나요?
바로 위에서 서버가 신뢰할 수 있는 진짜 서버 임을 확인하기 위해 필요한 것이 바로 인증서 라 했어요.
인증서에는 다음과 같은 정보들을 포함하고 있습니다.
1. 서비스 정보(인증서를 발급한 CA, 서비스의 도메인 등)
2. 서버 측 공개키(공개키, 공개키 암호화 방법)
3. 지문, 디지털 서명 등
우리가 지금 보는 이 티스토리도 인증서를 갖고 있습니다.
주소창 가장 왼쪽에 🔒보이시나요?
자물쇠가 잠겨있다는 건 이전 포스팅에서 공부했던 HTTPS 통신이라는 뜻입니다 :D
그럼 티스토리의 인증서를 한번 봐봐볼까요?
앞서 말했듯 서버의 공개키, 서명, 지문, 발급자 정보 등이 포함되어 있죠? :)
이것들이 인증서에서 어떤 역할을 하는지는 차차 알아봅시당.
그러기 전에 먼저,
이 인증서는 어디서 어떻게 생성할까요?
3. CA (Certificate Authority)
CA는 인증서를 발급해주는 기관으로, Root Certificate라고 부르기도 합니다.
CA는 아무 기업이나 할 수 있는 게 아니라 신뢰성이 엄격하게 공인된 기업들만 할 수 있습니다.
TLS 통신을 하려면 이 CA를 통해서 인증서를 발급받아야 합니다.
먼저, 미리 알아둘 것은 CA는 자체적으로 공개키와 비밀키를 가지고 있습니다. (꼭 기억)
CA의 비밀키는 절대 누설 되어선 안 되며,
실제 어떤 CA 기관은 이 비밀키가 누설되어 파산한 기관도 있습니다 따흑흑..
4. CA에서 인증서를 발급 받으려면..
다시 돌아와서, 서버는 CA로부터 인증서를 발급받는 방법을 알아 봅시다.
먼저 그림으로 전체적인 메커니즘을 보여 드릴게요.
자 실제 인증서를 통해 봐봅시당.
먼저, 발급 받고자 하는 기관은 자신의 사이트 정보(도메인 등)과 공개키를 CA에게 제출합니다.
그러면 CA는 검증을 걸친 후 발급 받고자 하는 기관의 공개 키를 해시(SHA-256 등) 합니다.
이렇게 해시한 값을 Finger Print(지문) 이라고 합니다.
이제 이 지문을 CA의 비밀키로 암호화 하고,
인증서의 발급자 서명으로 등록합니다.
이렇게 서명된 것을 디지털 서명 (Digital Signing) 이라고 합니다.
이제 CA는 서버에게 이 디지털 서명, 발급자 정보 등등이 등록되어 있는 인증서를 발급해 줍니다.
이러한 방식처럼,
상위 인증 기관이 하위 인증서가 포함하고 있는 공개키 (인증서)를 상위 기관의 비밀키로 암호화 하여
상호 보증하게 되는 것을 인증서 체인(Certificate Chain) 이라고 합니다.
내가 발급받는 CA 기관이 Root CA가 아니라면, 이 CA 기관마저 또 상위 CA에게 인증서를 발급받은 것입니다.
보통 3단계에 걸쳐서 인증서 체인이 일어나는데,
①
tistroty.com의 인증서는 그 상위 인증서인
Thawte TLS RSA CA G1의 인증기관(Intermediate CA)의 비밀키로 암호화 된 것이며,
②
Thawte TLS RSA CA G1 인증서는 그 상위 인증서인
DigiCert Global Root G2의 인증기관의 비밀키로 암호화 된 것입니다.
③
DigiCert Global Root G2는 상위 인증기관이 없는 Root CA이기 때문에 Self-Signed 되어 있어요.
Self-SIgned (스스로 보증) 이란,
자신의 인증서를 해시한 후, CA가 아닌 자신의 비밀키로 암호화 하여 서명으로 등록
하는 것을 말합니다
이게 바로 인증서 체인입니당!!
이해 가셨길!!!! :)))))
CA 인증 없이 인증서를 생성할 수 있을까?
가능합니다 :D 심지어 TLS 통신도 가능해요.
물론, 신뢰성은 떨어지겠지만 아예 불가능한 일은 아니예요.
CA 인증과 상관 없이 발행하는 인증서를 사설 인증서 라고 합니다.
이 사설 인증서는 Root CA처럼 Self-Signed 되어 있습니다.
때문에 보증기관이 없으며, 따라서 누구도 보증해주지 않는 인증서입니다.
이러한 사설 인증서를 사용하여도 TLS 통신을 할 수 있어요.
대신 공인 기관에서 발급받은 인증서가 아니란 정도는 사용자에게 알려줘야겠죠?
(가끔 홈페이지 들어가면 "신뢰할 수 없는 사이트입니다 "라는 안내문을 보신 적 있나요?
사설 인증서를 사용할 경우 공인 인증서가 아니기 때문에 그런 안내문이 뜹니다.)
4. SSL(TLS) 인증서로 서버를 인증하는 방법
CA에서 발급받은 인증서를 통해 서버의 신뢰성을 인증한다고 했어요.
근데 클라이언트는 이 인증서가 CA에서 발급받은 것인지, 중간에 누가 조작한 것인지 확인은 어떻게 할까요..!?
만약 누가 가짜로 만든 인증서일 수도 있잖아요!!!
그럼 어떠한 방식으로 인증되는지 볼까요?
먼저 알아 둘 것은, 클라이언트들은 CA 리스트를 이미 갖고있습니다.
OS를 설치할 때 PC에 포함되거나 브라우저가 포함하고 있습니다.
(Mac에는 keyChain에, 브라우저는 소스코드에~~)
여기서 CA 리스트란, 공인으로 인증된 CA기관들의 리스트들로,
그들의 🌟공개키🌟도 함께 갖고 있습니다(중요) :D
.
.
서버를 인증하는 방법은
위 내용도 모두 정리할 겸 전체적인 내용으로 봐볼게요 :)
① 서버 : 야 우리 믿을 수 있는 서버라고 인증서 발급 받자!
서버는 자신이 믿을 수 있는 서버임을인증하기 위해 CA에서 인증서를 발급받으려 합니다.
그러기 위해선 자신의 사이트 정보(도메인 등)과 사이트의 공개키를 CA에 제출해야 겠죠?
그러면 CA는 검증을 걸친 후 제출받은 서버의 공개키를 해시하여 CA의 비밀키로 암호화 합니다.
그리고 서버에게 이런 정보들이 들어 있는 인증서를 발급해 줍니다.
서버는 이제 자신이 진짜 서버임을 인증해줄 인증서를 갖고 있는 것입니다.
② 클라이언트 : 야 서버! 나랑 통신하고 싶으면 인증서 내놔!
자, 이제 클라이언트가 이 서버에 접속하려고 합니다.
TLS 통신에서 클라이언트와 서버는 서로 몇번 인사를 주고 받으며
서버는 CA에서 발급 받은 자신의 인증서를 클라이언트에게 전달합니다.
근데 띠용?
누군가 중간에 해킹해서 인증서를 바꿔치기 했다거나,
교묘하게 인증서의 공개키를 해킹범의 공개키로 바꿨을 수도 있잖아요.
그렇다면 인증서의 무결성은 어떻게 입증할까요!?
먼저, 클라이언트는 먼저
이 인증서가 자신이 가진 CA 리스트에 있는 기관에서 발급받은 것인지 확인합니다.
이것이 확인되면, 해당 CA 기관의 공개키로 서버 인증서의 서명(Digital Signing)을 복호화 합니다.
(CA는 자신의 비밀키로 인증서를 암호화를 하였으니, 공개키로 복호화가 가능합니다.)
디지털 서명을 복호화 하면, 인증서 내용을 해시한 값이 나오겠죠?
이처럼 디지털 서명을 CA 기관의 공개키로 복호화 하여 나온 해시 값과,
공개키를 해시한 값(지문)이 일치 한다면, 인증서가 위조되지 않았음을 인증하는 것입니다.
당연히 일치하지 않는다면 인증서가 위조되었다는 말이겠죠?!
글로 설명하면 어렵기 때문에
이해를 돕기위해 그림을 그려 봤어요 :)
만약, 인증서의 공개키가 임의로 수정된 값이라면
이 공개키를 해시한 값은 서명을 복호화한 값(원본 공개키의 해시 값)과 전혀 다른 값이 나오겠죠?:)
이런 방식으로 서버 인증서의 무결성을 검증할 수 있어요!
흠.. 근데 이부분에 대해서 막 명확한 자료를 제가 못찾았어서ㅠㅠ
제가 이해한 것을 바탕으로 작성 해봤는데, 혹시 틀린 내용 있으면 꼭 피드백 주세요!!
③ 클라이언트 : 서버 너 믿을만한 놈이었구나? 이제 암호화 통신하자!
클라이언트는 이제 서버가 CA 인증기관에서 인증받은 신뢰할 수 있는 서버임을 알았습니다.
또한, 인증서 안에 들어 있는 서버의 공개키도 알았습니다.
이제 서로 통신을 주고받기 위해 클라이언트는 자신이 사용할 '대칭키'를 서버에게 전달해 줘야 합니다.
어떻게요? 이전에 공부했던 TLS 암호화 방식을 통해서요!
클라이언트는 서버의 공개키로 대칭키를 암호화 하여 서버에게 보내고,
서버는 자신의 비밀키로 이를 복호화 하여 클라이언트의 대칭키를 알아내는 것입니다.
그럼 이제 둘은 사이좋게 대칭키로 암,복호화 하여 통신을 하는 것입니다.
.
.
.
자, 기나긴 대장정이 거의 다 끝났습니다.
이전 포스팅에서 TLS가 암호화를 하는 방법에 대해 공부했는데,
이제 그 암호화를 CA 인증서를 통해 어떻게 진행하는지 아시겠나요?
상당히 흥미롭지 않나요?
TLS 공부를 하면서, 처음엔 어렵기도 하고 이걸 어떻게 코드로 적용하나 막막하기만 했는데, 재밌었어요 :))))))))
근데요. 여기서 포스팅은 끝이 아니예요.
사실 이 과정만 알아도 전체적인 이론을 이해하는 데 무리는 없다만!
근데 다음 포스팅에선 위에서 이론적으로만 설명한 부분들을 좀 더 깊게 살펴볼 거예요.
서버와 클라이언트가 서로 인사 몇 번 하며 인증서를 검토하고 암호화하여 통신하고..
뭐.. 그런 과정들을 한다 했죠? 이를 handshake 한다고 표현해요.
쨌든, 위에선 간단하게 설명했지만, 서로 악수를 주고 받으며
Client Hello, Server Hello 하며 통신하는 부분에 대해 좀 더 깊게 다뤄볼 거예요.
그리고 마지막에 세션을 종료하는 것까지.
이것들에 대해 다 공부하고 나면 이제 당신은 TLS 마스터 ଘ(੭*ˊᵕˋ)੭
이번 포스팅은 이만 마칠게요.
틀린 내용이나 궁금한 점이 있으시면 댓글 남겨 주세요 :D
감사합니다
+) 생각보다 많은 분들이 TLS 포스팅을 보러 오셔서;;; 왜인진 모르겠지만;;;;;
그래서 그림까지 추가해서 더 보충했습니다..!! 누군가에겐 꼭 도움이 되었길!!
'기타 > TLS' 카테고리의 다른 글
| TLS(SSL) - 3. Handshake (18) | 2020.05.16 |
|---|---|
| TLS(SSL) - 1. TLS의 암호화 방식(대칭키, 비대칭키) (16) | 2020.03.31 |
