HTTPS
HTTPS와 HTTP
-
HTTP(Hypertext Transfer Protocol)은
HyperText인 html을 전송하기 위한 통신규약을 의미한다.
-
마지막에 S를 붙인다면 Secure라는 뜻으로 보안이 강화된 통신규약을 의미한다.
-
HTTP는 암호화가 되어있지 않은 방법으로 서버에 데이터를 전송하기 때문에
서버와 클라이언트가 서로 주고받는 메시지를 알아내기가 쉽다.
-
그러므로 서버로 비밀번호나 계좌번호 등 중요한 데이터를 서버로 전송할 경우에는
HTTPS 프로토콜을 사용하여 통신하는 것이 중요하다.
HTTPS와 SSL
- HTTPS는 SSL 프로토콜을 기반으로 돌아가는 프로토콜 중 하나다.
SSL
SSL 정의
-
Secure Sockets Layer은 암호규약이다.
( 영어: Transport Layer Security, TLS )
( 과거 명칭: 보안 소켓 레이어/Secure Sockets Layer, SSL )
-
TLS는 클라이언트/서버 응용 프로그램이 네트워크로 통신을 하는 과정에서
도청, 간섭, 위조를 방지하기 위해서 설계되었다.
그리고 암호화를 해서 최종단의 인증, 통신 기밀성을 유지시켜준다.
SSL과 TLS
-
SSL과 TLS는 같은 뜻으로 말하며 TLS1.0은 SSL3.0을 계승한다.
-
쉽게 생각하면 SSL의 New Version이 TLS이다.
하지만 TLS라는 이름보단 SSL이라는 이름으로 더 많이 사용되고 있다.
SSL 인증서 정의
-
SSL 인증서란 클라이언트와 서버간의 통신을 제 3자가 보증을 해주는 문서이다.
-
클라이언트가 서버에 접속하면
서버는 클라이언트에게 인증서를 전달한다.
그러면 클라이언트는 이 인증서를 보고
신뢰할 수 있는 사람인지 확인 후 데이터를 보내는 등 다음 절차를 수행하게 된다.
SSL 장점
-
전달되는 내용이 다른 사람에게 노출되는 것을 막을 수 있다.
-
클라이언트가 접속하려는 서버가 신뢰할 수 있는 서버 인지 알 수 있다.
-
전달되는 내용이 악의적으로 변경되는 것을 막을 수 있다.
SSL 암호화 종류
대칭키
-
대칭키 방식은 동일한 키로 암호화와 복호화를 할 수 있는 기법을 말한다.
ex) 123를 사용하여 암호화하였다면 복호화도 123를 입력해야 가능하다.
-
암호화(=암호를 만드는 행위)를 할 때 사용하는 비밀번호를 키(key)라고 한다.
-
이 키에 따라서 암호화된 결과가 달라지기 때문에
키를 모른다면 암호를 푸는 행위인 복호화도 할 수 없다.
단점
-
클라와 서버는 대화를 하기 위해서 반드시 대칭 키를 알고 있어야 한다.
그렇기 때문에 통신을 하기 앞서 키를 전달해야하는 과정이 필요하다.
(= 키 배송 문제)
-
그런데 만약 중간에 대칭키가 유출된다면
키를 획득한 공격자는 암호화된 데이터를 복호화하여 볼 수 있기 때문에
HTTPS를 사용할 필요성이 사라진다.
-
이런 단점을 보완하기 위해 나온 방식이 공개키 기법이다.
공개키
-
공개키 방식은 대칭키 방식과 다르게 2개의 키를 가지고 시작한다.
-
그 중 하나는 공개키(public key)
나머지 키를 비밀키(private key, 개인키/비밀키)라 부른다.
-
비밀키는 자신만이 소지하고
공개키는 타인에게 제공한다.
-
동작 원리는 다음과 같다.
공개키로 암호화하면 비밀키로 복호화 한다.
비밀키로 암호화하면 공개키로 복호화 한다.
ex) 클라이언트가 서버의 공개키를 가지고 1234(정보)를 암호화하여
서버에게 !@#$라는 text를 전달한다.
서버는 클라이언트가 보낸 !@#$라는 단어를 비밀키로 복호화하여서 1234라는 것을 확인한다.
-
주의할 점이 일반적으로는
공개키로 암호화 -> 비밀키로 복호화를 한다고 말을 한다.
그렇다고 비밀키로 암호화 -> 공개키로 복호화가 틀리다는건 아니다.
-
그렇기 때문에 개념을 다음처럼 생각하는게 좋다.
공개키 = A / 비밀키 = B
A 키로 암호화한 데이터를 B 키로 복호화 한다.
즉 키를 공개키로 부르냐 비밀키로 부르냐의 차이가 있을 뿐
사실상 데이터의 보안을 위해 사용되는 키라는 점을 기억하자.
-
공개키는 공개되어 있으며 보통 디지털 인증서안에 포함되어 있다.
그렇기 때문에 공개키가 존재한다는건 서버의 신원이 안전하다고 볼 수 있다.
이것을 우리는 전자서명이라고 부른다.
단점
- 공개키 암호화 방식의 알고리즘은 계산이 느리다는 단점이 있다.
SSL 통신 과정
-
통신을 위해선 핸드쉐이크 -> 세션 -> 세션 종료의 과정을 거친다.
-
암호화된 HTTP 메시지를 교환하기 전에 클라이언트와 서버는 SSL 핸드쉐이크를 진행한다.
-
SSL 핸드쉐이킹에서 핵심은 공개키와 대칭키 2가지 방법을 함께 사용한다는 점이다.
Step 1
-
Client Hello : Server에 접근하다.
-
클라이언트는 랜덤한 데이터와 현재 지원가능한 암호화 방식을 서버에게 전달한다.
-
자신의 능력을 서버에게 말해준다 생각하면 된다.
-
Step 2
-
Server Hello : Server가 응답하다.
-
3가지를 응답한다.
인증서 with 공개키
서버에서 생성한 랜덤한 데이터
가장 안전한 암호화 수단 방식
-
암호화 수단 방식은 클라이언트가 지원가능한 암호화 방식 목록 중 선택한다.
-
Step 3
-
클라이언트는 내장되어있는 CA 리스트에서
각 CA의 공개키를 이용하여 서버가 보낸 인증서를 복호화한다.
-
만약 CA리스트에 없는 인증서라면 사용자에게 경고의 메시지를 띄운다.
-
만약 복호화를 성공했을 시
해당 인증서는 CA의 개인키로 암호화 한 문서임이 보증되었기 때문에 서버를 신뢰할 수 있게 된다.
( 개인키로 암호화 -> 공개키로 복호화 )
그리고 클라이언트가 전송한 랜덤한 데이터 와
서버가 전송한 랜덤한 데이터 를 조합하여 Pre Master Secret 키를 생성한다.
Step 4
-
Step 2에서 받은 공개키를 이용하여
Pre Master Secret 키를 암호화하여 서버로 전송을 한다.
이 때 Pre Master Secret 키는 절대 노출되어선 안된다.
( 공개키는 인증서에 포함되어 있다. )
-
서버는 Pre Master Secret 값을 자신의 비밀키로 복호화하고
이로써 클라이언트와 서버는 Pre Master Secret 키를 공유하게 된다.
Step 5
-
서버와 클라이언트는 일련의 과정을 거쳐
Pre Matser Secret 값을 Master Secret 값으로 만든다.
그리고 Master Secret를 이용하여 Session Key를 만든다.
Step 6
-
클라이언트와 서버간의 세션이 형성되고
Session Key를 이용하여 암호화하여 데이터를 주고 받는다.
즉 대칭키 방식으로 데이터를 주고 받는다.
Result
-
대칭키는 공개키에 비해 빠르지만 키 배송 문제가 존재한다.
-
그렇기 때문에 SSL 핸드쉐이킹 과정에서는
Key를 공유하기 위해 공개키 방식을 사용하였고
세션이 형성 된 후에는 대칭키 방식으로 효율을 높혔다.
Summary
-
HTTPS와 SSL 개념에 대해 알아봤다.
-
또한 공개키와 대칭키의 특징에 대해 알아봤다.
-
그리고 SSL 핸드쉐이킹 과정에서는
2가지 암호화 방식을 사용하는 것을 확인할 수 있었고
각 암호화 방식의 단점을 어떻게 보완하였으며
각 암호화 방식의 장점을 어떻게 활용하였는지 알 수 있었다.
-
실제로 SSL을 서버에 적용시키는 과정은 SSL 적용하기 글을 참고하자.