[HTTP 완벽가이드] 14장 보안 HTTP

 

HTTP의 보안버전은 효율적이고, 이식성이 좋아야하고, 관리가 쉽고, 현실 변화의 적용력이 좋아야 한다. 

HTTP보안에 대한 특징

 

1. HTTPS 

모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화 한다. HTTP 하부에 전송 레벨 암호 보안 계층을 제공함으로써 동작하는데, 이 보안 계층은 안전 소켓 계층 (SSL) 또는 그를 계승한 전송 계층 보안(TLS)를 이용하여 구현된다. 

인코딩 및 디코딩은 보안계층에서 일어나기 때문에 HTTPS를 사용하기 위해 클라이언트와 서버가 프로토콜을 처리하는 로직을 크게 변경할 필요는 없다.

SSL (Secure Sockets Layer)

• 정의: 인터넷 통신을 암호화하여 데이터를 안전하게 전송하기 위해 설계된 프로토콜입니다.
• 역할: 클라이언트(예: 웹 브라우저)와 서버 간의 데이터가 도청되거나 위조되지 않도록 보호합니다.
• 상태: 현재는 더 이상 사용되지 않고, TLS로 대체되었습니다.

TLS (Transport Layer Security)

• 정의: SSL의 후속 버전으로, 보안 및 성능을 개선한 암호화 프로토콜입니다.
• 역할: SSL과 동일한 기능을 제공하지만 더 안전하고 효율적인 방식으로 구현됩니다.
• 현재 사용: TLS 1.2와 TLS 1.3이 널리 사용됩니다.

두 보안 레이어는 다른 의미를 가지지만 통상적으로 SSL으로 불린다.

 

2. 디지털 암호학

2.1 암호 (cipher)

암호란 메시지를 인코딩하는 어떤 특정한 방법과 디코딩하는 방법이다.

인코딩 되기전 원본 메시지는 텍스트 혹은 평문이라고 불린다.

암호가 적용되어 코딩된 메시지는 암호문이라고 불린다. 

 

2.2 암호 기계

암호는 상대적으로 간단한 알고리즘으로 시작했는데, 사람이 직접 인코딩하고 디코딩 해야 했기 때문이다. 기술이 진보하면서 보다 복잡한 암호로 메시지를 빠르게 인코딩&디코딩 하는 기계를 만들기 시작했다. 

 

2.4 키가 있는 암호

암호 기계는 암호화 동작 방식을 변경할 수있는 큰 숫자로 된 다른값을 설정할 수 있는 다이얼이 달려있다. 누군가 기계를 훔치더라도 올바른 다이얼 설정 (키값) 없이는 디코더가 동작하지 않을 것이다. 

이런 암호 매개변수를 키라고 부른다. 같은 암호기계일지라도 다른 키를 가지고 있다면 각각 다르게 동작한다. 그래서 올바른 디코딩을 위해서는 올바른 키가 필요하게된다. 

 

2.5 디지털 암호

디지털 시대가 열리고

- 속도 및 기능에 대한 기계 장치의 한계에 벗어나, 복잡한 인&디코딩 알고리즘이 가능해졌다. 

- 큰 키를 지원하는 것도 가능해져서 단일 암호 알고리즘으로 키 값마다 가상 암호 알고리즘을 만들어낼 수 있다.

(특히 키가 길면 인코딩시 많은 조합이 가능해 트래킹이 어려워진다)

 

기계장치의 물리적인 금속키 또는 다이얼과 달리, 디지털 키는 그냥 숫자에 불가하다.

디지털 키값은 인코딩과 디코딩 알고리즘에 대한 입력 값이다. 코딩 알고리즘은 데이터 덩어리를 받아 알고리즘과 키의 값에 근거해 인&디코딩하는 함수이다. 

 

3. 대칭키 암호법 

디지털 암호 = 대칭키 암호라고 불린다. 이유는 인코딩을 할때 사용하는 키와 디코딩을 사용할때 키가 동일하기 때문이다. 

잘 알려진 대칭키 암호 알고리즘은 DES, Triple-DES, RC2, RC4등이 있다. 

 

3.1 키 길이와 열거 공격 (Eunmeration Attack)

대부분의 인&디코딩 알고리즘은 공개적으로 알려져 있으므로 비밀 키는 누설되서는 안된다. 

무차별로 모든 키 값을 대입해 보는 공격을 열거 공격이라고 하는데, 만약 가능한 키 값이 몇가지 밖에 없다면 열거 공격을 통해 암호가 쉽게 깨지게 될 것이다. 

가능한 키 값의 개수는 키가 몇 바이트 인지, 얼마나 많은 키가 유효한지에 달려있다. 대칭키 암호에서는 보통 모든 키 값이 유효하다.

(8비트라면 256가지, 40비트면 2의 40승가지(약 1조), 128비트라면 340,000 * 12가지)

일반적으로 40비트면 충분했지만 최근엔 쉽게 깨질수 있어 56비트 정도를 더 안전하다고 판단한다. 그리고 128비트를 사용한 대칭키 암호는 매우 강력한 것으로 간주되기 때문에, 미국 국가안보국에서는 긴 키를 사용하는 암호화 소프트웨어의 수출을 통제하기도 한다. 

 

3.2 공유키 발급하기 

대칭키 암호의 단점은 발송자와 수신자가 암호 해석을 위해서 공유키를 가져야 한다는 것이다. 

만약 A가 특정 서버 B와 수신할때 보안이 필요하다면, 개인 비밀키를 생성하고 고객이 들어날수록 수백 수천개의 키를 생성하고 기억해야 하는 문제가 있다. 

 

4. 공개키 암호법

한 쌍의 호스트가 하나의 인&디코딩 키를 사용하는 대신, 두개의 비대칭 키를 사용하는 방법이다.

하나는 호스트의 메시지를 인코딩하기 위한 용, 하나는 디코딩을 위한 용이다. 인코딩은 공개되어있지만, 호스트만이 개인 디코딩 키를 알고있어야 한다. 

 

노드X는 자신의 인코딩 키를 공개적으로 배포할 수있고, 노드X에게 보내고자 하는 누구나 똑같고 잘 알려진 공개키를 사용할 수 있다. 하지만 X만이 디코딩 개인키를 가지기 때문에, X를 제외한 누구도 메시지를 디코딩 할 수 없다. 즉 키의 분리는 메시지 인코딩은 누구나 가능하지만 디코딩은 소유자만 가능하다는 것이다. 이는 노드는 서버의 공개키만 가지고 안전하게 메시지를 발송할 수 있기 때문에 편리하다. 

 

공개키 암호화 기술은 보안 프로토콜을 전 세계의 모든 컴퓨터 사용자에게 적용하는 것을 가능하게 했다.  

 

4.1 RSA

공개키 비대칭 암호의 과제는, 공개키, 암호문의 일부, 메시지와 암호문 이 세가지를 알고있더라고 비밀 키를 계산할 수 없다는 것을 확신시켜 주는 것이다. 이 요구를 만족하는 공개키 암호 체계 중 유명한 하나는 RSA 알고리즘이다.

 

4.2 혼성 함화 체계와 세션 키 

공개키 암호 방식의 알고리즘은 계산이 느린 경향이 있어, 실제로는 대칭과 비대칭 방식을 섞은 것을 쓴다. 

예를들면 노드들 사이의 안전한 의사소통 채널을 수립할때는 공개 키 암호를 생성하고, 임시의 무작위 대칭 키를 생성하고 교환해 이후의 나머지 데이터를 암호화 할때는 빠른 대칭키를 사용하는 방식이 쓰인다. 

 

5. 디지털 서명

암호 체계는 메시지를 암호화하고 해독하는것 뿐만 아니라 누가 썼는지 알려주고, 위조되지 않음을 증명하기 위해 메시지에 서명을 하도록 하는데 이용될 수 있다. (= 디지털 서명)

 

5.1 서명

디지털 서명은 메시지에 붙어있는 특별한 암호 체크섬이다. 보통 비대칭 공개키에 의해 생성되며, 개인 키는 오직 소유자만이 알고있어 일종의 지문 처럼 사용된다.

 

디지털 서명의 장점

a. 서명은 메시지 작성의 저자를 알려주고, 저자는 개인 키를 가지고 있어 저자만이 체크섬을 계산할 수 있다. 체크섬은 저자의 개인 서명처럼 동작한다. 

b. 서명은 메시지 위조를 방지한다. 악의적인 공격자가 송신중 메시지를 수정하면 체크섬은 더이상 그 메시지와 맞지 않게된다. 체크섬은 개인키에 관련되어 있기 때문에 공격자는 위조된 메시지에 대한 올바른 체크섬을 날조할 수 없다. 

체크섬 (Checksum)이란?

체크섬은 데이터를 전송하거나 저장할 때 오류를 감지하기 위해 생성된 고유한 값입니다. 데이터가 변경되었는지 확인하는 데 사용됩니다.

 

6. 디지털 인증서

디지털 인증서(=certs)는 신뢰할 수 있는 기관으로부터 보증 받은 사용자가 회사에 대한 정보를 담고 있다. 

 

6.1 인증서의 내부

공식적으로 인증기관에 의해 디지털 서명된 정보의 집합이 담겨있다. 누구나 인증서를 만들수는 있지만, 인증서의 정보를 보증하고 인증서를 개인 키로 서명할 수 있는 인정받은 서명 권한을 얻는 것은 아니다. 

 

6.2 X.509 v3 인증서

디지털 인증서에 대한 단일 표준은 없다. 대부분의 인증서는 X.509라 불리는 표준화된 서식에 저장하고 있다. 

X.509 v3인증서는 인증 정보를 파싱 가능한 필드에 넣어 구조화 하는 표준화된 방법을 제공한다. 

X.509 기반 인증서에는 웹 서버 인증서, 클라이언트 메일 인증서, 소프트웨어 코드사인 인증서, 인증기관 인증서를 비롯한 몇 가지 변종이 있다. 

 

6.3 서버 인증

사용자가 HTTPS를 통한 웹 트랜잭션을 시작할때, 최신 브라우저는 자동으로 접속한 서버에서 디지털 인증서를 가져온다. 서버가 인증서가 없으면 보안 커넥터는 실패한다. 

 

서버인증서에는 웹사이트의 이름과 호스트명, 공개키, 서명 기관의 이름, 서명기관의 서명 등을 포함한 많은 필드가 있다. 

 

브라우저가 인증서를 받으면, 서명 기관을 검사한다.

만약 기관이 신뢰가능한 기관이면 브라우저는 공개키를 알고있어 서명을 검증 할 수 있다. (브라우저는 여러 서명기관의 인증서가 미리 설치된 채로 출하된다) 

만약 기관이 모른는 곳이라면, 브라우저는 서명 기관을 신뢰 할 수 없기 때문에 사용자가 서명 기관을 신뢰하는지 확인하기 위한 처리를 한다. 

 

7. HTTPS의 세부사항

HTTPS는 HTTP 프로토콜에 대칭, 비대칭 인증서 기반 암호 기법의 강력한 집합을 결합한 것이며, HTTPS를 매우 안전하고 유연하고 관리가 쉽게 만들어 준다. 

 

7.1 개요

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

보안 계층은 SSL 혹은 TLS로 구현되었다. 

 

7.2 스킴

URL이 http스킴을 가지고 있다면, 클라이언트는 서버에 80번 포트로 연결하고 평범한 HTTP요청을 전송하다. 

URL이 https스킴을 가지고 있다면, 클라이언트는 서버에 443번 포트로 연결하고 서버와 바이너리 포맷으로 된 몇몇 SSL 보안 매개변수를 교환하면서 핸드셰이크를 하고 암호화된 HTTP명령이 뒤를 잇는다. 

 

SSL 트래픽은 바이너리 프로토콜이기 때문에 HTTP와는 다르다. 그래서 다른 포트를 통해서 전달된다. (SSL은 보통 443 포트를 통해 전달 받는다) 만약 SSL과 HTTP트래픽 모두가 80포트로 도착하면 웹 브라우저는 바이너리 SSL 트래픽을 잘못된 HTTP로 해석해 커넥션을 닫을 것이다. 

 

7.3 보안 전송 셋업

HTTPS에서 먼저 클라이언트는 웹서버의 443포트로 연결 한다. 일단 TCP연결이 되고나면 클라이언트와 서버는 암호법 매개변수와 교환 키를 협상하면서 SSL계층을 초기화 한다. 핸드셰이크가 완료되면 SSL초기화는 완료되고, 클라리언트는 요청 메시지를 보안 계층에 보낼 수 있다. 이 메세지는 TCP로 보내지기 전에 암호화 된다. 

 

7.4 SSL 핸드셰이크

핸드셰이크(Handshake)란?

핸드셰이크는 두 시스템(예: 클라이언트와 서버)이 서로 연결을 설정하고 통신 규칙을 합의하는 과정입니다. 이는 보안 프로토콜(SSL/TLS)에서 특히 중요한 단계로, 안전한 데이터 전송을 위한 초기 설정 과정입니다.

 핸드셰이크에서 일어나는 일

- 프로토콜 버전 번호 교환

- 양쪽이 알고있는 암호 선택

- 양쪽의 신원 인증

- 채널 암호화를 위한 임시 세션 키 생성

 

7.5 서버 인증서

SSL은 서버 인증서를 클라이언트에 나르고, 다시 클라이언트 인증서를 서버로 날려주는 상호 인증을 지원한다. 

보안 HTTPS 트랜잭션은 항상 서버 인증서를 요구 하는데 

서버 인증서는 조직의 이름, 주소, 서버 DNS 도메인 이름, 그와의 정보를 보여주는 X.509 v3에서 파생된 인증서 이다. 

 

7.6 사이트 인증서

SSL 자체는 사용자에게 웹 서버 인증서 검증 요구를 하지 않지만, 최신 웹 브라우저는 인증서에 대한 간단한 검사와 그 결과를 더 철저하게 검사할 수 있는 방법을 사용자에게 알려준다. 

 

넷스케이프가 제안한 웹 서버 인증서 검사를 위한 기초 알고리즘

a. 날짜 검사

브라우저는 인증서가 여전히 유효한지 시작및 종료 일을 검사한다. 

b. 서명자 신뢰도 검사 

인증서는 서버를 보증하는 어떤 인증기관에 의해 서명되어 있는데, 잘알려진 기관은 브라우저에 기본 내제되어 배포되지만 잘알려지지 않은 기관의 인증서를 받았다면 경고를 보내게 된다. 

c. 서명 검사

서명기관의 공개키를 서명에 적용에 체크섬과 비교후 인증서의 무결성을 검사한다. 

d. 사이트 신원 검사 

브라우저는 인증서의 도메인 이름이 서버 도메인과 맞는지 검사한다. 

 

8. HTTPS 클라이언트

SSL은 복잡한 바이너리 프로토콜이다. 암호 전문가가 아닌이상 가공되지 않은 SSL 트래픽을 직접 보내지 않는게 좋다. SSL 클라이언트와 서버 프로그래밍을 쉽게 만들어주는 상용 혹은 오픈 라이브러리들이 있다.  ( ex OpenSSL)

 

9. 프락시를 통한 보안 트랙픽 터널링

예를 들면 기업 네트워크와 공공 인터넷을 잇는 경계에 보안을 위해 프락시를 설치한다. 이 프락시는 방화벽 라우터가 HTTP 트래픽의 교환을 허락한 유일한 장치이며, 바이러스 검사나 기타 콘텐츠 제어를 수행할 것이다. 

 

클라이언트가 서버로 보낼 데이터를 서버의 공개키로 암호화하기 시작하면서 프락시는 HTTP헤더를 읽을 수 없다. HTTPS가 프락시와도 잘 동작할 수 있도록  수정해야 하는데, 인기있는 기법중에 하나는 HTTPS SSL터널링 프로토콜이다. 

HTTPS 터널링 프로토콜을 사용해서 클라이언트는 먼저 프락시에게 자신이 연결하고자 하는 안전한 호스트와 포트를 말해준다. 프락시가 읽을 수 있도록 암호화가 시작되기 전 평문으로 말해준다.