Homewho I amMy Thinking

Ideveloper's
Thinking

ideveloper
Front end Developer who steadily study
Nov 30, 2019 - 11 min read

보안 HTTP (HTTPS)

이 글은 HTTP 완벽가이드 14장을 참고해 정리한 포스팅입니다.

시작하기에 앞서

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

시작하기에 앞서 https의 이해를 돕는 링크를 첨부합니다.

HTTP를 안전하게 만드는 방법

많은 사람들은 웹 트랜잭션을 통해 중요한 일들을 일상속에서 하게 됩니다. 강력한 보안이 없다면, 온라인 쇼핑, 인터넷 뱅킹을 할때에도 안심 할 수 없을 것이고 회사들은 중요한 문서를 웹 서버에 올려놓을 수 없을 것입니다.

이로 인해 안전한 방식의 HTTP의 필요성이 대두되었습니다.

그리고 이러한 안전한 방식의 HTTP 기술은 아래와 같은 요소들을 보장 할수 있어야 합니다.

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

HTTPS

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

image

디지털 암호학

HTTPS에 대해 알아보기 전, SSL과 HTTPS에서 이용되는 암호 인코딩 기법에 대해 약간의 배경 지식을 제공할 필요가 있습니다. 알아볼 내용을 요약하면 아래와 같습니다.

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

암호, 암호법

암호법은 메시지 인코딩과 디코딩에 대한 기술입니다. 암호법은 단순이 메시지를 암호화 하는것 뿐만 아니라, 메시지의 변조를 방지하기 위해 사용할수도 있습니다. 또는 누군가가 어떤 메시지나 트랜잭션의 저자임을 증명하는데도 사용될 수 있습니다.

암호

  • 암호법은 암호라 불리는 비밀 코드에 기반합니다. 암호란 메시지를 인코딩 하는 어떤 특정한 방법과 나중에 그 비밀 메시지를 디코딩 하는 방법입니다.

키가 있는 암호

  • 코드 알고리즘과 기계가 다른 사람의 손에 들어갈 수 있기 때문에, 암호의 동작방식을 변경할 수 있는 특정 매개변수가 도입되었고 이를 키라고 부릅니다.
  • 디코딩 과정을 바르게 동작시키려면 올바른 키를 암호기계에 입력할 필요가 있습니다.

아래 예에서 알수 있듯 키 값에 따라, 다른 암호문이 만들어지게 됩니다. image 그림 - 다른 키를 사용하는 N번 회전 암호

키값을 활용한 암호화는 도식화 하면 아래와 같습니다. 평문 메시지 P, 인코딩 함수 E, 디지털 인코딩 키 e 가 주어지면 부호화된 암호화 문 C를 생성할 수 있고, 암호문 C를 디코더 함수 D와 디코딩 키 d를 사용해서 원래의 평문 P로 디코딩 할 수 있습니다. 물론, 디코딩과 인코딩 함수는 서로의 역입니다.

image 그림 - 평문은 인코딩 키 e로 인코딩되고, 디코딩 키 d로 디코딩됩니다.

대칭키 암호법

많은 디지털 암호 알고리즘은 대칭키 암호라 불리는데, 인코딩을 할때 사용하는 키가 디코딩을 할때와 같기 때문입니다.

키 길이와 열거 공격

  • 인코딩 및 디코딩 알고리즘은 공개적으로 알려져 있으므로, 키만이 유일한 비밀입니다.
  • 무차별로 모든 키 값을 대입해보는 공격을 열거 공격이라고 합니다.
  • 8비트 키라면, 256가지 값이 가능하며, 40비트 키라면 2^40(약 1조)가지가 가능하고, 128비트라면 약 340,000,000,000,000,000,000,000,000,000,000,000,000,000 가지의 값이 가능합니다.
공격비용 40비트 키 56비트 키 64비트 키 80비트 키 128비트 키
100,000달러 2초 35시간 1년 7만년 10^19년
100,000,000달러 200 마이크로초 13초 1시간 7년 10^15년

공유키 발급하기

  • 대칭키 암호의 단점 중 하나는 발송자와 수신자가 서로 대화하려면 둘 다 공유키를 가져야 한다는 것입니다.
  • 만약 N개의 노드가 있고, 각 노드가 상대 n-1과 대화를 나누어야 한다면, 대략 N^2개의 비밀키가 필요하게 됩니다.

공개키 암호법

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

RSA

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

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

이 모든 요구를 만족하는 공개키 암호 체계 중 유명한 하나는 RSA알고리즘입니다.

디지털 서명

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

암호 체크섬

디지털 서명은 메시지에 붙어있는 특별한 암호 체크섬입니다.이는 아래와 같은 두가지 이점을 가집니다.

  • 서명은 메시지를 작성한 저자가 누군지 알려줍니다. 저자만이 개인키를 가지고 있기 때문에 이 체크섬을 계산할 수 있고, 체크섬은 저자의 개인 서명 처럼 동작합니다.
  • 서명은 메시지 위조를 방지합니다. 악의적인 공격자가 송신중인 메시지를 수정했다면, 체크섬은 메시지와 맞지 않게 됩니다.

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

  • 아래 그림에서 볼수 있듯. 가변길이 메시지를 정제하여 고정된 길이의 요약으로 만들고, 사용자의 개인 키를 매개변수로 하는 서명 함수를 적용합니다. image

그림 - 디지털 서명 해독 과정

디지털 인증서

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

인증서의 내부

인증서 내부는 아래와 같은 정보를 담고 있고, 대상의 공개키도 담고 있습니다.

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

image

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

사용자가 HTTPS를 통한 안전한 웹 트랜잭션을 시작할때, 최신 브라우저는 자동으로 접속한 서버에서 디지털 인증서를 가져옵니다. 서버 인증서는 아래를 포함한 많은 필드를 가지고 있습니다.

  • 웹 사이트의 이름과 호스트명
  • 웹 사이트의 공개키
  • 서명 기관의 이름
  • 서명 기관의 서명

image 그림 - 서명이 진짜인지 검증

HTTPS의 세부사항

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

HTTPS의 개요

  • HTTPS는 HTTP 메시지를 TCP로 보내기 전에 먼저 그것들을 암호화하는 보안 계층으로 보냅니다.
  • 오늘날 HTTPS의 보안 계층은, SSL과 TLS로 구현되어 있는데, SSL과 TLS를 모두 SSL로 통용하여 사용하곤 합니다.

image

HTTPS의 스킴

보안 없는 일반적인 HTTP URL 스킴 접두사 (http) : http://ideveloper2.dev

보안이 되는 HTTPS 프로토콜에서의 URL 스킴 접두사 (https) : https://ideveloper2.dev/blog
  • 클라이언트는 웹 리소스에 대한 트랜잭션 수행 요청을 받으면, URL의 스킴을 검사하게 됩니다.
    • URL이 HTTP 스킴을 갖고 있다면, 클라이언트는 서버에 80번(기본값) 포트로 연결하고 평범한 HTTP명령을 전송하게 됩니다.
    • 이에 반해, 만약 URL이 HTTPS 스킴을 갖고 있다면, 클라이언트는 서버에 443번(기본값) 포트로 연결하고 서버와 바이너리 포맷으로 된 몇몇 SSL 보안 매개변수를 교환하면서 핸드셰이크를 하고 암호화된 HTTP 명령이 그뒤를 잇게 됩니다.
    • HTTPS는 바이너리 프로토콜이기 때문에 SSL과 HTTP 트래픽 모두 80번 포트로 도착한다면 잘못된 http로 해석하고 커넥션을 닫을 것입니다.

바이너리 프로토콜 vs 텍스트 프로토콜 : https://inthelife.tistory.com/457

보안 전송 셋업

  • (a)
    • 클라이언트는 웹 서버 80번 포트로 TCP 커넥션을 열고, 요청 메시지를 보내고, 응답 메시지를 받고, 커넥션을 닫습니다.
  • (b)
    • 클라이언트는 443번 포트로 TCP 커넥션을 열고, 클라이언트와 서버는 암호법 매개변수와 교환 키를 협상하면서 SSL 계층을 초기화 합니다.
    • 핸드셰이크가 완료되면 클라이언트는 요청메시지를 보안 계층에 보내고, TCP로 보내지기 전에 암호화 됩니다.

image

SSL 핸드셰이크

암호화된 HTTP 메시지를 보낼수 있게 되기전에 클라이언트와 서버는 SSL 핸드셰이크를 할 필요가 있는데, 그때 일어나는 일은 아래와 같습니다.

  • 프로토콜 버전 번호 교환
  • 양쪽이 알고 있는 암호 선택
  • 양쪽의 신원을 인증
  • 채널을 암호화 하기 위한 임시 세션 키 생성

따라서 암호화된 HTTP 데이터가 네트워크 상에서 오가기도 전에 SSL은 상당한 양의 핸드셰이크 데이터를 주고받게 됩니다.

image

서버 인증서

  • SSL은 서버 인증서를 클라이언트로 나르고 다시 클라이언트 인증서를 서버로 날라주는 상호 인증을 지원합니다.
  • 그러나 오늘날 클라이언트 인증서는 웹브라우징에서 흔히 쓰이지는 않습니다.
  • 한편 보안 HTTP 트랜잭션은 항상 서버 인증서를 요구하게 됩니다.
  • 서버 인증서는 조직의 이름, 주소, 서버 DNS 도메인 이름, 그외 여러 정보들을 보여주는 X.509 v3에서 파생된 인증서입니다.

image

사이트 인증서 검사

SSL 자체는 사용자에게 웹 서버 인증서를 검증할 것을 요구하지는 않지만, 최신 웹브라우저들은 대부분 인증서에 대해 간단하게 기본적인 검사를 합니다.

넷스케이프가 제안한 웹 서버 인증서 검사를 위한 알고리즘은 대부분 웹 브라우저의 검사 기법의 기초를 구축했고 단계는 다음과 같습니다.

  • 날짜 검사
    • 인증서의 시작 및 종료일 검사
  • 서명자 신뢰도 검사
    • 브라우저가 알려져 있지 않은 인증기관으로부터 서명된 인증서를 받았다면, 경고를 보여줌.
    • 또한 신뢰할만한 CA가 간접적으로 서명한 인증서를 받아들일 수 있음
    • ex) CA가 ideveloper2 블로그 인증서에 서명을 하고, ideveloper2 블로그가 다른 사이트 인증서에 서명을 한다면, 올바른 CA경로에서 파생된것으로 보고 받아들일 수 있음
  • 서명 검사
    • 브라우저는 서명기관의 공개키를 서명에 적용하여 그의 체크섬과 비교해봄으로써 인증서의 무결성을 검사하기도 함
  • 사이트 신원 검사
    • 인증서의 도메인 이름이 대화중인 서버의 도메인 이름과 비교하여 맞는지 검사

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

  • 클라이언트는 종종 그들을 대신해 웹 서버에 접근해주는 웹 프락시 서버를 이용하기도 합니다.
  • 예를 들어, 많은 회사가 기업 네트워크와 공공 인터넷을 잇는 경계에 보안을 위한 프락시를 설치합니다.

image

HTTPS SSL 터널링 프로토콜

  • 그러나 클라이언트가 서버로 보낼 데이터를 서버의 공개키로 암호화하기 시작했다면 프락시는 더이상 HTTP 헤더를 읽을 수 없게 됩니다.
  • 따라서 HTTPS 가 프락시와도 잘 동작할 수 있게 하기 위해, 클라이언트가 프락시에게 어디에 접속하려고 하는지 말해주는 방법을 약간 수정해야 합니다.
  • 가장 인기있는 기법은 HTTPS SSL 터널링 프로토콜이고, 프락시에게 자신이 연결하고자 하는 안전한 호스트와 포트를 말해줍니다.
  • HTTP는 CONNECT라고 불리는 새로은 메서드를 이용해 명문으로 된 종단 정보를 전송하기 위해 사용됩니다. CONNECT 메소드는 프락시에게 희망하는 호스트와 포트번호로 연결해달라 말하고, 그것이 완료되면 클라이언트와 서버 사이에서 데이터가 직접적으로 오갈 수 있게 해주는 터널을 만들게 됩니다.
  • 프락시는 CONNECT 요청에 대한 응답이 유효하면, 목적지 서버로 연결하고 200 connection established 응답을 클라이언트에게 보내게 됩니다.
network
Powered with by Ideveloper