대칭키, 공개키, HTTPS, SSL

HTTP 프로토콜

• 웹의 애플리케이션 계층 프로토콜
• HTTP(Hypertext Transfer Protocol)은 텍스트 기반의 통신 규약으로 인터넷에서 데이터를 주고받을수 있는 프로토콜입니다.
• 클라이언트-서버 구조를 따르며 TCP/IP위에서 작동합니다.

특징

• 클라이언트 서버 구조

  • 클라이언트가 서버에 요청(request)을 보내면, 서버는 그에 대한 응답(response)를 생성한다.

• Connectionless(비연결) 프로토콜

  • 클라이언트가 서버에 요청(request)을 했을 때, 요청에 맞는 응답(response)을 보낸 후 연결을 끊는다.

• Stateless(무상태) 프로토콜

  • 서버와의 연결이 끊어지면, 서버가 클라이언트의 상태 정보를 가지지 않는 처리 방식이다. 클라리언트가 요청할 때 필요한 데이터를 담아서 전송해야 한다.
  • 항상 같은 서버를 유지하지 않아도 되어서, 서버 확장성이 높다.

공개키와 대칭키

보안에는 키라는 개념이 있다. 키를 사용해 평문을 암호문으로 암호화하고 키를 사용해 암호문을 평문으로 복호화한다. 암호화 방식에는 크게 대칭키 암호화 방식과 공개키(비대칭키) 암호화 방식이 있다.

• 대칭키 암호화 방식은 암복호화에 사용하는 키가 동일한 암호화 방식을 말한다.
• 공개키 암호화 방식은 암복호화에 사용하는 키가 서로 다른 암호화 방식을 말한다. (비대칭키 암호화라고도 한다.)

대칭키

똑같은 개인 키를 송・수신자가 공유하여 정보를 암호화・복호화 하는 것

대칭 키 : 어떤 정보를 암호화・복호화 할 때 사용하는 키가 동일한 경우

• 암호화 된 정보의 전달, 확인을 위해선 송・수신자 둘 다 같은 키를 가져야 함

  • 어떤 정보가 대칭 키를 통해 암호화 되었을 시, 똑같은 키를 갖고 있는 사용자가 아닐 경우 해당 정보 확인 불가

• 키의 안전한 교환이 대칭 키 암호화 방식의 가장 중요한 부분

• 장점

  • 암・복호화 과정이 단순
  • 암・복호화 과정의 속도가 빠름 ⇒ 송신자와 수신자가 동일한 키를 가지고 있기 때문

• 단점

  • 송・수신자 간 키 교환이 이뤄져야함
  • 키 교환 과정 중 키 노출 위험
  • 송・수신자가 늘어날수록 관리해야할 키의 증가로 관리의 어려움

비대칭키(공개키)

1개의 쌍으로 구성된 공개키/개인키로 암호화・복호화 하는 것 방식

비대칭 키 : 어떤 정보를 암호화・복호화 할 때 사용하는 키가 서로 다른 경우

• 암호화 방식
  • 개인 키 암호화 방식 : 개인 키를 통해 암호화하여, 공개 키로만 복호화 가능 = 공개키는 모두에게 공개되어 있으므로, 인증된 정보임을 알려 신뢰성을 보장할수 있다.
    • 정보를 생산(송신)한 사람의 신원 정보 필요 시 사용
    • 데이터 제공자의 신원이 보장되는 ‘전자서명’ 등의 공인인증체계의 기본
  • 공개 키 암호화 방식 : 공개키를 통해 암호화하여 개인키로만 복호화 가능
    • 정보 자체에 대한 암호화가 필요 시 사용
    • 대칭 키 암호화 방식에서 키 값 교환에 따른 문제를 해결한 방법
• 장점
  • 단 하나의 공개 키를 사용함으로 모든 수신자와 개별 키를 만들 필요 없음
  • 데이터 송신과정 중 키를 탈취 당하더라도 해당 키로 복호화가 불가능하기에 공개키 방식보다 안전
• 단점
  • 암・복호화에 서로 다른 키를 사용하므로 대칭키와 비교해 느린 속도

HTTPS

HTTP는 정보를 텍스트로 주고 받기 때문에 네트워크에서 전송 신호를 인터셉트 하는 경우 원하지 않는 데이터 유출이 발생할 수 있다. 이러한 보안 취약점을 해결하기 위한 프로토콜이 HTTP에 S(Secure Socket)가 추가된 HTTPS이다.

HTTPS는 소켓 통신에서 일반 텍스트를 이용하는 대신에, SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화한다. 따라서 데이터의 적절한 보호를 보장한다. HTTPS의 기본 TCP/IP 포트는 443이다.

HTTPS는 HTTP와 어떻게 다를까요?

HTTPS는 HTTP와 별개의 프로토콜이 아니다. HTTPS는 단순히 HTTP 프로토콜을 통해 TLS/SSL 암호화를 사용하는 것입니다. HTTPS는 특정 공급자가 주장하는 실체가 맞는지 확인하는 TLS/SSL 인증서의 전송을 기반으로 이루어집니다.

SSL (Secure Sockets Layer)

암호학이 기밀성, 데이터 무결성, 종단점 인증 등의 보안서비스를 이용하여 향상시킨 TCP 버전을 SSL이라 부른다.

SSL의 필요성

예를 들어, 인터넷 상거래 시나리오를 들어보자.
하니가 원하는 물품, 주소, 지불카드 번호를 입력하고 "구매완료"를 클릭한 경우, 아무런 보안 수단을 취하지 않으면 다음과 같은 상황에 처할 수 있다.

• 기밀성(암호화)이 제공되지 않는다면, 하니의 주문 내용을 가로채서 지불 카드 정보를 얻을 수 있다.
• 데이터 무결성이 없다면, 하니가 원하는 구매 물품을 수정할 수 있다.
• 서버 인증이 제공되지 않는다면, 위장된 사이트에서 하니가 구매를 함으로써 신원 정보를 훔칠 수 있다.

SSL은 기밀성, 데이터 무결성, 서버 인증과 클라이언트 인증을 통해 TCP를 향상시켜 이러한 문제들을 해결한다.

왜 HTTPS Handshake 과정에서는 인증서를 사용하는 것 일까요?

SSL 핸드쉐이크 과정에서 서버는 서버의 공개키가 담긴 SSL 인증서를 클라이언트에게 제공한다. 인증서는 CA의 비밀키로 암호화되어 발급된 상태이다.
대부분 브라우저에는 공신력 있는 CA들의 정보와 CA가 만든 공개키가 이미 설치되어 있다. 서버가 보낸 SSL 인증서가 정말 CA가 만든 것인지를 확인하기 위해 내장된 CA공개키로 암호화된 인증서를 복호화해봅니다. 정상적으로 복호화가 되었다면 CA가 발급한 것이 증명되는 셈입니다. 만약 등록된 CA가 아니거나, 등록된 CA가 만든 인증서처럼 꾸몄다면 이 과정에서 발각이 되며 브라우저 경고를 보냅니다.
CA를 통해 발급된 인증서로 서버를 신뢰할 수 있다.