💛 네트워크 - HTTPS의 원리를 설명하시오.

1) [네트워크] HTTPS의 원리를 설명하시오.

• HTTPS는 HTTP 프로토콜에서 암호구간(SSL/TLS)을 얹은 프로토콜이다. 클라이언트는 HTTP를 통해 요청을 보낼 때 3-way 핸드셰이크를 통해 TCP 연결을 맺은 후에 데이터를 전송한다. 이 연결로 전송되는 데이터는 평문이다. 즉, 누구든 중간에서 네트워크 패킷을 가로채서 읽을 수 있다. 카드번호를 입력한다면 누군가 쥐도 새도 모르게 카드를 도용할 수 있다는 의미이다.

  • SSL/TLS

    • SSL와 TLS는 데이터를 안전하게 주고 받기 위한 암호화 프로토콜이다.

    • HTTPS는 이 SSL/TLS를 통해 데이터를 암호화해서 전송한다.
    • SSL은 TLS의 전신이며, TLS는 SSL의 개선된 버전이다. 최신 시스템에서는 TLS를 사용하고 있다.
  • TCP

    • TCP는 데이터를 신뢰성 있게 전송하기 위한 프로토콜이다.

    • ex) 인터넷에서 데이터를 보내는 과정에서 누락되거나 순서가 뒤바뀌지 않도록 보장함.

  • 3-Way Handshake

    • 3-Way Handshake는 TCP 연결을 설정하는 과정에서 클라이언트와 서버가 통신을 시작할 준비가 되었음을 서로 확인하는 과정이다.

      • SYN(Synchronize) : 클라이언트가 서버에 연결 요청을 보낸다.

      • SYN-ACK : 서버가 그 요청을 받아들여 응답한다.
      • ACK(Acknowledge) : 클라이언트가 다시 응답을 받아 확인하고 연결이 완료된다.

• HTTPS는 이러한 데이터를 암호화하여 보내기 위해 보안 조치를 추가한다. 인증서를 통해 서버의 진위를 확인하고, 서로가 함께 알 수 있는 암호화 키를 사용하여 데이터를 보호한다. 사이트가 HTTPS를 사용하는지는 쉽게 알 수 있다. HTTPS로 통신하는 웹사이트를 접속하면 주소창에 자물쇠 표시가 나온다. 이는 여러분의 데이터가 암호화되어 서버로 전달된다는 의미이다.

---

• HTTPS가 어떻게 데이터를 안전하게 보호하는지 알아보자.

• SSL/TLS는 응용계층(HTTP)과 전송계층(TCP) 사이에서 동작한다. 다만, SSL/TLS 핸드셰이크에 필요한 연결을 생성하기 위해 TCP 3-way 핸드셰이크를 진행한다. 서버와 클라이언트 간 TCP 연결이 맺어지고 나면, 아래와 같은 패킷 전달을 통해 암호화 통신 준비를 시작한다.

• SSL/TLS 핸드셰이크 과정

  • 1) 먼저, 클라이언트는 서버에게 “안녕! 나 이런 암호화 방식을 지원해!”라고 알려주면서, random 값을 보낸다. 이 값은 나중에 암호를 만들 때 쓸 것이다.

  • 2) 서버는 클라이언트가 제안한 암호화 방식 중 하나를 선택해서 “좋아, 이 방식으로 하자!”라고 응답한다. 이때 서버도 자신의 random 값을 만들어 클라이언트에게 준다. 이제 서로 2개의 random 값을 공유하게 된다.

  • 3) 서버는 “내가 진짜 서버야!”라는 걸 증명하기 위해 서버 인증서를 보낸다. 이 인증서는 공인된 기관(CA)에서 발급받은 것이고 그 안에는 서버의 공개키가 들어있다. 클라이언트는 이 인증서를 검증한다. 만약 이 인증서가 믿을만하면, 서버의 Public Key를 믿고 사용할 수 있다.

  • 4) 서버는 “이제 내가 보낼 건 다 보냈어”라고 알려준다.

  • 5) 클라이언트는 Pre Master Secret이라는 임시 비밀키를 만든다. 이 키는 아주 중요한 정보라서 서버의 공개키로 암호화해서 서버에게 보낸다. 서버는 자신의 개인 키로 이 비밀키를 풀 수 있다.

  • 6~9) 클라이언트와 서버는 아까 주고받았던 random 값 2개와 Pre Master Secret을 가지고 Master Secret라는 공통 비밀키를 만든다. 이 비밀키는 앞으로 두 사람이 데이터를 안전하게 주고받을 때 사용할 Session 키를 생성하는 데 사용된다.

• 이제부터 클라이언트와 서버는 서로 데이터를 주고받을 때 Session 키를 사용해서 암호화한다.

• 먼저, 데이터가 변조되지 않았는지 확인하기 위해 MAC 값(데이터의 체크섬 같은 것)을 만들어둔 뒤, 그 MAC 값과 데이터를 Session 키로 암호화한다.

• 서버는 받은 데이터를 풀어서 MAC 값을 다시 계산하고, 클라이언트가 보낸 값과 비교해서 데이터가 제대로 왔는지 확인한다. 만약 같다면 데이터는 안전하게 도착한 거다!

---

대칭/비대칭 키 암호화

• SSL/TLS 핸드셰이크는 대칭과 비대칭 키 암호화 방식을 혼합한 하이브리드 방식을 사용한다.

• 대칭 키 암호화 방식은 서버와 클라이언트가 동일한 키를 사용하는 암호화 방식이다. 클라이언트는 암호화 키를 사용하여 데이터를 암호화하고, 암호화된 데이터와 키를 서버에 전달한다. 서버는 암호화된 데이터를 전달 받은 키로 복호화한다. 마치 엑셀파일을 비밀번호로 암호화하고, 비밀번호를 알려주는 것과 같다. 간편한 방식이지만, 키를 전달하는 과정에서 제삼자에게 노출될 수 있다. 따라서 대칭 키 암호화 방식을 사용하기 위해서는 키를 안전하게 전달할 수 있는 방안이 필요하다.

• 비대칭 키 암호화 방식(공개키 암호화)은 암호화와 복호화에 서로 다른 키를 사용하는 방식이다. 대표적인 예가 인증서이다. 서버는 Public 키와 Private 키 쌍을 만든다. Private 키는 자신이 소유하고, Public 키를 만천하에 공개한다. 클라이언트는 서버의 Public 키를 사용하여 데이터를 암호화하고 이를 서버에 전달한다. 이때 별도의 키를 전달할 필요는 없다. 서버는 자신의 Private 키로 복호화를 진행한다. Private 키로 암호화하고 Public 키로 복호화하여 사용자를 인증하는 디지털 서명도 비대칭 키 암호화의 좋은 예이다.

• 비대칭 키 암호화 방식이 헷갈려서 조금 더 자세한 설명을 정리했다.

비대칭 암호화란?

비대칭 암호화는 두 개의 키를 사용하는 방식:

• Public Key (공개키): 누구나 사용할 수 있는 키
• Private Key (개인키): 서버가 자신만 알고 있는 비밀키

이 두 키는 서로 묶여있는데, Public 키로 암호화한 데이터는 Private 키로만 복호화할 수 있다. 그 반대로, Private 키로 암호화한 데이터는 Public 키로만 복호화가 가능하다.

예시: 편지와 자물쇠

1. 서버는 Public 키와 Private 키를 만든다. Public 키는 공개하니까 누구나 볼 수 있는 자물쇠 같은 것임. Private 키는 서버만 가지고 있고, 절대 남에게 주지 않는다.

2. 클라이언트는 서버에게 중요한 정보를 보내고 싶어졌다. 그래서 서버가 공개한 Public 키(자물쇠)를 사용해 정보를 암호화한다. 이 암호화된 정보는 잠긴 상자와 같아서, 클라이언트는 더 이상 내용을 볼 수 없다.

3. 이 잠긴 상자를 서버에게 보냈다. 이제 서버만이 가지고 있는 Private 키(열쇠)로 이 상자를 열 수 있다. 다른 사람은 그 상자를 열 수 없다, 왜냐하면 그 열쇠는 오직 서버에게만 있기 때문이다.

즉, 클라이언트가 서버의 Public 키로 암호화한 데이터를 보내면, 오직 서버의 Private 키를 가진 서버만 그 데이터를 복호화할 수 있다는 의미이다.

---

인증서

• 인증서는 서버가 자신을 증명하기 위해 발급한 문서이다.

• 인증서가 진짜라는 보장은 없다. 마음만 먹으면 위조가 가능하기 때문이다. 따라서 누군가 사용자를 대신해서 진짜 서버의 존재를 검증해 주어야 한다. 그 존재가 바로 인증 기관(CA, Certificate Authority)이다. 인증 기관은 우리가 믿어도 된다고 합의한 공식 기관들이다.

• 구글은 자신이 진짜임을 증명하기 위한 인증서를 인증 기관을 통해 발급 받는다. 이때 인증 기관은 이 서버가 진짜 구글 서버인지 확인하고, 이 정보를 자신의 Private 키로 암호화하여 디지털 서명을 만든다. 구글 서버는 이제 이 인증서와 디지털 서명을 클라이언트에 전달한다.

• 클라이언트는 CA의 Public 키를 가지고 있다(브라우저에 내장되어 있음). 이 키를 사용해서 구글 서버가 보낸 디지털 서명을 복호화 한다. 디지털 서명을 복호화하면 해시값(인증서의 특정 요약값)이 나오는데, 인증서를 해시한 값과 비교한다. 만약 두 값이 일치하면 위조되지 않았다는 의미이다.

• CA의 Public 키는 인증서가 진짜임을 확인하기 위한 도구이다. 클라이언트는 CA의 Public 키로 디지털 서명을 검증하고, 그 안에서 서버(구글)의 진짜 Public 키를 찾아낸다.

• 이 서버의 Public 키는 나중에 Pre Master Secret을 암호화할 때 사용할 진짜 중요한 키이다.

예시: 우체국과 편지

1. 서버(구글)는 자신이 진짜임을 증명하기 위해 CA(인증 기관)에 가서 “내가 진짜 구글이야”라는 신분증(인증서)을 받았다.

2. CA는 구글의 신분증을 확인한 후, 그 신분증에 도장을 찍는다(디지털 서명). 이 도장은 CA만이 찍을 수 있고, 다른 사람이 찍을 수 없다.

3. 클라이언트(사용자)는 이 신분증이 진짜인지 확인하기 위해 CA의 도장(디지털 서명)을 확인한다. 그 도장이 진짜라면, 클라이언트는 “아, 이 서버는 진짜 구글이구나”라고 믿고, 그 안에 있는 구글의 Public 키를 사용할 수 있는 것.