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

---

3부.HTTP : 식별, 인가, 보안

---

14장. 보안 HTTP

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

---

14.1 안전한 HTTP 만들기

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

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

  서버 인증

  • 클라이언트는 자신이 위조된 서버가 아닌 진짜와 이야기하고 있음을 알아야 한다.

  클라이언트 인증

  • 서버는 자신이 가짜가 아닌 진짜 사용자와 이야기하고 있음을 알 수 있어야 한다.

  무결성

  • 클라이언트와 서버는 그들의 데이터가 위조되는 것으로부터 안전해야 한다.

  암호화

  • 클라이언트와 서버는 도청에 대한 걱정 없이 서로 대화할 수 있어야 한다.

  효율

  • 저렴한 클라이언트나 서버도 이용할 수 있도록 알고리즘은 충분히 빨라야 한다.

  편재성

  • 프로토콜은 거의 모든 클아이언트와 서버에서 지원되어야 한다.

  괸리상 확장성

  • 현재 알려진 회선의 보안 방법을 지원해야 한다.

  사회적 생존성

  • 사회의 문화적, 정치적 요구를 만족해야 한다.

  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) 비밀 코드의 기술과 과학

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

  2) 암호(Cipher)

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

  3) 암호 기계

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

  4) 키가 있는 암호

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

  5) 디지털 암호

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

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 비트 키	56 비트 키	64비트 키	80비트 키	128비트 키
  100,000 $	2초	35 시간	1년	7만 년	10의 19승 Year
  1,000,000 $	200밀리초	3.5시간	37일	7,000년	10의 18승 Year
  10,000,00 $	20밀리초	21분	4일	700년	10의 17승 Year
  100,000,000 $	2밀리초	2분	9시간	70년	10의 16승 Year
  1,000,000,000 $	200mis	13초	1시간	7년	10의 15승 Year

  2) 공유키 발급하기

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

14.4 공개키 암호법

• 한 쌍의 호스트가 하나의 인코딩/디코딩 키를 사용하는 대신, 공개키 암호 방식은 두 개의 비대칭 키를 사용한다. 하나는 호스트의 메시지를 인코딩하기
  위한 것이며, 다른 하나는 그 호스트의 메시지를 디코딩하기 위한 것이다. 인코딩 키는 모두 공개되어 있지만 호스트만이 개인 디코딩 키를 가지고 있다.

• 키의 분리를 통해 메시지의 인코딩은 누구나 할 수 있도록 해주는 동시에, 메시지를 디코딩하는 능력은 소유자에게만 부여한다. 이는 노드가 서버로 안전하게
  메시지를 발송하는 것을 더 쉽게 해주는데, 이유는 서버의 공개 키만 있으면 되기 떄문이다.

  1) RSA

  • MIT에서 발명되고 이어서 RSA 데이터 시큐리티에 상용화된 알고리즘이다.
  • 공개키, 평문의 일부, 공개키로 평문을 인코딩하여 얻은 평문에 대한 암호문, 그리고 RSA 구현의 소스 코드까지 주어졌다 하더라도 암호를 크래킹하여
    해당하는 개인키를 찾는 것은 컴퓨터 과학의 모든 분야에서 가장 어려운 문제 중 하나라고 알려진 큰 소수의 계산하는 문제만큼 어렵다고 한다.

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

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

14.5 디지털 서명

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

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

  • 서명은 메시지를 작성한 저자가 누군지 알려준다. 저자는 저자의 극비 개인키를 갖고 있기 때문에, 오직 저자만이 이 체크섬을 계산할 수 있다.
  • 서명은 메시지 위조를 방지한다. 만약 악의적인 공격자가 송신 중인 메시지를 수정했다면, 체크섬은 더 이상 그 메시지와 맞지 않게 될 것이다. 또한
    체크섬은 저자의 비밀 개인키에 관련되어 있기 때문에, 침입자는 위조된 메시지에 대한 올바른 체크섬을 날조해낼 수 없을 것이다.
  • 디지털 서명은 보통 비대칭 공개키에 의해 생성된다. 개인 키는 오직 소유자만이 알고 있기 때문에, 저자의 개인 키는 일종의 지문처럼 활용된다.
  • 다음은 노드 A가 노드 B에게 메시지를 보내고, 서명하는 절차이다.
    • 노드 A는 가변 길이 메시지를 고정된 길이의 요약(digiest)으로 만든다. 이에 사용자의 개인키를 매개변수로 하는 서명 함수를 적용한다.
      여기서 디코더 함수 D가 사용된다.
    • 노드 A는 계산된 서명과 메시지 모두를 노드 B에게 전송한다.
    • 메시지를 받은 노드 B는 서명을 검사할 수 있다. 여기에 공개키를 이용한 역함수를 적용한다. 만약 풀어낸 요약이 노드 B가 가진 버전과 요약이
      일치하지 않는다면, 위조되었거나 노드 A가 개인키를 갖고 있지 않은 것이다.

14.6 디지털 인증서

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

  1) 인증서의 내부

  • 디지털 인증서에는 공식적으로 인증기관에 의해 디지털 서명된 정보의 집합이 담겨있다.
    • 대상의 이름, 유효기간, 인증서 발급자, 인증서 발급자의 디지털 서명
  • 추가적으로 디지털 인증서는 대상과 사용된 서명 알고리즘에 대한 서술적인 정보뿐 아니라 보통 대상의 공개키도 담고 있다.
  • 누구나 디지털 인증서를 만들 수 있지만, 그 모두가 인증서의 정보를 보증하고 인증서를 개인키로 서명할 수 있는 널리 인정받는 서명 권한을 얻는건
    아니다.

  

  2) X.509 v3 인증서

  • 디지털 인증서에 대한 전 세계적인 단일 표준은 없다. 그렇지만 오늘날 대부분의 인증서가 그들의 정보를 X.509라 불리는 표준화된 서식에
    저장하고 있다.
  • X.509 v3 인증서는 인증 정보를 파싱 가능한 필드에 넣어 구조화하는 표준화된 방법을 제공한다. 다음은 자체 서명 인증서
    (Self-Signed Certification)의 예이다.

    Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:00:00:00:00:01:15:4b:5a:c3:94
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
        Validity
            Not Before: Sep  1 12:00:00 1998 GMT
            Not After : Jan 28 12:00:00 2028 GMT
        Subject: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b:
                    ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B
    Signature Algorithm: sha1WithRSAEncryption
         d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5:
         ...

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

  3) 서버 인증을 위해 인증서 사용하기

  • 사용자가 HTTPS를 통한 안전한 웹 트랜잭션을 시작할 때, 최신 브라우저는 자동으로 접속한 서버에서 디지털 인증서를 가져온다.
  • 만약 서버가 인증서를 갖고 있지 않다면 보안 커넥션은 실패한다.
  • 서버 인증서는 다음을 포함한 많은 필드를 갖고 있다.
    • 웹 사이트의 이름과 흐스트명, 웹 사이트이 공개키, 서명 기관의 이름, 서명 기관의 서명
  • 브라우저가 인증서를 받으면 서명 기관을 검사한다. 신뢰해야 할지 확신할 수 없다면 대화 상자를 띄워 사용자에게 묻는다.

14.7 HTTPS 세부사항

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

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

  1) HTTPS 개요

  • HTTPS는 단지 보안 전송 계층을 통해 전송되는 HTTP이다.
  • HTTP 메시지를 TCP로 보내기 전에 먼저 그것들을 암호화하는 보안 계층으로 보낸다.
  • HTTPS의 보안 계층은, SSL과 그것의 현대적인 대체품인 TLS로 구현되었다.

  2) HTTPS 스킴

  • HTTPS 프로토콜에서 URL의 스킴 접두사는 https다.
  • HTTPS의 포토는 443(기본값)을 이용하며 HTTP 80과는 다르다.
  • HTTPS는 443번 포트로 연결하고 서버와 바이너리 포맷으로 된 몇몇 SSL 보안 매개변수를 교환하면서 핸드셰이크를 하고, 암호화된 HTTP 명령이
    뒤따른다.

  3) 보안 전송 셋업
  

  4) SSL 핸드셰이크

  • 암호화된 HTTP 메시지를 보낼 수 있게 되기 전, 클라이언트와 서버는 SSL 핸드셰이크를 할 필요가 있다. 핸드셰이크에서는 다음과 같은 일이 일어난다.
    1) 프로토콜 버전 번호 교환
    2) 양쪽이 알고 있는 암호 선택
    3) 양쪽의 신원을 인증
    4) 채널을 암호화하기 위한 임시 세션 키 생성
    

  5) 서버 인증서

  • 오늘날, 클라이언트 인증서는 웹 브라우징에선 흔히 쓰이지 않는다. 대부분의 사용자는 개인 클라이언트 인증서를 갖고 있지도 않다.
  • 한편, 보안 HTTPS 트랜잭션은 항상 서버 인증서를 요한다. 서버를 얼마나 신뢰할 수 있는지 평가하는 것을 도와주는 것이다.
  • 서버 인증서는 조직의 이름, 주소, 서버 DNS 도메인 이름, 그리고 그 외의 정보를 보여주는 X.509 v3에서 파생된 인증서다.
    

6) 사이트 인증서 검사

• 사이트 인증서를 검사하는 과정은 날짜 검사, 서명자 신뢰도 검사, 서명 검사, 사이트 신원 검사를 포함한다.

  7) 가상 호스팅과 인증서

• 하나의 서버에 여러 호스트(가상 호스트)로 운영되면 까다로울 수 있다.

14.8 진짜 HTTPS 클라이언트

• SSL은 복잡한 바이너리 프로토콜이라 사용하는데 어려울 수 있다. 오픈 소스 라이브러리를 활용하는 것이 좋다.

  1) OpenSSL

  • 생략

  2) 간단한 HTTPS 클라이언트

  • 생략

  3) 단순한 OpenSSL 클라이언트 실행하기

  • 생략

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

• SSL은 바이너리 프로토콜이다. 프락시는 암호화된 메시지를 받고 어리둥절할 것이다. 프락시는 메시지의 헤더에서 메시지가 어디로 전송되어야 하는지
  알아야 하는데 암호화된 메시지는 읽어낼수가 없다.이 때 HTTPS SSL 터널링 프로토콜을 사용한다.
• HTTP는 CONNECT라는 확장 메서드를 사용하여 어디로 갈지 명시 한다

  CONNECT home.netscape.com:443 HTTP/1.0
  User-agent: Mozilla/1.1N

• 프락시는 이 CONNECT 메서드를 받으면 직접 대상으로 연결시켜주는 터널을 만들어 준다.