19. 보안 HTTP

HTTP 안전하게 만들기

서버 인증

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

HTTPS

• 모든 HTTP 요청과 응답 데이터는 네트워크로 보내기 전에 암호화된다.
• HTTP하부의 전송 레벨 암호 보안 계층을 제공함으로써 작동하는데 다음과 같이 부른다.
  • 안전 소켓 계층(SSL; Secure Socket Layer)
  • 전송 계층 보안(TLS; Transport Layer Security)

	HTTP 계층	HTTPS 계층
애플리케이션 계층	HTTP	HTTP
보안 계층	-	SSL or TLS
전송 계층	TCP	TCP
네트워크 계층	IP	IP
데이터 링크 계층	네트워크	네트워크

---

디지털 암호학

암호

• 텍스트를 아무나 일기 못하도록 인코딩하는 알고리즘키
• 암호의 동작을 변경하는 수자로 된 매개변수대칭키 암호 체계
• 인코딩과 디코딩에 같은 키를 사용하는 알고리즘
• 호스트마다 한 개의 공개키를 할당비대칭키 암호 체계
• 인코딩과 디코딩에 다른 키를 사용하는 알고리즘공개키 암호법
• 비밀 메시지를 전달하는 수백만 대의 컴류터를 쉽게 만들 수 있는 시스템
• 한 쌍의 호스트가 하나의 인코딩/디코딩 키를 사용한다.
• 공개키 암호 방식은 두 개의 비대칭 키를 사용한다.
  • 메시지를 인코딩하기 위한 모든 호스트에게 공통으로 공개되어 있는 인코딩 키
  • 해당 메시지를 디코딩하기 위해 호스트만이 갖고있는 디코딩 키
• 참고 알고리즘
  • RSA알고리즘디지털 서명
• 메시지가 위조 혹은 변조되지 않았음을 입증하는 체크섬
• 체크섬을 만드는 과정에서 저자의 극비의 개인키를 사용한다.
• 공격자가 중간에 메시지를 가로 채 데이터를 수정했다면 체크섬을 계산해 낼 때 올바른 체크섬을 날조해 낼 수 없을 것이다.디지털 인증서
• 셰계적은 단일 표준은 없지만, X.509라는 표준화된 서식에 저장하고 있다.

필드	설명
버전	이 인증서가 따르는 X.509 인증서 버전의 번호.
일련번호	인증기관에 의해 생성된 고유한 정수. CA로부터의 각 인증서는 반드시 고유한 일련번호를 가져야 함.
서명 알고리즘 ID	서명을 위해 사용된 암호 알고리즘.
인증서 발급자	인증서를 발급하고 서명한 기관의 이름.
유효기간	인증서가 유효한 기간. 시작일과 종료일로 정의.
대상의 이름	인증서에 기술된 사람이나 조직과 같은 엔터티.
대상의 공개 키 정보	공개 키, 공개 키에 사용된 알고리즘, 추가 매개변수.
발급자의 고유 ID(option)	발급자의 이름이 겹치는 경우를 대비한 고유 식별자.
대상의 고유 ID(option)	대상의 이름이 겹치는 경우를 대비한 고유 식별자.
확장	(Version 3 이상에서 지원) 중요한 것인지, 그렇지 않은 것인지가 표시되어 있음. 기본제약 : 대상과 인증기관의 관계. 인증서 정책 : 인증서가 어떤 정책하에 승인되었는지. 키 사용 : 공개키가 어떻게 사용될 수 있는지에 대한 제한.
인증기관 서명	위의 모든 파일에 대한 인증기관의 디지털 서명.

• 신뢰할 만한 조직에 의해 서명되고 검증된 신원인지에 대한 확인 정보
• 디지털 인증서에 포함되어 있는 정보
  • 대상의 이름(사람, 서버, 조직 등)
  • 유효 기간
  • 인증서 발급자(누가 이 인증서를 보증하는지 기술)
  • 인증서 발급자의 디지털 서명
  • 대상의 공개키
  • ... 등
• 누구나 만들 수 있지만, 그 모두가 인증서의 정보를 보증하고 서명권한을 얻을 수 있는 것은 아니다.
• 사용자가 HTTPS를 통한 트랜잭션 시에 서버에서 디지털 인증서를 가져온다.
  만약 서버가 인증서를 갖고 있지 않다면 보안 커넥션은 실패한다.
• 서버 인증서의 필드
  • 웹 사이트의 이름과 호스트명
  • 웹 사이트의 공개키
  • 서명 기관의 이름
  • 서명 기관의 서명
  • ... 등
• 브라우저가 서버 인증서를 받으면, 서명 기관을 검사한다. 브라우저들은 여러 서명 기관의 인증서가 미리 설치된 채로 출하되기도 하는데, 브라우저는 그 서명을 검증할 수 있다. 만약, 서명기관이 모르는 곳이라면 사용자에게 서명 기관을 신뢰하는지 확인한다.

---

HTTPS 세부사항

HTTPS 개요

• 암호화되지 않은 HTTP 메시지를 TCP를 통해 전송하는 대신에 TCP로 보내기 전에 그것을 암호화하는 보안 계층으로 보낸다. HTTPS의 보안 계층은 SSL과 그것의 현대적 대체품인 TLS로 구현되었다.
• TLS(Transport Layout Security)는 SSL(Secure Socket Layout)을 보완한 것이지만, 통상 SSL이라고 부른다.

HTTPS Scheme

• HTTP는 80번(기본값) 포트를 사용하지만, HTTPS는 443번(기본) 포트를 사용한다.
• HTTP 대신 HTTPS를 Scheme으로 사용하여 보안 프로토콜 버전을 사용한다는 것을 명시.
• SSL 트래픽은 바이너리 프로토콜이기 때문에, 일반 80번 포트로 통신하면 대부분의 브라우저는 잘못된 HTTP로 해석하고 커넥션을 닫을 것이다.

보안 전송 셋업

• HTTP와 달리 STTPS에서의 절차는 SSL 보안 계층 때문에 약간 더 복잡하다.
  

SSL 핸드셰이크

• 과정
  • 프로토콜 버전 번호 교환
  • 양쪽이 알고 있는 암호 선택
  • 양쪽의 신원을 인증
  • 채널을 암호화하기 위한 임시 세션 키 생성
• SSL은 통신을 시작하기 위해 상당한 양의 핸드셰이크를 주고 받는다.
  • 아래의 그림은 단순화한 버전

서버 인증서

• SSL은 서버 인증서를 서버와 클라이언트에게 서로 날라주는 상호 인증을 지원한다. 하지만, 대부분의 사용자는 클라이언트 인증서를 갖고 있지도 않는다.
• 서버 인증서는 X.509 v3에서 파생된 인증서인데, 서버와 클라이언트는 모든 것이 믿을 만한 것인지 확인을 위해 인증서를 검증할 수 있다.

사이트 인증서 검사

• SSL 자체는 웹 서버 인증서를 검사할 것을 요구하지 않는다. 하지만, 최신 웹브라우저들은 대부분 간략하게 기본적인 검사를 하고 그 결과를 더 철저한 검사를 할 수 있는 방법과 함께 사용자에게 알려준다.
• 웹 서버 인증서를 검사하기 위한 알고리즘
  • 날짜검사
    • 인증서가 여전히 유효한지에 대한 시작 및 종료일을 검사한다.
  • 서명자 신뢰도 검사
    • 브라우저는 신뢰할 만한 서명 기관 목록을 포함한 채로 배포된다.
    • 알려져 있지 않은 서명 기관에 대해서는 브라우저에서 경고를 띄워준다.
  • 서명 검사
    • 한번 서명 기관에 신뢰가 생기면, 브라우저는 서명기관의 공개키를 서명에 적용하여 그의 체크섬과 비교해봄으로써 인증서의 무결성을 검사한다.
  • 사이트 신원 검사
    • 대부분의 브라우저는 인증서의 도메인 이름이 대화 중인 서버의 도메인 이름과 비교하여 맞는지 검사한다.
    • 몇몇 CA는 와일드카드 표현이 들어있는 인증서를 만들기도 한다.

가상 호스팅과 인증서

• 하나의 서버에 여러 호스트명(가상 호스트)로 운영되는 사이트의 보안 트래픽을 다루는 것은 까다로운데 몇몇 웹 서버 프로그램은 하나의 인증서만을 지원하니 참고하자.