HTTPS란?

의미

HTTP(HyperText Transfer Protocol)란, 하이퍼텍스트(해당 문서가 아닌, 다른 문서(or 자료 등)등의 위치를 표현할 수 있는 텍스트)를 전송하는 통신 규약이다.

HTTPS(HTTP Secure)란, HTTP에 데이터 암호화 기능이 추가된 프로토콜을 말한다.
대칭 키 + 비대칭 키 방식을 혼합해서 사용한다.

대칭 키 방식 vs 비대칭 키 방식
대칭 키 방식은 클라이언트와 서버가 동일한 키를 사용해 암호화/복호화하는 방식으로, 속도가 빠르지만 키가 노출되었을 때 위험성이 큼.
비대칭 키 방식은 한 쌍의 공개 키/개인 키를 가지고 암호화/복호화하는 방식으로, 키가 노출되어도 위험성이 비교적 작은 대신 속도가 느리다.

공개 키와 개인 키
공개 키는 외부에 드러낼 수 있는 키이고, 개인 키는 자신만 알고있어야 하는 키이다. 한쪽 키로 암호화한 데이터는, 다른 쪽 키로만 복호화할 수 있다.

이러한 특징으로 인해, 암호화를 공개 키로 할 때와 개인 키로 할 때, 얻을 수 있는 효과가 다르다.

• 공개 키로 암호화하면, 개인 키를 가진 사람만 볼 수 있다.
• 개인 키로 암호화하면, 해당 데이터가 "내가 암호화한 데이터" 임을 보증할 수 있다.

HTTPS의 동작 방식

위에 말했듯, HTTPS는 대칭 키 + 비대칭 키 방식을 혼합해서 사용한다.
이 과정을 자세히 알아보자.

데이터를 교환하는 과정에서는, 대칭 키 방식을 사용한다. 속도 면에서의 이점이 크기 때문이다.
이 대칭 키를 세션 키라고 하며, HandShake 과정에서 생성한다.
대칭 키는 속도가 빠른 대신, 키가 노출되면 위험성이 크다고 했다. 이 문제를 해결하기 위해, 세션 키를 교환할 때는 비대칭 키 방식을 사용한다.
이렇게 함으로써 통신을 빠른 속도로 수행하면서도, 키 노출의 위험성을 줄일 수 있다.

동작 과정

1. 클라이언트가 서버로 연결 요청
2. 서버는 공개 키(정확히는 인증서)를 클라이언트에 전달
3. 클라이언트는 인증서 유효성 검사 후, 세션 키를 발급
4. 발급한 세션 키를 서버의 공개 키로 암호화하여, 서버로 전달
5. 서버는 개인 키로 세션 키를 복호화하여 저장. 결과적으로 양쪽이 같은 세션 키를 갖게 됨.
6. 이후 통신 과정에서, 해당 세션 키로 데이터를 암호화/복호화하여 통신

후술하겠지만 이는 RSA방식의 키 교환 시 과정이며, 많이 사용되는 Diffie-Hellman 계열 방식에서는 위에서 클라이언트가 세션 키를 생성하여 서버로 전달하던 과정에서,
세션 키 생성에 필요한 파라미터들을 공유한 뒤 각자 생성하는 것으로 바뀐다.

위 과정을 보면 클라이언트 또는 서버가 갖고있는 세션 키를 탈취하거나, 서버의 개인 키를 탈취하지 않는 이상 웬만큼 안전함을 알 수 있다. 1~2번 과정에서 "누군가 서버인 척 대신 자신의 공개 키를 응답하고 이후 과정을 대신하면 보안을 뚫을 수 있지 않을까?" 했지만, 이 과정에서 CA(Certificate Authority) 기관들이 관여하므로, 이럴 가능성 또한 희박하지 않을까 생각한다.
우리가 브라우저로 특정 링크를 들어갔을 때, 인증된 CA기관의 인증서가 아닌 경우 신뢰할 수 없는 링크라는 알림이 뜬다. 이 때가 위와 같은 경우일 것 같다.

인증서 생성 및 사용 과정

위의 인증서와 관련된 부분에서, CA 기관들이 관여한다. 이 부분을 자세히 살펴보자.

1. 서버 측이 공개 키/개인 키 쌍을 생성한다.
2. 서버 측은 CA기관에게 공개 키를 저장하는 인증서 발급을 요청한다.
3. CA기관은 (CA기업 이름, 서버의 공개 키, 서버의 정보) 등을 포함하는 인증서를 발급하고, CA기관의 개인 키로 암호화하여 서버 측에 전달한다.
4. 서버 측은 클라이언트에게서 연결 요청을 받았을 때, 이 암호화된 인증서를 전달한다.
5. 클라이언트는 CA기관들의 공개 키를 미리 갖고 있어, 이 공개 키로 인증서를 복호화하여 서버의 공개 키를 얻는다.
6. 이후 위 HTTPS 과정의 세션 키 발급 단계부터 수행한다.

SSL, TLS

SSL(Secured Sockets Layer) vs TLS(Transport Layer Security)

같은 기능이지만, 최초 개발사인 Netscape가 SSL 업데이트에 참여하지 않게 되며, 소유권 변경을 위해 명칭만 바뀐 것이다.
SSL은 꽤 오래 전(1996년)부터 업데이트가 중단되었다.
그 이후론 TLS만 발전되어 왔다.

TLS Handshake (TLS 1.2)

아래는 TLS 1.2버전, Diffie Hellman 방식을 기준으로 Handshake 과정을 알아본다.

1. Client Hello

• 클라이언트가 서버에 연결 요청
• Cipher Suite, 세션 ID, SSL/TLS 프로토콜 버전, 랜덤 바이트(대칭 키 생성 등에 사용)등을 포함한다.

Cipher Suit
SSL/TLS 과정에서 사용되는 암호화 알고리즘의 조합이다.
키 교환 방식, 인증서 검증 방식, 데이터 암호화 방식 등의 정보를 담는다.
Handshake 과정에서, 클라이언트가 서버에게 사용 가능한 Cipher Suite 목록을 전달하면,
서버가 그 중에서 사용할 방식 하나를 선택하여 클라이언트에 전달한다.

2. Server Hello

• Client Hello에 대한 응답
• 선택한 Cipher Suite, 서버의 SSL/TLS 프로토콜 버전, 랜덤 바이트 등을 포함한다.
  
  

3. Certificate

• 서버가 클라이언트에게 SSL/TLS 인증서 전달
• 인증서에서 CA기관 확인 후, 해당 CA기관의 공개 키로 복호화한다(그 개인 키로 암호화되었으므로).
  • 브라우저는 미리 여러 CA기관의 공개 키를 갖고 있는다.
  • 해당 CA기관의 공개 키가 없다면, 기관의 정보와 공개 키를 다운받아와서 사용한다.
• 복호화를 통해 해당 CA기관의 인증서가 맞는지를 검사하고, 서버의 공개 키를 얻어온다.
  
  

4. Server Key Exchange / Server Hello Done

• Server Key Exchange는 인증서 내부에 서버의 공개 키가 없을 때, 서버가 이를 직접 전달함을 의미
  • Diffie-Hellman 기반 방식의 경우 서버의 공개 키 외에도 다른 정보들을 교환하므로, 해당 과정이 발생함
    

• 인증서 내부에 공개 키가 이미 있다면, Server Key Exchange는 생략
• 이후 Server Hello가 끝났음을 전달
  
  

5. Client Key Exchange

• 키 교환 방식이 RSA인 경우, 클라이언트가 대칭 키를 생성하여 서버로 전달한다.
• Diffie-Hellman 계열 방식인 경우, 대칭 키 생성에 필요한 정보들을 전달한다.
  
  

6. Change Cipher Spec

• 암호화되지 않은 통신에서, 암호화된 통신으로 변경하라는 신호
• 이후의 통신은 이전까지 합의한 방식들로 암호화하여 진행할 것임을 의미
  
  

7. Finish / Encrypted Handshake Message

• 다운그레이드 공격이라는 것이 있다. 제3자가 클라이언트인 척 서버에게 낮은 버전의 프로토콜을 사용할 것을 요청하여 취약점을 만들거나, 서버인 척 클라이언트를 HTTPS에서 HTTP로 리다이렉트시키는 것 등이 있다.
• 이를 방지하기 위해, 서버와 클라이언트가 Handshake과정의 메시지들을 해싱하여 교차 검증한다. 이 때 사용되는 것이 Encrypted Handshake Message이다. 검증 결과 문제가 있으면, 서버는 TLS 세션을 중단한다.
  
  

SSL/TLS Handshake vs TCP 3-way Handshake

서로 다르다. 3-way handshake가 끝난 후, SSL/TLS handshake가 수행된다.

대칭 키 교환 방식) Diffie-Hellman, RSA

Diffie-Hellman

대칭 키 생성에 필요한 재료를 교환한다.
서버와 클라이언트가 서로의 개인 키를 몰라도, 같은 대칭 키를 생성할 수 있다.
(1) 둘 다 아는 공통 정보
(2) 서버의 개인 키
(3) 클라이언트의 개인 키
위 3개로 대칭 키를 생성하며, 서로의 개인 키는 당연히 공유하지 않는다.

아래 생략한 부분을 간단히 요약하자면,
{(1) & (2)} & (3) = {(1) & (3)} & (2)
이다.
여기서 (1) & (2)는 서버의 공개 키, (1) & (3)은 클라이언트의 공개 키이다.

참고) 기반이 되는 식은 다음과 같다.

G = 정수, P = 소수일 때,
(G^a mod P)^b mod P = (G^b mod P)^a mod P
a = 서버의 개인 키
b = 클라이언트의 개인 키
G^a mod P = 서버의 공개 키
G^b mod P = 클라이언트의 공개 키
(G^a mod P)^b mod P = (G^b mod P)^a mod P = 대칭 키
가 된다.

생성 과정

1. Server Key Exchange 시, 공통 정보 & 서버의 공개 키를 전달한다.
2. Client Key Exchange 시, 공통 정보 & 클라이언트의 공개 키를 생성해 전달한다.
3. 각각은 상대의 공개 키와 자신의 개인 키를 사용해 대칭 키를 생성할 수 있다.

다만 이 방식은 CPU 부하가 커서, 효율을 개선한 ECDH 알고리즘도 존재한다.

Perfect Forward Secrecy(PFS/FS)

• 위 방식에서는 비밀 키를 탈취당할 경우 대칭 키(=세션 키)를 만들 수 있고, 현재 오고가는 데이터를 포함해 과거에 통신한 데이터도 복호화할 수 있다.(따로 저장해뒀다가)
• 주기적으로 세션 키를 새로 생성해서 통신 데이터를 암호화/복호화하면, 제3자 입장에서는 특정 시점의 세션 키를 알아야 복호화가 가능하다.

위에 언급한 ECDH에 PFS기능을 더한 ECDHE라는 방식을 주로 사용한다고 한다.

TLS 1.3부터는 Diffie-Hellman 계열 중 세션 키를 주기적으로 갱신하는 방식만 지원한다고 한다.

RSA

보안상의 취약점 때문에, TLS 1.3버전부터 RSA 키 교환 방식은 지원 중단되었다.
위의 HTTPS 동작 과정 부분과 같은 방식이다.
클라이언트가 세션 키를 생성 후, 서버의 공개 키로 암호화하여 전달하면, 서버는 개인 키로 복호화하여 사용한다.

이는 서버의 개인 키가 노출되면 위험성이 크고, PFS를 지원하지 않아 과거의 데이터까지 복원할 수 있게 되는 문제가 있다.

인증서는 왜 필요한가?

위조/사칭 사이트를 방지하고, 서버의 신뢰도를 높이기 위해 필요하다.

클라이언트는 인증서 유효성 검사 단계를 통해, 서버가 믿을 만한 곳인지를 확인할 수 있다. HTTPS 키 교환 과정에서 인증서가 아닌 서버의 공개 키만을 사용한다면 통신 내용을 제3자가 확인하는 것은 막을 수 있겠지만, 정작 대상 서버가 믿을 만한 곳인지는 판별하기 어렵다.

[참고 링크]

• [Web] HTTP와 HTTPS의 개념 및 차이점 - mangkyu.tistory
• SSL이란?, SSL과 TLS 정의 및 차이 - kanoos-stu.tistory
• HTTPS 통신 과정 쉽게 이해하기 #3(SSL Handshake, 협상 - aws-hyoh.tistory
• https의 cipher suite 및 RSA, DHE 키 교환 방법 - Jinyeong You.medium
• SSL/TLS #4, Forward Secrecy와 디피 헬만 키교환 방식, RSA 키교환 방식 - aws-hyoh.tistory
• [암호학] 암호학의 미궁 - 암호학의 발달 과정, Diffie-Hellman, RSA, 공개키 암호화 - loosie.tistory
• [ODOP:16]사이퍼 스위트(Cipher Suite/TLS v1.2)
• HTTPS 통신과정 쉽게 이해하기 번외편(Perfect Forward Secrecy) - aws-hyoh.tistory
• SSL/TLS #2, 인증서 검증과 Chain - aws-hyoh.tistory
• 알아두면 쓸데없는 신비한 TLS 1.3