초보자를 위한 HTTPS, SNI, 서버인증서, SSL Proxy

 

 

INTRO

많은 회사에서 외부(=인터넷)와 주고 받는 트래픽을 모니터링하고 있습니다. 그래서 종종 "사내 자료를 외부로 이메일 전송하다 적발" 이런식의 보안사고(?) 공지사항이 올라올때가 있습니다. 

SSL(=TLS)을 이용하지 않을 경우 어떤 내용을 외부로 업로드 했는지 알 수가 있습니다. 보통 사내 -> 사외 로 나가는 구간의 트래픽을 모니터링하면 되니까요. 

그런데 SSL 즉 암호화 통신을 하는 경우 트래픽을 모니터링 해봤자 그 내용을 알 수가 없습니다. 암호화된 내용을 복호화할 수 있는 key 가 없기 때문이죠. 

그래서 https://mail.naver.com/ 과 같이 이메일 사이트 자체를 접근하지 못하도록 하기도 합니다. SSL 위에 HTTP 가 올라가므로 mail.naver.com 이라는 도메인도 암호화가 될듯 한데 어떻게 알아낼까요? SNI 라는 것에 힌트가 있습니다.(아래에서 자세히 다룹니다.)

 

위와 같이 특정 사이트 접근을 막더라도, https://www.naver.com/  와 같이 이런 곳에 접근을 막으면 뉴스에 나올겁니다. 네이버에서 검색창에 입력하는 내용까지 모니터링을 하고 싶다면 어떻게 해야할까요? SSL Proxy에 답이 있습니다. 

이번 포스팅에서는 SSL Proxy 까지 이해하는걸 목표로 그 기초인 HTTPS, 서버인증서 부터 차근차근 알아보겠습니다.

 

SSL Proxy 

최종 목표인 SSL Proxy를 맨 앞에 구성했습니다. 아래  SSL Proxy 내용을 모두 이해할 수 있다면 그 아래의 HTTPS, 서버 인증서 등을 읽을 필요가 없습니다. 못알아듣겠으면 아래 HTTPS, 서버인증서 를 이해해야 한다는 뜻이겠죠? 동기부여를 위해 앞에 배치했습니다. :)

 

PC --------------------- naver  

일반적으로 PC의 웹브라우저에서 naver 에 접속한다면 위와 같이 PC 와 naver 서버가 직접 연결됩니다. 

naver는 HTTPS 로만 제공되므로 서버인증서를 PC에 알려주고, 이를 통해 비대칭키방식으로 대칭키방식에 사용할 비밀키 를 공유합니다. 이 후 양단간 대칭키방식으로 통신을 합니다. 

위와 같은 상황에서 트래픽을 중간에 가로채더라도 비대칭키방식의 개인키(private key) 나 대칭키방식의 비밀키 를 모르기에 어떤 내용을 주고 받는지 알수가 없습니다.

 

PC -- naver 구성방식에서 제 3자 즉 회사나 해커가 중간에서 복호화가 불가능한 이유는 개인키나 비밀키를 모르기 때문이라고 했습니다. 그렇다면 key 를 알수 있도록 구성을 하면 됩니다. 

 

PC -- SSL Proxy --- naver 

 

위와 같이 중간에 SSL Proxy 라는 서버를 두고, PC는 SSL Proxy 와 암호화통신을 하고, SSL Proxy 는 naver 와 암호화통신을 하는 겁니다. 즉 SSL Proxy 가 "PC -- SSL Proxy" 에서는 서버로 동작하고 , "SSL Proxy --- naver " 에서는 클라이언트로 동작합니다. 

 

"PC -- SSL Proxy"

PC 입장에서는 SSL Proxy 의 서버로 연결하는게 아닌 naver.com 으로  연결하려고 한것이므로 SSL Proxy 에는 naver.com 의 서버인증서가 있어야 하고 이 인증서와 매핑된 개인키도 가지고 있어야 합니다. 

naver.com 인증서는 공개되어 있으니 구하기 쉬우나 개인키는 naver.com 회사가 가지고 있는데 어떻하죠?

해킹해서 개인키를 훔쳐올수도 없으니, naver.com 의 인증서를 직접 만들어버리면 됩니다. 즉 가짜 인증서를 만들어 버리는 겁니다. 이러면 인증서와 개인키를 모두 알게 됩니다.

인증서를 만드는 것 자체는 간단합니다.  

아래는 java 의 keytool 로 인증서 생성하는 방법에 대한 사이트이니 더 궁금하면 확인해보세요.

https://velog.io/@jummi10/keytool%EB%A1%9C-local%EC%97%90%EC%84%9C-SSL-%EC%9D%B8%EC%A6%9D%EC%84%9C-%EC%83%9D%EC%84%B1-%EB%B0%8F-%EC%A0%81%EC%9A%A9

 

인증서 만드는게 어려운게 아니므로, 중요한건 이 인증서가 신뢰할만하다.. 라는 인증 도장을 받는게 중요합니다. 그래서 "서버 인증서" 파트에서 인증서 발급기관, 최상위 인증서 발급기관 등이 존재한다고 말했습니다. 

그런데 , 제 3자 즉 회사는 naver.com 의 주인이 아닌데 naver.com 의 인증서를 만들었으니 어떻게 보면 위변조 한것이고 이러니 당연히 인증서 발급기관에서 "인증"을 해주지 않게 됩니다. 

그러나 회사가 Root CA 의 인증서 마저도 직접 만들고 이를 windows 나 linux 의 인증서 저장공간에 등록을 해둔다면 사설 Root CA 인증서는 해당 컴퓨터에서는 Root CA 로 신뢰를 받게 됩니다.

따라서 외부의 인증서 발급기관에게 "가짜로 만든 인증서이긴 한데 인증 좀 해주세요" 라고 할 필요가 없습니다. 제일 힘이 쎈 Root CA 인증서도 회사가 가지고 있으니까요. 그래서 이 사설 Root CA 를 가지고 naver.com 가짜 인증서에 "인증 도장"을 찍어줍니다. 

 

보통 서버 인증서를 열어보면 아래처럼 CA 기관정보가 나오는데, 사설 Root CA 로 인증한 경우 사설 Root CA의 정보가 나오게 됩니다. 지금 다니는 회사의 PC 에서는 사설 Root CA 정보가 보이는데, 보안상 그걸 캡쳐해서 여기 올리기 어렵겠습니다.

 

"SSL Proxy --- naver" 

이제 나머지 부분인 "SSL Proxy -- naver" 구성을 살펴보겠습니다.

SSL Proxy 는 단순 클라이언트 입장이므로 추가로 할게 없습니다. PC 에서 요청 한 사이트로 대신 접속해서 정보를 가져오고, 이를 PC로 넘겨주기만 하면 됩니다.

 

 

 

전체 흐름을 정리하면 아래처럼 암호화 구간이 2개로 나누어져 있습니다.

PC ----(구간A)---- SSL Proxy ----(구간B)---- naver

1) PC 에서 hello 라고 검색 요청을 보냈다고 합시다.

2) 구간A 에서는 PC 와 SSL Proxy 간 암호화 통신을 합니다. SSL Proxy 는 서버 입장이므로 개인키를 가지고 있어서 복호화가 가능합니다.

3)SSL Proxy 는 복호화가 가능하므로 hello 라는 문자열을 알수가 있으며, 이를 다시 진짜 naver 서버와 암호화 통신을 합니다. 즉 네이버 서버와 암호화 통신 협상을 통해 알아낸 key 로 "hello" 문자열을 암호화해서 전달합니다.

4) naver에서 "검색한 결과 내용" 을 암호화해서 전달합니다. 구간B

5) SSL Proxy는 "검색한 결과 내용" 을 복호화 합니다. 이를 다시 PC-- SSL Proxy 에서 사용하고 있는 key 를 이용해서 다시 암호화 합니다.

6) PC 는 이를 복호화해서 화면에 보여줍니다.

 

꽤나 복잡한 구성이나 이렇게 하면 회사입장에서는 모든 HTTPS 트래픽을 복호화할수 있으니 보안 관리 risk 가 많이 줄어들게 됩니다.

하지만 대부분의 HTTPS 사이트에 대해 위와 같이 인증서를 하나씩 따로 만들어야 하는 번거로움이 있게 됩니다.

또한 1번 암호화할것을 2번 하게 되고, SSL Proxy 로 모든 HTTPS 트래픽이 몰리게 되므로 성능 문제도 발생할 수 있습니다. 그래도 최악보다는 차악을 선택하는게 나으니 이렇게 SSL Proxy 로 구성을 많이 합니다.

 

SSL Proxy 가 할수 있는 기능은 지금 언급한것 외에도 더 많이 있습니다. 보안관점에서의 SSL Proxy 기능을 여기서 다루었다고 보면 되겠습니다.

 

이 파트가 잘 이해되지 않으며 아래 파트들을 모두 읽어보시면 됩니다. :)

 

 

참고: Proxy 란 용어는 최종/원본 이 아니라 그 앞에 놓여진 것을 뜻합니다. 용도로는 캐시, 흐름제어, 공통 로직 수행등을 합니다. 즉 network 전용 용어가 아니라 프로그래밍에서도 사용됩니다. 

 

 

ref. 아래는 유사 내용을 다루는 참고사이트 입니다. 함께 읽으면 이해가 더 쉬워집니다.

https://xenostudy.tistory.com/639

[Linux Admin] 리눅스에서 ssl https 사설인증서 사용하기

 

wireshark

네트워크 트래픽 분석을 위해 wireshark 라는 패킷캡쳐/분석툴을 이용할겁니다. 설치 및 사용법은 아래링크를 참고하세요

https://semtul79.tistory.com/3

네트워크계의 CCTV - wireshark 로 network trouble shooting 한방에 끝내기

 

HTTPS 

본 파트는 동영상 설명이 있습니다.

https://youtu.be/-FiSsm6wHv4

 

 

HTTPS 를 알아보기 전에 먼저 HTTP에 대해 알아보겠습니다.

테스트를 위해 아래 HTTP 사이트로 접속하고 패킷 캡쳐를 해봅니다.

http://jsonplaceholder.typicode.com/

위와 같이 HTTP 는 IP > TCP > HTTP layer 순으로 패킷을 구성하며 패킷 캡쳐만으로도 어느 사이트에 접속하는지를 나타내는 Host 헤더를 통해 어느 사이트에 접속하는건지 알수 있습니다. 여기서는 jsonplaceholder.typicode.com 라고 적혀있네요.

 

이제 HTTPS 확인을 위해 

네이버 메일 사이트인 https://mail.naver.com/ 이곳으로 접속하고 패킷 캡쳐를 확인해봅니다. 

 

아래처럼 HTTP 라는 protocol 이 보이지 않고 TCP 나 TLS 만 보입니다. 또한 payload 를 보면 알수 없는 데이터만 보입니다.

 

 

이제 TLS protocol 로 된 패킷 하나를 클릭해서 상세 정보를 봐봅시다.

 

위와 같이 IP > TCP > TLS 순으로 layer 가 구성되는걸 알 수 있습니다. 또한 payload 부분이 암호화되어 있는것도 볼 수 있습니다. 암호화된 부분은 아마도 HTTP layer 에 있는 모든 데이터가 될겁니다.

 

이렇듯 SSL ( = TLS ) 은 TCP 위에 위치하면서 최상위 layer 인 L7 혹은 application layer의 데이터를 모두 암호화시켜줍니다. 그래서 위에 보이듯이 이게 HTTP 를 암호화한건지, FTP를 암호화한건지 조차 알수가 없습니다.

 

위 내용만 보면 https://mail.naver.com 과 같은 사이트에 접속시,  트래픽 모니터링을 해도 "네이버 메일"로 접속하는지를 알수가 없다고 생각될 겁니다. 물론 "네이버 메일" 사이트의 실제 공인 ip 를 알아낸 후 IP layer 에 있는 목적지 IP 주소를 기준으로 필터링을 해도 되나, 도메인이 아닌 ip 주소기반으로 필터링 하므로 언제 ip 가 변경될지 모르기에 100% 확실하지 않는 방법이며, 해당 ip 를 가진 서버중 일부가 www.naver.com  과 같은 네이버메인 페이지 서버역할을 하게 될 경우, 이 사이트가 필터링될수도 있으므로 아주 위험한 방법이라고도 볼 수 있습니다. 

암튼, 네이버 메일 사이트처럼 특정 도메인에 대해서만 필터링하는 기술은 SNI 부분에서 추가적으로 더 자세히 다루겠습니다.

비대칭키 암호화 ( 공개키, 개인키 )

가장 쉬운 암호화 방법은 양단간에 동일한 비밀키를 공유해서, 이를 가지고 암호화하고 복호화 하는 방법입니다.

이를 대칭키 암호화 방법이라고 하죠. "알집" 과 같은 프로그램으로 압축할때 비밀번호 걸어서 압축걸수 있는데 이때 쓰이는 방법이 대칭키 암호화입니다. 암호화,복호화에 동일한 비밀번호를 이용하니까요.

 

그럼 위의 대칭키 암호화를 쓰면 될텐데, 왜 비대칭키 암호화라는게 있을까요?

대칭키 암호화의 방식은 양단간에 동일한 비밀키를 공유한다고 위에 적었습니다. "알집" 같은건 암호화하고 복호화하는 주체가 모두 동일인 일 확률이 높으니 비밀키 공유가 아주 쉽습니다. 그냥 기억하고 있으면 되는거죠. 

그러나 네이버 사이트와 같은 경우, 익명의 수많은 클라이언트(=웹브라우저)가 접속을 하는데, 각 클라이언트마다 비밀키를 따로 전달해줘야 합니다. "비밀키 공유"가 전제조건이기 때문입니다. 그러나 비밀키 공유를 위해 비밀키를 클라이언트에 전달할때는 암호화를 아직 할수가 없으니 일반 평문으로 전달됩니다. 이러면 중간에서 패킷을 가로채서 볼 경우 비밀키가 제 3자에게도 공유되어 버리므로 문제가 있습니다.

이런 이유로, 서로 다른 2개의 키를 통해 암/복호화가 되는 방식을 연구해서 찾아냈고 그게 비대칭키 암호화 방식입니다. 즉 A 라는 문자열과 B 라는 문자열. 이렇게 2개 문자열이 key 가 됩니다.

즉 아래처럼 A 로 암호화한걸 B 로 복호화가 가능합니다. 이게 말이되는거임? 이라고 생각들겠지만, 더 자세한건 수학 영역이라서 이정도로 마무리 하겠습니다. ;;

hello  + A 로 암호화 ==> A#FADF

A#FADF + B로 복호화 ==> hello 

단 A로 암호화한걸 A로 복호화는 불가능함. -> A 라는 key 를 이용해서 암호화한 데이터를 A 라는 key 를 이용해서 복호화는 불가능하다는 뜻

그러나, A로 암호화후 B로 복호화 or B로 암호화 후 A 로 복호화는 모두 가능.  

 

네이버에 HTTPS 로 접속해서 통신시 암호화 문제를 다시 생각해봅시다. 

비대칭키의 2개 키중 하나를 네이버 서버만 간직합니다. 이 key 는 네이버 서버에만 저장되어야 하는 비밀스럽고 개인적인 key 로 사용되므로, 이를 개인키 혹은 비밀키 라고 부릅니다. 영어로는 private key 라고 합니다. 

그리고 나머지 키 하나를 모든 클라이언트(=웹브라우저)에게 전달해줍니다. 모두에게 공개되는 성격의 key 이므로 이를 공개키라고 부르며 영어로는 public key 라고 합니다. 

 

클라이언트에서 hello 라는 문자열을 암호화해서 네이버에 보내고자 할 경우 , 클라이언트가 알고있는 공개키로 암호화해서 네이버 서버로 전달합니다. 중간에 해커가 이걸 가로채더라도 복호화하려면 개인키가 필요하나 개인키는 네이버 서버만 가지고 있기 때문에  해커는 복호화 불가능합니다.  이렇게 데이터를 아무나 못 보게 하는걸 "데이터 보안"이라고 부릅니다. 

 

네이버 서버에서 클라이언트로 world 라는 문자열을 암호화해서 보내고자 할 경우 개인키로 암호화를 합니다. 공개키로 암호화해서 보내도 되지 않나? 생각할수도 있으나 클라이언트는 개인키를 가지고 있지 않으니 복호화가 불가능합니다. 

개인키로 암호화된 데이터에 대해 클라이언트는 공개키를 가지고 있으니 이를 복호화 할 수 있습니다. 그러나 해커가 이 패킷을 가로챈 후 공개키로 복호화하면 이 또한 복호화가 가능합니다. 공개키는 이름 그대로 공개되어 있기에 아무나 알 수 있기 때문입니다. 

즉 개인키로 암호화하는건 "너만 이걸 해독할수 있어" 라는 관점에서는 아무 효과가 없습니다.

그러나, 공지사항과 같은 중요한 메시지를 클라이언트에 전달할때는 의미가 있습니다. 즉 아무나 봐도 되는데, 이 메시지가 "네이버"에서 보낸것인지만 확실히 하면 되는곳에 의미가 있다는겁니다.

"내일 1시간동안 네이버 메일이 중단됩니다" 라고 공지사항을 각 클라이언트에 보내야 한다고 합시다. 개인키로 이 문자열을 암호화 한 후 클라이언트에 보내고 클라이언트는 공개키로 복호화해서 위 내용을 알 수 있습니다. 게다가 개인키/공개키 쌍이 맞아야만 제대로 복호화가 되므로, 이 메시지는 네이버가 보낸게 확실하다 라고 봐도 됩니다.  이를 "인증" 이라고 부릅니다.

 

아직 네이버에서 클라이언트로 "데이터 보안"관점에서 데이터를 내려주는 방법이 아직 해결 되지 않았습니다. 이 부분은 뒤의 서버 인증서 파트에서 다루겠습니다. 답만 적자면 대칭키 암호화 방식도 함께 사용해서 해결합니다.

 

비대칭키 방식은 원리자체가 선뜻 이해되지 않는 만큼이나 실제 암/복호화시 CPU 를 많이 사용하는 단점이 있습니다. 그래서 대칭키 방식과 함께 쓰이면서 보통 동작합니다. 이 부분도 서버 인증서 파트에서 다루겠습니다.

 

참고: 개인키, 비밀키 라는 용어는 대칭키, 비대칭키 방식에서 모두 사용되고 있습니다.  서적이나 기술블로그에 별 구분없이 동일하게 사용되니 너무 용어자체에 신경쓸 필요는 없고 공개되지 않은 key 라고만 알면 됩니다.

 

대칭키/비대칭키 암호화 기법에 대한 좀 더 자세한 부분은 아래 포스팅에서 확인하길 권장합니다.

https://myjamong.tistory.com/293

대칭키 / 비대칭키 양방향 암호화 기법

 

SNI

 

SNI 는 Server Name Indication 의 약자입니다. 서버 이름을 나타낸다 라고 해석하면 되며, TLS layer 안에 있는 필드이며 아래에서는 lcs.naver.com  이라는 도메인으로 접속하려는 트래픽임을 알 수 있습니다.

 

엥? mail.naver.com 에 접속하려는거 아니었나요? 라고 의문이 들겁니다. 네이버 메일 사이트에 접속시 내부적으로 naver 의 여러 다른 사이트에도 함께 접속하도록 네이버측에서 만들어둔것이니 그냥 그러러니.. 하면 됩니다.

중요한것은 TLS layer 내에 접속하려는 서버의 도메인 정보가 일반 text 로 보여진다는 겁니다.

 

SNI가 생긴 이유를 짧게 적자면, 하나의 서버에서 2개 도메인에 대해 서비스를 제공하고 싶은 경우가 종종 있습니다.

아래와 같은 구성이라고 생각하면 됩니다. 

PC -- reverse proxy server(web server) ------   A 도메인 서버/프로세스

                                                                |------  B 도메인 서버/프로세스

 

HTTP 일 때는 proxy server 는 Domain 이라는 HTTP 헤더 필드를 통해 2개 도메인중 어느 도메인에 접속하려는건지 알수 있으니 이 정보를 통해 특정 도메인 서버 or 프로세스로 전달이 가능합니다.

그러나 HTTPS 로 제공할 경우, HTTP의 Host 필드는 암호화되어 있습니다. 그래서 HTTPS 핸드쉐이크 과정에서 인증서를 내려줘야 하는데 어떤 걸 내려줘야 할지 알수가 없습니다. 다행히? SNI 필드는 암호화가 되어 있지 않아 이걸 보고 올바른 인증서를 내려줄 수가 있습니다. 

이런 이유로 SSL 이지만 도메인 정보만큼은 암호화하지 않고 전송되게 됩니다. 

이 방식을 잘 활용하면, 암호화 통신을 하더라도 중간에서 트래픽 모니터링을 하면 실제 데이터를 복호화해서 알아낼 수는 없더라도 어느 사이트(=도메인)에 접속하려는지는 알수가 있는겁니다.

 

이를 활용해서 SK브로드밴드, KT..와 같은 인터넷 서비스 업체(ISP) 에서는 불법 사이트 ( 도박,음란..)에 접속하려는 HTTPS 연결을 찾아낼 수 있고, 이를 차단할 수 있습니다.  일부에서는 이를 두고 "인터넷 검열" 이다라고 항의하기도 했습니다. 

 

암튼, 암호화 관점에서는 SNI 라는 건 SSL의 빈틈? 과 같은 존재입니다.

서버 인증서

국민은행 사이트에 접속하고 아래처럼 자물쇠 모양 아이콘을 누르면 국민은행의 서버 인증서를 볼 수 있습니다.

발급대상 필드에 www.kbstar.com  이라고 국민은행 도메인 정보가 들어가 있습니다.

즉 이 인증서는 www.kbstar.com  도메인에 대한 서버 인증서 라는걸 알 수 있습니다.

옆 탭의 "자세히"를 누르면 공개키 필드를 찾을 수 있습니다. 즉 서버인증서 내에는 공개키 가 들어있습니다.  서버인증서는 아무 클라이언트(=웹브라우저)에 모두 공개되고 있으므로 결국 국민은행의 공개키도 공개되고 있는것입니다. 즉 서버인증서를 공개함으로써 공개키를 전달합니다.

주민등록등본 등을 발급받으면 발급번호, 인증번호 와 같이 "진짜임" 을 나타내는 정보가 필요합니다. 그게 바로 "인증 경로" 탭 정보입니다. 아래처럼 국민은행 인증서는 Thawte EV... ( 써트 라고 읽음 ) 라는 인증기관에서 인증해줬다고(=발급해줬다고) 나옵니다.  그리고 Thawte EV... 라는 인증서는 DigiCert High ... 라는 인증기관에서 인증해줬다고(=발급해줬다고) 나옵니다.  다단계 빚보증 서는 느낌이 드네요 ;; .  그럼 맨 위에 있는 DigiCert High... 라는 인증기간도 누군가 보증해줘야 하는거 아닌가 ? 라고 생각할 수 있습니다. 사실 말은 맞는데 이렇게 꼬리에 꼬리를 물고 다른 인증기관이 인증(보증)을 해줘야 하는데 무한대로 반복될 뿐입니다. 그래서 국제 인증 기관에서 몇몇 기관(회사)에 최상위 인증기관이 될 수 있는 권한을 부여해줬습니다. 그리고 그 최상위 인증기관 명단(=인증서정보들)을 공개적으로 알려주고 windows, mac , linux 와 같은 OS 에서 이를 참고해서 OS 설치시 최상위 인증기관의 인증서를 함께 저장을 해둡니다. 유사하게 java 나 python 혹은 특정 프로그램들도 자체적으로 위 최상위 인증기관의 인증서 정보를 특정 위치에 저장해서 쓰거나 ,OS에 저장되어 있는 최상위 인증기관 인증서 정보를 참조해서 쓰고 있습니다. 즉 무조건 신뢰할수 있는 인증서를 미리 어디간 저장해둬서, 그 인증서에 대해서는 추가적인 보증을 확인할 필요가 없도락 한것입니다.

 

 

아래처럼 certmgr.msc 라고 검색창에 넣고 엔터를 칩니다.

그러면 아래처럼 해당 PC 에 저장된 신뢰할 수 있는 인증서 내역을 알 수 있습니다. 즉 추가적인 보증이 필요없는 무조건 믿어도 되는 인증서들 리스트 입니다. 

이제, 비대칭키 파트에서 풀지못한 네이버 -> 클라이언트로 "데이터 보안" 문제를 이제 풀어보겠습니다.

대칭키 방식의 유일한 단점은 비밀키 공유가 되어야 한다는 전제입니다. 

이를 해결한게 비대칭키 방식이고요

이 둘을 섞어서 쓰면 뭔가 더 좋은 방법이 있지 않을까요?

우선 비대칭키를 이용해서, 클라이언트에서 "A 라는 문자열을 대칭키 암호화의 key 로 쓰자" 라는 내용을 암호화해서 서버로 전달합니다. 위에서 봤듯이 이건 "데이터 보안"측면에서 잘 동작합니다.

서버는 이를 복호화한후 그 다음부터 A 라는 문자열로 암호화해서 데이터를 보냅니다. 

클라이언트는 A 라는 문자열을 key 로 쓴다는걸 알고 있으니 복호화가 가능합니다. 그러나 해커가 중간에서 이 내용들을 훔쳐보고 있었다라도 "A 라는 문자열을 대칭키 암호화의 key 로 쓰자" 라는 내용은 복호화를 못하기에 제일 중요한 A 라는 문자열이 key 라는 정보를 알지 못합니다. 그러니 대칭키 암호화 통신의 내용을 복호화하지 못합니다.

즉 비대칭키로  대칭키 암호화에 쓰일 key 정보를 공유합니다. 이후부터는 대칭키 암호화 방식으로만 통신합니다.

이러면 성능이 느린 비대칭키방식을 초반에만 쓰게 되며, 성능이 좋은 대칭키 방식을 초반 이후로 계속 사용할 수 있으니 성능이 좋아집니다. 

그리고 서버 인증서는 공개되어 있고, 서버 인증서내에는 공개키 가 들어있기에, 서버 인증서 공개만으로도 비대칭키 암호화 통신을 할 수 있게 된것입니다.

 

아래 링크에 비대칭키,대칭키를 이용한 암호화통신을 그림으로 좀 더 쉽게 표현한게 있으니 정리삼아 아래 링크도 확인해보세요

https://run-it.tistory.com/28

SSL[Secure Soket Layer]?대칭키?비대칭키?

 

인증서

위에서 서버 인증서를 다루었습니다. 좀 더 범용적인 의미로 인증서를 생각해봅시다.

우리에게 제일 친숙한 인증서는, 개인용 공인인증서 입니다. 은행이나 증권사이트에서 무료로 발급받는 그 인증서 말입니다.

 

제 PC의 경우 아래처럼 NPKI 디렉토리 내에 저장되어 있고 .der 이라는 확장자를 가진 인증서 파일.

그리고 .key 라는 확장자를 가진 개인키 파일 .. 이렇게 2개 파일로 구성됩니다. 즉 인증서를 발급 신청하면 인증서 + 개인키 이렇게 2가지를 발급해줍니다. 이건 개인용 공인인증서만 그런게 아니라 서버 인증서를 발급 기관에 신청해서 받더라도 동일합니다. 

.der 확장자를 더블 클릭하면 아래처럼 서버인증서와 동일한 모양의 창이 나오며 발급대상에 naver.com 과 같은 서버 도메인이 아닌 홍길동() 1233434-33 처럼 이름과 일련번호같은게 나옵니다. "자세히"탭을 클릭하면 이 또한 동일하게 공개키 정보가 보입니다.(그림은 생략함)

 

은행사이트에 이체를 할 경우, 공인인증서를 선택하라고 나옵니다. 이를 통해 서버(=은행 사이트)에 개인인증서를 공유하게 됩니다. 이 말은 서버에 나의 공개키를 전달해주는 겁니다.

내 PC 에는 개인키가 저장되어 있으며, 서버에는 공개키가 전달되었습니다.

이게 뭔가요? 비대칭키 암호화 통신 조건이 갖추어 진것입니다. 이제 은행 이체 금액 등등의 정보를 암호화해서 송수신 할 수 있으며, "내가 xxx에게 100만원을 송금했음" 이라는 사실을 나의 개인키로 암호화해서 서버로 전달함으로써 사실 증명. 즉 "인증" 도 함께 해줍니다. 즉 "데이터 보안" 과 "인증" 이 모두 수행됩니다.

 

서버 인증서나 개인 인증서나 결국 인증대상이 서버냐 개인이냐의 차이일뿐 나머지는 동일합니다.

 

참고: 인증서 발급 기관을 영어로 CA ( Certificate Authority) 라고 부르며, 최상위의 인증서 발급기관을 Root CA 라고 부릅니다.  즉 Root CA 는 보증이 더 이상 필요없는 인증서 발급기관이며, 이 기관에서 그 하위의 인증서 발급 기관(CA)를 지정해 주는 역할도 합니다.

즉 Root CA  도 인증서 보증 역할을 할 수 있고, CA 도 인증서 보증 역할을 할 수 있습니다. 그러나 CA 는 반드시 Root CA 의 보증이 필요하고 Root CA는 추가적인 보증이 필요 없습니다. 

 

아래에서 DigiCert High ... 로 시작하는 것이 Root CA 이며

그 하위의 Thawte EV ... 로 시작하는게 CA 입니다. 

본사 - 해외법인. 혹은 경찰청 - 파출소 , 구청 - 주민센터 . 뭐 이런 느낌이라고 보면 됩니다. 

만약 맨 위의 SSL Proxy 가 이해되지 않아서 여기까지 읽었다면, 이제 다시 맨 위의 SSL Proxy 부분을 읽으면 술술 이해가 될겁니다. :)

 

 

도움될 사이트:

생활코딩 사이트에 SSL 관련 엄청 자세하게 적혀있습니다. 아주 자세합니다;;;

https://www.opentutorials.org/course/228/4894

HTTPS와 SSL 인증서 - 생활코딩

 

* 도움이 되었다면 "좋아요" 부탁드립니다.