1. 1달 전

    18장 웹 호스팅

    HTTP 완벽 가이드 18장 정리

  2. 2달 전

    17장 내용 협상과 트랜스코딩

    HTTP 완벽 가이드 17장 정리

  3. 5달 전

    16장 국제화

    HTTP 완벽 가이드 16장 정리

  4. 5달 전

    15장 엔터티와 인코딩

    HTTP 완벽 가이드 15장 정리

  5. 6달 전

    14장 보안

    HTTP 완벽 가이드 14장 정리

  6. 7달 전

    12장 기본 인증

    HTTP 완벽 가이드 12장 정리

  7. 7달 전

    11장 클라이언트 식별과 쿠키

    HTTP 완벽 가이드 11장 정리

  8. 7달 전

    10장 HTTP 2.0

    HTTP 완벽 가이드 10장 정리

  9. 7달 전

    9장 웹 로봇

    HTTP 완벽 가이드 9장 정리

  10. 7달 전

    8장 통합점 게이트웨이, 터널, 릴레이

    HTTP 완벽 가이드 8장 정리

  11. 7달 전

    7장 캐시

    HTTP 완벽 가이드 7장 정리

  12. 7달 전

    6장 프락시

    HTTP 완벽 가이드 6장 정리

  13. 7달 전

    5장 웹서버

    HTTP 완벽 가이드 5장 정리

  14. 7달 전

    4장 HTTP 커넥션 관리

    HTTP 완벽 가이드 4장 정리

  15. 7달 전

    3장 HTTP 메시지

    HTTP 완벽 가이드 3장 정리

  16. 7달 전

    2장 URL과 리소스

    HTTP 완벽 가이드 2장 정리

  17. 7달 전

    1장 HTTP 개관

    HTTP 완벽 가이드 1장 정리

Tamm자바스크립트 웹 개발 환경을 좋아하고 사람들에게 재미를 주는 것에 관심이 많은 개발자 입니다.

14장 보안

HTTP 완벽 가이드 14장 정리

featured image thumbnail for post 14장 보안

이 장에서 다룰 내용으로는

  • 암호화 기법과 용어 정리
  • 서버 인증서, 디지털 인증서는 무엇이고, 어떻게 서로 신뢰할 수 있는지
  • HTTP에서 보안상 안전하게 메시지를 보내기 위해 사용하는 SSL, TLS의 동작을 이해한다.

14.1 HTTP를 안전하게 만들기

웹에서 은행 업무나 쇼핑 등 더 많은 일을 하기 위해서는 강력한 보안이 필요하다. 몇몇 인증을 다뤘지만, 인증 방식은 보안이 강력하지는 않다. 다음은 HTTP 보안이 필요한 기술이다.

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

14.1.1 HTTPS

안전한 웹 통신 프로토콜로 넷스케이프에서 개척하였다. 프로토콜 스킴은 HTTPS다.

Untitled 7ebc05d2 2a33 4127 96b7 49ced8edb009

모든 HTTP 요청과 응답 데이터는 보내지기 전에 암호화된다. HTTP와 TCP 사이에 하나의 계층이 추가가 되는데, SSL(Secure Sockets Layer)와 TLS(Transport Layer Security)이고 명확히 TLS는 SSL을 확장 시킨 것이기에 두 가지 모두를 SSL이라 통칭해서 설명하도록 한다.

14.2 디지털 암호학

용어 정리

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

14.2.1 비밀 코드의 기술과 과학

cryptography(암호법)은 과학이자 기술이다.

14.2.2 암호

암호는 꽤 오랜 역사를 갖고 있다. 특히 전쟁과 같을 때는 매우 핵심적인 역할을 했다.

Untitled e599ce81 fe1d 4161 b1b5 166c90d82f1d

Untitled e7f491ac 8a28 486b a099 129fb88d23c8

간단히 알파벳을 회전하여 만드는 암호를 율리우스 카이사르가 썼다고 한다.

14.2.3 암호 기계

암호를 만들고 해독하는 기계를 만들었다고 한다.

14.2.4 키가 있는 암호

만약 암호하는 기계가 적의 손에 들어가면?? 이런 상황을 방지 하기 위해 제대로 해독할 수 있는 숫자로 된 다이얼이 기계에 달려있었다. 이러한 암호 매개변수를 키라고 부른다. 키를 알 수 없다면 디코딩 할 수 없다.

Untitled 9a78227c dadd 462f a5c1 d9bd1bde8ddc

14.2.5 디지털 암호

디지털 계산으로 두 가지 주요한 발전이 있었다.

  • 복잡한 인코딩과 디코딩 알고리즘을 수행할 수 있다.
  • 매우 큰 키를 사용할 수 있다.

Untitled 1ed263e1 f144 4c21 a148 4fdd9a81c27d

14.3 대칭키 암호법

인코딩할 때 키와 디코딩 할 때 키가 같으면 대칭키라고 한다. 잘 알려진 대칭키 암호 알고리즘은 DES, Triple-DES, RC2, RC4 등이 있다.

대칭키는 개인키 암호법이라고 한다.

14.3.1 키의 길이와 열거 공격

키를 모르지만 무식하게 키가 될 수 있는 모든 경우의 수로 접근하면 암호가 깨질 수 있다. 실제로 컴퓨터는 빠르게 발전하고 있기 때문에 계산해서 공격할 수 있는 알고리즘은 실제로 보안에 취약점이 있는 것이다. 키의 길이는 키를 만들 수 있는 경우의 수에 영향을 미친다. 56비트의 DES 표준 키보다 128비트의 Triple-DES가 훨씬 공격에 대해 안전하다.

14.3.2 공유키 발급하기

키를 관리하는 것도 복잡한 일이다. 서로 통신하기 위해 개인키를 만들어야 하는데, 노드의 개수가 N개라면 N^2만큼의 개인키가 필요하기 때문이다.

14.4 비대칭키 암호법

인코딩할 때 키와 디코딩할 때 키가 다르다. 인코딩 할 때 키는 공개되어 있고, 호스트만이 메시지를 디코딩하는 개인키를 가진다.

키를 관리하는 일이 대칭키일 때보다 줄어든다. 노드가 N개 있을 때, 나의 개인키 하나와 N-1개의 공개키를 가지면 된다.

Untitled 05903d09 202f 440f be97 3fc152b9ba92

14.4.1 RSA

비대칭키 암호의 과제는 공개키를 소유한 나쁜 사용자가 다른 사람의 메시지를 탈취(스누핑)해서 암호문을 얻어도 원래의 메시지를 알수 없도록 해야 한다는 것이다.

이 문제를 해결하는 가장 유명한 알고리즘이 바로 RSA다. RSA는 소수의 계산이 오래 걸린다는 사실을 착안하여 만든 알고리즘이다.

14.4.2 혼성 암호 체계와 세션 키

공개키 알고리즘의 단점은 알고리즘이 계산이 느리다는 점이다. 그래서 고안한 것이 처음으로 보안 통신을 하려는 주체가 임의의 대칭키를 만들어 공개키로 암호화 해서 보내면 다음부터는 대칭키를 사용해서 통신하는 방법이다.

14.5 디지털 서명

이전에 다뤘는 암호 개념으로 만든 디지털 서명 기법에 대해 알아보자.

14.4.1 서명은 암호 체크섬이다

서명은 저자의 개인 키를 사용한다.

Untitled fc9f6a00 06b1 4ce2 b207 324461adfcde

  • A는 고정된 길이의 요약(digest)으로 만든다.
  • A는 그 요약에, 사용자의 개인 키를 매개변수로 하는 '서명' 함수를 적용한다. 서명 함수를 디코더 함수를 사용한다.
  • A는 디코더로 계산된 결과를 메시지의 끝에 덧붙이고 B에게 보낸다.
  • B는 공개키로 서명을 인코더 함수로 푼다. B의 요약과 일치하지 않는다면 올바른 사용자가 아니라고 판단한다.

14.6 디지털 인증서

CA(Certificate Authority) 에서 발급된 인증서

14.6.1 인증서의 내부

대상의 이름, 유효 기간, 인증서 발급자, 인증서 발급자의 디지털 서명을 담고 있다.

Untitled 7b7e6929 5f30 4b27 a5da 11b1efc7f7f8

14.6.2 X.509 v3 인증서

디지털 인증서에 대한 단일 표준은 없지만, 대부분의 인증서는 X.509라 불리는 표준화된 서식에 저장한다.

인증서 필드

  • Version 인증서의 버전을 나타냄
  • Serial Number CA가 할당한 정수로 된 고유 번호
  • Signature 서명 알고리즘 식별자
  • Issuer 발행자
  • Validity 유효기간

    • Not Before 유효기간 시작 날짜
    • Not After 유효기간 끝나는 날짜
  • Subject 소유자
  • Subject Public Key Info 소유자 공개 키 정보

    • Public Key Algorithm 공개 키 알고리즘
    • Subject Public Key
  • Issuer Unique Identifier (Optional) 발행자 고유 식별자
  • Subject Unique Identifier (Optional) 소유자 고유 식별자
  • Extensions (Optional) 확장

더 자세히 알고 싶다면 https://ko.wikipedia.org/wiki/X.509

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

최신 브라우저는 접속한 서버에서 디지털 인증서를 가져와서 해석한다.

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

Untitled c5e95d9b 095d 4257 b11a 823ecb1f268d

특히 서명 기관은 CA로 널리 알려진 인증된 인증기관이기 때문에 브라우저에는 CA에 대한 정보를 알고 있기 때문에 검사할 수 있다. 크롬의 경우 자신이 알고 있는 CA면 바로 연결이 되고, 모른다 싶으면 사용자에게 한 번더 물어본다.

14.7 HTTPS의 세부사항

본격적으로 HTTPS에 대해 알아보자.

14.7.1 HTTPS 개요

Untitled 4b8b1252 75f2 414d 82e3 f8110e008bd7

14.7.2 HTTPS 스킴

HTTP, HTTPS는 필요에 따라 사용하고 보통은 둘다 사용할 수 있게 하거나 보안 연결만 가능하게 한다.

https로 접근하게 되면 바이너리 포맷으로 된 SSL 보안 매개변수를 교환하면서 '핸드셰이크'를 한 후, 암호화된 HTTP 명령을 보내게 된다.

14.7.3 보안 전송 셋업

HTTPS는 기존 HTTP 통신 절차보다 훨씬 복잡한 과정을 거친다.

클라이언트가 HTTPS로 접근을 하면 TCP 커넥션을 맺고 SSL 계층에서 암호 매개변수와 교환 키를 협상한다(핸드셰이크). SSL 초기화가 완료되었고, 클라이언트는 요청 메시지를 SSL을 통해 보낸다. SSL에서는 메시지를 암호화 해서 TCP를 통해 서버로 보낸다.

Untitled a886285e e9df 4636 bdbf caa4e1677834

14.7.4 SSL 핸드셰이크

위에서 'SSL 계층에서 암호 매개변수와 교환 키를 협상한다'고 설명했는데, 핸드 셰이크를 좀 더 자세히 알아보자.

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

Untitled f5d8c80f af34 466a 8a6e b81463f00b37

14.7.5 서버 인증서

오늘날에는 클라이언트 인증서가 아닌 서버 인증서를 통해 안전한 통신을 한다.

Untitled 8e099011 a0a5 4ae3 a221 8bdeb320c343

14.7.6 사이트 인증서 검사

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

14.7.7 가상 호스팅과 인증서

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

14.8 진짜 HTTPS 클라이언트

SSL은 복잡한 바이너리 프로토콜이라 사용하는데 어려울 수 있다.

14.8.1 OpenSSL

SSL과 TLS의 가장 인기있는 오픈소스 구현체다.

14.8.2 간단한 HTTPS 클라이언트

c로하는 실제 코드를 예시로 들었는데, pass

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

pass

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

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

HTTP는 CONNECT라는 확장 메서드를 사용하여 어디로 갈지 명시 한다

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

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

14.10 추가 정보

추가 정보는 말그대로 추가 정보!. 

14.10 1 HTTP 보안

14.10.2 SSL과 TLS

14.10.3 공개키 인프라

14.10.4 디지털 암호