HTTP 완벽가이드 14장 보안 HTTP

어겐어갠·2022년 5월 30일
0

14장 보안 HTTP

14.1 HTTP를 안전하게 만들기

웹은 안전한 방식의 http를 필요로 한다.

보안 버전의 요구 사항

  • 효율적
  • 이식성
  • 관리의 쉬움
  • 적응력
  • 사회, 정부의 요구사항에 적합

  • 서버 인증
    : 클라이언트는 진짜 서버와 통신함을 알아야 함
  • 클라이언트 인증
    : 서버는 진짜 클라이언트와 통신함을 알아야 함
  • 무결성
    : 데이터의 위조에 대해 안전
  • 암호화
    : 도청에 대한 보안
  • 효율
    : 알고리즘은 충분히 빨라야 한다
  • 편재성
    : 모든 클라이언트와 서버에서 지원되어야 함
  • 관리상 확장성
    : 즉각적인 보안 통신을 할 수 있어야 함
  • 적응성
    : 최선의 보안 방법을 지원해야 함
  • 사회적 생존성
    : 사회 문화적, 정치적 요구를 만족 시켜야 함

14.1.1 HTTPs

http를 안전하게 만드는 방식
SSL 혹은 TLS 계층을 이용해 구현
SSL(Secure Sockets Layer, 안전 소켓 계층)
TLS(Transport Layer Security, 전송 계층 보안)

14.2 디지털 암호학

  • 암호
  • 대칭키 암호 체계
  • 비대칭 키 암호 체계
  • 공개키 암호법
  • 디지털 서명
  • 디지털 인증서

14.3 대칭키 암호법

인코딩과 디코딩할 때 키가 같다.

키가 누설되면 안된다.

14.3.2 공유키 발급하기

대칭키 암호의 단점중 하나는 발송자와 수신자가 둘 다 공유키를 가져야 한다.

그래서 개인 비밀 키를 가져야한다.
그렇다면 N개의 노드에 N^2의 비밀 키가 필요하다.

14.4 공개키 암호법

공개키 암호 방식은 두 개의 비대칭 키를 사용한다.
공개 키 = 인코딩 키
비밀 키 = 디코딩 키

전소에는 공개 키만 있므년 되기 때문에, 노드가 서버로 안전하게 메세지를 발송하는 것을 쉽게해준다.

14.4.1 RSA

공개키를 안전하게 하는 알고리즘

아래의 조건을 알고있더라도 비밀 키를 계산할 수 없는 것을 확신시킬 수 있다.

  • 공개키
  • 가로채서 얻은 암호문의 일부
  • 메세지와 그것을 암호화한 암호문

14.4.2 혼성 암호 체계와 세션키

공개키의 단점은 계산이 느리다.
실제로는 대칭과 비대칭 방식을 섞은 것이 쓰인다.

14.5 디지털 서명

누가 메세지를 썻는지 알려주고 위조되지 않았음을 증명하기 위해 디지털 서명을 사용한다.

14.5.1 서켱은 암호 체크섬이다

  • 서명은 메세지를 작성한 저자가 누구인지 알려준다.
  • 서명은 메세지 위조를 방지한다.

14.6 디지털 인증서

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

14.6.1 인증서의 내부

인증서는 이러한 것들을 갖고있다.

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

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

https 를 통한 안전한 웹 트랜잭션을 시작할 때, 브라우저는 자동으로 디지털 인증서를 가져온다.
서버 인증서는 하단의 필드를 가진다.

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

14.7 HTTPS의 세부사항

https는 http의 가장 유명한 보안 버전이다.

14.7.1 HTTPS의 개요

https는 보안 전송 계층을 통해 전송된다.
보안 계층은 SSL 혹은 TLS로 구현되어 있다.

14.7.2 HTTPS 스킴

보안 http는 선택적이다. 따라서 보안 프로토콜 버전을 수행한다고 말해줄 방법이 필요하다. 이는 스킴을 통해 이루어진다.

  • 만약 https 스킴을 가지고 있다면, 클라이언트는 서버에 443 포트로 연결하고 '핸드셰이크'를 하고, 암호화된 http 명령이 뒤를 잇는다.

14.7.4 SSL 핸드셰이크

핸드셰이크에서는 다음과 같은 동작이 이루어진다.

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

14.7.5 서버 인증서

오늘날, 클라이언트 인증서는 웹 브라우징에서는 잘 쓰지 않는다.

보안 https 프랜잭션은 항상 서버 인증서를 요구한다.

14.7.6 사이트 인증서 검사

브라우저들은 인증서에 대해 간단하게 기본적인 검사를 한다.

  • 날짜 검사
    : 인증서가 유효한지
  • 서명자 신뢰도 검사
    : 인증서는 인증 기관(Certificate Authority, CA)에 의해 서명되어있는데 이를 검사
  • 서명 검사
    : 서명 기관이 믿을만하면, 서명기관의 공개키를 서명에 적용해 인증서의 무결성을 검사
  • 사이트 신원 검사
    : 인증서의 도메인 이름이 대화중인 서버의 도메인 이름과 비교하여 맞는지 검사

14.7.7 가상 호스팅과 인증서

가상 호스트로 운영되는 사이트의 보안 트래픽을 다루는 것은 까다롭기도 하다.(도메인 비교가 어려우므로)

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

클라이언트는 종종 웹 프락시 서버를 이용한다.
그러나 클라이언트가 서버로 보낼 데이트럴 공개키로 암호화하면 프락시는 더이상 http 헤더를 읽을 수 없다.
https가 프락시와도 잘 동작할 수 있게, 클라이언트는 프락시에게 어디에 접속하는지 말하는 방법을 약간 수정해야한다.
그 방법 중 하나가 https ssl 터널링 프로토콜 이다.

profile
음그래

0개의 댓글