HTTPS
HTTP는 클라이언트와 서버 간 데이터를 주고 받는 통신 프로토콜이다.
우리는 주민번호 등과 같은 개인정보 또한 주고받는 데이터일 수 있는데, 이 때 이 HTTP는 우리들의 개인정보가 안전하게 암호화되지 않는 단점이 존재한다. 위와 같은 보안취약점을 개선하고자 HTTP+S(Secure Socket)이 추가된 HTTPS 등장하게 되었다. 통신 과정을 이해하기 위해선 대칭키와 비대칭키 방식에 대한 이해가 필요하다.
동작 과정
대칭키방식과 비대칭키 방식을 혼합하여 동작하게 된다.
그리고 동작과정은 두 가지 방식으로 생각한다.
- 인증 : 클라이언트의 개인정보를 넘겨도 문제 없는 안전한 사이트인지!
- 통신
- 인증
클라이언트와 웹서버 간 통신을 한다.
이 때, 우리의 개인정보 같은 민감한 데이터들을 "웹서버"를 믿고 줄 만큼 안전한 사이트인지 확인을 해봐야 한다.
이에 서버는 공인기관(CA)을 통해 "우리 사이트는 안전한 믿을만한 사이트야"라는 인증을 진행하게 된다.
이 때, 서버는 공인 기관으로부터 인증을 진행 후 별도 인증서를 받는데 이를 'SSL인증서'라고 한다. (SSL인증서 내엔 서버의 공개키 존재)
통신 시 서버는 공인기관으로부터 받은 SSL인증서를 클라이언트에 건네주어 "우리 안전한 사이트 맞아"라는 것을 증명하게 된다.
- 통신
클라이언트가 통신하고자 하는 서버가 CA의 인증 후 SSL인증서를 보유하고 있는 상태이다.
통신 시 데이터 암호화 방식은 대칭키 방식을 사용할 것이다.(비대칭키는 컴퓨터에 과부하 준다고 함)
<인증 후 상태>
- 클라이언트 : CA공개키 보유
- 서버 : CA개인키로 암호화된 SSL인증서 보유
<설명>
1. 클라이언트는 서버 접속 시도
2. 인증기관의 개인키로 암호화된 인증서를 클라이언트에 전달
3. 클라이언트는 해당 인증서가 인증기관을 통해 정상적으로 발급된 인증서인지 확인을 한다.
인증기관의 공개키로 복호화하여 성공한다면, 신뢰가능한 서버이며 발급한 대상이 인증기관임을 증명한다.
클라이언트는 서버의 공개키 또한 획득한다.
4. 클라이언트는 통신 간 데이터 암호화에 사용할 대칭키를 만들어 보유한 서버의 공개키로 암호화하여 전송한다.
(암호화된 대칭키는 오직 개인키를 가진 해당 서버만이 알 수 있으므로 보다 안정적으로 대칭키 교환 성공!!!!!!!)
5. 서버는 개인키로 암호화된 대칭키를 복호화하여 대칭키 획득!!
6. 클라이언트와 서버는 대칭키를 안정적으로 교환했으므로 데이터 암/복호화 문제없이 통신 진행
세션 종료 시 통신 시 데이터 암/복호화에 사용되는 대칭키 폐기.
참고
HTTPS란? (동작방식, 장단점) | EunJeong Kwak (rachel-kwak.github.io)
HTTPS 통신과정 쉽게 이해하기 #3(SSL Handshake, 협상) (tistory.com)