Skip to content

[HTTP] HTTPS.md

Latest commit

 

History

History
290 lines (239 loc) · 22.3 KB

[HTTP] HTTPS.md

File metadata and controls

290 lines (239 loc) · 22.3 KB

HTTP를 안전하게 만들기


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

  • HTTP의 보안 버전은 효율적이고, 이식성이 좋아야 하고, 관리가 쉬어야 하며, 현실 세계의 변화에 대한 적응력이 좋아야 한다.

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

  • HTTPS
    • 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화된다.
    • HTTPS는 HTTP 하부의 전송 레벨 암호 보안 계층을 제공함으로써 동작하는데, 이 보안 계층은 SSL(Secure Sockets Layer) 혹은 그를 계승한 TLS(Transport Layer Security)을 이용하여 구현된다.
    • 어려운 인코딩 및 디코딩 작업은 대부분 SSL 라이브러리 안에서 일어나기 때문에 TCP 입력/출력 호출을 SSL 호출로 대체하고, 보안 정보를 설정하고 관리하기 위한 몇 가지 호출을 추가하기만 하면 된다.

디지털 암호학

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

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

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

  • 디지털 암호
    • 디지털 계산의 도래로, 두 가지 주요한 발전이 있었다.
      • 속도 및 기능에 대한 기계 장치의 한계에서 벗어남으로써, 복잡한 인코딩과 디코딩 알고리즘이 가능해졌다.
      • 매우 큰 키를 지원하는 것이 가능해져서, 단일 암호 알고리즘으로 키의 값마다 다른 수조 개의 가상 암호 알고리즘을 만들어낼 수 있게 되었다. 키가 길수록 인코딩의 많은 조합이 가능해지고 무작위로 추측한 키에 의한 크래킹이 어려워진다.
    • 디지털 키는 그냥 숫자에 불과하다.
    • 디지털 키값은 인코딩과 디코딩 알고리즘에 대한 입력값이다.

대칭키 암호 법

  • 대칭키 암호란 인코딩과 디코딩 시에 사용하는 키가 동일한 것

  • 발송자와 수신자 모두 통신을 위해 비밀 키를 똑같이 공유할 필요가 있다.

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

  • 키 길이와 열거 공격(Enumeration Attack)
    • 무차별로 모든 키값을 대입해보는 공격을 열거 공격이라고 한다.
    • 가능한 키값의 개수는 키가 몇 비트이며 얼마나 많은 키가 유효한지에 달려있다.
    • 대칭키 암호에서는, 보통 모든 키값이 유효하다.
    • 8비트 키라면 256가지, 40비트라면 2의 40제곱(약 1조) 가지가 가능하다.
    • 128비트 키를 사용한 대칭키 암호는 매우 강력한 것으로 간주된다.

  • 공유키 발급하기
    • 대칭키 암호의 단점 중 하나는 발송자와 수신자가 서로 대화하려면 둘 다 공유키를 가져야 한다는 것
    • 대화 참여자의 각 쌍은 그들만의 개인 키를 가질 필요가 있다.
    • 각 노드가 상대 N-1과 은밀하게 대화를 나누어야 한다면, 대략 총 N제곱개의 비밀 키가 필요하다. 이것은 관리자의 입장에서 지옥이다.

공개키 암호법

  • 공개키 암호 방식은 두 개의 비대칭 키를 사용한다.

  • 하나는 호스트의 메시지를 인코딩하기 위한 것이고, 다른 하나는 그 호스트의 메시지를 디코딩 하기 위한 것이다.

  • 각 호스트마다 누구나 사용할 수 있는 인코딩 키가 할당되어 있기 때문에, 공개키 암호 방식은 대칭 키의 쌍이 N제곱개로 폭발적으로 증가하는 것을 피할 수 있다.

  • 키의 분리는, 메시지의 인코딩은 누구나 할 수 있도록 해주는 동시에, 메시지를 디코딩 하는 능력은 소유자에게만 부여한다.

  • 공개 키 인프라(Public-Key Infrastructure, PKI) 표준화 작업이 25년 넘게 계속 진행 중인 상태다. (X.509)

  • RSA
    • 비대칭 암호의 과제는, 공격자가 아래 내용을 알고 있다 해도 비밀인 개인 키를 계산할 수 없다는 것을 확신시켜 주는 것이다.
      • 공개키(물론 공개니까 누구나 얻을 수 있다)
      • 가로채서 얻은 암호문의 일부(네트워크를 스누핑해서 획득)
      • 메시지와 그것을 암호화한 암호문(인코더에 임의의 텍스트를 넣고 실행해서 획득)
    • 이 모든 요구를 만족하는 공개키 암호 체계 중 유명한 하나는 MIT에서 발명되고 이어서 RSA 데이터 시큐리티에서 상용화된 RSA 알고리즘이다.
    • 공개키, 평문의 일부, 암호문, 그리고 RSA 구현 소스코드까지 주어졌다 하더라도 암호를 크래킹 하여 해당하는 개인 키를 찾아내는 것은 컴퓨터 과학의 모든 분야에서 가장 어려운 문제 중 하나라고 알려진 큰 소수를 계산하는 문제만큼 어렵다고 한다.

  • 혼성 암호 체계와 세션 키
    • 공개키 암호 방식의 알고리즘은 계산이 느린 경향이 있다.
    • 실제로는 대칭과 비대칭 방식을 섞은 것이다.
    • 예를 들어, 노드들 사이의 안전한 의사소통 채널을 수립할 때는 편리하게 공개 키 암호를 사용하고, 이렇게 만들어진 안전한 채널을 통해 임시의 무작위 대칭 키를 생성하고 교환하여 이후의 나머지 데이터를 암호화할 때는 빠른 대칭 키를 사용하는 방식이 흔히 쓰인다.

디지털 서명

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

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

디지털 인증서

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

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

  • X.509 v3 인증서
    • 디지털 인증서에 대한 전 세계적인 단일 표준은 없다.
    • 오늘날 대부분의 인증서가 그들의 정보를 X.509라 불리는 표준화된 서식에 저장하고 있다.
    • X.509 v3 인증서는 인증 정보를 파싱 가능한 필드에 넣어 구조화하는 표준화된 방법을 제공한다.
    • X.509 기반 인증서에는 (가장 중요한) 웹 서버 인증서, 클라이언트 이메일 인증서, 소프트웨어 코드 사인(code-signing) 인증서, 인증기관 인증서를 비롯한 몇 가지 변종이 있다.

  • X.509 인증 필드
필드 서명
버전 이 인증서가 따르는 X.509 인증서 버전의 번호. 요즘은 보통 버전 3이다.
일련번호 인증기관에 의해 생성된 고유한 정수. CA로부터의 각 인증서는 반드시 고유한 일련번호를 가져야 한다.
서명 알고리즘 ID 서명을 위해 사용된 암호 알고리즘. 예를 들면, “RSA 암호화를 이용한 MD2 요약"
인증서 발급자 인증서를 발급하고 서명한 기관의 이름. X.500 포맷으로 기록되어 있다.
유효 기간 인증서가 유효한 기간. 시작일과 종료일로 정의된다.
대상의 이름 인증서에 기술된, 사람이나 조직과 같은 엔터티. 이 대상 이름은 X.500 포맷으로 기록되어 있다.
대상의 공개 키 정보 인증 대상의 공개 키, 공개 키에 사용된 알고리즘, 추가 매개변수.
발급자의 고유 ID(선택적) 발급자의 이름이 겹치는 경우를 대비한, 인증서 발급자에 대한 선택적인 고유한 식별자.
대상의 고유 ID(선택적 대상의 이름이 겹치는 경우를 대비한, 인증 대상에 대한 선택적인 고유한 식별자.
확장 선택적인 확장 필드의 집합(버전 3 이상에서 지원). 각 확장 필드는 중요한 것인지 그렇지 않은 지가 표시되어 있다. 중요한 확장은 중요하기 때문에 인증서 사용자에 의해 반드시 이해되어야 한다. 만약 인증서 사용자가 중요한 확장 필드를 이해하지 못한다면, 인증서를 거절해야 한다. 흔히 쓰이는 확장들에는 다음과 같은 것이 있다.
기본 제약
대상과 인증기관의 관계
인증서 정책
인증서가 어떤 정책하에 승인되었는지
키 사용
공개키가 어떻게 사용될 수 있는지에 대한 제한
인증기관 서명 위의 모든 필드에 대한 인증기관의 디지털 서명. 명시된 서명 알고리즘을 사용한다.

  • 서버 인증을 위해 인증서 사용하기
    • 사용자가 HTTPS를 통한 안전한 웹 트랜잭션을 시작할 때, 최신 브라우저는 자동으로 접속한 서버에서 디지털 인증서를 가져온다.
    • 서버가 인증서를 갖고 있지 않다면, 보안 커넥션은 실패한다.
    • 서버 인증서가 포함하고 있는 필드
      • 웹 사이트의 이름과 호스트 명
      • 웹 사이트의 공개키
      • 서명 기관의 이름
      • 서명 기관의 서명
    • 브라우저가 인증서를 받으면, 서명 기관을 검사한다.
    • 서명기관의 공개키로 서명기관의 서명을 요약한 값을 비교하여 인증

HTTPS의 세부사항

  • HTTPS는 HTTP의 가장 유명한 보안 버전이다.

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

  • HTTPS 개요
    • HTTPS는 그냥 보안 전송 계층을 통해 전송되는 HTTP이다.
    • 암호화되지 않은 HTTP 메시지를 TCP를 통해 전송하기 전에 그것들을 암호화하는 SSL 혹은 TLS 계층으로 보내는 것

  • HTTPS 스킴
    • 만약 URL이 http 스킴을 갖고 있다면, 클라이언트는 서버에 80번(기본값) 포트로 연결한다.
    • 만약 URL이 https 스킴을 갖고 있다면, 클라이언트는 서버에 443번(기본값) 포트로 연결하고 서버와 바이너리 포맷으로 된 몇몇 SSL 보안 매개변수를 교환하면서 ‘핸드 셰이크’를 하고, 암호화된 HTTP 명령이 뒤를 잇는다.
    • SSL 트래픽은 바이너리 프로토콜이기 때문에, HTTP와는 완전히 다르다.
    • 만약 SSL과 HTTP 트래픽 모두가 80번 포트로 도착한다면, 대부분의 웹브라우저는 바이너리 SSL 트래픽을 잘못된 HTTP로 해석하고 커넥션을 닫을 것이다.

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

  • SSL 핸드 셰이크
    • 핸드 셰이크에서 일어나는 일
      • 프로토콜 버전 번호 교환
      • 양쪽이 알고 있는 암호 선택
      • 양쪽의 신원을 인증
      • 채널을 암호화하기 위한 임시 세션 키 생성
    • HTTPS는 데이터가 네트워크를 오가기도 전에, SSL은 통신을 시작하기 위해 상당한 양의 핸드 셰이크 데이터를 주고받는다.
    • 핸드 셰이크 단계
      • 클라이언트가 암호 후보들을 보내고 인증서를 요구한다.
      • 서버는 선택된 암호화 인증서를 보낸다.
      • 클라이언트가 비밀정보를 보낸다. 클라이언트와 서버는 키를 만든다.
      • 클라이언트와 서버는 서로에게 암호화를 시작한다고 말해준다.

  • 서버 인증서
    • SSL은 서버 인증서를 클라이언트로 나르고 다시 클라이언트 인증서를 서버로 날라주는 상호 인증을 지원한다.
    • 그러나 오늘날, 클라이언트 인증서는 웹 브라우징에선 쓰이지 않는다.
    • 대부분의 사용자는 개인 클라이언트 인증서를 갖고 있지도 않다.
    • HTTPS 트랜잭션은 항상 서버 인증서를 요구한다.
    • 서버 인증서는 조직의 이름, 주소, 서버 DNS 도메인 이름, 그리고 그 외의 정보를 보여주는 X.509 v3에서 파생된 인증서다.

  • 사이트 인증서 검사
    • SSL 자체는 사용자에게 웹 서버 인증서를 검증할 것을 요구하지 않지만, 최신 웹브라우저들 대부분은 인증서에 대해 간단하게 기본적인 검사를 하고 그 결과를 더 철저한 검사를 할 수 있는 방법과 함께 사용자들에게 알려준다.
    • 넷스케이프가 제안한 웹 서버 인증서 검사를 위한 알고리즘
    • 날짜 검사
      • 인증서가 여전히 유효함을 확인하기 위해 인증서의 시작 및 종료일을 검사한다.
      • 만약 인증서가 만료되었거나 아직 활성화되지 않았다면, 인증서 검사는 실패하고 브라우저는 에러를 보여준다.
    • 서명자 신뢰도 검사
      • 모든 인증서는 서버를 보증하는 어떤 인증 기관(Certificate Authority, CA)에 의해 서명되어 있다.
      • 여러 가지 수준의 인증서가 있는데, 각각은 다른 수준의 배경 검증을 요구한다.
      • 예를 들어 전자상거래 서버 인증서를 발급받고자 한다면, 사업체로서의 법인에 대한 법적 증명을 제시해야 한다.
      • 브라우저는 신뢰할 만한 서명 기관의 목록을 포함한 채로 배포된다.
      • 만약 브라우저가 알려져 있지 않은(그리고 악의적일 가능성이 있는) 인증기관으로부터 서명된 인증서를 받았다면, 브라우저는 보통 경고를 보여준다.
      • 브라우저는 신뢰할 만한 CA가 간접적으로 서명한 인증서를 받아들이는 것을 선택할 수 있다.
    • 서명 검사
      • 한번 서명 기관이 믿을 만하다고 판단하면, 브라우저는 서명기관의 공개키를 서명에 적용하여 그의 체크섬과 비교해봄으로써 인증서의 무결성을 검사한다.
    • 사이트 신원 검사
      • 서버가 누군가 다른 이의 인증서를 복사하거나 그들의 트래픽을 가로채는 것을 방지하기 위해, 대부분의 브라우저는 인증서의 도메인 이름이 대화 중인 서버의 도메인 이름과 비교하여 맞는지 검사한다. 서버 인증서에는 보통 단일 도메인 이름이 들어있지만 몇몇 CA는 서버 클러스터나 서버 팜을 위해 서버 이름의 목록이나 서버 이름들에 대한 와일드카드 표현이 들어있는 인증서를 만든다. 만약 호스트 명이 인증서의 신원과 맞지 않는다면, 사용자를 우선으로 생각하는 클라이언트는 반드시 이 사실을 사용자에게 알리거나 잘못된 인증서 에러와 함께 커넥션을 끊어야 한다.

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

  • 클라이언트는 종종 그들을 대신하여 웹 서버에 접근해주는 웹 프락시 서버를 이용한다.

  • 예를 들어, 많은 회사가 기업 네트워크와 공공 인터넷을 잇는 경계에 보안을 위한 프락시를 설치한다.

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

  • 그러나 클라이언트가 서버로 보낼 데이터를 서버의 공개키로 암호화하기 시작했다면, 프락시는 더 이상 HTTP 헤더를 읽을 수 없다. 그리고 만약 프락시가 HTTP 헤더를 읽을 수 없다면, 프락시는 요청을 어디로 보내야 하는지 알 수 없게 된다.

  • 프락시는 암호화된 요청을 다룰 수 없다.

  • HTTPS가 프락시와도 잘 동작할 수 있게 하기 위해, 클라이언트가 프락시에게 어디에 접속하려고 하는지 말해주는 방법을 약간 수정해야 한다. 인기 있는 기법 하나는 HTTPS SSL 터널링 프로토콜이다.

  • HTTPS 터널링 프로토콜을 사용해서, 클라이언트는 먼저 프락시에게 자신이 연결하고자 하는 안전한 호스트와 포트를 말해준다.

  • 클라이언트는 이 내용을 프락시가 읽을 수 있도록 암호화가 시작되기 전의 평문으로 말해준다.

  • HTTP는 CONNECT라 불리는 새로운 확장 메서드를 이용해서 평문으로 된 종단 정보를 전송하기 위해 사용한다.

  • CONNECT 메서드는 프락시에게 희망하는 호스트와 포트 번호로 연결을 해달라고 말해주며, 그것이 완료되면, 클라이언트와 서버 사이에서 데이터가 직접적으로 오갈 수 있게 해주는 터널을 만든다.

  • CONNECT 메서드는, 안전한 원 서버의 호스트 명과 포트를 콜론으로 구분된 형태로 제공하는, 한 줄로 된 텍스트 명령이다.

CONNECT home.netscape.com:443 HTTP/1.0
User-agent: Mozilla/1.1N
빈 줄
<SSL로 암호화된 데이터가 이다음에 온다…>


  • 요청의 빈 줄 다음에, 클라이언트는 프락시로부터의 응답을 기다릴 것이다. 프락시는 요청을 평가하여 그것이 유효하고 사용자가 그러한 커넥션을 요청할 수 있도록 허가를 받았는지 확인한다. 만약 모든 것이 적법하다면 프락시는 목적지 서버로 연결하고 성공하면 200 Connection Established 응답을 클라이언트에게 보낸다.
    • HTTP/1.0 200 Connection established
    • Proxy-agent: Netscape-Proxy/1.1