네트워크

[네트워크] HTTP의 보안 취약점과 HTTPS

취업 드가자잇 2024. 4. 8. 14:51

이전 글에서 HTTP이 무엇인지, 버전별로 어떠한 특징을 가지고 있는지에 대해서 설명했다.

그리고 설명하면서 HTTP는 1.0, 1.1, 2.0, 3.0 모두 기본적으로 평문 통신을 지원하기에 보안상에 취약점이 있다는 것을 소개해드렸을 것이다. 

그렇다면 평문 통신이 뭐기에 보안상에 취약하다는 걸까 궁금하실 수 있다 (아니면 말고 ㅎㅎ)

 

HTTP의 보안상 취약점

  1. 도청될 수 있다 (평문 통신으로 인한 취약점) 
    1. 평문으로 통신하기때문에 중간에 탈취될 시 정보가 그대로 탈취된다
    2. 송신측에서 암호화 및 수신측에서 복호화 하는 방식으로 해결이 가능하나 리소스가 많이 든다
  2. 위장된 상대와 통신이 가능하다 (무상태성으로 인한 취약점) 
    1. HTTP는 기본적으로 무상태 프로토콜이기에, 각 요청은 독립적으로 수행되며, 이때 통신 상대를 확인하지 않기 때문에 위장이 가능하다
    2. 때문에 도스(Dos)와 같은 공격에 취약하다
  3. 위조될 수 있다 (데이터의 무결성으로 인한 취약점) 
    1. HTTP는 TCP/IP기반의 프로토콜을 따르기에 데이터가 손실없이, 올바른 순서로 전송되는걸 보장한다. 그러나 중간에서 누군가 네트워크 트래픽을 가로채는것까지 막아주는 것은 아니며, 평문으로 데이터를 전송하기에 전송중 데이터가 중간에 수정되더라도 이를 알아차릴 방법이 없다
    2. 해시값, 디지털 서명을 사용할 수 있으나 완벽한 해결법은 아니다

 

HTTPS

HTTP는 이렇듯 꽤 치명적인 보안상 취약점들을 가지고 있기에 이를 보완할 필요가 있었다. 그래서 등장한 것이 HTTPS(Hypertext Transfer Protocol Secure)이다. 그렇다면 HTTPS 통신에서는 어떤 과정을 거치기에 이런 보안 이슈들을 해결할 수 있는 걸까? HTTPS의 통신 과정은 다음과 같다.

통신 과정 (SSL / TLS handshake)

1. Client Hello

클라이언트측은 랜덤키를 생성, 사용가능한 암호화 알고리즘 후보 전송한다.

 

2. Server Hello

서버측도 랜덤키를 생성, 사용할 암호화 알고리즘 후보 전송한다.

이때 Certificate, CA 인증서도 함께 전송한다. 

만약 인증서에 공개키가 포함 안됬을시 공개키를 별도로 전송한다. 

 

3. Certificate Request,Server Hello Done

클라이언트는 유효한 인증서인지 브라우저에 내장된 CA들의 정보를 통해 비대칭키 시스템을 사용하여 확인한다. 

CA의 인증을 받은 인증서는 해당 CA의 개인키로 암호화되어있다.

그렇기에 이게 진짜라면 브라우저에 저장된 해당 CA의 공개키로 인증서를 복호화할 수 있다.

그리고 복호화된 인증서에는 서버의 공개키가 포함되어 있다. 

인증서가 유효하다면 서버측에 행동 완료를 알린다.

 

4. Client Key Exchange, Change Cipher Spec

클라이언트측이 Pre-master-secret 키를 생성, 이를 서버 공개키로 암호화 하여 전송한다. 그 후, 클라이언트는 "Change Cipher Spec" 메시지를 보내어 암호화된 통신을 시작할 준비가 되었음을 알린다.

 

5. 이후 과정

서버는 클라이언트로부터 받은 Pre-master secret을 자신의 개인키로 복호화한다. 이후, 서버와 클라이언트는 Pre-master secret와 각자 가지고 있는 랜덤키를 사용하여 master secret을 생성하고, 이 master secret을 기반으로 session-key(대칭 키)를 생성한다. 마지막으로, 서버 역시 "Change Cipher Spec" 메시지를 클라이언트에게 전송하여 암호화된 세션을 시작한다. 그리고 세션 종료시 이를 폐기한다. 

 

통신 과정(도식화)

보안 취약 해결

결론적으로, HTTPS는 이와같이 통신을 위한 사전절차를 추가함으로서 다음과 같은 보안상 취약점을 크게 개선할 수 있었다

 

1. 도청될 수 있다 (평문 통신으로 인한 취약점) 

보안 계층을 통해 통신 자체를 암호화 한다

공개키와 비대칭키를 혼합한 방식으로 통신

 

2. 위장된 상대와 통신이 가능하다 (무상태성으로 인한 취약점)

증명서를 통해 통신 상대가 누구인지 확인할 수 있다

도메인 주소가 포함되어 있기 때문

 

3. 위조될 수 있다 (데이터의 무결성으로 인한 취약점)

메시지 인증 코드(MAC, Message Authentication Code)를 사용하여 위조를 감지한다

HMAC은 해시 함수에 키를 결합하여 메시지에 대한 인증 코드를 생성한다.

말은 어렵지만 이전에 밝혔던 것처럼 통신 과정에서 서로 다른 랜덤키를 생성하여 결과적으로 session-key를 만들어내는 과정에 도달했던 것처럼 키가 없으면 올바른 HMAC을 생성하는 것이 불가능하며 위조될 수 있는 위험성을 크게 낮췄다는 의미이다.