HTTPS
HTTPS는 그 이름에도 알 수 있듯이, HTTP Secure로서 암호화 기술을 통해 콘텐츠를 안전하게 전달한다. 즉 데이터의 변조 위험을 막을 수 있고 디지털 인증서를 사용함으로써 신뢰성을 얻는 방식이다.
이 HTTPS는 TCP 위에 *SSL(Secure Socket Layer)/TLS(Transport Layer Security) 계층을 더해 이용된다. 그리고 이에 대해 두 개의 서로 다른 키를 사용하여 당사자간의 통신을 암호화할 수 있다
*TLS는 SSL의 상위 버전이며 따라서 최근에는 대부분 TLS를 이용한다, 과거엔 편의상 SSL과 용어를 통쳐서 불리었지만 TLS는 최신 보안 표준을 준수한다는 점에서 차이를 갖는다.
서로 다른 키?
암호화된 내용을 풀기 위한 Key가 개인키와 공개키로 나뉘어져있다
- 공개키: 서버가 제공하며, 클라이언트가 데이터를 암호화할 때 사용한다. (안전한 방식으로 서버와 통신하고자 하는 모든 이가 사용할 수 있다) 이 정보는 개인키로만 해독 가능하다.
- 개인키: 웹 사이트 소유자가 관리하며, '개인'이라는 말에서 유추할 수 있듯이 비공개로 유지된다. 이 키는 웹 서버에서 존재하는데, 공개키로 암호화된 정보를 해독하는 데 사용한다
Secure, 안 하면 어떤데?
기존의 HTTP를 통해 정보를 전송한다면 이는 쉽게 가로챌 수 있는 데이터가 된다. 즉, HTTP가 데이터를 암호화하지 않음으로써 네트워크를 통해 전송되는 모든 정보가 중간자(MITM) 공격이나 패킷 스니핑으로 쉽게 노출된 위험이 있다. 이로 인해 악성 스크립트를 삽입하고, 데이터 유출 등의 보안 문제가 발생할 수 있다. 작은 규모로는 악의적인 광고자가 웹페이지 소유자의 승인 없이 콘텐츠를 삽입하는 등의 일을 행해 서비스 품질이 낮아지는 정도는 애교다, 그러나 점점 커지며 악성 정보에 대한 갈취/변조 등으로 번질 수 있으니 막아야한다.
SSL/TLS 핸드셰이크 과정
서버와 CA 간의 인증서 발급
우선은 그린 것과 같이 서버가 CSR(Certificate Signing Request)를 CA(Certificate Authority)에 요청하는 절차가 필요하다.
즉, 서버가 인증서를 발급받기 위해 CA에 인증서 서명 요청을 제출하는 과정인데, 이 CSR에는 서버의 공개키와 서버에 대한 식별 정보(도메인 이름, 조직 이름, 국가 코드 등)을 포함한다. 이에 대해 CA가 검토하여 인증서를 발급하는 꼴이다. 그리고 발급받은 인증서(server.crt)를 Nginx나 Apache로 설치하고 클라이언트와의 통신을 시작할 준비를 마친다.
이때, 서버가 공개키-개인키를 생성하게 되어있는데, 공개키는 말했듯이 CA에 제출되어 인증서 일부에 포함되지만, 개인키는 서버에 안전하게 저장되어 외부로 유출되지 않는다. 그리고 이 쌍이 이후 서버-클라이언트간 암호화 통신의 기반이 된다.
서버와 클라이언트간의 TSL 통신 (Handshake 과정)
자료마다 생략된 과정이나 흐름 순서가 달라, Cloudflare에 기술된 내용을 기준으로 그렸을 때 위와 같다.
일단 TLS Handshake는 서버와 클라이언트가 암호화 통신을 시작하기 위해 필요한 키와 프로토콜을 협상하는 과정이다. 세분화 시키면 이이렇다.
1. 클라이언트의 ClientHello 메시지 전송
클라이언트는 지원하는 암호화 알고리즘(Cipher Suite) 목록, 클라이언트의 난수(랜덤 데이터), TLS 버전 정보와 같은 것을 포함하여 메시지를 전송한다.
2. 서버의 ServerHello 메시지 응답
클라이언트의 1번 메시지에 대한 응답을 한다. 여기에는 받은 목록에서 선택한 암호화 알고리즘과, 서버측의 난수, 그리고 디지털 인증서 (SSL/TLS)를 포함한다.
3. 클라이언트의 인증서 검증
기존에 파이어폭스, 크롬 등은 CA 인증기관의 공개키를 갖고 있는데, 이를 통해서 서버의 메시지 응답으로 포함된 인증서를 신뢰가능한지 확인한다.
4. 클라이언트의 pre-master secret 전송
클라이언트는 무작위 바이트 문자열을 서버측에 하나 더 전송한다. 이는 공개 키로 암호화되어있고, 서버가 개인키로만 해독할 수 있게 되어있다. (아까 받은 SSL 인증서를 통해 공개키를 이용할 수 있기 때문에 가능하다)
5. 서버의 pre-master secret 해독
암호를 해독한다
6. 각자가 세션 키를 생성한다
이제 서로가 교화한 난수와 pre-master secret을 통해 세션 키를 생성하게 된다. 각자가 만든 이 세션 키는 데이터 암호화에 사용될 예정이며, 따라서 서로의 결과가 같아야 한다.
7. 완료 송수신
이제 서버가 완료되었음을 알리면 클라이언트도 완료되었음을 알린 다. 즉, 핸드셰이크 완료 메시지 교환 이후 모든 통신은 세션 키를 사용한 대칭키 암호화로 보호된다.
위와 같은 다소 복잡한 동작을 취하는 이유는 당연히, 보안성과 신뢰성을 위함이다. 데이터를 암호화하여 탈취당하거나 중각자 공격을 방지하고, 클라이언트 서버 간 안전한 연결을 유지하는 데에 도움이 되고자 한다. 따라서 안전하고 신뢰성 있는 통신을 보장하는 핵심 프로토콜이라고 정리할 수 있다.