12. 보안 HTTP

드디어 이전 장부터 노래를 부르던 보안 HTTP입니다!

이전에 배운 보안들은 중요한 데이터를 맡기기에는 보안의 강력함이 부족했습니다. 중요한 트랜잭션을 위해서는 HTTP에 디지털 암호화 기술을 결합할 필요가 있었는데 이의 완성본이 보안 HTTP입니다!

 

보안 HTTP는 다음 요건을 만족해야 합니다.

필요 요건	설명
서버 인증	클라이언트는 위조된 서버가 아닌 진짜 서버와 통신을 하고 있음을 알아야 한다!
클라이언트 인증	서버는 위조된 클라이언트가 아닌 진짜 클라이언트와 통신을 하고 있음을 알아야 한다!
무결성	통신 도중 데이터는 위조로부터 안전해야 한다!
암호화	도청에 대한 걱정 없이 서로 통신할 수 있어야 한다!
효율	하드웨어적 제한요건이 적어야 한다. (저렴한 장비에도 보안 알고리즘이 충분히 빨라야 한다.)
편재성 (보편성)	거의 모든 클라이언트와 서버에서 지원되어야 한다.
관리상 확장성	누구든 어디서든 즉각적인 보안 통신을 할 수 있어야 한다.
적응성	항상 최신(최선)의 보안 방법을 지원해야 한다.

 

 

HTTPS

기존 HTTP에서 보안 계층(SSL or TLS)이 추가된 형식으로 HTTP 메시지를 TCP로 보내기 전 암호화를 시키는 보안 계층 보냅니다.보안 HTTP중 가장 인기가 있는 방식입니다.

 

1. 동작 과정

URL이 https 스킴을 입력하면서 시작이 됩니다. 

 

1) 셋업

그림1 셋업 과정

전체적인 셋업과정은 다음과 같습니다.

---

① 서버 URI 추출, DNS를 이용해 IP 및 포트 찾기 [HTTP : 80, HTTPS : 443]

② 클라이언트측에서 커넥션 생성을 요청합니다. (SYN)

③ 서버측에서 커넥션 생성 요청에 대한 응답을 보냅니다. (SYN + ACK) 

 

===================== TCP 연결 완료 =====================

 

④ 클라이언트의 암 호법 매개변수 (SSL 보안 매개변수) + 교환 키 전송

⑤ 서버의 암호법 매개변수 (SSL 보안 매개변수) + 교환 키 전송

(SSL 핸드 셰이크)

 

===================== SSL 초기화 완료 =====================

 

SSL 초기화가 완료되면, TCP로 메시지를 보낼 때마다, 암호화가 되어 전송이 됩니다.

---

 

PLUS1. SSL 핸드 셰이크

  SSL 핸드 셰이크에서는 다음과 같은 일이 일어납니다.

    1. 프로토콜 버전 번호 교환

    2. 공통으로 알고 있는 암호 선택

    3. 서버 인증서를 이용한 신원 인증.

    4. 채널을 암호화할 임시 세션 키 생성

 

 

PLUS2. 서버 인증서 (서버 디지털 인증서)

SSL에서는 클라이언트/서버 인증서를 통해 신원을 인증하는 기능을 지원합니다. 오늘날에는 클라이언트 인증서는 잘 쓰이지 않고, 서버 인증서만 쓰입니다. (몇몇 인트라넷에서만 사용)

SSL 트랜잭션에서는 개인이 '이 서버가 신뢰할만한가'를 알기 위해 서버 인증서를 요구합니다. 이를 통해 가짜 서버와 통신하는 것을 막을 수 있습니다.

 

검사방식은 다음과 같습니다.

  1st. 날짜 검사 (인증서 신선도)

  2nd. 서명자 신뢰도 검사

  3rd. 공개키를 이용한 서명과 체크섬 비교

  4th. 사이트 신원 검사 (인증서 도메인명과 서버 도메인명 비교)

 

 

2) 데이터 통신 시작

그림2 데이터 통신 과정

다음은 데이터 통신 과정입니다.

 

HTTP는 TCP 내에서 일반적인 통신을 하지만 HTTPS는 SSL 초기화가 완료되었기 때문에, 메시지를 보안 계층에 보내 암호화 후 전송을 실시합니다. 일반 HTTP의 데이터 통신과정은 이전에 다루었으니 HTTPS의 데이터 통신과정만 다루겠습니다!

---

① 요청 메시시를 보안 계층에 보내 암호화(E) 후 TCP를 통해 전송

② 받은 암호문을 복호화(D) 후 읽어 요청에 대한 응답 메시지를 ①과 같은 방법으로 전송

 

===================== 데이터 통신 완료 =====================

 

③ 데이터 통신이 완료되었으면, SSL 닫음을 알립니다. (Fin)

④ SSL 닫음을 확인하고 SSL을 닫습니다.

 

===================== SSL 닫음 완료=====================

 

⑤ TCP 커넥션을 닫음을 알립니다 (FIN)

⑥ TCP 커넥션 닫음을 확인하고 확인 메시지를 전송합니다 (FIN + ACK)

 

===================== 커넥션 종료=====================

---

 

2. 프록시를 통한 보안 트래픽 터널링

프록시를 설명할때 보안을 위해서도 프록시를 사용한다고 했습니다.

 

주로 모든 트래픽이 반드시 프록시를 거치게 하는 방식으로 제어하는 방법을 채택했었습니다.

그림 3 방화벽 프록시

여기서 문제가 발생합니다.

 

만약 클라이언트가 서버의 공개키로 암호화를 해 메시지를 전송한다면??

 

이로 인해 발생하는 문제점은 트래픽을 제어하는 출구 프록시는 데이터를 복호화할 수 없기 때문에, HTTP 헤더를 읽을 수 없게 됩니다. 이로 인해 요청의 최종 목적지를 몰라 전송에 어려움을 겪게 됩니다.

이를 방지하기 위해서 메시지에 추가 작업을 해 프록시에게 해당 정보를 알려주어야 합니다. 현재 HTTPS SSL 터널링 프로토콜이 가장 인기있는 방식입니다. 

 

작동 순서

1ST. 클라이언트는 암호문을 전송하기 전, HTTP CONNECT 메서드를 통해 프록시에게 목적지 서버 정보들을

       평문으로 전송합니다.

2ND. 프록시는 받은 정보(호스트, 포트번호)를 통해 클라이언트와 목적지 서버 사이를 오갈 수 있는 터널을 만듭니다.

3RD. 커넥션 핸드 셰이크가 성공하면, SSL 데이터를 전송합니다.

 

클라이언트와 프록시는 다음 메시지들을 주고받습니다.

그림4 HTTPS SSL 터널링 프로토콜