HTTPS

1. 기본 개념: 네트워크 프로토콜

우리가 인터넷을 통해 메시지를 보낼 때, 데이터는 단순히 선을 타고 가는 것이 아니라 여러 계층(Layer)을 거치며 포장되고 운송됩니다.

이를 이해하기 쉬운 비유로 설명하면 다음과 같습니다.

• 어플리케이션 계층 (User): 택배로 보낼 '물건' (실제 데이터)

• 커널 계층 (Transport/Network): 물건을 담는 '박스' (포장 및 주소 지정)

• 하드웨어 계층: 택배가 이동하는 '도로 및 화물차' (물리적 이동)

이때 HTTP는 웹에서 데이터를 주고받는 규칙(프로토콜)이며, 이 데이터를 안전하게 배달하기 위해 하위 계층인 TCP 프로토콜을 사용합니다.

2. TCP의 특징과 한계

TCP의 특징: 연결 지향형

TCP는 데이터를 보내기 전에 연결(Connection)을 먼저 확인합니다. 이를 3-way Handshake라고 부르며, 마치 대화를 나누기 전 서로 인사를 하고 전용 대화방(Socket)을 만드는 것과 같습니다.

• 포트(Port)와 소켓(Socket):

  • 서버에는 80번 같은 문(Port)이 하나지만, 그 문을 통해 들어온 요청들은 각각 별도의 '전용 대화방'인 소켓을 만들어 1:1로 통신합니다. 이 덕분에 하나의 서버가 여러 PC와 동시에 통신할 수 있습니다.

  • OSI 7계층에서 7계층 → 4계층으로의 데이터 전달은 소켓이 필요합니다.

    • 7계층 = 사용자 공간

    • 1~4 계층 = 커널 공간

TCP의 치명적인 단점: 보안

TCP는 데이터를 포장(패킷)해서 보내지만, 그 포장을 뜯으면 내용물이 그대로 보입니다(Plain Text).

즉, 중간에 누군가 데이터를 가로채면 내용을 훔쳐보거나(도청), 위조하기가 쉽습니다. 이 문제를 해결하기 위해 등장한 것이 바로 SSL입니다.

3. SSL의 핵심 기술: 암호화

SSL은 데이터를 안전하게 보호하기 위해 대칭키와 비대칭키 방식을 혼합하여 사용합니다.

• 대칭키 (Symmetric Key):

  • 하나의 키로 잠그고(암호화) 열기(복호화)를 모두 합니다.

  • 속도가 빠르지만, 상대방에게 키를 건네줄 때 키 자체가 탈취될 위험이 있습니다.

Asymmetric Key

• 비대칭키 (Asymmetric Key):

  • 공개키(Public Key)로 잠그면 개인키(Private Key)로만 열 수 있습니다. (반대도 가능)

  • 클라이언트가 자신의 대칭키를 공개키로 암호화하여 서버로 전송하면, 서버는 자신의 개인키로 복호화하여 대칭키를 얻습니다.

SSL의 해결책 (하이브리드 방식)

1. 비대칭키를 사용해 '대칭키'를 안전하게 서버로 전달합니다.

2. 서로 '대칭키'를 공유한 후에는, 속도가 빠른 대칭키로 실제 데이터를 암호화해서 주고받습니다.

[상황]

• 클라이언트(브라우저): 대칭키(세션키)를 만들어서 서버에서 몰래 주고 싶음.

• 서버: 공개키(자물쇠)와 개인키(열쇠)를 가지고 있음.

[전달 과정]

1. 공개키 획득: 클라이언트가 서버에 접속하면, 서버는 자신의 '공개키'가 담긴 인증서를 클라이언트에게 줍니다. (누구나 가져가도 되는 키입니다.)

2. 대칭키 생성: 클라이언트는 임시로 사용할 '대칭키'를 하나 생성합니다. (아직 서버에게 전송하지 않음)

3. 암호화 (핵심): 클라이언트는 방금 만든 '대칭키'를 서버의 '공개키'로 암호화합니다. 이제 이 데이터는 서버의 개인키가 없으면 절대 열어볼 수 없는 상태가 됩니다. 중간에서 가로채도 열 수 없습니다.

4. 전송 및 복호화: 암호화된 데이터를 서버로 보냅니다. 서버는 자신이 가진 '개인키'로 이것을 열어서(복호화) '대칭키'를 꺼냅니다.

[결과]

이제 클라이언트는 자기가 만들었으니 대칭키를 가지고 있고, 서버는 암호화된 걸 받아서 풀었으니 대칭키를 갖게 되었습니다.

4. 서버의 공개키를 구분하는 방법: 인증서 (Certificate)

비대칭키를 써도 문제가 하나 남습니다. "내가 통신하려는 서버가 진짜 네이버나 구글이 맞는가?"입니다.

해커가 가짜 공개키를 뿌리고 서버인 척할 수 있기 때문입니다. 이를 막기 위해 인증서(Certificate)가 사용됩니다.

1. 서명 (Signing): 서버는 신뢰할 수 있는 기관(CA)에 자신의 정보를 줍니다. 기관은 서버의 정보와 공개키를 확인한 후, 기관의 '개인키'로 서명(암호화)하여 인증서를 발급합니다.

2. 검증 (Verification): PC(브라우저)는 서버로부터 인증서를 받습니다. PC는 이미 기관의 '공개키'를 가지고 있으므로, 이를 이용해 인증서를 열어봅니다(복호화).

3. 신뢰: 인증서가 기관의 공개키로 잘 풀린다면, "아, 이 서버는 믿을 수 있는 기관이 보증한 진짜 서버구나"라고 신뢰하게 됩니다. 그 후 인증서 안에 들어있던 서버의 공개키를 꺼내서 통신을 시작합니다.

이제 3-Handshake 과정이 끝나고 TCP 연결이 수립된 뒤, 그 위에서 TLS Handshake가 시작되어 인증서 확인과 키 교환이 이루어 집니다.

Summary

이 모든 과정을 종합하여 정리하면 다음과 같습니다.

• SSL (Secure Sockets Layer):

  • 어플리케이션 계층(HTTP)과 트랜스포트 계층(TCP) 사이에 위치하여, 데이터가 소켓을 통해 나가기 전에 암호화해 주는 보안 계층입니다.

  • 전송계층(TCP)의 443 포트는 Well-Known Port입니다.

• HTTPS:

  • HTTP가 일반 TCP 소켓이 아닌, SSL이라는 보안 계층을 얹은 소켓을 통해 통신하는 것을 말합니다.

  • HTTP가 일반 소켓(유리)라고 한다면, HTTPS는 보안 소켓(방탄복)

• TLS (Transport Layer Security):

  • SSL은 원래 넷스케이프 사에서 만들었습니다. 이것이 널리 쓰이자 국제 표준으로 정립한 것이 TLS입니다.

  • 즉, TLS는 SSL의 표준화된 업그레이드 버전이며 원리는 동일합니다. (SSL의 버전 중 하나가 TLS)

• TCP 연결 수립(SYN → SYN-ACK → ACK) → TLS 핸드셰이크(Client Hello → Server Hello → Certificate 등)

"HTTP는 TCP 위에서 동작하는데, TCP는 보안에 취약합니다. 그래서 데이터를 암호화하는 SSL(TLS) 계층을 중간에 끼워 넣었고, 이렇게 SSL을 통해 암호화 통신을 하는 HTTP를 HTTPS라고 부릅니다."