약 3년 전, 구글 크롬은 암호화되지 않은 모든 사이트(HTTP)에 대해 '안전하지 않음' 표시를 하기 시작했습니다. 웹브라우저와 서버 간의 통신의 암호화를 의무로 하여 보다 안전한 통신을 추구하고자 하는 듯합니다. 여러분들도 크롬을 사용하여 사이트에 접속하면 사이트 주소 왼편에 자물쇠를 눌러 안전 여부를 확인할 수 있습니다. 그렇다면 브라우저와 서버는 어떻게 암호화 통신을 하는 것일까요? 그 과정에 대하여 알아보고자 합니다.
HTTPS
HTTPS가 무엇인가에 대해서 먼저 짚고 넘어가야 합니다.
HTTPS(HyperText Transfer Protocol over Secure Socket Layer, HTTP over TLS, HTTP over SSL, HTTP Secure)는 월드 와이드 웹 통신 프로토콜인 HTTP의 보안이 강화된 버전이다. HTTPS는 통신의 인증과 암호화를 위해 넷스케이프 커뮤니케이션즈 코퍼레이션이 개발했으며, 전자 상거래에서 널리 쓰인다.
HTTPS는 소켓 통신에서 일반 텍스트를 이용하는 대신에, SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화한다. 따라서 데이터의 적절한 보호를 보장한다. HTTPS의 기본 TCP/IP 포트는 443이다. 보호의 수준은 웹 브라우저에서의 구현 정확도와 서버 소프트웨어, 지원하는 암호화 알고리즘에 달려있다. HTTPS를 사용하는 웹페이지의 URI은 'http://'대신 'https://'로 시작한다.
출처 : 위키백과
HTTPS란 HTTP의 보안이 강화된 버전으로 HTTP를 기반으로 하여 웹서버와 통신을 하되 암호화 통신을 위한 별도의 협의 과정을 거친다는 것을 의미합니다. 그 협의 과정에 SSL(Secure Socket Layer)과 TLS(Transport Layer Security, SSL 강화버전)이라는 프로토콜을 사용하여 데이터를 암호화합니다. HTTP는 'TCP'를 기반으로 하는 프로토콜입니다. TCP를 이용한 3-way handshake(연결 협의)를 거친 후에 HTTP를 사용하여 페이지를 얻어오기 때문이지요. 그리고 웹브라우저와 웹서버의 통신에는 IP가 필요합니다. 그렇기 때문에 HTTPS의 기본 'TCP/IP' 포트를 언급하는 것입니다. 암호화 알고리즘(암호화 수단)을 어느 것을 선택하느냐에 따라 암호화의 강도가 달라지며, HTTPS를 사용하는 웹페이지는 웹사이트 주소를 'HTTPS://'로 시작합니다.
HTTPS의 '추상적' 통신 과정(부제 : 클라이언트는 서버를 믿지 않는다.)
(추상적이라고 한 이유는 SSL handshake, 공개키, 개인키, 대칭키와 같은 요소가 전혀 언급되지 않기 때문입니다. 2번째 3번째 글에서 다루고 있습니다.)
앞서 말한 것처럼 웹브라우저와 서버가 통신하기 위해서는 HTTPS를 사용합니다. 그리고 HTTPS를 통해 내 소중한 데이터를 서버와 주고받게 되지요. 여기서 부딪치는 첫 번째 문제는 과연 이 서버가 진짜인가 하는 것입니다. 만약 서버가 가짜임을 모르고 중요한 데이터를 넘겨주게 된다면 큰 피해를 볼 수밖에 없습니다. 그래서 서버가 진짜임을 인증하기 위해 공인기관으로부터 별도의 인증서를 받게 되는데 이를 'SSL 인증서'라고 합니다. 이 인증서를 통해 서버가 진짜임을 검증하게 되면, 그 후부터 서로의 데이터를 어떻게 암호화할 것인지 다음단계를 협상하게 됩니다. 지금부터는 검증과정을 알아보도록 하겠습니다.
가끔 뉴스를 보다보면, 미성년자들이 위조된 신분증을 가지고 술집에 가서 술을 마시다가 가게들이 영업 정지당한다는 소식을 듣습니다. 업주들에겐 참으로 억울한 일이 아닐 수 없죠. 그래서인지 요즘엔 주민등록증을 가지고 지문을 대조하여 진짜인지 가짜인지를 확인시켜주는 단말기가 있다더군요. 왜 이런 말을 하냐고요? 이 과정이 HTTPS 통신과정과 일치하기 때문입니다. ^______^
자! 위의 그림을 가지고 설명을 시작하겠습니다.
1. 성인 : "나도 이제 20살이니, 주민등록증을 발급받고 당당하게 술집에 가야겠다. 민증을 발급받기 위해 내 지문 정보를 제공해야겠지?"
2. 동사무소 : "음 지문정보와 생년월일을 확인해보니 본인이 맞고 이제 성인이시군요. 지문을 주민등록증에 붙여서 발급해드리겠습니다."
3. 술집 : "미성년자 같은데... 일단 주민등록증은 발급받았단 말야...이게 진짜인지 아닌지 모르겠네....."
4. 술집 : "이 주민등록증을 발급한 동사무소에 의뢰해야겠다."(실제로는 단말기가 지문을 대조합니다.)
5. 동사무소 : "네. 이건 제가 발급한 주민등록증이 맞고, 이것을 가진 사람은 성인입니다."
6. 술집 : "아 그렇군~, 어서 오세요~ 술은 무엇으로 드릴까요?"
7. 술집과 성인 : "이 술 주시고, 저 술 주시고, 안주는 이것으로 주시고....."
위의 인증과정에서는 주민등록증(SSL 인증서)이 가장 큰 역할을 하고 있습니다. 술집 주인(웹 브라우저)과 성인(서버)이 주문을 받고 음식을 제공(암호화된 통신)을 할 수 있게 되었군요. 앞서 말했듯 SSL 인증서는 이 서버가 진짜인지 아닌지를 증명하는 존재입니다. 가끔 붉은색 표시와 함께 '신뢰할 수 없는 사이트'라고 뜨는 이유도 이 SSL 인증서 때문이지요. 이처럼 SSL 인증서는 서버의 신분증과 같은 역할을 합니다. 이를 다시 HTTPS 통신 과정으로 변형해보겠습니다.
1. 서버 : "내가 쇼핑몰 사이트 하나를 만들었는데 말이야... 내가 진짜 쇼핑몰 사이트라는 걸 웹브라우저들이 믿게 하고 싶어. 그러면 내 도메인 주소를 비롯한 정보를 제공하고 공인 인증기관인 CA에게 SSL 인증서를 발급받아 신뢰를 얻자"
2. 인증기관(CA) : "제출하신 도메인 주소와 사이트 관련 정보 등을 검토한 결과, 실제 운용 중인 사이트로 판명됩니다. SSL 인증서를 발급해드리니 서버 외부에 게시하시기 바랍니다."
3. 웹브라우저 : "이 서버가 쇼핑몰 사이트라는데... SSL 인증서가 있구먼.. 근데 이게 진짜인지 어떻게 알지?'
4. 웹브라우저 : "그렇지! 이걸 발급한 인증기관에게 물어보자"
5. 인증기관(CA) : "이건 제가 발급한 인증서가 맞으며, 이 인증서를 보유한 서버도 쇼핑몰 사이트가 맞습니다."
6. 웹브라우저와 서버 : "서버가 진짜구나. 이제 우리 데이터를 어떻게 암호화할 것인가에 대해 협상하자!"
웹브라우저가 서버를 신용하게 되었으므로 웹브라우저와 서버는 데이터를 어떻게 암호화할 것인지에 대해 협상을 하기 시작합니다. 이 협상에 사용되는 암호화 알고리즘의 집합이 바로 Cipher Suite이며, 이 전반적인 과정을 SSL Handshake(TLS Handshake)라고 합니다. 이제 서버와 웹브라우저는 암호화에 사용할 키를 어떻게 공유할 것인지, 키를 어떤 알고리즘으로 만들어 데이터를 암호화할 것인지 협상을 하게 될 것입니다.
HTTPS 통신과정을 간략하게 다루어 보았습니다. #2에서는 현 문서에서 다룬 검증과정에서 'Key'라는 존재가 어떻게 활용되는지 좀 더 다루어 보도록 하겠습니다. 감사합니다.
'Network Infra 쉽게 이해하기 > HTTPS 쉽게 이해하기' 카테고리의 다른 글
| HTTPS 통신과정 쉽게 이해하기 #3(SSL Handshake, 협상) (27) | 2020.03.23 |
|---|---|
| HTTPS 통신과정 쉽게 이해하기 #2(Key가 있어야 문을 열 수 있다) (11) | 2020.03.21 |
| SSL/TLS #4, Forward Secrecy와 디피 헬만 키교환 방식, RSA 키교환 방식 (4) | 2020.03.20 |
| SSL/TLS #3, MAC(Message Authentication Code) (2) | 2020.03.20 |
| SSL/TLS #2, 인증서 검증과 Chain (2) | 2020.03.20 |
댓글