[Network] HTTPS

HTTPS?

HTTPS란 HyperText Transfer Protocol over Secure Socket Layer의 줄임말로 HTTP 프로토콜에 보안을 담당하는 레이어(SSL 또는 TLS)를 추가하여 보안성이 강화된 프로토콜이다. HTTP 프로토콜은 단순히 텍스트를 주고받는 프로토콜이기 때문에 누군가가 네트워크에서 신호를 가로챌 수도 있고, 위조된 자료를 전송할 수도 있기 때문에 보안성이 떨어진다는 보안상의 문제가 있었다. 이를 해결하기 위해 등장한 것이 HTTPS 이다.

SSL 인증서

HTTPS 프로토콜을 얘기하기 위해서는 SSL 인증서라는 것이 꼭 필요하다. SSL 인증서는 클라이언트와 서버간의 통신을 보증해주는 문서를 의미한다. 인증서의 기능은 크게 2가지가 있다.

1. 클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장한다.
2. SSL 프로토콜에 사용할 공개키를 클라이언트에게 제송한다.

클라이언트가 서버에 접속하면 서버는 클라이언트에게 이 인증서 정보를 전달한다. 클라이언트는 이 인증서가 신뢰할 수 있는지 검증한 뒤 다음 절차를 수행한다.

그리고 인증서를 발급해주는 기관을 CA(Certificate Authority) 혹은 Root Certificate라고 부른다. CA는 신뢰성이 엄격하게 공인된 민간 기업들만 참여할 수 있다.

공개키 암호화 방식?

HTTPS 프로토콜은 공개키 암호화 방식을 사용한다. 공개키 암호화 방식에는 공개키와 개인키(또는 비밀키) 총 2 종류의 키가 필요하다. 공개키는 말 그대로 모두에게 공개된 키이다. 개인키는 공개키와는 달리 서버만 알 수 있는 키이다. 공개키 암호화 방식의 핵심은 공개키로 암호화한 데이터는 개인키를 통해 복호화할 수 있고, 개인키를 통해 암호화한 데이터는 공개키를 통해 복호화할 수 있다는 것이다.

이는 2가지 의미를 가진다. 첫 번째는 공개키로 암호화한 데이터는 개인키만 복호화할 수 있기 때문에 개인키를 가지고 있는 쪽에서만 데이터를 읽을 수 있어 보안성이 좋다. 그리고 두 번째는 개인키로 암호화한 데이터를 공개키를 통해 복호화함으로써, 올바른 서버로부터 데이터를 받았다는 것을 보장할 수 있다.

1. 어플리케이션 서버(A)를 만든 기업은 HTTPS를 적용하기 위해 개인키와 공개키를 만든다.
2. A 기업은 신뢰할 수 있는 CA를 선택해 공개키를 관리해달라고 계약한다.
3. CA기업은 CA기업만의 공개키와 개인키를 가지고 있다. CA기업은 CA기업의 이름, A 기업의 공개키, 공개키의 암호화 방법 등의 정보를 담은 인증서를 발급하고, 발급한 인증서를 CA 기업의 개인키로 암호화해서 A 기업에 제공한다.
4. A 기업은 클라이언트로부터 암호화된 HTTPS 요청이 아닌 요청이 들어왔을 때 암호화된 인증서를 전송한다.
5. CA 기업의 공개키는 브라우저가 이미 알고있기 때문에 클라이언트는 CA 기업의 공개키로 서버로부터 전달받은 인증서를 복호화하고, 이를 통해 A 기업의 공개키를 얻을 수 있다.
6. 그 뒤로는 클라이언트가 A 기업의 서버와 통신할 때는 A 기업의 공개키로 암호화해서 Request를 날릴 수 있게 된다.

SSL 통신 과정

이번에는 SSL 통신 방식을 알아보도록 하자. 위 그림에서 공개키 저장소는 CA가 담당한다. 실제로 SSL은 공개키 방식과 대칭키 방식을 둘 다 사용한다.

공개키 방식이 보안성이 훨씬 뛰어난데 대칭키를 사용하는 이유가 무엇인가?

공개키 방식은 대칭키 방식에 비해서 매우 많은 컴퓨터 자원을 사용한다는 단점이 있다. 이를 보완하기 위해서 두 가지 방식을 같이 사용하는 것이다.

실제 데이터는 대칭키 방식으로, 대칭키의 키는 공개키 방식으로 암호화를 한다. 네트워크를 통한 통신 과정은 크게 핸드쉐이크 -> 전송 -> 세션 종료 3단계로 이뤄진다. 이번엔 각 단계를 차근차근 살펴보자.

핸드쉐이크

핸드쉐이크 과정을 통해서 서버와 클라이언트는 SSL 인증서를 주고받는다.

1. 클라이언트가 서버에 접속한다. 이 단계를 Client Hello라고하며 다음과 같은 데이터를 주고받는다.

• 클라이언트 측에서 생성한 랜덤 데이터
• 클라이언트가 지원하는 암호화 방식들 : 클라이언트와 서버가 지원하는 암호화 방식이 서로 다를 수 있기 때문에 상호간에 어떤 암호화 방식을 사용할 것인지에 대한 협상을 해야 한다. 이 협상을 위해서 클라이언트 측에서는 자신이 사용할 수 있는 암호화 방식을 전송한다.
• 세션 아이디 : 이미 SSL 핸드쉐이킹을 했다면 비용과 시간을 절약하기 위해서 기존의 세션을 재활용하게 되는데 이 때 사용할 연결에 대한 식별자를 서버 측으로 전송한다.

2. 서버는 클라이언트에 대한 응답으로 Server Hello를 한다. 이 단계에서는 다음과 같은 정보를 주고받는다.

• 서버 측에서 생성한 랜덤 데이터
• 서버가 선택한 클라이언트의 암호화 방식 : 클라이언트가 전달한 암호화 방식 중에서 서버 쪽에서도 사용할 수 있는 암호화 방식을 선택해서 클라이언트로 전달한다. 이로써 암호화 방식에 대한 협상이 종료되고 서버와 클라이언트는 이 암호화 방식을 이용해서 정보를 교환하게 된다.
• 인증서

3. 클라이언트는 전달받은 인증서가 CA에서 발급된 것인지 확인하고 클라이언트가 가지고 있는 CA 공개키를 사용해서 인증서를 복호화한다. 복호화한 인증서를 통해 서버의 공개키를 얻을 수 있다. 그리고 클라이언트와 서버가 서로 주고받은 랜덤 데이터를 조합하여 pre master secret 키를 생성한다. 그리고 이 pre master secret키를 서버의 공개키로 암호화하여 서버에게 전송한다.

4. 서버는 전달받은 pre master secret을 서버의 개인키로 복호화하고, 서버와 클라이언트는 각각 pre master secret키를 일련의 과정을 통해 master secret 값을 얻는다. 그리고 master secret 값을 이용해서 session key를 생성하고, 클라이언트와 서버는 session key를 대칭키로 사용하게 된다.

5. 클라이언트와 서버는 서로 핸드쉐이크 단계가 끝났음을 알린다.

세션

세션은 실제로 서버와 클라이언트가 데이터를 주고 받는 단계이다. 이 단계에서는 session key를 이용해서 데이터를 암호화하고 복호화한다.

세션 종료

데이터 전송이 끝나면 서로에게 통신이 끝났음을 알리고, 이 때 사용한 세션키를 폐기한다.