HTTP - (8) HTTPS, 보안

요즈음 웹에 개인정보와 같은 중요한 정보들을 올려두곤 한다. 예를 들어 온라인 쇼핑몰이라든지, 혹은 중요 문서들을 웹 서버에 올려둔다.

이처럼 웹은 안전한 방식의 통신을 필요로 한다.

이번 글은 HTTP 보안 기술에 대해 살펴볼 것이다.

​

보안 기술에는 여러 가지가 있다.

- 서버 인증, 클라이언트 인증, 무결성, 암호화, 효율 등이 있다.

​

가장 알려져있는 HTTPS부터 시작해보자.

HTTPS는 HTTP와 달리 네트워크로 요청과 응답 메시지가 오가기 전에 암호화된 채로 전송된다.

HTTP하부(애플리케이션 계층 하부)에 암호 보안 계층을 추가하여 동작하는데,

이 계층은 SSL(안전 소켓 계층)혹은 TLS(전송 계층 보안)을 통해 구현된다.

​

출처 : http://www.ktword.co.kr/abbr_view.php?m_temp1=3132

SSL에 대해 좀 더 자세히 얘기하기 전에, 디지털 암호학에 대한 기본 배경지식을 훑고 가자.

기본적인 개념은 아래와 같다.

* 암호 : 평문이 아닌, 아무나 읽을 수 없게 인코딩하는 기법

* 키 : 암호화하는 매개변수

* 대칭키 암호 체계 : 인코딩과 디코딩이 같은 키를 사용함 (반대 : 비대칭키 암호 체계)

​

악의적인 공격은 직접 모든 경우의 수를 다 따져 맞는 키를 알아내게 될 것이다.

따라서 가능한 키가 많으면 많을 수록 암호 수준이 올라간다.

ex. 8비트 키라면 256가지 값이 가능, 40비트는 약 1조 가지의 값이 가능함

참고로 128비트 키를 사용한 대칭 암호는 보안 수준이 매우 강력한 것으로 여겨진다.

​

대칭키를 사용하게 되면 발송자/수신자가 모두 동일한 키를 사용해야한다는 것이다.

하지만 이 경우에는 키를 노드 수만큼 발급하고 서로 관리하고 있어야한다. 이에 따라 공개키 암호법이 등장했다.

공개키 암호 방식은 두 개의 비대칭 키를 사용하는 것인데, 하나는 인코딩용, 다른 하나는 디코딩용이다.

인코딩 키는 모두에게 공개되어있지만, 디코딩 키는 호스트만이 알고 있다.

즉 서버만이 공개키를 보유하고, 이를 모든 클라이언트들에게 공유하여 메시지를 암호화하도록 하면, 보안이 보장되는 것이다.

​

이처럼 메시지 내용을 해독할 수 없도록 하는 암호 방식도 있지만,

메시지를 작성한 사람이 누구이고, 그 메시지가 위조되지 않았다는 것을 증명하기 위해 사용되는 '디지털 서명' 역시 보안에서 중요하다.

서명은 체크섬인데, 저자가 누구인지를 알려주고 위조를 방지하는 역할을 한다.

디지털 서명은 보통 비대칭 공개키로 생성되는데, 개인 키는 오로지 소유자만이 알고 있기 때문에 일종의 '지문'인 것이다.

노드가 개인 키를 이용하여 서명을 담은 메시지를 보내면, 수신자는 공개키로 디코딩하고, 위조 여부를 판단한다.

​

이번엔 디지털 인증서에 대해 살펴보자.

인증서는 보통 우리가 생각하는 여권이나 운전면허와 같은 ID와 유사하다. 대상의 이름, 유효 기간, 발급자, 발급자의 서명이 담겨있다.

디지털 인증서는 세계적으로 단일 표준이라고 할 만한 것이 따로 없다. 하지만 대부분 X.509라고 불리는 표준화된 서식으로 담는다.

주로 버전, 일련번호, 서명 알고리즘 ID, 인증서 발급자, 유효 기간 등이 있다.

​

사용자가 HTTPS를 통해 웹 트래픽을 개시하였을 때, 브라우저는 디지털 인증서를 가져오게 된다.

디지털 인증서의 서명 기관이 공공적으로 신뢰할만한 기관이라면 브라우저는 통상 공개키를 이미 알고 있을 것이다.

이 공개키를 기반으로 브라우저는 서명을 검증하게 된다.

​

이제 다시 HTTPS 이야기로 돌아가자.

HTTPS는 단순히 보안 전송 계층을 통해 전송되는 HTTP이다. HTTP메시지를 TCP로 보내기 전에 암호화하게 된다.

HTTP보안은 선택적이기 때문에 웹 서버에게 보안 프로토콜을 적용할 경우 URL스킴을 통해 판단하도록 한다. (http:// , https://)

URL이 http스킴이라면 클라이언트는 서버에 80번 포트로 연결하고, https스킴일 경우에는 443번 포트로 연결한다.

포트 넘버가 다른 이유는, SSL 트래픽이 바이너리 프로토콜이기 때문이다.

​

HTTP와 HTTPS의 트랜잭션 과정을 비교하여 살펴보자.

* HTTP

1) 서버 80번 포트로 TCP커넥션을 수립

2) TCP커넥션을 통해 메시지 요청과 응답이 오감

3) TCP커넥션 닫힘

​

* HTTPS

1) 서버의 443번 포트로 TCP커넥션 수립

2) SSL 보안 매개변수 Handshake

3) SSL을 통해 HTTP요청 > TCP로 암호화된 요청 전송. 응답 역시 반대

4) SSL 닫힘 통지, TCP커넥션 닫힘

​

여기에서 Handshake란 프로토콜 버전 번호와 암호, 신원 인증 등의 과정이 진행된다.

클라이언트가 서버로 암호 후보들을 보내고, 인증서를 요구하면 서버가 암호와 인증서를 보낸다.

클라이언트는 비밀정보를 서버로 보내고, 각자는 키를 생성하게 된다.

이 때 서로에게 암호화를 시작한다는 노티를 주고받는다.

​

통상적으로 클라이언트 인증서는 요구하지 않으며, 서버 인증서는 항상 필요로 하게 된다.

서버 인증서를 받게 되면, 브라우저는 인증서 검사를 하게 된다.

우선 가장 먼저 유효 기간으로부터 날짜 검사를 진행한다. 그 후 서명자 신뢰도를 검사하고, 서명에 대해 검증한다.

서명자 신뢰도를 검사할 때 참고할 점은, 브라우저들이 일반적으로 신뢰할만한 인증서 기관에 대해서는 목록을 내포한채로 배포된다는 것이다.

​

SSL은 바이너리 프로토콜인데, 무척 복잡하다고 한다. 클라이언트와 서버에서 SSL프로그래밍을 가능하게 해주는 오픈 소스 라이브러리들이 있다.

OpenSSL이 가장 대표적인 SSL, TSL의 구현 소스이다.

​

만약 프락시를 통해 보안 트래픽을 전송해야할 경우엔 어떻게 해야할까?

바로 터널링을 사용하는 것인데, 클라이언트가 서버로 보낼 데이터를 서버 공개키로 암호화하였다면 프락시는 HTTP헤더를 읽을 수 없기 때문이다.

즉 프락시는 암호화된 요청을 다룰 수 없기 때문에, 클라이언트쪽에서 어디에 접속하고자 하는 것인지 프락시에게 알려준다.

그 방법이 바로 HTTPS SSL 터널링인데, 클라이언트가 프락시에게 연결하고자 하는 호스트와 포트를 알려주게 된다. (평문으로)

CONNECT라는 새로운 HTTP 메서드를 통해 그 정보를 전달하면,

클라이언트와 서버 사이에서 직접 데이터가 오갈 수 있도록 터널을 만들어 제공해준다.

​

---

참고도서

https://book.naver.com/bookdb/book_detail.nhn?bid=8509980

 

HTTP 완벽 가이드

성공적인 웹 트랜잭션 뒤의 숨은 핵심, HTTP의 모든 것『HTTP 완벽 가이드』는 HTTP 규약이 어떻게 작동하고 웹 기반 애플리케이션을 개발하는 데 어떻게 사용하는지 설명하고, HTTP가 효율적으로 동작하도록 함께 사용하는 다른 핵심 인터넷 기술에 대해서 소개한 책이다. 책에서는 HTTP 메서드, 헤더, 상태 코드, 프락시와 캐시의 최적화, 웹 로봇과 크롤러 설계 전략, 쿠키, 인증, 보안 HTTP, 국제화와 내용 협상, 리다이렉션과 부하 균형 전략, 더 좋은 성능의 HTTP, HTTP/2.0에 대해서 다루고 있다. 또한, 10...

book.naver.com