1. HTTP를 안전하게 만들기

HTTP의 보안 버전은 효율적이고, 이식성이 좋아야 하고, 관리가 쉬워야 하며, 현실 세계의 변화에 대한 적응력이 좋아야 한다. 그래서 우리는 다음을 제공해 줄 수 있는 HTTP 보안 기술을 적용해야 한다.

• 서버 인증
• 클라이언트 인증
• 무결성
• 암호화
• 효율
• 편재성
• 관리상 확장성
• 적응성
• 사회적 생존성

1) HTTPS

HTTPS를 사용할 때, 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화된다.

2. 디지털 암호학

• 암호

• 키

• 대칭키 암호 체계

• 비대칭키 암호 체계

• 공개키 암호법

• 디지털 서명

• 디지털 인증서

  1) 비밀 코드의 기술과 과학

  암호법은 메시지 인코딩과 디코딩에 대한 과학이자 기술이다. 암호법은, 수표에 손으로 쓴 서명이나 봉투의 양각된 왁스 봉인과 같이, 누군가가 정말로 어떤 메시지나 트랜잭션의 저자임을 증명하는 데도 사용될 수 있다

  2) 암호

  3) 암호 기계

  기술이 진보면서, 사람들은 보다 복잡한 암호로 메시지를 빠르고 정확하게 인코딩하고 디코딩하는 기계를 만들기 시작했다.

  4) 키가 있는 암호

  5) 디지털 암호

  3. 대칭키 암호법

  많은 디지털 암호 알고리즘은 대칭키 암호라 불리는데, 왜냐하면 그들이 인코딩을 할 때 사용하는 키가 디코딩을 할 때와 같이 때문이다.

  1) 키 길이와 열거 공격

  2) 공유키 발급하기

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

  4. 공개키 암호법

  공개키 암호 방식은 두 개의 비대칭 키를 사용한다.

  1) RSA

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

  5. 디지털 서명

  암호 체계는 메시지를 암호화 하고 해독하는 것뿐 아니라, 누가 메시지를 썼는지 알려주고 그 메시지가 위조되지 않았음ㅁ을 증명하기 위해 메시지에 서명을 하도록 하는 데에 이용될 수 있다.

서명은 암호 체크섬이다.

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

6. 디지털 인증서

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

1) 인증서의 내부

기본적인 디지털 인증서는 보통 다음과 같이 인쇄된 ID에도 흔히 들어가게 되는 기본적인 것들을 담고 있다.

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

2) X.509 v3 인증서

디지털 인증서에 대한 전 세계적인 단일 표준은 없다. 하지만 오늘날 사용되는 대부분의 인증서가 X.509라 불리는 표준화된 서식에 저장하고 있다는 것이다.

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

사용자가 HTTPS를 통한 안전한 웹 트랜잭션을 시작할 때, 최신 브라우저는 자동으로 접속한 서버에서 디지털 인증서를 가져온다. 만약 서버가 인증서를 갖고 있지 않다면, 보안 커넥션은 실패한다. 서버 인증서는 다음을 포함한 많은 필드를 갖고 있다.

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

7. HTTPS의 세부사항

HTTPS는 HTTP의 가장 유명한 보안 버전이다. HTTPS는 HTTPS 프로토콜에 대칭, 비대칭 인증서 기반 암호 기법의 강력한 집합을 결합한 것이다.

1) HTTPS 개요

HTTPS는 그냥 보안 전송 계층을 통해 전송되는 HTTPdlek. 암호화되지 않는 HTTP 메시지를 TCP를 통해 전 세계의 인터넷 곳곳으로 보내는 대신에 HTTPS는 HTTP 메시지를 TCP로 보내기 전에 먼저 그것들을 암호화하는 보안 계층으로 보낸다.

2) HTTPS 스킴

오늘날 보안 HTTP는 선택적이다. 따라서 웹 서버로의 요청을 만들 때, 우리는 웹 서버에게 HTTP의 보안 프로토콜 버전을 수행한다고 말해줄 방법이 필요하다. 이것은 URL의 스킴을 통해 이루어진다.

3) 보안 전송 셋업

암호화되지 않는 HTTP에서, 클라이언트는 웹 서버의 80번 포트로 TCP 커넥션을 열고, 요청 메시지를 보내고, 응답 메시지를 받고, 커넥션을 닫는다.

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

4) SSL 핸드셰이크

암호화된 HTTP 메시지를 보낼 수 있게 되기 전에, 클라이언트와 서버는 SSL 핸드셰이크를 할 필요가 있다. 핸드셰이크에서는 다음과 같은 일이 일어난다.

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

5) 서버 인증서

SSL은 서버 인증서를 클라이언트로 나르고 다시 클라이언트 인증서를 서버로 날라주는 상호 인증을 지원한다. 그러나 오늘날, 클라이언트 인증서는 웹 브라우징에선 흔히 쓰이지 않는다. 대부분의 사용자는 개인 클라이언트 인증서를 갖고 있지도 않다.

한편, 보안 HTTPS 트랜잭션은 항상 서버 인증서를 요구한다. 서버 인증서는 조직의 이름, 주소, 서버 DNS 도메인 이름, 그리고 그 외의 정보를 보여주는, X.509 v3에서 파생된 인증서이다. 사용자와 사용자의 클라이언트 소프트웨어는 모든 것이 믿을 만한 것인지 확인하기 위해 인증서를 검증할 수 있다.

6) 사이트 인증서 검사

SSL 자체는 사용자에게 웹 서버 인증서를 검증할 것을 요구하지 않지만, 최신 웹 브라우저들 대부분은 인증서에 대해 간단하게 기본적인 검사를 하고 그 결과를 더 철저한 검사를 할 수 있는 방법과 함께 사용자에게 알려준다.

넷스케이프가 제안한 웹 서버 인증서 검사 알고리즘은 다음과 같다.

• 날짜 검사
• 서명자 신뢰도 검사
• 서명 검사
• 사이트 신원 검사

7) 가상 호스팅과 인증서

가상 호스트로 운영되는 사이트의 보안 트래픽을 다루는 것은 까다로운 경우도 많다. 몇몇 인기 있는 웹 서버 프로그램은 오직 하나의 인증서만을 지원한다. 만약 사용자가 인증서의 이름과 정확히 맞지 않는 가상 호스트 명에 도착했다면 경고 상자가 나타날 것이다.

8. 진짜 HTTPS 클라이언트

SSL은 복잡한 바이너리 프로토콜이다. 암호 전문가가 아닌 이상, 가공되지 않은 SSL 트래픽을 직접 보내지 마라. 다행이도 이를 쉽게 만들어주는 것들이 존재한다.

1) OpenSSL

OpenSSL은 SSL과 TLS의 가장 인기 있는 오픈 소스 구현이다.

2) 간단한 HTTPS 클라이언트

www.openssl.org 참고

3) 우리의 단순한 OpenSSL 클라이언트 실행하기

9. 프락시를 통한 트래픽 터널링

클라이언트는 종종 그들을 대신하여 웹 서버에 접근해주는 웹 프락시 서버를 이용한다. 그러나 클라이언트가 서버로 보낼 데이터를 서버의 공개키로 암호화하기 시작했다면, 프락시는 더 이상 HTTP헤더를 읽을 수 없다!

HTTPS가 프락시와도 잘 동작할 수 있게 하기 위해, 클라이언트가 프락시에게 어디에 접속하려고 하는지 말해주는 방법을 약간 수정해야 한다. 인기 있는 기법 하나는 HTTPS SSL 터널링 프로토콜이다.