[HTTP 완벽 가이드 14장] 보안 HTTP

14.1 HTTP를 안전하게 만들기

HTTP 보안 기술을 사용함으로써 얻을 수 있는 것들

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

1) HTTPS

• 넷스케이프에서 개척하였으면 모든 주류 브라우저와 서버에서 지원한다.
• HTTPS를 사용할 때, 모든 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화된다.
• HTTPS는 HTTP 하위 계층에 보안 계층을 제공함으로써 동작한다.
• TLS와 SSL은 매우 비슷하며 관례적으로 SSL 표현을 많이 사용한다.

2) 디지털 암호학

• SSL과 HTTPS에서 이용되는 암호 인코딩 기법

암호

• 텍스트를 아무나 읽지 못하도록 인코딩하는 알고리즘

키

• 암호의 동작을 변경하는 숫자로 된 매개변수

대칭키 암호 체계

• 인코딩과 디코딩에 같은 키를 사용하는 알고리즘

비대칭키 암호 체계

• 인코딩과 디코딩에 다른 키를 사용하는 알고리즘

공개키 암호법

• 비밀 메시지를 전달하는 수백만 대의 컴퓨터를 쉽게 만들 수 있는 시스템

디지털 서명

• 메시지가 위조 혹은 변조되지 않았음을 입증하는 체크섬

체크섬(checksum)이란?
번호 등에 오류가 존재하는 바의 여부를 확인하기 위해 추가로 끼워넣는 번호로 대개 0~9 중 하나다.

디지털 인증성

• 신뢰할 만한 조직에 의해 서명되고 검증된 신원 확인 정보

1) 암호(cipher)

• 암호란 메시지를 인코딩하는 어떤 특정한 방법과 나중에 그 비밀 메시지를 디코딩하는 방법이다.
• 평문 혹은 텍스트 -> 암호 -> 암호문

2) 키가 있는 암호

• 디코딩 과정을 바르게 동작시키려면 올바른 키를 암호 기계에 입력할 필요가 있다.
• 똑같은 평문을 어떤 키로 암호화 하느냐에 따라 다른 암호문이 생성된다.
• 오늘날 거의 대부분 암호 알고리즘은 키를 사용한다.

3) 디지털 암호

• 속도 및 기능이 좋아지면서, 복잡한 인코딩과 디코딩 알고리즘이 가능해졌다.
• 매우 큰 키를 지원하는 것이 가능해져서, 단일 암호 알고리즘으로 키의 값마다 다른 수조 개의 가상 암호 알고리즘을 만들어낼 수 있게 되었다.

평문 P, 암호문 C, 인코더 E, 디코더 D, 인코딩 키 e, 디코딩 키 d
C = E(P, e)
P = D(C, d)

14.3 대칭키 암호법

• 대칭키 암호법은 인코딩을 할 때 사용하는 키가 디코딩을 할 때 사용하는 키와 같다(e = d).
• 대칭키 암호법에서의 키를 k라 부르자.
• 발송자와 수신자 모두 통신을 위해 비밀키 k를 똑같이 공유할 필요가 있다.
• 발송자는 평문을 k로 암호화하여 수신자에게 발송하고, 수신자는 암호문을 수신하여 k로 복호화한다.

1) 키 길이와 열거 공격(Enummeration Attack)

• 무차별로 모든 키 값을 대입해보는 공격을 열거 공격이라고 한다.
• 가능한 키 값의 개수는 키가 몇 비트이며 얼마나 많은 키가 유요한지에 달려있다.

2) 공유키 발급하기

• 클라이언트는 서버와 암호화 된 대화를 하기 위해 클라이언트와 서버만의 개인 비밀 키를 발급해야 한다.
• 그러려면 비밀 키를 발급하고 그것을 기억할 방법이 필요하다.
• 클라이언트가 수천 개 라면 서버는 수천 개의 비밀 키를 생성하고 기억해야 할 것이다.
• 그 키를 관리해야 하는 사람 입장에서 이것은 지옥이다.

14.4 공개키 암호법

• 한 쌍의 호스트가 하나의 인코딩/디코딩 키를 사용하는 대신, 공개키 암호 방식은 두 개의 비대칭 키를 사용한다.
• 하나는 메시지 인코딩을 위한 것, 다른 하나는 메시지를 디코딩하기 위한 것
• 인코딩 키는 모두에게 공개되어 있지만 디코딩 키는 호스트만이 알고 있다.
• 서버는 자신의 인코딩 키를 공개적으로 배포했기 때문에 메시지를 서버에게 보내고자 하는 누구나 똑같고 잘 알려진 키를 사용함으로써 키가 폭발적으로 증가하는 것을 막을 수 있다.

1) RSA

• 공개키 비대칭 암호의 과제는, 해커가 아래 내용을 알고 있다 해도 비밀인 개인 키를 계산할 수 없다는 것을 확신시켜 주는 것이다.

1. 공개키(물론 공개니까 누구나 얻을 수 있다)
2. 가로채서 얻은 암호문의 일부(네트워크를 스누핑해서 획득)
3. 메시지와 그것을 암호화한 암호문(인코더에 임의의 텍스트를 넣고 실행해서 획득)

스누핑이란?
스누핑(Snooping)의 Snoop은 '기웃거리다, 염탐하다'라는 뜻을 가진 단어로,
네트워크 상에서 떠도는 정보를 몰래 획득하다라는 행위를 말한다.

• 이 모든 요구를 만족하는 공개키 암호 체계 중 RSA 데이터 시큐리티에서 상용화된 RSA 알고리즘이 가장 유명하다.

2) 혼성 암호 체계와 세션 키

• 공개 키 암호 방식의 알고리즘은 계산이 느린 경향이 있다.
• 그래서 대칭과 비대칭 방식을 섞은 것이 쓰인다.

14.5 디지털 서명

• 암호 체계는 누가 메시지를 썼는지 알려주고 그 메시지가 위조되지 않았음을 증명하기 위해 메시지에 서명하는 데에 이용될 수 있다.
• 디지털 서명은 인터넷 보안 인증서에게 중요하다.

1) 서명은 암호 체크섬이다

• 디지털 서명은 메시지에 붙어있는 특별한 암호 체크섬이다.
• 이들의 두 가지 이점

1. 서명은 메시지를 작성한 저자가 누구인지 알려준다. 저자는 저자의 극비 개인 키를 갖고 있기 때문에, 오직 저자만이 이 체크섬을 계산할 수 있다. 체크섬은 저자의 개인 '서명'처럼 동작한다.
2. 서명은 메시지 위조를 방지한다. 만약 악의적인 공격자가 송신 중인 메시지를 수정했다면, 체크섬은 더 이상 그 메시지와 맞지 않게 될 것이다. 그리고 체크섬은 저자의 비밀 개인 키에 관련되어 있기 때문에, 침입자는 그 위조된 메시지에 대한 올바른 체크섬을 날조해낼 수 없을 것이다.

• 디지털 서명은 보통 비대칭 공개키에 의해 생성된다.
• 개인 키는 오직 소유자만이 알고 있기 때문에, 저자의 개인 키는 일종의 '지문'처럼 사용된다.

• A는 가변 길이 메시지를 정제하여 고정된 길이의 digest로 만든다.
• A는 그 Digest에, 사용자의 Secret Key를 매개변수로 하는 Signature 함수를 적용한다.
• 오직 그 사용자만이 Secret Key를 알고 있기 때문에, 올바른 서명 함수는 서명자가 소유자임을 보여준다.
• 서명 함수로 디코더 함수 D를 사용한 이유는, 그 함수가 사용자의 Secret Key와 관련되어 있기 때문이다.
• 한번 서명이 계산되면, A는 그것을 메시지의 끝에 덧붙이고, 메시지와 그에 대한 서명 둘 다를 B에게 전송한다.
• B는 발송자가 A이며 메시지가 위조되지 않았다는 것을 증명하기 위해 서명을 검사할 수 있다.
• B는 A의 Secret Key로 변형된 Signature에 Public Key를 이용한 역함수를 적용한다.
• 만약 풀어낸 Digest가 B가 갖고 있는 Digest와 다르다면, 메시지가 송신 중에 위조되었거나 아니면 발송자가 A의 Secret Key를 갖고있지 않는 것이다. (즉, 메시지를 쓴 것은 A가 아니다)

14.6 디지털 인증서

• 디지털 인증서(흔히 certs라 불리는)는 신뢰할 수 있는 기관으로부터 보증 받은 사용자나 회사에 대한 정보를 담고있다.

1) 인증서의 내부

• 공식적으로 '인증 기관'에 의해 디지털 서명된 정보의 집합이 담겨있다.
• 기본적으로 디지털 인증서에 담겨있는 정보
  • 대상의 이름(사람, 서버, 조직 등)
  • 유효 기간
  • 인증서 발급자(누가 이 인증서를 보증하는가)
  • 인증서 발급자의 디지털 서명
• 대상자의 공개키

2) 서버 인증을 위해 인증서 사용하기

• 사용자가 HTTPS를 통한 안전한 웹 트랜잭션을 시작할 때, 최신 브라우저는 자동으로 접속한 서버에서 디지털 인증서를 가져온다.
• 만약 서버가 디지털 인증서를 갖고 있지 않다면, 보안 커넥션은 실패한다.
• 서버 인증서는 다음을 포함한 많은 필드를 갖고 있다.
  • 서버의 이름과 호스트명
  • 서버의 공개키
  • CA의 이름
  • CA의 서명
• 브라우저가 인증서를 받으면 CA를 검사한다.
• 해당 기관이 신뢰할만한 CA라면 브라우저는 그의 공개키를 이미 알고 있을 것이며 '디지털 서명'에서 이야기했던 바와 같이 브라우저는 그 서명을 검증할 수 있다.
• 브라우저가 모르는 CA라면, 브라우저는 해당 CA를 신뢰할 수 없으므로 사용자에게 CA를 신뢰하는지 확인하기 위한 대화상자를 보여준다. (CA가 사용자가 다니는 IT 부서이거나 혹은 소프트웨어 개발사일 수 있다)

14.7 HTTPS의 세부사항

• HTTPS는 HTTP의 가장 유명한 보안 버전이다.
• 주류 상용 브라우저와 서버에 구현되어 있다.

1) HTTPS 개요

• HTTPS는 그냥 보안 전송 계층을 통해 전송되는 HTTP이다.
• HTTP: 메시지를 TCP를 통해 보낸다.
• HTTPS: 메시지를 보안 계층으로 보내 암호화한 뒤 TCP를 통해 보낸다.

2) HTTPS 스킴

• 보안 HTTP는 선택적이기 때문에, 웹 서버로 요청할 때 우리는 웹 서버에게 HTTP의 보안 프로토콜 버전을 수행한다고 말해줄 방법이 필요하다.
• 보안 X -> HTTP / 보안 O -> HTTPS
• (웹 브라우저 등의)클라이언트는 웹 리소스를 요청받으면 URL 스킴을 검사하여 http 스킴이라면 80포트로, https 스킴이라면 443포트로 연결한다.

3) 보안 전송 셋업

• HTTPS에서의 절차는 SSL 보안 계층 때문에 HTTP보다 약간 더 복잡하다.
• 클라이언트는 먼저 웹 서버의 443포트로 연결하고 TCP 연결이 되고 나면, 클라이언트와 서버는 암호화를 어떤 방법으로 할지와 교환 키를 협상하면서 SSL 계층을 초기화 한다.
• 핸드셰이크가 완료되면 SSL 초기화는 완료되며, 클라이언트는 요청 메시지를 보안 계층에 보낼 수 있다.
• 이 메시지는 TCP에 보내지기 전에 암호화 된다.

4) SSL 핸드셰이크

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

5) 서버 인증서

• 보안 HTTPS 트랜잭션은 항상 서버 인증서를 요구한다.
• CA에 의해 서명된 서버 인증서는, 사용자가 개인 정보를 보내기 전에 그 서버를 얼마나 신뢰할 수 있는지 평가하는 것을 도와줄 것이다.
• 사용자와 사용자의 클라이언트 소프트웨어는 모든 것이 믿을 만한 것인지 확인하기 위해 인증서를 검증할 수 있다.