HTTPS와 HTTP의 차이점. 핵심은 SSL/TLS [ 네트워크 면접질문 6 ]
WHY
CS에서 보안 질문을 직접적으로 하는 편은 드문데 그 이유는 네트워크에서 질문할 수 있기 때문이라고 생각한다.
대부분의 보안은 네트워크와 연관된 경우가 많기에 네트워크 분야를 공부하다 보면 자연스럽게 보안 지식도 마주하게
된다.
해당 질문은 보안 + 네트워크 두마리 토끼를 잡을 수 있는 질문으로 상황에 따라 HTTP로 깊게 들어가는 질문으로 나아갈지 보안으로 깊게 들어가는 질문으로 나아갈지 선택할 수 있다.
다음의 질문으로 한 단계 더 깊게 들어갈 수도 있다.
1. SSL/TLS 인증 절차의 과정. [ 상당히 깊게 들어간 질문이다. ]
2. 비대칭 암호와와 대칭 암호화가 TLS에서 사용되는 이유.
3. HTTP에 어떤 문제점이 있는지
등등.. 다양한 스펙트럼으로 나아갈 수 있다. 그만큼 해당 질문과 연계된 지식이 상당히 많다는 것!!
해당 질문을 공부하면서 오랜만에 암호화 공부도 하게 되었다.
배경
인터넷의 등장과 함께 프라이버시 문제가 언급되게 되었다.
인터넷을 기반으로 개인 맞춤형 서비스를 진행하다 보니 로그인을 통해 사이트에 고유한 개인 정보를 저장하게 되었고
전자상거래를 통해 은행과 계좌와 관련된 비밀정보도 오가게 되었다.
그러다 보니 상당히 중요한 개인정보가 유출되는 경우가 생기기 시작한다.
[ DB가 유출되거나.. 네트워크를 통해 도청되거나..]
HTTPS는 HTTP가 전송하는 데이터가 암호화되지 않은 부분을 보완한 프로토콜이다.
TLS 계층을 거치는 방식으로 HTTP를 운영하여 HTTP의 전송 메시지 바디(전송되는 데이터가 있는 부분)를 암호화시키는 것이다.
구글은 2014년에 대부분의 사이트에 HTTPS를 사용하라고 권고했고 검색 엔진 가산점 정책에 HTTPS를 추가시켜서 많은 사이트가 HTTPS로 전환하게끔 이끌었다. [ 사용자에게 더 안전한 사이트를 연결해주겠다는 정책이기에 멋지다고 생각한다. ]
핵심 정보
HTTP와 HTTPS의 차이점은 간단하다. 보안 적용의 유무이다.
보안의 핵심에는 SSL/TLS 프로톨과 CA 인증 메커니즘에 있다.
HTTP는 SSL/TLS 인증서를 사용하지 않고 HTTPS는 SSL/TLS 인증서를 사용한다.
"인증서를 사용한다"??라는 말이 무엇일까. 아래에서 살펴보도록 하자. 이 부분이 가장 큰 핵심이다.
HTTP와 HTTPS
HTTP는 클라이언트-서버 구조에 사용되는 프로토콜이다.
요청-응답 구조를 가지며 인터넷에서 가장 많이 사용되는 프로토콜인 HTTP.
HTTP의 단점은 "보안이 적용되지 않은 데이터"를 전송한다는 것이다. 상당히 위험하다.
네트워크의 전형적인 공격인 "중간자 공격"에 취약하고 언제든지 데이터가 도청될 수 있는 네트워크 환경에서는 네트워크를 사용하는 내내 위험하다고 볼 수 있다.
거기에다가 신뢰할 수 없는 서버에 개인 정보를 전송하게 되면 어떻게 될까?
EX 똑같은 웹 사이트로 사용자를 속이는 경우.
HTTP 자체는 보안에 상당히 취약한 프로토콜이라고 말할 수 있다. [
그래서 예전에는 브라우저 혹은 호스트 측에서 강력한 보안이 필요한 경우 플러그인 방식으로 필요한 애플리케이션을 설치했다. ]
HTTPS는 HTTP에 TLS 계층을 더한 것이다.
- TLS(SSL의 개선된 버전)은 서버와 브라우저 사이에 안전하게 암호화된 데이터를 전송할 수 있게 해 준다.
- HTTP는 80 포트를 사용하고 HTTPS는 443번 포트를 사용한다.
암호화 메커니즘을 통해 암호학에서 핵심으로 두는 3가지 보안 기능성을 얻게 된다. (CIA)
1. 기밀성(Confidentiality)
교환되는 데이터를 도청해도 의미가 없게끔 데이터가 강력한 암호 알고리즘으로 암호화된다.
대칭 알고리즘을 통해 암호화와 복호화된다.
2. 무결성(Integrity)
정보가 중간에 변질되지 않았음을 보장하는 것이다. (중간에 중요한 정보만 가로채거나 수정하는 것을 방지)
클라이언트와 서버는 전자 서명(Digital Signature)을 통해 통신을 맺어 신뢰성을 확보한다.
3. 인증(Authentication)
응답자가 안전한 응답자인지 어떻게 알 수 있을까?
이를 위해서 인증서 제도를 운영한다. 인증서 기관을 통해 해당 서버가 안전한 서버라는 것을 확인할 수 있다.
HTTPS는 요약하면 다음을 통해 보안성을 강화한다.
1. 클라이언트는 CA 인증서를 확인해서 안전한 서버임을 확인한다.
2. 클라이언트와 서버는 공개키/개인키(비대칭 암호화)를 통해서 안전한 통신 세션을 맺는다.
3. 공개키/개인키로 공유한 대칭키를 통해서 데이터를 암호화 복호화하여 데이터의 기밀성을 얻는다.
SSL/TLS를 살펴보고 CA에 대한 정보 그리고 실제 HTTPS의 통신 절차를 확인해보자.
SSL과 TLS
둘 다 네트워크를 통해 작동하는 서버, 시스템 및 응용 프로그램 간에 "인증 및 데이터 암호화"를 제공하는 암호화 전용 프로토콜이다. SSL은 TLS이전의 프로토콜로 2015년에 SSL 3.0은 지원이 중단되고 TLS가 사용되고 있다.
SSL 프로토콜이 남긴 레거시로 현재도 많은 분야에서 TLS와 SSL을 같은 표현으로 사용하기도 한다.
(SSL/TLS 이렇게 묶는다.)
짧게 보는 SSL(Secure Socket Layer) 역사
SSL과 TLS은 OSI 모델(7 계층)의 presentation 레이어에서 처리된다.
넷스케이프(브라우저의 전신)에 의해 개발되었으며 1995년 SSLv2를 통해 처음 공개된다.
몇 가지 취약점을 빠르게 개선해 1996년에 SSLv3으로 대체되었다. [ 버전 2는 2011년에 버전 3은 2015년에 폐지된다. 이후 TLS가 암호화 메커니즘을 담당한다. ]
- 공개키/개인키와 대칭키를 기반으로 암호화를 적용한다.
TLS (Transport Layer Security)
1999년에 SSL의 새 버전으로 도입된다. SSLv3을 기반으로 하며 SSLv3의 개선 버전이다.
SSL이라는 표현이 일반적으로 사용되고 있어서 현재도 보안 인증서를 SSL 인증서라고 부른다.
HTTPS는 웹 사이트를 SSL/TLS 인증서로 보안하는 경우를 의미한다.
공개키 암호화 (비대칭 암호화)
- 공개키로 데이터를 암호화하여 공개키 소유자에게 보낸다. 공개키 소유자는 개인키로 복호화한다.
[ 공개키는 데이터를 암호화하는 용도이고, 개인키는 데이터를 복호화하는 용도이다. ]
암호화 절차가 까다롭기에 데이터를 암호화하기보다는 서로의 신원을 확인하거나 특정 데이터( 대칭키 )를 공유하는 용도로 사용한다.
대칭키 암호화 (대칭 암호화)
암호화와 복호화에 같은 "비밀키"를 사용한다.
빠르게 데이터를 암호화/복호화할 수 있으나 상대방이 안전한 사람인지 확인할 방법이 없다.
그래서 비대칭 암호화로 안전한 상대인지 확인하고 이후의 데이터를 대칭키로 암호화/복호화하는 하이브리드 방식으로 진행한다.
SSL/TLS 디지털 인증서 [ CA를 통해 보장받는다. ]
클라이언트와 서버 간의 통신을 공인된 제삼자(CA)가 보증해주는 문서이다. 해당 문서를 통해 서버의 안정성을 보장받을 수 있다. [ 주소 입력창 HTTPS 프로토콜 쪽에 자물쇠로 확인 가능! ]
클라이언트로 하여금 접속하려고 하는 서버가 신뢰할 수 있는 서버인지 확인하는 데 사용한다.
SSL/TLS 디지털 인증서가 적용되어야 구글 검색 엔진에서 가산점을 받을 수 있다.
TCP/IP 세션을 연결하는 3-way handshake 다음으로 보안을 위한 SSL/TLS handshake 과정을 거친다.
송신자와 수신자가 암호화된 데이터를 교환하기 위한 협상과정을 거치는 것이다.
SSL 인증서 전달.
대칭키( 데이터 암호화 복호화에 사용할 비밀키) 전달.
암호화 알고리즘 결정
등이 처리된다.
[ 우측에 시간을 보면 TCP 핸드셰이크 과정보다 TLS 핸드셰이크 과정이 2배 정도 길다는 것을 알 수 있다. ]
TLS handshake 절차
1. Client Hello [ 사용 가능한 암호화 알고리즘을 전달 ]
1. 세션 아이디 [ 해당 세션을 재사용하기 위함 ]
2. TLS 프로토콜 버전 [ 호환성 체크 ]
3. 랜덤 바이트 정보
4. 사용 가능한 암호화 목록(ciper suite 정보)을 전달한다.
[ 프로토콜, 키 교환 방식, 인증서 검증용, 대칭키를 이용한 블록 암호화 방식, 메시지 인증 등등이 해당된다. ]
2. Server Hello (서버의 응답) [ 클라이언트가 제공한 알고리즘 목록 중 하나 선택 + CA 인증서 전달 ]
클라이언트의 가능한 암호화 목록 중 하나를 선택하여 클라이언트에 응답한다.
Server는 인증 기관(CA)의 개인키(비밀키)로 암호화하여 "서버의 SSL/TLS 인증서"를 Client에 전달한다.
[ 인증서의 경우 CA의 비밀키로 암호화된 상태이다. ]
임의의 난수를 전달한다.
3. Client Certificate 처리 [ 서버의 인증서 확인 + 앞으로 교환할 비밀키 전달 ]
인증서 내부에는 서버가 발행한 공개키가 들어있다.
클라이언트는 서버가 보낸 암호화된 SSL 인증서를 CA의 공개키로 복호화한다.
[ 브라우저는 이 과정을 수월하게 처리하기 위해서 CA들의 정보와 CA가 만든 공개키를 미리 설치해둔다. ]
CA가 만든 인증서인지 확인하기 위해서 CA의 공개키로 암호화된 인증서를 복호화한다.
[ 여기서 실패하면 브라우저 경고를 보낸다. ]
복호화에 성공했다면 해당 인증서는 CA의 개인키로 암호화되었음을 확인하게 되면서 CA의 인증을 받았다는 것을
확인하게 된다.
3 - 1). key Exchange
클라이언트는 대칭 암호화에 사용할 비밀키를 서버의 공개키( CA 개인키로 암호화된 정보를 CA 공개키로 복호화해서 알아낸 정보)로 암호화하여 서버로 전송한다.
이 정보를 premaster secret이라 부른다.
해당 비밀키가 앞으로의 데이터를 암호화하고 복호화에 사용될 것입니다.
4. 서버의 처리 [ 비밀키 확인. SSL/TLS 연결 종료. 이후 데이터 교환 ]
서버는 자신의 공개키로 암호화된 클라이언트가 보낸 premaster secret을 서버의 개인키로 복호화한다.
이로써 클라이언트와 서버는 데이터 암호화 복호화에 사용할 비밀키를 공유하게 된다.
Finished 패킷을 보내면서 SSL Handsake를 종료하고 이후 비밀키를 통해 암호화 복호화 과정을 처리하게 된다.
마무리
"네트워크" 항목에 속하지만 사실상 보안과 관련된 정보가 상당히 많다.
네트워크와 보안은 긴밀하게 연결되어 있는데 그 교차점을 통해 두 지식을 모두 확인하기 좋았던 지식이라 생각한다.
핵심은 SSL/TLS Handshake 과정. 내부 패킷과 알고리즘에 더 깊이 들어가 보고자 한다면 참고자료 마지막의
aws-hyoh님의 블로그 글 시리즈를 참고하기를 바란다(상당히 유익하다).
해당 글을 정리하지 않았다면 HTTP에 보안이 적용된 프로토콜이라고 대답하고 멈췄을 것 같다.
다음에 질문이 온다면
배경.
SSL/TLS.
보안의 핵심 기능인 CIA를 어떻게 확보할 수 있는지.
CA인증서와 TLS 핸드 셰이크 처리
등등으로 답변할 수 있을 것 같다.
지금 보면 난이도가 상당히 높은 질문으로 생각된다.
다음으로는 TCP와 UDP의 차이점을 살펴보고자 한다.
- 참고자료
- 우아한 테트 코스 : 다니의 HTTPS : link [ HTTPS의 과정을 쉽게 이해할 수 있다. ]
- Hello Digital World : 12장 프라이버시와 보안.
- 초보몽키의 개발공부로그 : link [ 그림설명이 good! ]
- TLS와 SSL의 차이점 : link
- 그림으로 보는 HTTPS, SSL/TLS : link [ CA의 3가지 목표 : link ]
- TLS와 SSL의 차이점 : link [ SSL와 TLS의 역사를 배울 수 있다 ]
- 깃헙(WearSoft) : link [ 깔끔한 정리 ]
- aws-hyoh님의 블로그 : link [ CA + SSL handshake 에 대한 깔끔한 정리 ]
개인적으로 이 분의 블로그가 HTTPS 정리의 끝판왕이지 않을까 싶다. - 상진강 님의 브런치 글 : link