Hypertext: 참조를 통해 한 문서에서 다른 문서로 즉시 접근할 수 있는 텍스트(즉, 다른 페이지의 링크를 담고 있는 텍스트)
Transfer: 전송
Protocol: 통신 규약
http는 인터넷 상에서 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약이다.
- 주로 HTML 문서를 주고받는 데에 쓰인다.
- 비연결성(Connectionless): 한번 연결을 맺은 후에 클라이언트의 요청에 대해 서버가 응답을 마치면 연결을 끊어버린다.
- 무상태 프로토콜(Stateless protocol): 서버가 클라이언트의 상태를 유지하지 않아 서버는 클라이언트를 식별하지 못한다.
- 암호화 없이 평문으로 전송하기 때문에 도청이 가능하다
- 통신 상대를 확인하지 않기 때문에 위장이 가능하다
- 데이터의 무결성을 보장하지 않기 때문에 변조가 가능하다
HTTP: Hypertext 통신 규약
over Secure Socket Layer | over TLS | over SSL | HTTP Secure: 보안을 통한
소켓 통신에서 SSL/TLS 프로토콜을 사용하여 서버 인증과 데이터 암호화를 통해 더 안전하게 사용 가능한 프로토콜이라고 할 수 있다
SSL (Secure Sockets Layer)과 TLS (Transport Layer Security)은 네트워크 통신에서 데이터의 보안 및 기밀성을 제공하기 위한 프로토콜이다.
네스케이프에 의해서 SSL이 발명되었고, 이것이 점차 폭넓게 사용되다가 표준화 기구인 IETF의 관리로 변경되면서 TLS라는 이름으로 바뀌었다(TLS 1.0은 SSL 3.0을 계승한다). 일반적으로는 구분없이 SSL이라 말한다.
- CA(Certificate Authority,디지털 인증서를 제공하는 공인된 기업)를 통한 인증서 방식
- 대칭 키, 공개 키(비대칭키) 암호화 방식을 모두 사용
- 하나의 키로 암호화와 복호화를 모두 수행하는 방식
- 키 전달, 관리에 어려움이 있다.
- 디지털 서명 기법 적용 불가
-
암호화에 쓰이는 키 값과 복호화에 쓰이는 키 값이 다른 방식
-
개인키로 암호화 한 정보는 그 쌍이 되는 공개키로만 복호화가 가능하고, 공개키로 암호화한 정보는 그 쌍이 되는 개인키로만 복호화가 가능
-
공개키가 유출된다고해도 비공개키를 모르면 정보를 복호화 할 수 없기 때문에 안전함
암호화 과정- 암호학적으로 연관된 두개의 키를 생성한다
- 하나를 비공개키(private key, 개인키, 비밀키)로 지정하여 자신만 가지고, 나머지를 공개키(public key)로 지정하여 타인에게 제공한다
- 타인은 공개키를 이용해서 정보를 암호화하고 비공개키를 가지고 있는 사람에게 전송한다.
- 비공개키의 소유자는 이 키를 이용해서 암호화된 정보를 복호화한다.
[공개키로 암호화] -> [개인키로 복호화]
공개키로 암호화한 정보는 그 쌍이 되는 개인키로만 복호화가 가능.
인가할 사용자의 공개키로 암호화 하여 데이터를 전송 -> 인가된 사용자만 볼 수 있음
[개인키로 암호화] -> [공개키로 복호화]
개인키로 암호화 한 정보는 그 쌍이 되는 공개키로만 복호화가 가능.
임의의 암호문이 A의 암호문인지 확인하려면 A의 공개키로 복호화가 가능한지 확인 하면 됨
:서버에 인증서를 발급해주는 공인된 기관들
SSL을 통해서 암호화된 통신을 제공하려는 서비스는 CA를 통해서 인증서를 구입해야 한다.
- 클라이언트가 접속한 서버가 신뢰 할 수 있는 서버임을 보장한다.
- 서비스의 정보(인증서를 발급한 CA, 서비스의 도메인 등등)를 가짐
- SSL 통신에 사용할 공개키를 클라이언트에게 제공한다.
- 서버 측 공개키(공개키의 내용, 공개키의 암호화 방법)를 가짐
- 인증서를 받기 위해 CA로 서버의 정보와 서버의 공개 키를 전달
- CA의 비밀 키로 암호화하여 인증서를 발급
- 서버는 클라이언트에게 요청을 받으면, 인증서를 보내줌
- 브라우저(클라이언트)는 CA 리스트와 CA의 공개 키를 내장하고 있기 때문에, 인증서를 복호화하여 서버의 정보와 서버의 공개 키를 얻을 수 있음 (+ 해당 서버가 신뢰할 수 있는 서버임을 알게 됨)
동작의 핵심
실제 데이터: 대칭키 방식으로 암호화
해당 대칭키의 전달: 공개키 방식으로 암호화해서 클라이언트와 서버가 주고 받는다.
컴퓨터와 컴퓨터가 네트워크를 통해서 통신을 할때 핸드쉐이크 -> 세션 -> 세션종료 의 과정을 거친다.
암호화된 HTTP 메시지를 교환하기 전에 클라이언트와 서버는 SSL 핸드쉐이크를 진행한다.
클라이언크가 서버에게 인사! 랜덤한 데이터("hi")와 지원 가능한 암호화 방식, 세션 아이디를 전달
*세션 아이디 : 이미 SSL 핸드쉐이킹을 했다면 비용과 시간을 절약하기 위해서 기존의 세션을 재활용하게 되는데 이 때 사용할 연결에 대한 식별자를 서버 측으로 전송한다.
서버가 클라이언트에게 인사!
랜덤한 데이터("hello")와 지원 가능한 암호화 방식, CA에서 발급받은 인증서를 전달
클라이언트에 내장된 CA의 공개키를 이용해서 인증서를 복호화하여 서버의 정보와 서버의 공개 키를 얻는다. 복호화에 성공했다면 인증서는 CA의 개인키로 암호화된 문서임이 암시적으로 보증된 것이다. 즉, 신뢰할 수 있는 서버임이 증명됨
그리고 1-2 과정에서 교환한 랜덤 데이터 "hi"와 "hello"를 조합하여 pre master secret(임시 키)를 생성한다.
pre master secret 키는 이후 데이터를 주고 받을 때 암호화를 위해 사용 될 키이므로 제 3자에게 절대 노출되어서는 안된다.
때문에 이 키를 공개키 방식으로 교환한다.
3단계에서 얻은 서버의 공개키로 pre master secret 키를 암호화 하여 전송한다.
서버는 자신의 개인키로 암호화 된 pre master secret 키를 복화화 하여 키를 얻는다.
이로서 서버와 클라이언트가 모두 같은 키를 가지게 된다.
클라이언트와 서버는 일련의 과정을 거쳐 pre master secret 값을 master secret 값으로 만든다.
master secret는 session key를 생성하는데 이 session key 값을 이용해서 서버와 클라이언트는 데이터를 대칭키 방식으로 암호화 한 후에 주고 받는다
클라이언트와 서버는 핸드쉐이크 단계의 종료를 서로에게 알린다.
공개 키 암호화 방식은 보안은 확실하지만, 복잡한 연산과 많은 시간을 소모한다. 만약 공개키를 그대로 사용하면 많은 접속이 몰리는 서버는 매우 큰 비용을 지불해야 한다.
반대로, 대칭키 암호화 방식은 대칭키를 상대에게 전송해야 하는데, 암호화가 되지 않은 인터넷을 통해서 키를 전송하는 것은 위험하다.
그래서 속도는 느리지만 데이터를 안전하게 주고 받을 수 있는 공개키 방식으로 대칭키를 암호화하고, 실제 데이터를 주고 받을 때는 대칭키를 이용해서 데이터를 주고 받는 것이다.
Reference
RAON CTF - WEB Essential
HTTPS (HTTP Secure)
HTTPS와 SSL 인증서
그림으로 쉽게 보는 HTTPS, SSL, TLS