보안 HTTP에 필요한 요구 사항

서버 인증
클라이언트 인증
무결성: 데이터 위조 확인
암호화: 도청으로부터 안전
효율: 저사양에서도 충분히 빠를 수 있는 알고리즘
편재성(Ubiquity): 프로토콜은 모든 클라이언트와 서버에서 지원되어야 함
관리상 확장성: 누구든 어디서든 즉각적인 보안 통신이 가능해야함
적응성: 최선의 보안 방법을 지원해야함
사회적 생존성: 사회의 문화적, 정치적 요구를 만족시켜야 함

HTTPS 개론

보안 HTTP중 가장 인기있는 방식
Netscape Corp.에서 제안
http://가 아닌 https:// 형식을 사용
HTTPS를 사용할 때, 모든 HTTP 요청과 응답은 네트워크로 보내지기 전에 암호화
HTTP(어플리케이션 계층)와 TCP(전송 계층) 사이에 보안 계층을 제공, 이곳에서 인코딩, 디코딩 실행
– Secure Sockets Layer: SSL
– Transport Layer Security: TLS

그림1. HTTP, HTTPS의 계층 구조

보안 HTTP를 사용하기 위해 클라이언트, 웹 서버를 크게 변경할 필요 없음
대부분의 경우 TCP 입력/출력 호출을 SSL 호출로 대체 후
보안 정보를 설정하고 관리하기 위한 몇 가지 호출을 추가하면 됨.

디지털 암호학

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

키가 있는 암호

키: 암호의 동작방식을 변경할 수 있는 암호 매개변수
키값에 따라 인코딩, 디코딩 결과가 제각각 다르게 동작
현대의 암호화 알고리즘은 알고리즘을 알아도 암호를 깨드리는 데에 도움이 될 패턴을 찾아내기 어렵게 설계

대칭키 암호법

인코딩과 디코딩에 같은 키를 사용하는 암호 알고리즘
DES, Triple-DES, RC2, RC4

키 길이와 열거 공격(Enumeration Attack)

대부분의 경우, 인코딩 및 디코딩 알고리즘은 공개적
비밀 키는 누설되면 안됨
악의적인 목적으로 암호의 키 값을 알아내기 위해 무차별적으로 값을 입력할 수 있음
키의 길이에 따라 암호를 깨뜨리는데 드는 비용이 다름
– 40비트 키: 작고 중요하지 않은 업무
– 128비트 키: 매우 강력한것으로 간주, 무차별 대입으로는 실질적으로 깨뜨릴수 없다고 알려짐

공개키 암호법

대칭키는 호스트와 클라이언트 사이에 각각의 키가 필요
키를 발급, 관리하는데 어려움이 있음
인코딩 키는 공개, 디코딩 키는 호스트만 소유
누구든지 호스트로 요청이 가능, 호스트만 디코딩이 가능
공개키 암호화 기술을 통해 보안 프로토코콜을 모든 사용자에게 적용하는 것이 가능
공개 키 인프라 표준화 작업이 계속해서 진행중(X.509)

RSA

공개키 비대칭 암호의 과제는 공개키, 암호문과 메시지를 알고 있더라도 디코딩 키를 계산할 수 없어야 함
MIT에서 발명되고 이어서 RSA 데이터 시큐리티에서 상용화된 RSA 알고리즘이 있다

혼성 암호 체계와 세션 키

공개키 암호 방식의 알고리즘은 계산이 느린 경향
의사소통 채널 수립할 때는 공개 키 암호를 사용
안전한 채널을 통해 무작위 대칭 키를 생성하고 교환하여 나머지 데이터를 암호화할 때 빠른 대칭키를 사용하는 방식이 사용

디지털 서명

암호 체계는 메시지 암호화 및 해독뿐만 아니라 서명에 이용될 수 있음
서명: 누가 메시지를 작성했는지, 메시지가 위조되지 않았음을 증명하는데 이용

서명: 암호 체크섬

서명은 메시지 작성자를 알려줌
작성자는 개인 키를 가지고 있기 때문에 작성자만이 체크섬을 계산 가능
체크섬은 저자의 개인 ‘서명’처럼 동작
서명은 메시지 위조 방지
도중에 메시지가 수정되면 체크섬이 맞지 않게됨

디지털 인증서

디지털 인증서는 ‘certs’라 불리는 신뢰할 수 있는 기관으로부터 보증 받은 사용자나 회사에 대한 정보를 담고 있음

그림2. 일반적인 디지털 서명의 포맷

X.509 v3 인증서

디지털 인증서에 대한 전 세계적인 단일 표준은 없음
대부분의 인증서가 X.509라 불리는 표준화된 서식에 저장

X.509 인증 필드

필드	설명
버전	이 인증서가 따르는 X.509 인증서 버전의 번호
일련번호	인증기관에 의해 생성된 고유 번호. CA로부터의 각 인증서는 반드시 고유 일련번호를 가져야함
서며 알고리즘 ID	서명을 위해 사용된 알고리즘
인증서 발급자	인증서를 발급하고 서명한 기관의 이름. X.500 포맷으로 기록
유효 기간	인증서가 유효한 기간, 시작일과 종료일로 정의
대상의 이름	인증서에 기술된, 사람이나 조직과 같은 엔티티. X.500 포맷으로 기록
대상의 공개 키 정보	인증 대상의 공개 키, 공개키에 사용된 알고리즘, 추가 매개변수
발급자의 고유 ID(선택적)	발급자의 이름이 겹치는 경우를 대비, 인증서 발급자에 대한 선택적인 고유 식별자
대상의 고유 ID(선택적)	대상의 이름이 겹치는 경우를 대비한, 인증 대상에 대한 선택적인 고유 식별자
확장	기본제약, 인증서 정책, 키 사용
인증기관 서명	위의 모든 필드에 대한 인증기관의 디지털 서명, 명시된 서명 알고리즘 사용

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

최신 브라우저는 HTTPS 웹 트랜잭션 시작시에 접속한 서버에서 자동으로 디지털 인증서를 가져옴
인증서가 없으면 HTTPS 커넥션은 실패
서버 인증서는 다음과 같은 필드를 가지고 있음
– 웹 사이트의 이름과 호스트 명
– 웹 사이트의 공개키
– 서명 기관의 이름
– 서명 기관의 서명
브라우저가 인증서를 받으면 서명 기관을 검사
CA가 신뢰할 만한 기관이면 브라우저는 공개키를 이미 알고 있음
공개키를 이용해 서명을 검증
서명 기관이 모르는 곳이라면 대화상자를 보여줌

HTTPS의 세부사항

HTTPS: HTTP의 가장 유명한 보안 버전

HTTPS 스킴

스킴: https://
(웹 브라우저 등의) 클라이언트는 웹 리소스에 대한 트랜잭션 수행을 요청 받으면 스킴을 우선 검사
HTTP 스킴이면, 클라이언트는 서버에 80포트로 연결, HTTP 명령 전송
HTTPS 스킴이면 443포트로 연결, 바이너리포맷로 연결된 핸드셰이크, HTTP 명령 전송
SSL 트래픽은 바이너리 프로토콜

보안 전송 셋업

웹 서버의 443포트(보안 HTTP의 기본 포트)로 연결
암호법 매개변수와 교환 키를 협상하며넛 SSL 계층을 초기화
핸드셰이크가 완료되면 초기화는 완료
클라이언트는 보안 계층에 요청메세지를 보낼 수 있게 됨

SSL 핸드셰이크

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

서버 인증서

SSL은 서버 인증서, 클라이언트 인증서를 통한 상호 인증을 지원
보안 HTTPS 트랜잭션은 항상 서버 인증서를 요구
HTTPS 인증서는 사이트 정보가 더해진 X.509 인증서

사이트 인증서 검사

SSL 자체는 사용자에게 웹 서버 인증서를 검증할 요구를 하지 않음
최신 웹브라우저들 대부분은 인증서에 대해 간단하게 기본적인 검사를 거침
– 날짜검사: 인증서의 시작, 종료일을 검사
– 서명자 신뢰도 검사: 모든 인증서는 서버를 보증하는 인증 기관(Certificate Authority, CA)에 의해 서명
– 서명 검사: 서명기관의 공개키를 이용해 체크섬을 비교해 봄으로서 인증서의 무결성을 검사
– 사이트의 신원검사: 브라우저는 인증서의 도메인 이름과 대화중인 서버의 도메인이 맞는지 비교

출처: "HTTP 완벽가이드", 이응준, 정상일 옮김, 인사이트, 2014