개요

---

웹을 배포해본 적이 있다면 SSL에 대해 들어본 적이 있을 것이다. SSL이 적용된 URL의 프로토콜은 https://로 시작하며, http://와 달리 보안(Secure)을 의미하는 s가 붙는다. 지금 이 사이트의 주소도 🔗 https://blog.itcode.dev로 SSL이 적용된 걸 확인할 수 있다. 🔗 NAVER나 🔗 Google도 마찬가지. 이 처럼 SSL은 굳이 웹 개발자에게만 친숙한 개념이 아니다. 누구나 인터넷을 사용했다면, 좋든 싫든 모두가 SSL을 접했다고 봐도 무방하다.

SSL(Secure Socket Layer)

---

그렇다면 이 SSL이란 놈은 뭘까? SSL은 Secure Socket Layer의 약자로, 직역하면 암호화 소켓층이다. 1994년 Netscape사에서 처음 개발되어 3.0 버전까지 존재한다.

SSL이란, 웹 서버와 클라이언트의 통신 암호화 프로토콜이다.

SSL이 적용되지 않은 통신의 경우, 위 그림과 같이 평문(Plain Text)가 그대로 전송된다. 만약 제 3자가 어떠한 방식으로든 통신 패킷을 탈취할 경우, 그 내용을 쉽게 확인할 수 있다.

통신 내용에 시덥잖은 것만 있다면 다행이겠지만, 사용자의 개인 정보나, 결제 정보와 같은 민감한 정보의 통신이라면 얘기가 달라진다.

SSL을 적용한다면 이러한 문제를 기술적으로 해결할 수 있다. 요청을 암호화해서 보내므로 통신 패킷이 탈취되도 복호화 키가 없으면 원래 내용을 알 수 없기 때문이다.

TLS(Transport Layer Security)

---

SSL을 접하다보면 TLS라는 개념도 접하게 된다. 찾다보면 SSL이랑 TLS랑 혼재되어있기도 하고.

SSL은 1996년에 3.0 버전이 출시되었으며, 보안취약점으로 인해 현재는 퇴출된 상태다.

TLS는 국제 인터넷 표준화 기구(IETF)에서 개발한 것으로, SSL 3.0의 보안취약점을 보완한 통신 보안 프로토콜이다. 현재 TLS는 2018년 1.3 버전이 출시됏다.

SSL을 보완한 것이 TLS지만, 인터넷에 적용되는 통신 보안 프로토콜을 전부 통틀어서 SSL이라 부른다.

하지만 정작 SSL은 2015년에 SSL의 마지막 버전인 3.0 마저 금지됐으므로, 현재 사용 중인 통신 보안 프로토콜은 모두 TLS다. 마치 호빵과 찐빵같은 상황인 셈.

메모

호빵과 찐빵이 왜 나와
우리가 흔히 호빵, 찐빵이라고 구분없이 부르는 음식의 정식 명칭은 찐빵이다. 호빵은 삼립식품에서 내놓은 찐빵 제품의 이름으로, 오랜 시간동안 유명해져 원래의 명칭을 대체하기도 한다.
비슷한 예로 초코파이, 대일밴드 등이 있다.

SSL의 특징

---

1. URL 프로토콜은 https이며, 기본 포트는 443이다.
2. 통신 데이터가 암호화되어, 패킷이 탈취되는 사고가 발생해도 데이터를 지킬 수 있다.
3. SSL 인증서를 통해 도메인의 신뢰성을 검증할 수 있다.
4. 데이터 송/수신 과정에서 암/복호화가 발생하므로 속도가 느리다.

SSL의 원리

---

SSL의 통신하는 원리는 아래와 같으며, 이러한 일련의 과정을 HandShake라 한다. 클라이언트와 서버 간의 요청/응답을 반복하며 통신에 필요한 사전 작업을 하는게 마치 악수 같아 붙여졌다고 한다.

1. ClientHello 요청

클라이언트가 특정 주소에 접근하면, 해당하는 서버에 요청을 보낸다. 🔗 NAVER에 접근하면 네이버 서버에 요청을 보내게 된다.

• 난수 데이터
• 암호화 프로토콜 정보 (프로토콜, 버전 등)
• 클라이언트가 사용 가능한 암호화 기법
• 세션 아이디
• 기타 확장 정보

이 요청에는 위와 같은 정보들이 포함되어있다. 클라이언트의 주요 정보를 서버에 전송하여, 해당 클라이언트를 식별하고, 어떤 암호화를 사용할 수 있는 지 등의 정보를 서버가 인지하도록 한다.

2. ServerHello 응답

서버가 ClientHello 요청을 받으면, 위의 정보를 담아 클라이언트에게 일종의 화답을 보낸다.

• 난수 데이터 (ClientHello의 데이터와 다름)
• 서버가 사용할 암호화 기법
• 인증서
  • CA
  • 도메인
  • 공개키

난수 데이터는 ClientHello에서 보낸 데이터과 아무런 상관관계가 없는 별개의 데이터다.

클라이언트가 사용 가능하다고 통보한 암호화 기법 중 서버에서 활용할 암호화 기법을 전달하여 동일한 암호화 기법으로 송수신할 수 있도록 선언한다.

인증서 정보와 함께, 서버와의 암호화 통신을 위한 서버 공개키가 전달된다. 서버의 공개키로 데이터를 암호화하면 서버는 이를 받아 개인키로 복호화하여 요청을 분석할 수 있다.

3. 인증서 검토

서버가 전달한 인증서가, 실제 해당 서버의 인증서인지, 신뢰할 수 있는 CA에서 발급된 것인지, 실제 해당 CA에서 발급받았는지 등 인증서를 검토한다.

인증서에 이상이 없다면 주소창에 위와 같이 표시된다. (Microsoft Chromium Edge 기준)

만약 문제가 있다면 아래와 같은 창을 보게 될 것이다.

이는 브라우저가 사용자에게 보내는 경고문으로, 해당 사이트의 인증서가 올바르지 않으므로 신뢰할 수 없다고 경고하는 것이다.

물론 사이트 관리자의 실수로 인증서가 만료됐거나, 잘못된 인증서를 교체해서 발생한 사소한 이유일 수도 있다. 하지만 낮선 사이트를 접속하는데 이와 같은 경고가 뜬다면, 정상적인 방법으로 인증서를 발급받을 수 없는 사이트일 가능성이 있으므로 접근을 자제하자.

악의가 없는 사이트일지라도, 사용자의 데이터는 보호해주지 못 하니 주의할 것.

4. Premaster Secret 송수신

ClientHello, ServerHello에서 송수신한 난수 데이터를 조합하여 Premaster Secret을 생성한다.

이를 ServerHello에서 전달받았던 공개키로 암호화한다. 이 데이터는 서버가 가진 개인키로만 복호화가 가능하다. 즉, 이 데이터는 탈취된다 하더라도 그 내용이 보호된다.

서버는 수신된 데이터를 복호화하여 클라이언트와 동일한 Premaster Secret을 저장할 수 있다.

5. 통신 키 생성

보유한 Premaster Secret을 토대로 Master Secret, Session Key를 생성한다. 이를 통해 클라이언트와 서버가 동일한 키를 보유하게 되므로 자신들끼리의 암호화 통신이 가능하다.

6. 데이터 송수신

필요한 데이터는 저장된 Session Key를 통한 대칭키 암호화 방식으로 암/복호화하여 통신한다.

7. 세션 종료

클라이언트와의 연결이 끊겼을 경우 사용했던 Session Key는 폐기한다.

정리

---

SSL은 통신 패킷을 암호화하여 패킷 탈취, 정보 누출 등을 방지하기 위한 보안 프로토콜이다.

현재는 모두 TLS로 교체되었지만, SSL 자체가 고유명사되어 넓은 의미의 통신 보안 프로토콜을 명칭하는 의미로 쓰인다.

현대에 이르러서는 웹 배포에 있어서 필수적인 사항이므로, 내용을 잘 이해하자.

다음 장에서는 SSL 인증서에 대해 다룬다.