HTTPS 통신 중 클라이언트가 CA 기업의 암호를 푸는 방법

[minaver]

이슈

HTTPS 프로토콜을 살펴보던중

클라이언트 브라우저는 CA 기업 공개키를 알고 있고 이를 해독하여 기업의 공개키를 얻음 이라는 과정이 잘 이해되지 않았다.

공개키로 암호화된 데이터는 개인키(비밀키)가 있어야 복호화 할 수 있는 것으로 이해했는데 해당 과정에서는 CA 기업의 공개키로 암호화된 기업의 공개키를 CA 기업의 공개키로 복호화하는 것처럼 설명하였다. HTTPS 통신 중 클라이언트가 CA 기업의 암호를 푸는 방법은 무엇일까?

[minaver]

공개키 - 개인키 관계를 얕게 이해했었다.

공개키 - 개인키 관계가 무조건 공개키로 암호화 -> 개인키로 복호화 과정이 아닌 반대 방향으로 개인키로 암호화 -> 공개키로 복호화 되는 경우도 있다고 한다.

공개키 -> 암호화 & 개인키 -> 복호화

이 경우는 기존 이해한 방식대로 개인키를 가져야지만 공개키로 암호화된 데이터를 복호화하여 사용할 수 있어 데이터를 보안하여 전달할 수 있는 방법이다.

개인키 -> 암호화 & 공개키 -> 복호화

이 경우는 공개키로 복호화가 가능하니 공개키를 가진 모든 사용자가 데이터를 복호화 할 수 있는 경우이다. 처음에 들었을 때는 읭? 그러면 키가 무슨 소용이고 암호화가 무슨 소용이지? 이라는 생각이 먼저 든다. 설명을 찾아보니 이 방법을 사용하는 이유는 데이터 보완이 주 목적이 아닌 데이터 제공자의 신원을 보장하기 위해 사용하는 방식이라고 한다. 암호화된 데이터가 공개키로 복호화된다는 건 공개키와 쌍을 이루는 개인키에 의해 암호화 되었음을 의미하고 이는 데이터의 신원 확인이 보장된다는 것이다.

결론 : 보안이 아닌 인증에 초점을 둔 사용 방식임

즉, 사용자가 검증된 열쇠(공개키)를 들고 있고 데이터들이 비밀 상자(개인키로 암호화)안에 들어있을 때 해당 비밀 상자가 사용자들이 들고 있는 검증된 열쇠로 열린다면 '아 이 검증된 열쇠를 뿌린 사용자가 만든 데이터가 맞구나!' 라고 확신할 수 있다는 이야기이다.

즉 브라우저가 CA 기업의 SSL 인증서를 CA 기업의 공개키로 복호화하는 것은 해당 SSL 인증서가 CA 기업이 정상적으로 발급한 인증서임을 인증하는 과정인 것이다.

[minaver]

HTTPS 인증 과정

HTTPS 인증 과정에 대해 다시 정리해보자 HTTPS 인증 과정의 목적은 서버 - 클라이언트 사이에 주고받을 데이터의 암호화 알고리즘을 결정, 동일한 대칭키를 공유하는 것이다.

대칭키를 pure하게 네트워크를 사용하여 공유하면 탈취의 위험이 굉장히 크다. 그래서 이 대칭키를 암호화하여 서버와 클라이언트만 알 수 있게끔 공유한다.

절차

-- TCP Handshake 시작 --

1. 3-way handshake

-- SSL Handshake 시작 --

(Client -> Server) 2. Client Hello (Server -> Client) 3. Server Hello, Certificate, Server Key Exchange, Server Hello Done (Client -> Server) 4. Client Key Exchange, Change Ciper Spec (Server -> Client) 5. Server / Client SSL Handshake Finished

-- SSL Handshake 종료 --

1. 3-way handshake

HTTPS 가 TCP 기반의 프로토콜이기 때문에 SSL Handshake 에 앞서 연결을 생성하기 위한 과정이다.

2. Client Hello

클라이언트에서 통신하고 싶은 서버로 연결을 시도하는 패킷을 전송한다.

• 패킷 내용 : 클라이언트가 사용 가능한 cipher suite 목록, session id, ssl protocol version ...

3. Server Hello

Client Hello 에 대해 서버가 응답 패킷을 보낸다.

• 패킷 내용 : 클라이언트에서 받은 cipher suite 목록 중 선택한 1개의 cipher suite, ssl protocol version ...

3. Certificate, Server Key Exchange, Server Hello Done

Certificate : Server 의 SSL 인증서 내용을 전달

• 패킷 내용 : 인증서의 signature algorithm, public key info

Server Key Exchange : Certificate 내의 SSL 인증서에 서버의 공개키(public key)가 없는 경우, 서버가 직접 서버의 공개키를 전달

• 인증서 내부에 서버의 공개키가 존재한다면 Server Key Exchange 는 생략된다

Server Hello Done : 서버가 행동을 마쳤다는 의미이다.

4. Client Key Exchange, Change Ciper Spec

Client Key Exchange : Certificate 나 Server Key Exchange에서 확보한 서버의 공개키로 통신할 데이터를 암호화할 대칭키를 암호화한다. (서버에게 외부 탈취없이 전달하기 위해!)

Change Ciper Spec : SSL Handshake 의 완료를 알림.

5. Server / Client SSL Handshake Finished

서버는 클라이언트가 전달한 암호화된 대칭키(비밀키)를 받았다. 이 키는 서버의 공개키로 암호화되었으니, 서버의 비밀키로 복호화해서 얻을 수 있다. 이로서 클라이언트와 서버가 외부의 탈취없이 동일한 대칭키를 공유할 수 있게 됐다.

참고자료

HTTPS 통신 원리 쉽게 이해하기 (Feat. SSL Handshake, SSL 인증서)

[minaver]

Cipher suite

서버와 클라이언트가 통신할때 합의해야 하는 알고리즘들과 운용 방식을 정리한 정보

SSL/TLS_(키교환 알고리즘)_(인증 알고리즘)_WITH_(대칭 암호 알고리즘)_(블록 암호 운용 방식)_(해시 알고리즘)

• 키교환 알고리즘 : Server와 Client간 Key를 교환할 방식을 선정
• 인증 알고리즘 : Server와 Client간 교환한 인증서를 확인하는 알고리즘
• 대칭 암호 알고리즘 : 실제 데이터를 암호화 하는 알고리즘
• 블록 암호 운용 방식 : 데이터를 암호화 할때 한꺼번에 암호화 하는 것이 아니라 블록 단위로 암호화 하게 되는데, 블록된 암호화 패킷을 조합하여 데이터를 추측 하는 것을 방지하기 위한 방식
• 해시 알고리즘 : 서로 상대방이 암호화 한것이 맞는지 확인하기 위한 알고리즘

참고자료

SSL/TLS, Cipher suite란?