HTTP 완벽 가이드 14장. 보안 HTTP

14.1 HTTP 안전하게 만들기

웹 트랜잭션을 중요한 일에 사용하기 때문에 강력한 보안이 없다면, 안심할 수 없다.
보다 중요한 트랜잭션을 위해서는, HTTP와 디지털 암호화 기술을 결합해야 한다.
HTTP의 보안 버전은 효율적이고, 이식성이 좋아야 하고, 관리가 쉬어야 하며, 현실 세계의 변화에 대한 적응력이 좋아야 한다.
HTTP 보안 기술
- 서버 인증: 클라이언트는 위조된 서버가 아닌지 알 수 있어야 한다.
- 클라이언트 인증: 가짜 클라이언트가 아닌지 알 수 있어야 한다.
- 무결성: 클라이언트와 서버는 데이터가 위조로부터 안전해야 한다.
- 암호화: 클라이언트와 서버는 도청에 대한 걱정이 없어야 한다.
- 효율: 알고리즘은 충분히 빨라야 한다.
- 편재성: 프로토콜은 거의 모든 클라이언트와 서버에게 지원되어야 한다.
- 관리성 확장: 언제 어디서 누구든 보안 통식을 할 수 있어야 한다.
- 적응성: 최선의 보안 방법을 지원해야 한다.
- 사회적 생존성 - 문화적, 정치적 요구를 만족해야 한다.

HTTPS

HTTPS를 사용할 때 모든 HTTP 요청과 응답 데이터는 네트워크로 보내기 전에 암호화한다.
보안 계층은 SSL, TLS를 이용하여 구현된다.

HTTP 프로토콜	Layer	HTTPS 프로토콜	Layer
HTTP	애플리케이션 계층	HTTPS	애플리케이션 계층
-	-	SSL or TLS	보안계층
TCP	전송계층	TCP	전송계층
IP	네트워크계층	IP	네트워크계층
네트워크 인터페이스	데이터링크 계층	네트워크 인터페이스	데이터링크 계층

어려운 인코딩 및 디코딩은 대부분 SSL 라이브러리 안에서 일어나기 때문에, 보안 HTTP를 사용하기 위한 웹 클라이언트와 서버가 프로토콜을 처리하는 로직을 변경할 필요가 없다.
TCP 입력/출력 호출을 SSL 호출로 대체하고 보안 정보를 설정하고 관리하기 위한 몇가지 호출을 추가하면 된다.

14.2 디지털 암호화

암호: 인코딩하는 알고리즘
키: 암호의 동작을 변경하는 숫자로 된 매개변수
대칭키 암호 체계: 인코딩과 디코딩에 같은 키를 사용하는 알고리즘
비대칭키 암호 체계: 인코딩과 디코딩에 다른 키를 사용하는 알고리즘
공개키 암호법: 비밀 메시지를 전달하는 수백만 대의 컴퓨터를 쉽게 만들 수 있는 시스템
디지털 서명: 메시지가 위조 혹은 변조되지 않았음을 입증하는 체크섬
디지털 인증서: 신뢰할만한 조직에 의해 서명되고 검증된 신원 확인 정보
비밀 코드의 기술과 과학
- 암호법은 메시지 인코딩, 디코딩에 대한 과학이자 기술
- 메시지 암호화 + 메시지 변조 방지
암호
- 메시지를 인코딩하는 어떤 특정한 방법과 나중에 그 비밀 메시지를 디코딩하는 방법
- 평문 -> 인코딩 -> 암호문 -> 디코딩 -> 평문
암호 기계
- 복잡한 암호를 위해 사용되는 기계
키가 있는 암호
- 암호기계를 훔치더라도, 올바른 다이얼 설정(키) 없이는 디코더가 동작하지 않는다.
- 암호 기계들은 서로 다른 키 값을 갖고 있기 떄문에 제각각 다르게 동작
디지털 암호
- 디지털 키는 숫자로 인코딩과 디코딩 알고리즘에 대한 입력값이다.
- 평문 메시지(P), 인코딩 함수(E), 디지털 인코딩(e)가 주어지면 암호문 C = E(P, e) 로 구할 수 있다.

14.3 대칭키 암호법

많은 디지털 암호 알고리즘은 대칭키 알고리즘이라 불린다.
인코딩, 디코딩 키가 동일하기 때문이다(e=d)
P = D(C, d) // P: 평문, D: 디코딩 함수, C: 암호문, d: 디코딩 키
키 길이와 열거 공격(Enumeration Attack)
- 키가 노출되면 안된다. 대부분 디코딩, 인코딩 알고리즘은 공개되어 있고 키만이 유일한 비밀이다.
- 무차별로 모든 키 값을 대입해보는 것이 열거 공격(Enumeration Attack)이라 한다.
- 대칭키 암호에서는, 보통 모든 키 값이 유효하다. 8bit key라면 256가지 값이 가능하며, 40bit key라면 약 1조가지의 값이 가능하고,128bit key라면 약 340,000,000,000,000,000,000,000………… 가지의 값이 가능하다.
공유키 발급
- 대칭키 암호의 단점 중 하나는 발송자와 수신자가 서로 대화하려면 둘 다 공유키를 가져야 한다는 것이다.
- 이는 여러 사용자가 생겨날때 키를 관리하는 관리자 측면에선 지옥이다.

14.4 공개키 암호법

두 개의 비대칭 키를 사용
하나는 호스트의 메시지를 인코딩하기 위한 것이며 모두를 위해 공개되어 있다.
다른 하나는 메시지를 디코딩하기 위한 것이며 호스트만이 개인 디코딩 키를 알고 있다.
모든 사람이 X에게 보내는 메시지를 같은 키로 인코딩할 수 있지만, X를 제외한 누구도 그 메시지를 디코딩할 수 없다.
- 오직 X만이 디코딩 개인 키를 갖고 있기 때문이다
RSA
- MIT에서 발명되고 이어서 RSA 데이터 시큐리티에 상용화된 알고리즘이다.
- 공개키, 평문의 일부, 공개키로 평문을 인코딩하여 얻은 평문에 대한 암호문, 그리고 RSA 구현의 소스 코드까지 주어졌다 하더라도 암호를 크래킹하여 해당하는 개인키를 찾는 것은 컴퓨터 과학의 모든 분야에서 가장 어려운 문제 중 하나라고 알려진 큰 소수의 계산하는 문제만큼 어렵다고 한다.
혼성 암호 체계와 세션 키
- 비대칭 공개키 암호 방식은 누구나 공개키만 알면 그 키에 대응되는 공개 서버에 안전하게 메시지를 보낼 수 있게 해주므로 훌륭하다. 두 노드가 안전하게 소통하려 할 떄 협살을 먼저 해야 할 필요가 없다.
- 공개키 암호화 알고리즘은 계산이 느린 경향이 있다. 실제로는 대칭키와 비대칭키 방식을 섞은 것이 쓰인다.

14.5 디지털 서명

디지털 서명이라 불리는 기법은 인터넷 보안 인증서 기법에 중요한 역할을 한다.
서명은 암호 체크섬이다.
- 디지털 서명은 메시지에 붙어있는 특별한 암호 체크섬이다.
- 이점
  - 서명은 메시지를 작성한 저자가 누군지 알려준다.
    - 저자는 저자의 극비 개인키를 갖고 있기 때문에 체크섬은 저자만이 체크섬을 계산할 수 있다.
    - 체크섬은 저자의 개인 서명처럼 동작
  - 서명은 메시지 위조를 방지한다.
    - 송신중인 메시지를 위조했다면 체크섬이 맞지 않게 된다.
    - 체크섬은 저자의 비밀 개인 키와 관련되어 있기 때문에 위조된 메시지에 대한 올바른 체크섬을 날조해낼 수 없다.
- 다음은 노드 A가 노드 B에게 메시지를 보내고, 서명하는 절차이다.
  - 노드 A는 가변 길이 메시지를 고정된 길이의 요약(digiest)으로 만든다. 이에 사용자의 개인키를 매개변수로 하는 서명 함수를 적용한다.
  - 여기서 디코더 함수 D가 사용된다.
  - 노드 A는 계산된 서명과 메시지 모두를 노드 B에게 전송한다.
  - 메시지를 받은 노드 B는 서명을 검사할 수 있다. 여기에 공개키를 이용한 역함수를 적용한다. 만약 풀어낸 요약이 노드 B가 가진 버전과 요약이 일치하지 않는다면, 위조되었거나 노드 A가 개인키를 갖고 있지 않은 것이다.

14.6 디지털 인증서

certs라고 불리는 디지털 인증서는 신뢰할 수 있는 기관으로부터 보증 받은 사용자나 회사에 대한 정보를 담고 있다.
인증서 내부
- 인증 기관에 의해 디저털 서명된 정보의 집합이 담겨있다.
  - 대상 이름(사람, 서버, 조직 등)
  - 유효 기간
  - 인증서 발급자(누가 이 인증서를 보증하는가)
  - 인증서 발급자의 디지털 서명
- 보통 대상의 공개키도 담고 있다
X.509 v3 인증서
- 디지털 인증서에 대한 전세계적인 단일 표준이 없다.
- 대부분의 인증서가 그들의 정보를 X.509라 불리는 표준화된 서식에 저장하고 있다.
- X.509 기반 인증서에는 웹 서버 인증서, 클라이언트 이메일 인증서, 소프트웨어 코드사인(code-signing) 인증서, 인증기관 인증서를 비롯한 몇가지 변종이 있다.
서버 인증을 위해 인증서 사용하기
- 사용자가 HTTPS를 통해 안전한 웹 트랜잭션을 시작할 때, 최신 브라우저는 자동으로 접속한 서버에서 디지털 인증서를 가져온다.
- 서버가 인증서를 갖고 있지 않다면, 보안 커넥션은 실패한다.
- 서버 인증서 필드
  - 웹 사이트의 이름과 호스트 명
  - 웹 사이트의 공개키
  - 서명 기관의 이름과 서명
- 브라우저가 인증서를 받으면 서명 기관을 검사한다. 신뢰해야 할지 확신할 수 없다면 대화 상자를 띄워 사용자에게 묻는다.

14.7 HTTPS의 세부사항

HTTP 프로토콜에 대칭, 비대칭 인증서 기반 암호 기법의 강력한 집합을 결합한 것이다.
무정부 상태의 분권화된 글로벌 인터넷 환경에서도 매우 안전한 동시에 매우 유연하고 관리하기 쉽게 만들어준다.
HTTPS 개요
- HTTPS는 단지 보안 전송 계층을 통해 전송되는 HTTP이다.
- HTTP 메시지를 TCP로 보내기 전에 먼저 그것들을 암호화하는 보안 계층으로 보낸다.
- HTTPS의 보안 계층은, SSL과 그것의 현대적인 대체품인 TLS로 구현되었다.
HTTPS 스킴
- HTTPS 프로토콜에서 URL의 스킴 접두사는 https다.
- 만약 URL이 http 스킴을 갖고 있다면 클라이언트는 서버에 80번(기본값) 포트로 연결하고 평범한 HTTP 명령을 전송
- 만약 URL이 https 스킴을 갖고 있다면 클라이언트는 서버에 443번(기본값) 포트로 연결하고 서버와 바이너리 포맷으로 된 몇몇 SSL 보안 매개변수를 교환하면서 ‘핸드셰이크’를 하고, 암호화된 HTTP 명령이 뒤를 잇는다.
보안 전송 셋업
- HTTP: 클라이언트는 웹 서버의 80번 포트로 TCP 커넥션을 열고, 요청 메시지를 보내고, 응답 메시지를 받고 커넥션을 닫는다.
- HTTPS
  - 클라이언트는 웹 서버의 443포트(기본 포트)로 연결
  - 클라이언트와 서버는 암호법 매개변수와 교환키를 협상하면서 SSL 계층을 초기화한다.
  - 핸드셰이크가 완료되면 SSL 초기화는 완료되며, 클라이언트는 요청 메시지를 보안계층에 보낼 수 있다. 이 메시지는 TCP 로 보내지기 전에 암호화된다.
  - 연결을 끊을 때도 SSL 닫힘을 통지한 후에 TCP 커넥션을 닫는다.
SSL 핸드셰이크
- SSL 보안 매개변수 핸드셰이크 키를 만든다.
  - 클라이언트가 암호 후보들을 보내고 인증서를 요구한다.
  - 서버는 선택된 암호와 인증서를 보낸다.
  - 클라이언트가 비밀 정보를 보낸다. 클라이언트와 서버는 키를 만든다.
  - 클라이언트와 서버는 서로에게 암호화를 시작한다고 말해준다.
서버 인증서
- SSL은 서버 인증서를 클라인트로 나르고, 다시 클라이언트 인증서를 서보로 날라주는 상호 인증을 지원한다.
- 서버 인증서는 조직의 이름, 주소, 서버 DNS 도메인 이름, 그외의 정보를 보여주는 X.509 v3에서 파생된 인증서다.
사이트 인증서 검사
- 사이트 인증서를 검사하는 과정은 날짜 검사, 서명자 신뢰도 검사, 서명 검사, 사이트 신원 검사를 포함한다.
가상 호스팅과 인증서
- 하나의 서버에 여러 호스트(가상 호스트)로 운영되면 까다로울 수 있다.

14.8 진짜 HTTPS 클라이언트

SSL은 복잡한 바이너리 프로토콜이다.
몇가지 SSL 클라이언트와 서버 프로그래밍을 쉽게 만들어주는 상용 혹은 오픈 소스 라이브러리가 존재한다.
OpenSSL
- SSL과 TLS의 가장 인기 있는 오픈 소스 구현이다.
- OpenSSL은 SSLeay 라이브러리를 계승하였다.

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

SSL은 바이너리 프로토콜이다. 프락시는 암호화된 메시지를 받고 어리둥절할 것이다.
프락시는 메시지의 헤더에서 메시지가 어디로 전송되어야 하는지 알아야 하는데 암호화된 메시지는 읽어낼수가 없다.
- 이 때 HTTPS SSL 터널링 프로토콜을 사용한다.
HTTP는 CONNECT라는 확장 메서드를 사용하여 어디로 갈지 명시 한다.
```
CONNECT home.netscape.com:443 HTTP/1.0
User-agent: Mozilla/1.1N
```
프락시는 이 CONNECT 메서드를 받으면 직접 대상으로 연결시켜주는 터널을 만들어 준다.

** 참고 서적: HTTP 완벽 가이드