보안 HTTP

HTTP를 안전하게 만0들기

HTTP의 보안 버전은 효율적이고, 이식성이 좋아야 하고, 관리가 쉬워야 하며, 현실 세계의 변화에 대한 적응력이 좋아야한다.
HTTP를 안전하게 만들기 위한 보안 기술 : 서버 인증, 클라이언트 인증, 무결성, 암호화, 편재성, 효율, 관리상 확장성, 적응성, 사회적 생존성

HTTPS

HTTPS는 HTTP를 안전하게 만드는 방식 중에서 가장 인기 있는 것이다.
URL이 https://로 시작하는 것을 보고 HTTPS방식임을 알아볼 수 있다
HTTPS는 HTTP의 하부에 전송 레벨 암호 보안 계층을 제공함으로써 동작하는데, 이 보안 계층은 안전 소켓 계층(SSL) 혹은 전송 계층 보안(TLS)을 이용하여 구현된다
HTTPS는 TCP위에 놓은 보안 계층 위의 HTTP이다
대부분의 경우, TCP 입력/출력 호출을 SSL호출로 대체하고, 보안정보를 설정하고 관리하기 위한 몇 가지 호출을 추가한다0

디지털 암호학

암호(cipher) : 암호란 메시지를 인코딩하는 어떤 특정한 방법과 나중에 그 비밀 메시지를 디코딩하는 방법이다

키가 있는 암호 : 대부분의 기계들에는 암호의 동작방식을 변경할 수 있는 큰 숫자로 된 다른 값을 설정할 수 잇는 다이얼이 달려있다. 이것을 암호 매개변수 키라고 부른다. 이 가상 암호 기계들은 서로 다른 키 값을 갖고 있기 때문에 제각각 다르게 동작한다. 예를들어, 같은 입력 메시지 'meet me at midnight'가 같은 인코딩 기계를 통과하더라도 키의 값에 따라 다른 출력(암호문)을 생성한다.

디지털 암호

평문 메시지 P, 인코딩 함수 E, 디지털 인코딩 키 e가 주어지면 부호화된 암호문 C를 생성할 수 잇다. 그리고 암호문 C를 디코더 함수 D와 디코딩 키 d를 사용해서 원래의 평문 P로 도로 디코딩 할 수 있다.

P의 인코딩에 대한 디코딩은 원래의 메시지 P를 돌려준다

코딩 알고리즘은 데이터 덩어리를 받아서 알고리즘과 키의 값에 근거하여 인코딩하거나 디코딩하는 함수이다.

대칭키 암호법

대칭키 암호 알고리즘으로 DES, Triple-DES, RC2, RC4등이 있다.
128비트 대칭키 암호는 매우 강력한 것으로 간주한다
대칭키 암호의 단점 중 하나는 발송자와 수신자가 서로 대화하려면 둘다 공유키를 가져야 한다.

공개키 암호법

공개키 암호 방식은 두개의 비대칭 키를 사용한다. 하나는 호스트의 메시지를 인코딩하기위한 것이며, 다른 하나는 그 호스트의 메시지를 디코딩하기 위한 것이다. 
인코딩 키는 모두를 위해 공개되어 있지만, 디코딩 키는 호스트만 알고 있다
모든 사람이 X에게 보내는 메시지를 같은 키로 인코딩 할 수 있지만, X를 제외한 누구도 그 메시지를 디코딩할 수 없다.
RSA 알고리즘은 공개키, 평문의 일부, 공개키로 평문을 인코딩하여 얻은 평문에 대한 암호문, RSA구현의 소스코드까지 주어졌어도 암호를 크래킹하여 개인 키를 찾아내는 것을 어렵게 만든다.
실제로는 노드들 사이의 안전한 의사소통 채널을 수립할 때는 공개 키 암호를, 이렇게 만들어진 안전한 채널을 통해 임시의 무작위 대칭 키를 생성하고 교환하여 이후의 나머지 데이터를 암호화할 때는 때른 대칭 키를 사용하는 방식으로 사용된다

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

E.G

노드 A는 가변 길이 메시지를 정제하여 고정된 길이의 요약으로 만든다
노드 A는 그 요약에, 사용자의 개인 키를 매개변수로 하는'서명' 함수를 적용한다. 오직 사용자만의 개인 키를 알고 있다.
한번 서명이 게산되면, 노드 A는 그것을 메시지의 끝에 덧붙이고 메시지와 그에 대한 서명 둘 다 를 노드 B에게 전송한다
노드 B는 개인 키로 알아보기 어렵게 변형된 서명에 공개키를 이용한 역함수를 적용한다. 만약 풀어낸 요약이 노드 B가 갖고 잇는 버전의 요약과 일치하지 않는다면, 메시지가 송신중에 위조되었거나 발송자가 노드 A의 개인 키를 갖고 있지 않는 것이다.

디지털 인증서

X.509 v3인증서

필드	설명
버전	이 인증서가 따르는 X.509 인증서 버전의 번호. 요즘은 보통 버전 3이다
일련번호	인증기관에 의해 생성된 고유한 정수. CA로부터의 각 인증서는 반드시 고유한 일련번호를 가져야 한다
서명 알고리즘 ID	서명을 위해 사용된 암호 알고리즘. 예를 들면 'RSA 암호화를 이용한 MD2요약'
인증서 발급자	인증서가 유효한 기간. 시작일과 종료일로 정의된다.
대상의 이름	인증서에 기술된, 사람이나 조직과 같은 엔터티. 이 대상 이름은 X.500포맷으로 기록되어 있다
대상의 공개 키 정보	인증 대상의 공개 키. 공개 키에 사용된 알고리즘. 추가 매개변수
발급자의 고유 ID(선택적)	발급자의 이름이 겹치는 경우를 대비한, 인증서 발급자에 대한 선택적인 고유한 식별자
대상의 교유ID(선택적)	대상의 이름이 겹치는 경우를 대비한, 인증 대상에 선택적인 고유한 식별자
확장	선택적인 확장 필드의 집합. 기본 제약 - 대상과 인증기관과의 관계 인증서 정책 - 인증서가 어떤 정책하에 승인되었는지 키 사용 - 공개키가 어떻게 사용될 수 있는지
인증기관 서명	위의 모든 필드에 대한 인증기관의 디지털 서명. 명시된 서명 알고리즘을 사용한다.

일반적인 디지털 서명의 포맷과 서명이 진짜인지 검증하는 과정

HTTPS의 세부사항

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

HTTPS 스킴

보안이 되는 HTTPS 프로토콜에서 URL의 스킴 접두사는 다음과 같이 https://이다
만약 URL이 http 스킴을 갖고 있다면, 클라이언트는 서버에 80번(기본값)포트로 연결하고 평범한 HTTP명령을 전송한다
만약 URL이 https스킴을 갖고 있다면, 클라이언트는 서버에 443번(기본값) 포트로 연결하고 서버와 바이너리 포맷으로 된 몇몇 보안 매개변수를 교환하면서 '핸드셰이크'를 하고, 암호화된 http 명령이 뒤를 잇는다
SSL 트래픽은 바이너리 프로토콜이기 때문에, HTTP와는 완전히 다르다. 그 트래픽은 보통 443 포트를 통해 전달된다

서버 인증서 : 보안 HTTPS 트랜잭션은 항상 서버 인증서를 욕한다. 서버인증서는 조직의 이름, 주소, 서버DNS도메인 이름, 그외의 정보를 보여주는 X.509 v3에서 파생된 인증서이다.

사이트 인증서 검사

넷스케이프가 제안한 웹 서버 인증서 검사를 위한 알고리즘은 다음을 검사한다

만약 루이지애나 풍의 전자상거래 사이트인 Cajun-Shop.com이 있다고 해보자. 이 사이트의 호스팅 제공자는 공식 이름 cajun-shop.securesites.com을 제공했다. 사용자가 https://Cajun-Shop.com 으로 접속했을 때, 서버 인증서에 나열된 공식 호스트 명 (*.securesites.com)과 맞지 않으므로,경고가 나타난다.

이러한 문제를 피하기 위해 보안 트랜잭션을 시작하는 모든 사용자를 cajun-shop.securesites.com으로 리다이렉트한다.

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

프락시는 암호화된 요청을 다룰 수 없다. 때문에 HTTP SSL 터널링 프로토콜을 사용한다

클라이언트는 먼저 프락시에게 자신이 연결하고자 하는 안전한 호스트와 포트를 말해준다. CONNECT메서드를 사용해 프락시에게 희망하는 호스트와 포트번호로 연결을 해달라고 말해주며, 그것이 완료되면, 클라이언트와 서버 사이에서 데이터가 직접적으로 오갈 수 있게 해주는 터널을 만든다.

요청의 예

CONNECT home.netscape.com:443 HTTP/1.0 User-agent: Mosilla/1.1N <SSL로 암호화된 데이터가 이 다음에 온다...>

프락시가 서버로 연결을 성공하면

HTTP/1.0 200 Connection established Proxy-agent : Netscape-Proxy/1.1