HTTP?
웹 브라우저와 웹 서버가 통신할 때 규칙이 필요한데 이러한 규칙을 HTTP(Hyper-Text Transfer Protocol)라고 한다. HTTP는 클라이언트 - 서버 구조를 따르고 있다. 이는 클라이언트(= 웹 브라우저)에서 서버로 요청하고 서버에서 클라이언트에게 응답하는 형태이다. 서비스를 요청하고 제공하는 쪽이 명확하기 때문에 단방향 통신이다. (요청자는 계속 요청하고 응답자는 계속 응답만 하므로 단방향!)
HTTP의 자세한 설명은 HTTP를 참고하자.
HTTP의 문제점
HTTP는 서버와 통신 시 텍스트 형태의 평문으로 데이터를 주고받기 때문에 데이터를 탈취하거나 변조할 위험성이 크다. 따라서 네트워크 통신 시 데이터를 감청할 수 없도록 별도 처리를 해야 하는데 이런 보안 개념을 적용한 것이 HTTPS(Hyper-Text Transfer Protocol Secure)이다.
HTTPS를 이해하기 위한 배경지식
암호화 / 복호화
암/복호화의 종류로는 대칭키 암호화와 비대칭키 암호화가 있다.
대칭키 암호화는 데이터를 암호화/복호화할 때 같은 키를 사용한다. 대칭키 암호화의 단점은 키를 공유하는 과정에서 탈취당할 수 있다. 그렇게 되면 탈취자가 암호화된 데이터를 복호화할 수 있게 된다.
비대칭키 암호화는 데이터를 암호화/복호화할 때 다른 키를 사용한다. A키로 암호화하면 B키로 복호화할 수 있고, B키로 암호화하면 A키로 복호화할 수 있다. 공개키와 개인키를 사용하는데 공개키는 외부적으로 공개하지만 개인키는 공개하지 않는다.
HTTPS는 기존에 평문으로 전송하던 데이터를 암호화/복호화한다. 암호화와 복호화하기 위해서는 Key가 필요하다. HTTPS에 사용하는 암호화 방식은 대칭키 암호화와 비대칭키 암호화를 혼합해서 사용한다.
전자서명
전자서명은 네트워크를 통해 전달되는 디지털 메시지 또는 문서에 대한 진위성(authenticity), 무결성(integrity), 부인 방지(non-repudiation) 특성을 제공한다. 즉 전자서명된 메시지 또는 문서는 신원이 확인된 서명자에 의해 생성되었으며, 송수신 과정에서 내용이 수정되거나 조작되지 않았음을 증명하는 것과 같다.
비대칭키 암호화 방식으로 전자서명을 구현할 수 있다. 위 과정에서 제3자가 중간에 공개키를 탈취해 데이터를 복호화할 수 있는 위험이 있지만 목적은 데이터 보호가 아니라 전달받은 문서(데이터)가 공개키와 쌍을 이루는 개인키로 암호화되었는지 확인해 문서(데이터)를 제공한 쪽의 신원을 파악하는 것이다.
CA
CA(Certificate Authority) : 인증기관, 디지털 서명을 이용한 전자상거래 등에 있어서 누구나가 객관적으로 신뢰할 수 있는 제3자를 의미
CA는 인증서의 진위를 보증하는 회사를 의미한다. 아무 기업이나 할 수 있는 것이 아니고 엄격하게 공인된 기업들만 참여할 수 있다. 대표적으로 Symantic (VeriSign), Comodo, GoDaddy, GlobalSign 등이 있다. HTTPS 프로토콜을 사용하여 암호화된 데이터를 전송하려면 서버는 위에서 언급한 CA 기업에서 인증서를 구입해야 한다. 이때 보안 수준이 높은 CA의 경우 인증서를 내어주기 전 사업자 등록 번호 등의 문서를 요구하는 경우도 있다.
Google의 Chrome, Apple의 Safari, MS의 Edge 등의 브라우저에 선별된 CA 리스트와 함께 각 CA의 공개키를 탑재한다. 이 부분을 꼭 기억하자.
SSL 인증서란?
SSL 인증서란 서버가 CA로부터 발급받은 문서(파일)를 의미한다. 서버는 클라이언트와 네트워크 통신 시 인증서를 클라이언트에게 전송한다. 클라이언트는 전달받은 인증서가 신뢰 가능한지 검증하고 신뢰 가능하다고 판단되면 보안 연결을 수립한다.
인증서를 통해
- 클라이언트와 통신하는 서버를 신뢰할 수 있는지 보장한다.
- SSL 통신에 사용할 서버의 개인키와 대응하는 공개키를 클라이언트에게 제공한다.
SSL 인증서 계층
인증서는 계층 구조로 구성되어 있다.
- Root 인증서
- ICA 인증서
- 개인 인증서
Root 인증서는 모두 신뢰하기로 약속한 기관의 인증서이며 대표적으로 GeoTrust가 있다. Root 인증서는 일반적으로 브라우저에 내장되어있다.
ICA 인증서는 중간에 위치한 인증서로 Google과 같은 신용도가 높은 회사가 Root CA의 인증서의 전자 서명을 받아 만든 인증서이다.
계층적으로 인증서를 구성하는 이유는 CA의 비밀키가 유출될 경우를 대비한 구성으로 이해하면 될 것 같다. 각 계층의 인증서는 상위 CA를 통해 검증이 가능하고 Root 인증서의 경우 상위 계층이 없어 자기 자신을 검증한다.
SSL 인증서 내용
- 인증서 버전
- 일련번호
- 인증서 서명 알고리즘
- 발행기관
- 지문
여기서 지문에 주목해보자. 지문은 인증서의 내용을 종합해서 해시화한 값이다. 이 지문을 상위 CA의 비밀키로 암호화한다. 인증서의 지문은 인증서의 신뢰성을 보장할 때 사용되는 부분이니 이 부분을 꼭 기억하자!
SSL 인증서가 신뢰성을 보증하는 방법
위 이미지에서 개인 인증서가 어떻게 상위 인증서의 보증을 받는지 알아보자.
우선, 선행조건으로 SSL 인증서를 발급받기 위해서 개인 인증서의 지문을 상위 인증서를 발급한 ICA의 비밀키로 암호화해달라고 요청한다.
개인 인증서가 신뢰할 수 있는지 판단하려면,
- 암호화된 지문을 ICA의 공개키로 복호화한 값과
- 개인 인증서의 내용을 해시함수로 계산한 해시값을 비교한다. 비교한 값이 같으면 개인 인증서의 내용이 위조/변조되지 않았고 이미 신뢰하기로 약속한 ICA의 개인키로 암호화되었다는 것을 통해 해당 개인 인증서는 신뢰할 수 있다.
해시 알고리즘 : 같은 입력값에 대해서는 같은 출력값이 보장되며, 입력 값과 관계없이 고정된 길이의 데이터를 반환한다.
HTTPS
HTTP는 웹 브라우저와 서버가 통신하기 위해 사용하는 프로토콜이라면 HTTPS는 여기서 더 나아가 통신하는 데이터를 SSL/TLS 프로토콜을 이용해 암호화하는 것을 의미한다. HTTPS는 SSL/TLS 레이어 위에서 동작한다.
SSL과 TLS는 같은 말이다. 네스케이프에 의해 SSL이 발명되었고, TLS라는 명칭으로 변경되었다. 하지만 SSL 이름도 많이 사용하니 참고하자!
HTTPS 통신 과정
- Handshake
- 세션
- 세션 종료
1. Handshake
실제 데이터를 전달하기 전 Handshake 과정을 거친다. 이 과정에서 상대방이 존재하는지, 또 상대방과 데이터를 주고받기 위해 허용할 수 있는 암호화 방법 등을 파악한다.
서버는 클라이언트에게 인증서를 전송하고 클라이언트는 인증서를 검증한 후 서버의 공개키를 획득한다. 클라이언트는 대칭키를 생성한 후 서버의 공개키로 암호화한다. 대칭키는 서버로 전달되고 서버의 개인키로 복호화한 후 대칭키를 획득한다. 이로써 클라이언트, 서버 모두 대칭키를 가지고 있다.
비대칭키 암호화는 대칭키를 공유할 때 일회성으로 사용한다. 그 이유는 비대칭키 암호화는 컴퓨팅 자원을 많이 사용하기 때문이다. 서버의 자원은 한정적이기에 실제 데이터를 주고받을 때는 효율성이 좋은 대칭키 암호화 방식을 사용한다. 이를 통해 대칭키 공유 시 유출의 문제점을 해결했다.
2. 세션
세션은 실제로 서버와 클라이언트가 데이터를 주고받는 단계이다. 대칭키(세션키)를 이용해 데이터를 암호화/복호화한다.
3. 세션 종료
데이터 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려준다. 이때 대칭키(세션키)를 폐기한다. 실제 세션이 시작되고 종료되기까지 시간은 아주 짧기 때문에 해커가 암호화된 내용을 해독하여 탈취하는 일은 사실상 불가능하다고 한다.