[3부 14장] 보안 HTTP

[vo0a]

14장. 보안 HTTP

디지털 암호화를 이용해 도청이나 위조로부터 HTTP 트랜잭션을 안전하게 보호하는 기술을 제시한다.

14.1 안전한 HTTP 만들기

대량 구매, 은행 업무, 보안 자료 접근을 위해서 보다 강력하고 중요한 트랜잭션을 위해서는, HTTP와 디지털 암호화 기술을 결합해야 한다.

HTTP의 보안 버전은 효율적이고, 이식성이 좋아야 하고, 관리가 쉬워야 하며, 현실 세계의 변화에 대한 적응력이 좋아야 한다. 또한 사회와 정부의 요구사항에도 충족해야 한다.

• 서버 인증 - 클라이언트는 자신이 위조된 서버가 아닌 진짜와 이야기하고 있음을 알아야 한다.
• 클라이언트 인증 - 서버는 자신이 가짜가 아닌 진짜 사용자와 이야기하고 있음을 알 수 있어야 한다.
• 무결성 - 클라이언트와 서버는 그들의 데이터가 위조되는 것으로부터 안전해야 한다.
• 암호화 - 클라이언트와 서버는 도청에 대한 걱정 없이 서로 대화할 수 있어야 한다.
• 효율 - 저렴한 클라이언트나 서버도 이용할 수 있도록 알고리즘은 충분히 빨라야 한다.
• 편재성(Ubiquity) - 프로토콜은 거의 모든 클라이언트와 서버에서 지원되어야 한다.
• 관리상 확장성 - 누구든 어디서든 즉각적인 보안 통신을 할 수 있어야 한다.
• 적응성 - 현재 알려진 회선의 보안 방법을 지원해야 한다.
• 사회적 생존성 - 사회의 문화적, 정치적 요구를 만족해야 한다.

1) HTTPS

HTTP를 안전하게 만드는 방식 중에서도 가장 인기 있는 것이다. 넷스케이프 커뮤니케이션 주식회사에서 개척하였으며 모든 주류 브라우저와 서버에서 지원한다.

• URL의 시작이 https://이다.
• HTTPS를 사용할 때, 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화 된다.
• HTTPS는 HTTP의 하부에 전송 레벨 암호 보안 계층을 제공함으로써 동작하는데, 이 보안 계층은 안전 소켓 계층(Secure Sockets Layer, SSL)혹은 그를 계승한 전송 계층 보안(Transport Layer Security, TLS)를 이용하여 구현된다.
• 어려운 인코딩 및 디코딩 작업은 대부분 SSL 라이브러리 안에서 일어나기 때문에, 보안 HTTP를 사용하기 위해 웹 클라이언트와 서버가 프로토콜을 처리하는 로직을 크게 변경할 필요는 없다.
• 대부분의 경우, TCP 입력/출력 호출을 SSL 호출로 대체하고, 보안 정보를 설정하고 관리하기 위한 몇 가지 호출을 추가하면 된다.

14.2 디지털 암호학

SSL과 HTTPS에서 이용되는 암호 인코딩 기법에 대해 약간의 배경 지식을 알아본다.

• 암호
  ◦ 텍스트를 아무나 읽지 못하도록 인코딩하는 알고리즘
• 키
  ◦ 암호의 동작을 변경하는 숫자로 된 매개변수
• 대칭키 암호 체계
  ◦ 인코딩과 디코딩에 같은 키를 사용하는 알고리즘
• 비대칭키 암호 체계
  ◦ 인코딩과 디코딩에 다른 키를 사용하는 알고리즘
• 공개키 암호법
  ◦ 비밀 메시지를 전달하는 수백만 대의 컴퓨터를 쉽게 만들 수 있는 시스템
• 디지털 서명
  ◦ 메시지가 위조 혹은 변조되지 않았음을 입증하는 체크섬
• 디지털 인증서
  ◦ 신뢰할 만한 조직에 의해 서명되고 검증딘 신원 확인 정보

1) 비밀 코드의 기술과 과학

• 암호법은 메시지 인코딩과 디코딩에 대한 과학이자 기술(art)이다.
• 암호법은 단순히 참견쟁이들이 볼 수 없도록 메시지를 암호화하는 것뿐 아니라, 메시지의 변조를 방지하기 위해 사용할 수 있다.
• 누군가가 정말로 어떤 메시지나 트랜잭션의 저자임을 증명하는 데도 사용될 수 있다.

2) 암호(Cipher)

• 암호법은 암호라 불리는 비밀 코드에 기반한다.
• 암호란 메시지를 인코딩하는 어떤 특정한 방법과 나중에 그 비밀 메시지를 디코딩하는 방법이다.
• 인코딩되기 전의 원본 메시지는 흔히 텍스트 혹은 평문이라 부르며, 암호가 적용되어 코딩된 메시지를 보통 암호문이라고 부른다.

3) 암호 기계

• 사람들은 암호화 작업을 연필과 종이와 암호첩으로 수행할 수 있었다. 그러나 똑똑한 사람들이라면 꽤 간단하게 암호를 깨트리는 것도 가능했다.
• 기술의 진보로 사람들은 보다 복잡한 암호로 메시지를 빠르고 정확하게 인코딩하고 디코딩하는 기계를 만들기 시작했다.
• 암호 기계는 암호를 어렵게 하기 위해, 단순히 회전을 하는 대신 글자들을 대체하고, 그 순서를 바꾸었으며, 메시지를 자르고 토막내었다.

4) 키가 있는 암호

• 적의 손에 암호 알고리즘과 기계가 들어갈 수 있기 때문에, 대부분의 기계들에는 암호의 동작방식을 변경할 수 있는 큰 숫자로 된 다른 값을 설정할 수 있는 다이얼이 달려있다.
• 누군가 기계를 훔치더라도, 올바른 다이얼 설정(키 값)이 없이는 디코더가 동작하지 않을 것이다.
• 이러한 암호 매개변수를 키라고 부른다. 디코딩 과정을 바르게 동작시키려면 올바른 키를 암호 기계에 입력할 필요가 있다.
• 암호 키는 하나의 암호 기계를 여러 가상 암호 기계의 집합처럼 만들어주며, 이 가상 암호 기계들은 서로 다른 키 값을 갖고 있기에 제각각 다르게 동작한다.

5) 디지털 암호

• 디지털 계산의 도래로, 두 가지 주요한 발전이 있었다.
  • 속도 및 기능에 대한 기계 장치의 한계를 벗어남으로써, 복잡한 인코딩과 디코딩 알고리즘이 가능해졌다.
  • 매우 큰 키를 지원하는 것이 가능해져서, 단일 암호 알고리즘으로 키의 값마다 다른 수조 개의 가상 암호 알고리즘을 만들어낼 수 있게 되었다. 이는 무작위 크래킹을 어렵게 하였다.
• 기계 장치의 물리적인 금속 키나 다이얼 설정과는 달리, 디지털 키는 그냥 숫자에 불과하다.
  • 인코딩, 디코딩 알고리즘에 대한 입력값이다.
  • 코딩 알고리즘은 데이터 덩어리를 받아서 알고리즘과 키의 값에 근거하여 인코딩하거나 디코딩하는 함수이다.

14.3 대칭키 암호법

대칭키 암호에서, 발송자와 수신자 모두 토인을 위해 비밀 키를 똑같이 공유할 필요가 있다.

• 발송자는 공유된 비밀 키를 메시지를 암호화하고 그 결과인 암호문을 수신자에게 발송하기 위해 사용한다.
• 수신자는 역시 암호문을 받은 뒤 같은 공유된 키를 사용하여 원래의 평문을 복원하기 위해 해독 함수를 적용한다.
• 잘 알려진 대칭키 암호 알고리즘으로는 DES, Triple-DES, RC2, RC4 등이 있다.

1) 키 길이와 열거 공격(Enumeration Attack)

• 비밀 키가 누설되면 안되는 것은 매우 중요하다. 대부분의 경우, 인코딩 및 디코딩 알고리즘은 공개적으로 알려져 있으므로, 키만이 유일한 비밀이다!
• 좋은 암호 알고리즘은 공격자가 코드를 크래킹하려면 이 우주에 존재하는 모든 가능한 키 값을 시도해보는 것 외에 다른 방법이 없게 만든다.
• 무차별적인 키 값 대입 공격을 열거 공격이라고 한다.
• 무차별 대입으로 모든 값을 시도하면 결국 암호를 깨게 될 것이다. 그러나 만약 가능한 키 값이 아주 많다면, 암호를 깨뜨릴 수 있는 값 하나를 찾기 위해 수일, 수년, 심지어는 우주의 수명만큼의 시간을 들여야 할 것이다.
• 대칭키 암호에서는, 보통 모든 키 값이 유효하다. 8bit key라면 256가지 값이 가능하며, 40bit key라면 약 1조가지의 값이 가능하고,128bit key라면 약 340,000,000,000,000,000,000,000............ 가지의 값이 가능하다.
• 평범한 대칭키 암호에서, 40비트 키는 작고 중요하지 않은 업무에서는 충분하다고 할 수 있다. 그러나 오늘날 빠른 워크스테이션에게는 쉽게 깨질 수 있다.
• 반면에 128비트는 매우 강력한 것으로 간주한다.
• 키의 길이란 이처럼 중요하다.

2) 공유키 발급하기

• 대칭키 암호의 단점 중 하나는 발송자와 수신자가 서로 대화하려면 둘 다 공유키를 가져야 한다는 것이다.
• 이는 여러 사용자가 생겨날때 키를 관리하는 관리자 측면에선 지옥이다. N^2 개의 키 관리가 필요하다.

14.4 공개키 암호법

• 한 쌍의 호스트가 하나의 인코딩/디코딩 키를 사용하는 대신, 공개키 암호 방식은 두 개의 비대칭 키를 사용한다.
  • 하나는 호스트의 메시지를 인코딩하기위한 것이며, 다른 하나는 그 호스트의 메시지를 디코딩하기 위한 것이다.
  • 인코딩 키는 모두 공개되어 있지만 호스트만이 개인 디코딩 키를 가지고 있다.
    • 그래서 공개키 암호 방식이라는 이름이 붙었다.
• 키의 분리를 통해 메시지의 인코딩은 누구나 할 수 있도록 해주는 동시에, 메시지를 디코딩하는 능력은 소유자에게만 부여한다.
• 이는 노드가 서버로 안전하게 메시지를 발송하는 것을 더 쉽게 해주는데, 이유는 서버의 공개 키만 있으면 되기 때문이다.

1) RSA

공개키 비대칭 암호의 과제는, 설혹 악당이 아래 내용을 알고 있다 해도 비밀인 개인 키를 계산할 수 없다는 것을 확신시켜 주는 것이다.

• 공개키(누구나 얻을 수 있다)
• 가로채서 얻은 암호문의 일부(네트워크를 스누핑해서 획득)
• 메시지와 그것을 암호화한 암호문(인코더에 임의의 텍스트를 넣고 실행해서 획득)

이 모든 요구를 만족하는 공개키 암호 쳬계 중 유명한 하나는 MIT에서 발명되고 이어서 RSA 데이터 시큐리티에 상용화된 RSA 알고리즘이다.

공개키, 평문의 일부, 공개키로 평문을 인코딩하여 얻은 평문에 대한 암호문, 그리고 RSA 구현의 소스 코드까지 주어졌다 하더라도 암호를 크래킹하여 해당하는 개인키를 찾는 것은 컴퓨터 과학의 모든 분야에서 가장 어려운 문제 중 하나라고 알려진 큰 소수의 계산하는 문제만큼 어렵다고 한다. 만약 큰 숫자를 소수들로 분해하는 빠른 방법을 찾아낸다면 스위스 은행 계좌를 뚫는 것뿐 아니라 튜링상도 받을 수 있다.

2) 혼성 암호 체계와 세션 키

• 비대칭 공개키 암호 방식은 누구나 공개키만 알면 그 키에 대응되는 공개 서버에 안전하게 메시지를 보낼 수 있게 해주므로 훌륭하다. 두 노드가 안전하게 소통하려 할 때 협상을 먼저 해야 할 필요가 없다.
• 공개키 암호화 알고리즘은 계산이 느린 경향이 있다. 실제로는 대칭키와 비대칭키 방식을 섞은 것이 쓰인다.
  • [1부 1장] HTTP 개관 #2 - SSL 통신 과정

14.5 디지털 서명

메시지가 위조되지 않았음을 증명하기 위해서 메시지에 서명을 하도록 하는 데에 이용될 수 있다. 디지털 서명이라 불리는 이 기법은 인터넷 보안 인증서에게 중요하다.

1) 서명은 암호 체크섬이다.

• 서명은 메시지를 작성한 저자가 누군지 알려준다. 저자는 저자의 극비 개인키를 갖고 있기 때문에, 오직 저자만이 이 체크섬을 계산할 수 있다.
• 체크섬은 저자의 개인 서명처럼 동작한다.
• 서명은 메시지 위조를 방지한다. 만약 악의적인 공격자가 송신 중인 메시지를 수정했다면, 체크섬은 더 이상 그 메시지와 맞지 않게 될 것이다. 또한 체크섬은 저자의 비밀 개인키에 관련되어 있기 때문에, 침입자는 위조된 메시지에 대한 올바른 체크섬을 날조해낼 수 없을 것이다.

디지털 서명은 보통 비대칭 공개키에 의해 생성된다. 개인 키는 오직 소유자만이 알고 있기 때문에, 저자의 개인 키는 일종의 지문처럼 활용된다.

다음은 노드 A가 노드 B에게 메시지를 보내고, 서명하는 절차이다.
▪ 노드 A는 가변 길이 메시지를 고정된 길이의 요약(digest)으로 만든다. 이에 사용자의 개인키를 매개변수로 하는 서명 함수를 적용한다.여기서 디코더 함수 D가 사용된다.
▪ 노드 A는 계산된 서명과 메시지 모두를 노드 B에게 전송한다.
▪ 메시지를 받은 노드 B는 서명을 검사할 수 있다. 여기에 공개키를 이용한 역함수를 적용한다. 만약 풀어낸 요약이 노드 B가 가진 버전과 요약이 일치하지 않는다면, 위조되었거나 노드 A가 개인키를 갖고 있지 않은 것이다.

14.6 디지털 인증서

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

1) 인증서의 내부

디지털 인증서에는 공식적으로 인증기관에 의해 디지털 서명된 정보의 집합이 담겨있다.

• 대상의 이름
• 유효기간
• 인증서 발급자
• 인증서 발급자의 디지털 서명

추가적으로 디지털 인증서는 대상과 사용된 서명 알고리즘에 대한 서술적인 정보뿐 아니라 보통 대상의 공개키도 담고 있다.
누구나 디지털 인증서를 만들 수 있지만, 그 모두가 인증서의 정보를 보증하고 인증서를 개인키로 서명할 수 있는 널리 인정받는 서명 권한을 얻는 것은 아니다.

브라우저가 인증서를 받으면 서명 기관을 검사한다. 기관이 공공이 신뢰할만한 서명 기관이라면 그것의 공개키를 이미 알고 있을 것이다.

• 브라우저들을 여러 서명 기관의 인증서가 미리 설치된 채로 출하된다.
• 브라우저는 그 서명을 검증할 수 있다.
• 만약 서명 기관이 모르는 곳이라면, 브라우저는 서명 기관을 신뢰해야 할지 확신할 수 없으므로, 대개 사용자가 서명 기관을 신뢰하는지 확인하기 위한 대화상자를 보여준다.

14.7 HTTPS 세부사항

HTTP 프로토콜에 대칭, 비대칭 인증서 기반 암호 기법의 강력한 집합을 결합한 것이다.

무정부 상태의 분권화된 글로벌 인터넷 환경에서도 매우 안전한 동시에 매우 유연하고 관리하기 쉽게 만들어준다.

1) HTTPS 개요

• HTTPS는 단지 보안 전송 계층을 통해 전송되는 HTTP이다.
• HTTP 메시지를 TCP로 보내기 전에 먼저 그것들을 암호화하는 보안 계층으로 보낸다.
• HTTPS의 보안 계층은, SSL과 그것의 현대적인 대체품인 TLS로 구현되었다.
• HTTPS 프로토콜에서 URL의 스킴 접두사는 https다.
• HTTPS의 포토는 443(기본값)을 이용하며 HTTP 80과는 다르다.
• HTTPS는 443번 포트로 연결하고 서버와 바이너리 포맷으로 된 몇몇 SSL 보안 매개변수를 교환하면서 핸드셰이크를 하고, 암호화된 HTTP 명령이 뒤따른다.

2) SSL 핸드셰이크

14.9 프락시를 통한 보안 트래픽 터널링

방화벽 라우터가 HTTP 트래픽의 교환을 허락한 유일한 장치이며, 바이러스 검사나 기타 콘텐츠 제어를 수행한다.

클라이언트가 데이터를 서버의 공개키로 암호화하면 프락시는 HTTP 헤더를 읽을 수 없다.

이 때 HTTPS SSL 터널링 프로토콜을 사용한다.

• HTTSP가 프락시와도 잘 동작할 수 있게 하기 위해, 클라이언트가 프락시에게 어디에 접속하려고 하는지 말해주는 방법을 수정하는 기법.
• 연결하고자 하는 안전한 호스트와 포트를 암호화가 시작되기 전의 평문으로 말해준다.
• CONNECT 확장 메서드를 이용해서 정보를 전송하고, 완료되면 클라이언트와 서버 사이에서 데이터가 직접적으로 오갈 수 있게 해주는 터널을 만든다.
• 핸드셰이크가 성공했다면 SSL 데이터 전송이 시작된다.
  • CONNECT home.netscape.com:443 HTTP/1.0 User-agent: Mozilla/1.1N SSL로 암호화된 데이터