HTTPS
1. HTTPS 란?
- HTTPS = HTTP + SECURE
- HTTP 프로토콜 내용을 암호화
특징
2. HTTPS 의 특징
1. 인증서 (Certificate)
-
데이터 제공자 시원 보장
-
도메인 종속
-
서버로부터 응답(인증서 포함)을 받으면 클라이언트는 응답객체의 도메인과 인증서의 도메인을 비교하여 일치하는지 확인한다.
2. CA (Certificate Authority)
-
공인 인증서 발급기관
-
각각의 브라우저는 신용하는 CA 정보를 가지고 있다.
3. 비대칭 키 암호화
- 암호화/복호화 하는 키가 다르다.
공개키(비대칭 키) : 암호화, 인증서에 포함되어 있다, 서버가 클라이언트에게 전달
비공개키(개인키, 공통키) : 복호화
3. HTTPS 의 동작 방식
-
HTTPS 는 대칭키 방식과 공개키 방식 을 하이브리드 하여 통신한다.
-
실제 데이터는 대칭키 방식으로 하며, 대칭키를 생성하기 위하여 공개 키 방식을 사용한다.
-
크게 3가지 액션으로 동작하게 된다.
-- 악수(Handshake)
-- 데이터 전송
-- 세션 종료
3.1 악수(Handshake)
-
클라이언트, 서버간의 통신을 하기 전 실제 통신을 할수 있는지, 서로 검토하는? 단계이다. 굳이 비유하자면 사람 관계와 비슷하다. 내가 어떤 새로운 친구를 만나고 싶을때, 상대방에게 나에 대한 존재를 알려줘야 하고 또한 상대방도 나란 사람에 대해서 조금이라도 파악이 되어야 친구가 되고 싶은 마음이 생길것이다.
-
친구가 되기로 한게 악수(handshake)로 표현할수 있으며, 친구가 된 이후 서로 오가는 대화들이 데이터가 될수 있다.
-
클라이언트와 서버간도 비슷하며, 클라이언트가 서버에게 처음에 Hello 라고 인사를 하게 된다. 즉, 클라이언트가 서버에 처음 접속하게 되는 시점이며 이 단계를 Client Hello 라고 한다. 또한 서버는 Client Hello 에 대한 응답으로 Server Hello를 하게 된다
3.1.1 Client Hello 단계
-
클라이언트에서 랜덤 데이터를 생성한다.
-
클라이언트에서 사용할수 있는 암호화 방식들을 서버에 전달한다.
-
클라이언트에서 사용되는 암호화 방식과, 서버에서 할수 있는 암호화 방식이 다를 수 있기 때문에, 두군데 모두 사용할수 있는 암호화 방식에 대해서 협상이 필요하다.
3.1.2 Server Hello 단계
-
Client Hello 에 대한 응답 과정이다.
-
클라이언트와 동일하게 랜덤 데이터를 생성하며, 클라이언트에 전달한다.
-
클라이언트가 전달한 암호화 방식 중에서 서버 쪽에서도 사용할 수 있는 암호화 방식을 선택해서 클라이언트로 전달한다. 채택된 암호화 방식으로 클라이언트 서버간 통신이 진행된다. 물론 클라이언트에서 보내준 암호화 방식을 서버에서 지원하지 않는다면, 암호화 협상 결렬로 인해 악수는 불발된다.
-
서버가 발급받은 인증서를 클라이언트로 전달한다.
3.1.3 Client 인증 단계
-
클라이언트는 서버의 인증서가 CA에 의해서 발급된 것인지를 확인하기 위해서 클라이언트에 내장된 CA 리스트를 확인한다. CA 리스트에 인증서가 없다면 사용자에게 경고 메시지를 출력한다.
인증서가 CA에 의해서 발급된 것인지를 확인하기 위해서 클라이언트에 내장된 CA의 공개키를 이용해서 인증서를 복호화한다. 복호화에 성공했다면 인증서는 CA의 개인키로 암호화된 문서임이 암시적으로 보증된 것이다.
인증서를 전송한 서버를 믿을 수 있게 된 것이다. -
클라이언트는 Server Hello 단계에서 받은 랜덤데이터와 Client Hello 단계에서 생성한 랜덤데이터를 조합하여 pre master secret 키를 생성한다.
이 키는 데이터를 주고 받을때 사용하기 위한 암호화 키 이며 대칭키 방식으로 사용되어질 키값이다.
중요한 키임으로 절대 제 3자에게 노출되면 안된다. 그렇기 때문에 이 pre master secret 값을 서버에게 전달할때 서버가 제공한 공개키로 암호화 하여 전송하며,
서버는 자신의 비공개키로 복호화 하여 pre master secret 값을 취득한다.
클라이언트가 사용한 공개키는 Server Hello 단계에서 전달받은 인증서 안에 들어있다.
3.1.4 Server 인증 단계
-
서버는 클라이언트가 전송한 pre master secret 값을 자신의 비공개키로 복호화한다. 이렇게 되 서버와 클라이언트가 모두 pre master secret 값을 공유하게 된다.
-
서버와 클라이언트는 모두 일련의 과정을 거쳐서 pre master secret 값을 master secret 값으로 만든다.
-
master secret는 session key를 생성하는데 이 session key 값을 이용해서 서버와 클라이언트는 데이터를 대칭키 방식으로 암호화 한 후에 주고 받는다. 이렇게해서 세션키를 클라이언트와 서버가 모두 공유하게 된다.
3.1.5 악수(Handshake) 종료
-
위의 과정으로 클라이언트와 서버는 악수 단계의 종료를 서로에게 공유한다.
-
HTTPS 연결이 성립되었다고 말할수 있다.
3.2 데이터 전송
- 실제로 서버와 클라이언트가 데이터를 주고 받는 과정이다. 상대방에게 데이터를 송신하기 전, 악수 단계에서 발생한 세션 key 값으로 데이터를 대칭키방식으로 암호화 한다.
암호화 된 데이터는 상대방으로 송신되며, 상대방도 세션 key 값을 알고 있기 때문에 데이터를 복호화 할수 있다. HTTPS 의 동작 원리 - 1편에서 다뤘듯이, SSL통신은 공개키 방식, 대칭키 방식의 하이브리드 조합으로 통신하게 되는데
왜 굳이 복잡하게 두개를 섞어서 사용할까? 공개키 방식은 컴퓨터 자원을 꽤 많이 사용함으로 비용이 많이 드며, 또한 대칭키 방식만 사용하게 되면 인터넷상을 대칭키를 서로 주고 받아야 히는데,
보안상 엄청 위험하다. 그래서 속도는 느리지만 데이터를 안전하게 주고 받을 수 있는 공개키 방식으로 대칭키를 암호화하고, 실제 데이터를 주고 받을 때는 대칭키를 이용해서 데이터를 주고 받는 것이다.
3.3 세션 종료
- 데이터 송,수신이 끝나면 SSL 통신이 끝났음으로 서로에게 알려준다.
이 때 통신에서 사용한 세션 key(대칭키)를 폐기한다.
출처
