[HTTP 완벽 가이드] 3부 학습

11장: 클라이언트 식별과 쿠키

개별 접촉

• 웹 서버는 요청을 보낸 사용자를 식별하거나 방문자가 보낸 연속적인 요청을 추적할 수 있다.
• 웹 사이트들은 개인화된 서비스를 제공한다.
  • 개별 인사
  • 사용자 맞춤 추천
  • 저장된 사용자 정보
  • 세션 추적
• HTTP가 사용자를 식별하는 데 사용하는 기술은 다음과 같다.

HTTP 헤더

• 사용자에 대한 정보를 전달하는 일반적인 HTTP 요청 헤더는 다음과 같다.
  1. From: 사용자의 이메일 주소
  2. User-Agent: 사용자의 브라우저
  3. Referer: 사용자가 현재 링크를 타고 온 근원 페이지(사용자가 직전에 방문한 페이지)
  4. Authorization: 사용자 이름과 비밀번호
  5. Client-ip(확장): 클라이언트의 IP 주소
  6. X-Forwarded-For(확장): 클라이언트의 IP 주소
  7. Cookie(확장): 서버가 생성한 ID 라벨
• 헤더만 가지고 사용자를 식별하기는 어렵다.

클라이언트 IP 주소

• 사용자가 확실한 IP 주소를 가지고 있고, 그 주소가 바뀌지 않고, 웹 서버가 요청마다 클라이언트 IP를 알 수 있다면 사용자 식별에 IP 주소를 문제 없이 사용할 수 있다.
• 사용자 식별에 IP 주소를 사용하는 방식의 단점은 아래와 같다.
  • 클라이언트 IP 주소는 사용자가 아닌 사용자의 컴퓨터를 식별하므로 여러 명이 한 대의 컴퓨터를 사용한다면 사용자별 식별이 불가능하다.
  • 많은 인터넷 서비스 제공자(ISP)가 동적 IP 주소를 할당한다.
  • 많은 사용자가 네트워크 주소 변환(NAT) 방화벽을 통해 인터넷을 사용한다. 이 방식에서는 실제 클라이언트 IP 주소가 아니라 하나의 방화벽 IP 주소가 외부로 노출된다.
  • 프락시나 게이트웨이를 지나면서 원 서버에 프락시 서버의 IP 주소가 전달된다. 모든 프락시나 게이트웨이가 원본 IP 주소를 보존하지는 않는다.

사용자 로그인

• 웹 서버는 사용자 이름과 비밀번호로 인증(로그인)할 것을 요구해 사용자가 명시적으로 식별을 요청하도록 할 수 있다.
• HTTP는 WWW-Authenticate와 Authorization 헤더를 사용해 웹 사이트에 사용자 이름을 전달하는 자체 체계를 가진다.
• 한 번 로그인 과정이 일어나면 그 세션이 진행되는 내내 사용자에 대한 식별 정보를 Authorization 헤더에 담아 전달한다.

뚱뚱한 URL

• 사용자의 상태 정보를 포함하는 URL을 뚱뚱한(fat) URL이라고 한다.
• 웹 서버와 통신하는 독립적인 HTTP 트랜잭션을 하나의 세션/방문으로 묶는 용도로 뚱뚱한 URL을 사용할 수 있다.
• 뚱뚱한 URL의 문제는 아래와 같다.
  • 못생긴 URL이 사용자들에게 혼란을 준다.
  • URL 자체가 사용자 정보를 포함하기 때문에 공유할 수 없다.
  • URL 자체가 달라지기 때문에 캐시를 사용할 수 없다.
  • 서버가 URL에 해당하는 HTML 페이지를 다시 그리게 되므로 서버 부하가 가중된다.
  • 사용자가 링크를 타고 다른 사이트로 이동하거나 특정 URL을 요청하면 뚱뚱한 URL 세션에서 이탈하기 쉽다.
  • 세션 지속성이 없어 로그아웃 시 모든 정보를 잃는다.

쿠키

쿠키의 타입

• 쿠키는 크게 세션 쿠키(session cookie)와 지속 쿠키(persistent cookie) 타입으로 나눌 수 있다.
• 세션 쿠키는 사용자가 브라우저를 닫으면 삭제되는 임시 쿠키이다.
• 지속 쿠키는 디스크에 저장되어 브라우저를 닫거나 컴퓨터를 재시작해도 남아있는 쿠키이다.
• 쿠키에 Discard 파라미터가 설정되어 있거나, Expires 또는 Max-Age 파라미터가 없으면 세션 쿠키가 된다.

동작 방식

• 쿠키는 이름=값 형태의 리스트를 가진다.
• 브라우저는 서버로 온 Set-Cookie 혹은 Set-Cookie2 헤더에 있는 쿠키 컨텐츠를 브라우저 쿠키 데이터베이스에 저장한다. 브라우저는 서버가 할당한 쿠키를 Cookie 요청 헤더에 기술해 전송한다.

쿠키 상자: 클라이언트 측 상태

• 쿠키 정보를 저장하는 시스템을 클라이언트 측 상태(HTTP 상태 관리 체계)라고 한다. 브라우저는 HTTP 상태 관리 체계를 유지할 책임을 갖는다.
• 브라우저별 다른 방식으로 쿠키를 저장한다.
  • 크롬은 SQLite 파일에 쿠키를 저장한다.
    • createion_utc: 쿠키 생성 시점
    • host_key: 쿠키 도메인
    • name: 쿠키 이름
    • value: 쿠키 값
    • path: 쿠키와 관련된 도메인에 있는 경로
    • expire_utc: 쿠키 파기 시점

사이트별 쿠키

• 브라우저는 아래와 같은 이유로 사이트에 2~3개의 쿠키만 보낸다.
  • 성능 저하
  • 대부분 서버에 특화된 이름/값 쌍이므로 사이트에서 인식하지 못하는 무의미한 값
  • 신뢰하지 않는 사이트에 정보 제공 제한
• 브라우저는 쿠키를 생성한 서버에게만 쿠키에 담긴 정보를 전달한다.
• 많은 웹 사이트는 광고 협력업체와 계약한다.
  • 광고들은 웹 사이트 일부처럼 제작되고 지속 쿠키를 만들어낸다.
  • 같은 광고사에서 제공하는 서로 다른 웹 사이트에 사용자가 방문하면 지속 쿠키의 도메인이 같기 때문에 브라우저는 지속 쿠키를 광고사 서버로 전송한다.
  • 쿠키 Domain 속성은 브라우저가 해당 도메인을 가지는 모든 사이트에 쿠키를 전달한다는 의미이다.
  • 쿠키 Path 속성은 브라우저가 해당 경로에 속하는 페이지에만 쿠키를 전달한다는 의미이다.

쿠키와 세션 추적

• 쿠키는 웹 사이트에 수차례 트랜잭션을 만들어내는 사용자를 추적하는 데 사용한다.

쿠키와 캐싱

• 쿠키 트랜잭션 문서를 캐싱할 때에는 이전 사용자 쿠키가 다른 사용자에게 할당되거나 개인정보가 노출되지 않도록 주의해야 한다. 캐시를 다루는 기본 원칙은 다음과 같다.
  1. 캐시되지 말아야 할 문서가 있다면 표시하라
     • 캐시되지 말아야 할 문서는 Cache-Control: no-cache={문서} 로 명시한다.
  2. Set-Cookie 헤더를 캐시하는 것에 유의하라
     • 같은 Set-Cookie 헤더를 여러 사용자에게 보내면 사용자 추적에 실패한다.
     • 모든 요청마다 재검사를 수행하여 클라이언트로 가는 응답을 검증하게 할 수 있다.
  3. Cookie 헤더를 가지고 있는 요청을 주의하라
     • 요청이 Cookie 헤더를 가지면 결과 컨텐츠가 개인정보를 담고 있을 수도 있다.
     • 모든 요청마다 재검사를 수행하여 클라이언트로 가는 응답을 검증하게 할 수 있다.

쿠키, 보안, 개인정보

• 원격 데이터베이스에 개인 정보를 저장하고 키 값을 쿠키에 저장하는 방식을 표준으로 사용하면 클라이언트-서버 사이 예민한 데이터가 오가는 것을 줄일 수 있다.

 

12장: 기본 인증

인증

• 인증이란 본인이 누구인지 증명하는 것이다.

HTTP의 인증 요구/응답 프레임워크

• HTTP 요청 메시지를 받았을 때 서버는 요청을 처리하는 대신 사용자가 누구인지를 알 수 있게 비밀번호같은 개인 정보를 요구하는 인증 요구로 응답할 수 있다.
• 사용자는 다시 요청을 보낼 때 인증 정보를 첨부해야 한다.
• 인증 정보가 맞지 않으면 서버는 다시 인증 요구를 보내거나 에러를 낼 수 있다.
• 인증 정보가 맞으면 요청을 처리한다.

인증 프로토콜과 헤더

• HTTP에는 기본 인증, 다이제스트 인증이라는 두 가지 공식적인 인증 프로토콜이 있다.

단계 헤더 헤더 설명 메서드 상태

단계	헤더	헤더 설명	메서드 상태
요청			GET
인증 요구	WWW-Authenticate	어떤 영역에서 어떻게 인증할지 설명	401 Unauthorized
인증	Authorization	인증 알고리즘, 사용자 이름, 비밀번호	GET
성공	Authentication-Info(선택)	인증 세션에 관한 추가 정보	200 OK

보안 영역

• 웹 서버는 기밀문서를 보안 영역(realm) 그룹으로 나누어 리소스별 접근 조건을 관리한다.
• realm은 해설 형식이나 서버 호스트명 등 사용자가 권한 범위를 이해하기 쉽도록 작성한다.

기본 인증

• 기본 인증에서 응답의 Authorization 헤더에는 base-64로 인코딩한 사용자 이름:비밀번호가 들어간다.
• 기본 인증 프로토콜은 Authentication-Info 헤더를 사용하지 않는다.

프락시 인증

• 프락시 서버를 이용한 인증은 접근 정책을 중앙에서 관리할 수 있으므로 회사 리소스 전체에 대한 통합 접근 제어가 가능하다.

웹 서버 인증 프락시 서버 인증

웹 서버 인증	프락시 서버 인증
비인증 상태 코드: 401	비인증 상태 코드: 407
WWW-Authenticate	Proxy-Authenticate
Authorization	Proxy-Authorization
Authentication-Info	Proxy-Authentication-Info

기본 인증의 보안 결함

1. 사용자 이름, 비밀번호를 쉽게 디코딩할 수 있다.
   • 모든 HTTP 트랜잭션을 SSL 암호화 채널을 통해 보내거나 보안이 더 강화된 다이제스트 인증을 사용하는 것이 좋다.
2. 제삼자가 사용자 이름, 비밀번호 자체를(디코딩하지 않더라도) 원 서버에 보내 인증에 성공하고 서버에 접근할 수 있다.
3. 메시지의 인증 헤더 이외의 부분을 수정해 트랜잭션의 원래 의도를 변경하는 프락시가 개입하는 경우 정상적인 동작을 보장하지 않는다.
4. 사용자가 가짜 서버/게이트에 연결되어 있다는 것을 검증할 수 없다.

• 위의 결함을 보완하기 위해 기본 인증은 의도치 않게 리소스에 접근하는 것을 제한하는 데에 사용하거나, SSL 같은 암호 기술과 혼용해 사용한다.

 

13장: 다이제스트 인증

• 기본 인증을 안전하게 이용하려면 SSL과 결합해 사용해야 한다.
• 다이제스트 인증은 기본 인증과 호환되는 더 안전한 대체재로서 개발되었다.

다이제스트 인증의 개선점

• 다이제스트 인증의 특징은 다음과 같다.
  • 비밀번호를 네트워크를 통해 평문으로 전송하지 않는다.
  • 인증 체결을 가로채서 재현하려는 시도를 차단한다.
  • 구현에 따라 메시지 내용 위조를 차단하는 것도 가능하다.
  • 그 외 몇몇 알려진 형태의 공격을 차단한다.

요약 사용하기

• 다이제스트 인증의 좌우명은 “절대로 비밀번호를 네트워크를 통해 보내지 않는다”이다.
• 대신 비밀번호를 비가역적으로 뒤섞은 지문(fingerprint) 혹은 요약(digest)를 보낸다.
• 다이제스트 인증의 동작 과정은 아래와 같다.
  1. 클라이언트가 보호된 문서를 요청한다.
  2. 서버는 클라이언트가 비밀번호를 알고 있음을 스스로 증명하여 신원을 인증하기 전까지 문서 제공을 거부한다. 서버는 클라이언트에게 사용자 이름과 요약된 형태의 비밀번호를 요구한다.
  3. 클라이언트는 비밀번호의 요약을 전달하여 자신이 비밀번호를 알고 있음을 증명한다.
  4. 서버는 클라이언트가 제공한 요약과 서버가 내부적으로 계산한 요약을 비교해 일치하면 클라이언트에게 문서를 제공한다.

단방향 요약

• 요약은 정보 본문의 압축이다.
• 요약은 단방향 함수로 동작하고 무한한 입력값을 유한한 범위의 압축으로 변환한다.
  • 유한한 범위 내에서 압축하기 때문에 충돌이 발생할 수 있지만 그 범위가 크기 때문에 충돌 가능성은 무시해도 될 만큼 작다.
• MD5는 임의의 바이트 배열을 원래 길이와 상관없이 128비트 요약으로 변환한다.
• 요약 함수는 암호 체크섬으로 불리며 단방향 해시 함수이거나 지문 함수이다.

재전송 방지를 위한 난스 사용

• 단방향 요약을 사용하면 비밀번호 대신 요약만 보내고 악의적인 사용자가 해당 요약을 해독할 수 없음을 보장하면 된다.
• 대신 악의적인 사용자가 요약 자체를 가로채 해당 요약으로 요청을 보내는 재전송 공격을 막기 위해 난스(nonse)를 사용한다.
• 난스는 서버가 클라이언트에게 보내주는 특별하고 자주 바뀌는 증표이다.
• 난스를 비밀번호에 섞으면 요약도 변하게 된다. 서버에 저장된 비밀번호 요약은 특정 인증에 대해서만 유효하기 때문에 재전송 공격을 막을 수 있다.
• 난스를 사용하지 않는 다이제스트 인증은 기본 인증만큼 허약하기 때문에 다이제스트 인증은 난스 사용을 요구한다.

다이제스트 인증 핸드셰이크

• 다이제스트 인증의 세 단계 핸드셰이크 과정은 다음과 같다.
  1. 서버가 난스 값을 계산한다. 서버는 난스를 WWW-Authenticate 인증 요구 메시지에 담고 서버가 지원하는 알고리즘 목록과 함께 클라이언트에게 전송한다.
  2. 클라이언트는 알고리즘을 선택하고 요약을 계산한다. 요약을 Authorization에 담아 서버에게 돌려준다. 클라이언트가 서버를 인증하기를 원한다면 난스를 보낼 수 있다.
  3. 서버는 요약, 선택된 알고리즘, 보조 데이터를 받고 클라이언트가 했던 그대로 요약을 계산한다. 서버가 가진 요약과 클라이언트가 제공한 요약이 일치하는지 확인한다. 클라이언트가 서버를 인증하기를 원했다면 클라이언트 요약이 만들어진다.

요약 계산

• 다이제스트 인증의 핵심은 공개된 정보, 비밀 정보, 시한부 난스 값을 조합한 단방향 요약이다.

요약 알고리즘 입력 데이터

• 요약은 다음 요소로부터 계산된다.
  • 단방향 해시 함수 H(d), 요약 함수 KD(s, d)
    • s: 비밀(secret)
    • d: 데이터(data)
  • 비밀번호 등 보안 정보를 담는 데이터 덩어리 A1
  • 비밀이 아닌 속성을 담는 데이터 덩어리 A2
• A1, A2는 요약을 생성하기 위해 H와 KD에 의해 처리된다.

H(d), K(s, d) 알고리즘

• 다이제스트 인증은 여러 요약 알고리즘을 선택할 수 있도록 지원한다. RFC2617에서는 MD5, MD5-sess를 제안하며 기본값은 MD5이다.
• H(d) = MD5(d)
• KD(s, d) = H(연결(s:d))

보안 관련 데이터 A1

• 보안 데이터는 사용자 이름, 비밀번호, 보호 영역(realm), 난스로 이루어져 있다.
• MD5는 모든 요청마다 단방향 해시를 실행한다. A1은 사용자 이름, 비밀번호, 보호 영역을 콜론으로 연결한 것이다.
• MD5-sess는 해시 계산을 처음 WWW-Authenticate 핸드셰이크를 할 때 한 번만 수행한다. 사용자 이름, 비밀번호, 보호 영역에 대한 해시를 계산한 값 뒤에 현재 난스, 클라이언트 난스를 붙인 것이 A1이다.

메시지 관련 데이터 A2

• 메시지 관련 데이터는 요청 메서드, 메시지 엔터티 본문과 같은 메시지 자체의 정보를 나타낸다. 메시지 위조를 방지하기 위해 사용된다.
• HTTP 요청 메서드와 URL만 포함하는 경우가 기본값이다. qop=”auth”인 경우이다.
• 위에 메시지 엔티티 본문을 추가해 메시지 무결성 검사를 제공할 수 있다. qop=”auth-int”인 경우이다.

요약 알고리즘 전반

• 요약을 계산하는 두 가지 방법은 아래와 같다.
  1. 비밀 정보와 난스가 붙은 메시지 데이터의 해시를 이용해 요약을 계산한다.
  2. 난스 횟수, qop, c난스(클라이언트 난스) 데이터를 요약에 추가한다.

다이제스트 인증 세션

• 특정 보호 공간을 위한 WWW-Authenticate 인증 요구에 대한 클라이언트 응답은 그 보호 공간에 대한 인증 세션을 시작하게 한다. 이 인증 세션은 다른 인증 요구를 받을 때까지 지속된다.
• 클라이언트는 사용자 이름, 비밀번호, 난스, 난스 횟수, 보호 공간 내 미래 요청에 들어갈 Authorization를 만들기 위해 사용될 인증 세션 관련 값들을 기억해야 한다.

사전(preemptive) 인가

• 일반적 인증에서의 요청은 트랜잭션이 완료되기 전에 요청/인증 요구 사이클을 필요로 한다.
• 만약 클라이언트가 다음 난스가 무엇일지 알고 있어서 서버가 물어보기 전에 올바른 Authorization 헤더를 생성할 수 있다면 이 사이클을 생략할 수 있다.
• 다이제스트 인증에서는 재전송 공격 방지를 위해 난스를 사용하기 때문에 사전 인가 과정이 조금 더 복잡하다. 아래와 같은 방법으로 사전 인가를 수행할 수 있다.
  • 다음 난스를 Authentication-Info 헤더에 담아 미리 보낸다.
    • 다음 요청을 보내기 전에 다음 난스 값을 받아야 하므로 회전 지연이 생긴다.
  • 서버가 짧은 시간 동안 난스 재사용을 허용한다.
    • 공격자의 재전송 공격이 가능해 보안성이 감소된다.
  • 클라이언트와 서버가 동기화되어 있고 예측 가능한 난스 생성 알고리즘을 사용한다.

난스 선택

• RFC 2617은 BASE64(타임스탬프 H(타임스탬프”:” ETag “:”개인 키)) 난스 공식을 제안했다.
  • ETag는 요청된 엔티티에 대한 ETag 헤더값이다.

상호 인증

• RFC 2617은 클라이언트도 서버를 인증할 수 있도록 확장했다.
• 서버가 공유된 비밀 정보에 근거한 올바른 응답 요약을 생성할 수 있도록 클라이언트 난스(c난스) 값을 제공함으로써 가능하다. 서버는 이 요약을 Authenticateion-Info 헤더를 통해 전달한다.

보호 수준(Quality of Protection) 향상

• qop 필드는 요약 헤더의 세 가지 헤더 WWW-Authenticate, Authorization, Authenticate-Info 모두에 존재할 수 있다.
• qop 필드는 서버가 어떤 보호 기법을 어느 정도 수준으로 사용할지 협상하도록 한다.

메시지 무결성 보호

• qop=”auth-int”가 적용되면 계산되는 H(엔티티 본문)는 메시지 본문의 해시가 아니라 엔티티 본문의 해시이다.

보안에 대한 고려사항

헤더 부당 변경

• 양 종단 암호화나 헤더에 대한 디지털 서명이 필요하다.

재전송 공격

• 매 트랜잭션마다 유일한 난스 값을 사용하면 재전송 공격을 완전히 피할 수 있다.

다중 인증 매커니즘

• 클라이언트가 언제나 가능한 한 가장 강력한 인증 제도를 선택해 보안성을 강화한다.

사전 공격

• 악의적인 사용자는 난스/응답 쌍에 대해 비밀번호 추측 프로그램을 사용해 비밀번호를 추측할 수 있다. 비밀번호를 상대적으로 복잡하게 만들거나 비밀번호 만료 정책을 강화해야 한다.

악의적인 프락시와 중간자 공격

• 프락시 중 하나가 악의적이거나 보안이 허술한 경우 중간자 공격에 취약할 수 있다. 도청을 방어하는 유일한 방법은 SSL을 사용하는 것이다.

선택 평문 공격

• 보안이 허술하거나 악의적인 프락시가 트래픽 중간에 끼어들거나 서버 자체가 악의적인 경우 클라이언트에게 잘못된 난스를 제공할 수 있다. 이는 응답의 해독을 쉽게 한다.
• 미리 계산된 사전 공격: 사전 공격 + 선택 평문 공격
• 자동화된 무차별 대입 공격: 주어진 범위에서 가능한 모든 비밀번호를 열거해 크래킹을 시도

비밀번호 저장

• 다이제스트 인증 매커니즘은 서버에 H(A1)과 사용자 이름 튜플을 저장한다.
• 서버의 다이제스트 인증 비밀번호 파일이 유출되면 암호 해독 없이 모든 문서가 공격자에게 노출된다.
• 이 문제를 완화하는 방법은 아래와 같다.
  • 비밀번호 파일을 안전하게 보호한다.
  • 영역 이름을 유일화하고 파일 유출 시 피해를 특정 영역으로 국소화한다.

 

14장: 보안 HTTP

• 보다 중요한 트랜잭션을 위해서는 HTTP와 디지털 암호화 기술을 결합해야 한다.

HTTPS

• HTTPS는 넷스케이프에서 개척한 HTTP를 안전하게 만드는 방식이다. HTTP가 보안 전송 계층을 통해 전송된다.
• 모든 HTTP 요청, 응답 데이터는 네트워크로 보내지기 전에 암호화된다.
  • HTTP 하부에 전송 레벨 암호 보안 계층인 안전 소켓 계층(Secure Sockets Layer, SSL)을 제공해 동작한다.
• 보안 HTTP를 사용하기 위해서는 대부분의 경우 TCP 입/출력 호출을 SSL 호출로 대체하고 보안 정보 설정/관리를 위한 몇 가지 호출을 추가하면 된다.

HTTPS 스킴

• URL이 HTTPS 스킴(https)를 가진다면 클라이언트는 서버에 보안 HTTP의 기본 포트인 443 포트로 연결한다. 서버와 바이너리 포맷으로 된 몇몇 SSL 보안 매개변수를 교환해 핸드셰이크를 수행하고, 암호화된 HTTP 명령이 전달된다.

보안 전송 셋업

• HTTPS 트랜잭션 과정은 다음과 같다.
  1. 클라이언트가 서버의 443 포트로 TCP 연결을 수립한다.
  2. 클라이언트와 서버는 SSL 보안 매개변수를 협상하며 핸드셰이크한다.
  3. 클라이언트는 SSL을 통한 HTTP 요청(TCP를 통해 보내진 암호화된 요청)을 보낸다.
  4. 클라이언트는 SSL을 통한 HTTP 응답(TCP를 통해 보내진 암호화된 응답)을 받는다.
  5. SSL이 닫힘을 통지한다.
  6. TCP 커넥션이 닫힌다.

SSL 핸드셰이크

• 암호화된 HTTP 메시지를 보내기 전에 클라이언트와 서버는 다음과 같은 과정이 수행되는 SSL 핸드셰이크를 수행해야 한다.
  • 프로토콜 버전 번호 교환
  • 양쪽이 알고 있는 암호 선택
  • 양쪽의 신원 인증
  • 채널을 암호화하기 위한 임시 세션 키 생성
• SSL 핸드셰이크 과정은 다음과 같다.
  1. 클라이언트가 암호 후보들을 보내고 인증서를 요구한다.
  2. 서버는 선택된 암호화 인증서를 보낸다.
  3. 클라이언트가 비밀정보를 보낸다. 클라이언트와 서버는 키를 만든다.
  4. 클라이언트와 서버는 서로에게 암호화를 시작한다고 말해준다.

인증서

• SSL은 서버 인증서를 클라이언트로, 클라이언트 인증서를 서버로 전달하는 상호 인증을 지원하지만 클라이언트 인증서는 웹 브라우징에서 잘 쓰이지 않는다.
• 보안 HTTPS 트랜잭션은 항상 서버 인증서를 요구한다.
  • 서버 인증서는 조직 이름, 주소, 서버 DNS 도메인 이름 등의 정보를 보여주는 인증서이다.
• 웹 서버 인증서 검사를 위한 알고리즘 수행 단계는 다음과 같다.
  1. 날짜 검사: 인증서 만료/활성화 여부 검사
  2. 서명자 신뢰도 검사: 인증 기관 검사
  3. 서명 검사: 인증서 무결성 검사
  4. 사이트 신원 검사: 호스트명과 인증서 신원 비교
• 가상 호스트로 운영되는 사이트는 인증서 이름과 호스트명이 다를 수 있다. 이 문제를 피하기 위해 사이트는 보안 트랜잭션을 시작하는 모든 사용자를 공식 호스트명으로 리다이렉트한다.

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

• 클라이언트가 서버로 보낼 데이터를 서버 공개키로 암호화한다면 프락시는 더 이상 HTTP 헤더를 읽을 수 없고, 어디로 요청을 보내야 하는지 알 수 없다.
• HTTPS가 프락시와 잘 동작하도록 하기 위해 HTTPS SSL 터널링 프로토콜을 사용한다.
  • 클라이언트는 프락시에게 CONNECT라는 확장 메서드를 사용해 자신이 연결하고자 하는 안전한 호스트와 포트를 (암호화 이전에) 평문으로 말해준다.
  • CONNECT 메서드가 완료되면 클라이언트와 서버 사이에서 데이터가 직접적으로 오갈 수 있는 터널을 만든다.