1. HTTPS
1.1. HTTPS와 HTTP
- HTTP(HyperText Transfer Protocol)는 HyperText인 HTML 문서를 전송하기 위한 프로토콜이다.
- 마지막에 S를 붙인다면 Secure라는 뜻으로 보안이 강화된 통신규약을 의미한다.
- HTTP는 암호화가 되어있지 않은 방법으로 서버에 데이터를 전송하기 때문에 서버와 클라이언트가 서로 주고받는 메시지를 알아내기가 쉽다.
- 그러므로 서버로 비밀번호나 계좌번호 등 중요한 데이터를 서버로 전송할 경우에는 HTTPS 프로토콜을 사용하여 통신하는 것이 중요하다.
1.2. HTTPS와 SSL
- HTTPS는 SSL 프로토콜을 기반으로 돌아가는 프로토콜 중 하나다.
2. SSL
1.1. SSL 이란
- Secure Socket Layer라는 암호 규약
- SSL은 '보안 계층'이라는 독립적인 프로토콜 계층을 만들어, 위 그림과 같이 응용 계층과 전송 계층 사이에 속하게 된다.
출처: https://blog.naver.com/skinfosec2000/222135874222
1.2. SSL과 TLS
- SSL과 TLS(Transport Layer Security)는 같은 뜻으로 말하며 TLS1.0은 SSL3.0을 계승한다.
- 쉽게 생각하면 SSL의 New Version이 TLS이다.
- 하지만 TLS라는 이름보단 SSL이라는 이름으로 더 많이 사용되고 있다.
1.3. SSL 인증서란
- SSL 인증서란 클라이언트와 서버 간의 통신을 제3자가 보증을 해주는 문서이다.
- 클라이언트가 서버에 접속하면 클라이언트는 이 인증서를 보고 신뢰할 수 있는지를 확인한 후 데이터를 보내는 등 다음 절차를 수행하게 된다.
- 서버는 클라이언트에게 인증서를 전달한다.
1.4. SSL의 장점
- 전달되는 내용이 다른 사람에게 노출되는 것을 막을 수 있다.
- 클라이언트가 접속하려는 서버가 신뢰할 수 있는 서버 인지 알 수 있다.
- 전달되는 내용이 악의적으로 변경되는 것을 막을 수 있다.
3. SSL 암호화 종류
3.1. 대칭키
3.1.1. 대칭키란
- 대칭키 방식은 동일한 키로 암호화와 복호화를 할 수 있는 기법을 말한다.
- ex) 1234를 사용하여 암호화하였다면 복호화도 1234를 입력해야 가능하다.
- 암호화(=암호를 만드는 행위)를 할 때 사용하는 비밀번호를 키(key)라고 한다.
3.1.1. 단점
- 클라이언트와 서버는 대화를 하기 위해서 반드시 대칭 키를 알고 있어야 한다. (= 키 배송 문제)
- 그렇기 때문에 통신을 하기 앞서 키를 전달해야하는 과정이 필요하다.
- 그런데 만약 중간에 대칭키가 유출된다면 HTTPS를 사용할 필요성이 사라진다.
- 이런 단점을 보완하기 위해 나온 방식이 공개키 기법이다.
3.2. 공개키
3.2.1. 공개키란
- 공개키 방식은 대칭키 방식과 다르게 2개의 키를 가지고 시작한다.
- 그 중 하나는 공개키(public key)
- 나머지 키를 비밀키(private key, 개인키/비밀키)라 부른다.
- 비밀키는 자신만이 소지하고, 공개키는 타인에게 제공한다.
- 동작 원리는 다음과 같다. 비밀키로 암호화하면 공개키로 복호화 한다. 서버에게 !@#$라는 text를 전달한다.
- 서버는 클라이언트가 보낸 !@#$라는 단어를 비밀키로 복호화하여서 1234라는 것을 확인한다.
- ex) 클라이언트가 서버의 공개키를 가지고 1234(정보)를 암호화하여
- 공개키로 암호화하면 비밀키로 복호화 한다.
- 공개키는 공개되어 있으며 보통 디지털 인증서안에 포함되어 있다. 이것을 우리는 전자서명이라고 부른다.
- 그렇기 때문에 공개키가 존재한다는건 서버의 신원이 안전하다고 볼 수 있다.
3.2.1. 단점
- 공개키 암호화 방식의 알고리즘은 계산이 느리다는 단점이 있다.
4. SSL 통신 과정
- 통신을 위해선 핸드쉐이크 -> 세션 -> 세션 종료의 과정을 거친다.
- 암호화된 HTTP 메시지를 교환하기 전에 클라이언트와 서버는 SSL 핸드쉐이크를 진행한다.
- SSL 핸드쉐이킹에서 핵심은 공개키와 대칭키 2가지 방법을 함께 사용한다는 점이다.
Step 1: Client Hello
- Client Hello : Server에 접근한다.
- 클라이언트는 자신의 브라우저가 지원할 수 있는 암호화 방식(Cipher Suite)을 먼저 제시한다.
- 그리고 랜덤 데이터를 생성하여 추가로 전송한다.
Step 2: Server Hello
- Server Hello : Server가 응답한다.
- 가장 안정한 암호화 방식 (클라이언트가 제시한 암호화 방식 중 하나를 선정)
- 서버 자신의 인증서 with 공개키
- 서버에서 생성한 램덤 데이터
Step 3: 인증서 확인 pre master secret 암호화
- 클라이언트는 내장되어있는 CA 리스트에서 각 CA의 공개키를 이용하여 서버가 보낸 인증서를 복호화한다.
- 만약 CA 리스트에 없는 인증서라면 사용자에게 경고의 메시지를 띄운다.
- 복호화에 성공했다면 인증서는 CA의 개인키로 암호화된 문서임이 암시적으로 보증된 것이다. 인증서를 전송한 서버를 믿을 수 있게 된 것이다.
- 서버의 랜덤 데이터와 클라이언트가 생성한 랜덤 데이터를 조합하여 pre master secret 키를 생성한다.
- 이 키는 뒤에서 살펴볼 세션 단계에서 데이터를 주고 받을 때 암호화하기 위해서 사용된다.
Step 4~5: pre master secret 전달 및 복호화
- 이 때 사용할 암호화 기법은 대칭키이기 때문에 pre master secret 키는 제 3자에게 절대로 노출되어서는 안 된다.
- 그럼 문제는 이 pre master secret 값을 어떻게 서버에게 전달할 것인가이다.
- 이 때 사용하는 방법이 바로 공개키 방식이다.
- Step 2에서 받은 공개키로 pre master secret 키를 암호화하여 서버로 전송하면 서버는 자신의 비공개키로 안전하게 복호화 할 수 있다.
Step 6: master secret 및 session key (대칭키) 생성
- 서버와 클라이언트는 모두 일련의 과정을 거쳐 pre master secret 값을 master secret 값으로 만든다.
- master secret는 session key를 생성하는데 이 session key 값을 이용해서 서버와 클라이언트는 데이터를 대칭키 방식으로 암호화한 후에 주고 받는다.
- 클라이언트와 서버는 핸드쉐이크 단계의 종료를 서로에게 알린다.
- 클라이언트와 서버간의 세션이 형성되고즉 session key를 활용한 대칭키 방식으로 데이터를 주고 받는다.
Reference