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

NOTE
Basic Authentication은 데이터를 평문으로 보내는 것과 다름없으므로, 더 높은 보안을 위해 암호화를 사용한다. 이러한 암호화 프로토콜을 적용한 HTTP를 HTTPS라고 한다.

키워드#

HTTPS, SSL/TLS, 공개 키 암호법, 대칭 키 암호법, 443번 포트

메모 및 핵심 요점#

HTTP 보안 기술이 만족시켜야 하는 것 : Confidence, Integrity, Encryption, 효율, 편재성, 확장성, 적응성, 사회적 생존성
HTTPS 의 특징
- 모든 HTTP 요청과 응답 데이터가 네트워크로 보내지기 전에 암호화
- HTTP 하부에 전송 레벨 암호 보안 계층을 제공 (이 보안 계층은 SSL 또는 TLS를 이용하여 구현됨)
암호 : 메시지(평문) 을 인코딩 하는 어떤 특정한 방법과 나중에 그 비밀 메시지(암호문)를 디코딩하는 방법
키 : 암호의 동작 방식을 변경할 수 있는 매개 변수, 디코딩 과정을 바르게 동작시키려면 올바른 키를 암호 기계에 입력해야 함.
대칭키 암호 방식 : 인코딩 키 = 디코딩 키, 발송자와 수신자가 비밀 키 k를 동시에 공유해야 함
- ex: DES, Triple-DES, RC2, RC4
- 대부분의 경우, 암호화 알고리즘은 이미 공개되어 있는 경우가 많으므로 키가 중요함. 키의 길이가 길 수록 보안 상 유리함 (키를 알아내기가 힘드므로, 열거 공격을 방어)
- 단점 : 둘 다 공유키를 가져야하므로, 모든 노드에 대한 키를 생성하고 기억해야 함
공개 키 암호법 : 두 개의 비대칭 키 (인코딩을 위한 공개 키, 디코딩을 위한 개인 키)를 사용.
- 공개 키 암호 방식의 알고리즘은 계산이 느린 경향이 있음

☁️ 공개 키 알고리즘을 사용하는 경우, 중간에 키가 가로채질 염려를 덜 수 있는 것 처럼 보인다. 단일 키 알고리즘의 경우 한 쌍의 비밀 키 자체를 공유하는 과정에서 중간에 가로채질 문제가 있으나 공개 키의 경우 이러한 문제를 해결할 수 있는 것 처럼 보인다.

현실 세계에서는 공개 키 알고리즘을 통해 편리하게 안전한 의사 소통 채널을 수립하고, 이렇게 수립된 안전한 채널을 통해 무작위 대칭 키를 생성하고 교환하여 나머지 데이터를 암호화할 때 빠른 대칭키를 사용한다.
디지털 서명 : 암호 체계를 이용하여 누가 메시지를 썼는지 알려주고 그 메시지가 위조되지 않았음을 증명하기 위해 메시지에 서명을 하도록 하는 데 이용, 메시지에 붙어 있는 특별한 암호 체크섬-
디지털 서명 과정 - 주로 비대칭 공개키에 의해 생성
- 메시지를 고정된 길이의 요약(digest)로 만든다.
- 그 요약에, 사용자의 개인 키를 매개변수로 하는 ‘서명’ 함수를 적용
- 그 서명을 메시지의 끝에 덧붙이고, 메시지와 그 서명 둘 다를 노드 B에게 전송
- 메시지를 받은 노드 B가 공개키를 이용하여 서명을 풀어보고 노드 B가 가지고 있는 버전과 같은지 비교함.
디지털 인증서 : 공식적으로 ‘인증 기관’에 의해 디지털 서명된 정보의 집합이 담겨 있음. 누구나 디지털 인증서를 만들 수 있지만, 그 모두가 인증서의 정보를 보증하고 인증서를 개인 키로 서명할 수 있는 널리 인정받는 서명 권한을 얻을 수 있는 것은 아니다.
- X.509 : 인증 정보를 파싱 가능한 필드에 넣어 구조화하는 표준화된 방법을 제공한다. 오늘날 사용되는 대부분의 인증서가 그들의 정보를 X.509라 불리는 표준화된 서식에 저장됨.
서버 인증을 위한 인증서 사용하기
- 브라우저가 자동으로 접속한 서버에서 디지털 인증서를 가져온다. (서버가 인증서를 가지지 않는 경우, 보안 커넥션 실패)
HTTPS = HTTP 프로토콜 + 대칭, 비대칭 인증서 기반 암호 기법
- HTTPS는 그냥 보안 전송 계층 (SSL, TLS) 을 통해 전송되는 HTTP이다. 즉, 메시지를 TCP로 보내기 전에 보안 전송 계층을 거쳐서 그것을 먼저 암호화하게 된다.
- https는 바이너리 프로토콜이기 때문에, HTTP와는 완전히 다르다. (HTTP는 text 프로토콜이다) 띠리사 HTTPS에서 들어오는 트래픽은 443번 포트로 전달된다.
SSL이 보안 서버와의 커넥션을 준비하는 방법
1. 클라이언트는 먼저, 웹 서버의 443번 포트 (HTTPS의 기본 포트)로 연결한다.
2. 클라이언트와 서버가 암호법 매개변수와 교환 키를 협상하면서 SSL 계층 초기화
3. SSL을 통한 요청과 응답 (이제 이 메시지들은 TCP로 보내기 전에 암호화 됨)
4. SSL 닫힘
5. TCP 닫힘
보안 HTTPS 트랜잭션은 항상 서버 인증서를 요구한다.
HTTPS 를 사용할 때 프락시가 존재한다면 프락시는 클라이언트에서 보내는 HTTP 헤더를 읽을 수 없기 때문에 (암호화 되어 있으므로) 요청을 어디로 보내야 하는지 알 수가 없다. 따라서 클라이언트는 HTTP의 CONNECT 메서드를 사용하여 프락시에게 HTTP를 통하여 자신이 연결하고자 하는 안전한 호스트와 포트를 알려준다. (이를 SSL 터널링 기법이라고 한다)

스터디에서 배운 내용#

인용#

보다 중요한 트랜잭션을 위해서는, HTTP와 디지털 암호화 기술을 결합해야 한다.

☁️ HTTP 기본 인증의 가장 큰 문제점은 중간에 가로챌 수 있는 점이기 때문에, 트랜잭션 자체를 보호할 수 있는 방법을 사용하거나, 중간에 가로채더라도 이를 서버에서 사용할 수 없게끔 만들어야 한다.

코딩 알고리즘은 데이터 덩어리를 받아서 알고리즘과 키의 값에 근거하여 인코딩하거나 디코딩하는 함수이다. 평문 메시지 P, 인코딩 함수 E, 디지털 인코딩 키 e가 주어지면 부호화된 암호문 C를 생성할 수 있다. 그리고 암호문 C를 디코더 함수 D와 디코딩 키 d를 사용해서 원래의 평문 P로 도로 디코딩할 수 있다. 물론, 디코딩과 인코딩 함수는 서로의 역이다. P의 인코딩에 대한 디코딩은 원래의 메시지 P를 돌려준다. (361p)

비밀 키가 누설되면 안된다는 것은 매우 중요하다. 대부분의 경우, 인코딩 및 디코딩 알고리즘은 공개적으로 알려져 있으므로, 키만이 유일한 비밀이다! 좋은 암호 알고리즘은 공격자가 코드를 크래킹하려면 이 우주에 존재하는 모든 가능한 키 값을 시도해보는 것 외에 다른 방법이 없게 만든다. 무차별로 모든 키 값을 대입해보는 공격을 열거 공격 이라고 한다. (362p)

모든 사람이 X에게 보내는 메시지를 같은 키로 인코딩 할 수 있지만, X를 제외한 누구도 그 메시지를 디코딩할 수 없다. 왜냐하면 오직 X만이 디코딩 개인 키 dx를 가지기 때문이다. 키의 분리는, 메시지의 인코딩은 누구나 할 수 있도록 해주는 동시에 ,메시지를 디코딩 하는 능력을 소유자에게만 부여한다. (365p)

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

브라우저가 인증서를 받으면, 서명 기관을 검사한다. 만약 그 기관이 공공이 신뢰할만한 서명 기관이라면 브라우저는 그것의 공개키를 이미 알고 있을 것이며, 이전 절 “디지털 서명”에서 이야기 했던 바와 같이 브라우저는 그 서명을 검증할 수 있다. (371p)

☁️ 브라우저 자체에서 신뢰할 수 있는 기관에 대한 정보를 가지고 있다. 여기서 브라우저가 이 정보를 가지고 있지 않으면 사용자에게 서명 기관을 신뢰하는지에 대한 대화상자를 보여주는 듯.

만약 URL이 https 을 갖고 있다면, 클라이언트는 서버에 443번(기본값) 포트로 연결하고, 서버와 바이너리 포맷으로 된 몇몇 SSL 보안 매개변수를 교환하면서 ‘핸드셰이크’를 하고, 암호화된 HTTP 명령이 뒤를 잇는다.