HTTP완벽가이드 스터디 13, 14장

13 다이제스트 인증

http://iloveulhj.github.io/posts/http/http-digest-auth.html 

이 포스트는 “HTTP 완벽가이드”의 “13장, 다이제스트 인증”을 정리한 내용입니다.

---

• 기본 인증은 편리하고 유연하지만 안전하지 못함
• 다이제스트 인증은 기본 인증과 호환되는 대체재로서 개발
• 널리 쓰이지는 않지만 개념은 보안트랜잭션의 구현에 유용함

---

#다이제스트 인증의 개선점

특징

• 비밀번호를 네트워크를 통해 평문으로 전송하지 않음
• 인증 체결을 가로채서 재현하지 못함
• 구현 방법에 따라 메시지 내용 위조 방지 가능

단방향 다이제스트

• 다이제스트(요약)는 단방향 함수로 동작, 무한 가지의 모든 입력값을 유한의 범위로 압축 변환
• MD5(메시지 다이제스트 #5), SHA(Secure Hash Algorithm)…
• 요약함수는 보통 cryptographic checksums로 불림, 단반향 해시 함수이거나 fingerprint function임

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

• 난스(nonce)라 불리는 자주 바뀌는 증표를 발급
• 다이제스트를 탈취하여 서버로 전송하는 해킹을 막기위한 방법
• 다이제스트는 특정 난스 값에 대해서만 유효

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

그림1. 다이제스트 인증 핸드셰이크

자료 출처: David Gourley and Brian Totty, "HTTP: The Definitive Guide (Definitive Guides)", O'Reilly, 2002

1. 서버는 난스값을 계산
2. 난스를 WWW-Authenticate 인증요구 메시지에 담아, 서버가 지원하는 알고리즘 목록과 함께 클라이언트에 전송
3. 클라이언트는 알고리즘 선택, 비밀번호와 그 외 데이터에 대한 요약 계산
4. 클라이언트는 Authorization 메시지에 요약을 담아 서버로 전송, 서버를 인증하려면 클라이언트를 난수를 보낼 수 있음
5. 서버는 요약, 알고리즘, 그외 보조데이터를 받아 요약을 검증함. 클라이언트가 서버에게 인증을 요구했다면 클라이언트 요약이 만들어 클라이언트에 전송. 다음번 난스를 클라이언트에게 미리 전송하기도 함

---

#요약(digest) 계산

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

다이제스트 알고리즘의 입력 값

H(d)	단방향 해시함수
KD(s,d)	요약함수. s는 secret, d는 data를 의미
A1	비밀번호 등 보안 정보를 담고 있는 데이터 덩어리
A2	요청 메시지의 비밀이 아닌 속성을 담고 있는 데이터 덩어리

H(d)와 KD(s,d) 알고리즘

• RFC2617에서 제안된 알고리즘은 MD5, MD5-sess(‘sess’는 세션을 의미)
• 만약 알고리즘이 정해지지 않았다면 MD5가 기본

KD 요약 함수는 콜론으로 연결된 비밀 데이터와 일반데이터의 MD5를 계산
H(<데이터>) = MD5(<데이터>)  

KD(<비밀>,<데이터>) = H(연결(<비밀>:<데이터>)

•  

보안 관련 데이터(A1)

사용자 이름, 비밀번호, 보호 영역, 난스와 같은 비밀 보호 정보로 이루어짐
MD5: A1 = <사용자>:<영역>:<비밀번호>

MD5-sess: A1 = MD5(<사용자>:<영역>:<비밀번호>):<난스>:<c난스>

•  

메시지 관련 데이터(A2)

• URL, 요청 메서드, 메시지 엔티티 본문과 같은 메시지 자체의 정보

qop(quality of protection)에 따라 A2의 두가지 사용법이 있음
정의되지 않음:  <요청메서드>:<uri 지시자 값>

auth:  <요청메서드>:<uri 지시자 값>

auth-int:  <요청메서드>:<uri 지시자 값>

•  

---

#보호수준(qop) 향상

• qop 필드는 WWW-Authenticate, Authorization, Authentication-Info에 모두 존재 가능
• qop 필드는 클라이언트와 서버가 어떤 보호 기법을 어느 정도 수준으로 사용할 수 있지 협상할 수 있게 허용

메시지 무결성 보호

• qop=”auth-int”면 메시지 무결성 보호가 적용
• auth-int의 경우 계산되는 H(엔티티 본문)은 메시지 본문의 해시가 아닌 엔티티 본문의 해시

---

#실제 상황에 대한 고려

다중 인증 요구

• 서버는 클라이언트에게 가능한 가능한 인증 요구를 보냄

오류 처리

• 다이제스트 인증에서, 지시자나 그 값이 적절하지 않거나 요구된 지시자가 빠진 경우 400 Bad Request가 절절한 응답임
• 인증서버는 반드시 uri 지시자가 가리키는 리소스가 요청줄에 명시된 리소스와 같음을 확인해야함
  다를 경우 이는 공격의 징후일 수 있으므로 로그를 남기는 것이 좋음

---

#보안에 대한 고려사항

• 헤더 부당 변경
• 재전송 공격
• 다중 인증 메커니즘
• 사전(dictionary) 공격
• 악의적인 프락시와 중간자 공격
• 선택 평문 공격
• 비밀번호 저장

---

#다이제스트 인증 기능의 구현을 위한 지원 데이터

WWW-Authenticate 지시자들

realm	사용자 이름과 비밀번호가 어디 사용될 것인지 알려주기 위해 사용자에게 보여질 문자열
nonce	401 응답이 만들어질 때마다 유일하게 생성되어야 하는 서버에 특화된 데이터 문자열
domain	보호될 공간을 정의한 따옴표로 감싸진 URI들의 공백으로 분리된 목록
opaque	서버에 의해 정의된 데이터의 문자열, 클라이언트는 같은 보호 공간의 URI에 대한 다음번 요청에서 Authorizaiton 허더에 이 값을 담아 반환
stable	클라이언트로부터의 이전 요청이 nonce 값이 신선하지 않아서 거부되었음을 의미하는 플래그
algorithm	다이제스트와 체크섬을 생성할 때 사용하는 알고리즘, 기본 값은 MD5
qop	선택적, 서버가 지원하는 보호 수준을 의미

Authorization 지시자들

username	특정 realm에서의 사용자 이름
realm	WWW-Authenticte 헤더에 담겨 클라이언트에게 넘겨진 releam
nonce	WWW- Authenticate 헤더에 담겨 클라이언트에게 넘겨진 nonce
uri	요청 URI에서의 URI, 프락시에 의해 요청이 변경될 수 있기 때문에 존재
response	다이제스트 값, 사용자가 비밀번호를 알고 있음을 증명
algorithm	다이제스트와 체크섬을 생성할 때 사용하는 알고리즘, 기본 값은 MD5
opaque	서버에 의해 정의된 데이터의 문자열, 같은 보호 공간의 URI에 대한 다음번 요청에서 값을 그대로 넣어서 반환
cnonce	qop 지시자가 보내진 경우만 포함. 메시지 무결성 보호를 제공
qop	클라이언트가 메세지에 적용한 “보호 수준”의 정도
nc	qop 지시자가 보낸 경우에만 포함. 클라이언트가 이 요청의 nonce값과 함께 보낸 요청들의 횟수 합계

Authentication-Info 지시자들

nextnonce	미래의 인증 응답 시에 클라이언트가 사용해주기를 서버가 원하는 nonce
qop	서버에 의해 응답에 적용된 ‘보호 수준”의 정도
rspauth	response auth를 의미. 선택적인 응답 다이제스트가 들어있으며 이를 이용해 상호 인증을 지원
cnonce	응답 대상인 클라이언트의 요청에 들어있는 값과 반드시 같아야 함
nc	응답 대상인 클라이언트 요청에 들어있는 값과 반드시 같아야 함

#추가 정보 RFC 2617,”HTTP Authentication: Basic and Digest Access Authentication”

14 HTTP 보안

https://moon-seung-chan.tistory.com/14

14.1 안전한 HTTP 만들기

• 대량 구매, 은행 업무, 보안 자료 접근을 위해서 보다 강력하고 중요한 트랜잭션을 위해서는, HTTP와 디지털 암호화 기술을 결합해야 한다.
• HTTP의 보안 버전은 효율적이고, 이식성이 좋아야 하고, 관리가 쉬워야 하며, 현실 세계의 변화에 대한 적응력이 좋아야 한다. 또한 사회와 정부의
  요구사항에도 충족해야 한다.
  서버 인증
• 클라이언트 인증
• 무결성
• 암호화
• 효율
• 편재성
• 괸리상 확장성
• 사회적 생존성
• 1) HTTPS

• 

•  

14.2 디지털 암호학

• SSL과 HTTPS에서 이용되는 암호 인코딩 기법에 대해 약간의 배경 지식을 알아본다.
  암호
• 키
• 대칭키 암호 체계
• 비대칭키 암호 체계
• 공개키 암호법
• 디지털 서명
• 디지털 인증서
• 1) 비밀 코드의 기술과 과학
• 2) 암호(Cipher)
• 3) 암호 기계
• 4) 키가 있는 암호
• 5) 디지털 암호
•  

14.3 대칭키 암호법

• 대칭키 암호에서, 발송자와 수신자 모두 토인을 위해 비밀 키를 똑같이 공유할 필요가 있다. 발송자는 공유된 비밀 키를 메시지를 암호화하고 그 결과인
  암호문을 수신자에게 발송하기 위해 사용한다.
• 수신자는 역시 암호문을 받은 뒤 같은 공유된 키를 사용하여 원래의 평문을 복원하기 위해 해독 함수를 적용한다.
• 잘 알려진 대칭키 암호 알고리즘으로는 DES, Triple-DES, RC2, RC4 등이 있다.
  1) 키 길이와 열거 공격(Enumeration Attack)
•  

공격 비용	40 비트 키	56 비트 키	64비트 키	80비트 키	128비트 키
100,000 $	2초	35 시간	1년	7만 년	10의 19승 Year
1,000,000 $	200밀리초	3.5시간	37일	7,000년	10의 18승 Year
10,000,00 $	20밀리초	21분	4일	700년	10의 17승 Year
100,000,000 $	2밀리초	2분	9시간	70년	10의 16승 Year
1,000,000,000 $	200mis	13초	1시간	7년	10의 15승 Year

• 
  2) 공유키 발급하기
•  

14.4 공개키 암호법

• 한 쌍의 호스트가 하나의 인코딩/디코딩 키를 사용하는 대신, 공개키 암호 방식은 두 개의 비대칭 키를 사용한다. 하나는 호스트의 메시지를 인코딩하기
  위한 것이며, 다른 하나는 그 호스트의 메시지를 디코딩하기 위한 것이다. 인코딩 키는 모두 공개되어 있지만 호스트만이 개인 디코딩 키를 가지고 있다.
• 키의 분리를 통해 메시지의 인코딩은 누구나 할 수 있도록 해주는 동시에, 메시지를 디코딩하는 능력은 소유자에게만 부여한다. 이는 노드가 서버로 안전하게
  메시지를 발송하는 것을 더 쉽게 해주는데, 이유는 서버의 공개 키만 있으면 되기 떄문이다.
  1) RSA
• 2) 혼성 암호 체계와 세션 키
•  

14.5 디지털 서명

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

14.6 디지털 인증서

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

• 

  
  2) X.509 v3 인증서

Certificate:

Data:

    Version: 3 (0x2)

    Serial Number:

        04:00:00:00:00:01:15:4b:5a:c3:94

Signature Algorithm: sha1WithRSAEncryption

    Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA

    Validity

        Not Before: Sep  1 12:00:00 1998 GMT

        Not After : Jan 28 12:00:00 2028 GMT

    Subject: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA

    Subject Public Key Info:

        Public Key Algorithm: rsaEncryption

            Public-Key: (2048 bit)

            Modulus:

                00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b:

                ...

            Exponent: 65537 (0x10001)

    X509v3 extensions:

        X509v3 Key Usage: critical

            Certificate Sign, CRL Sign

        X509v3 Basic Constraints: critical

            CA:TRUE

        X509v3 Subject Key Identifier: 

            60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B

Signature Algorithm: sha1WithRSAEncryption

     d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5:

•      ...
• X.509 기반 인증서에는 웹 서버 인증서, 클라이언트 이메일 인증서, 소프트웨어 사인코드(code-signing) 인증서를 비롯한 몇 가지 변종이 있다.

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

14.7 HTTPS 세부사항

• HTTP 프로토콜에 대칭, 비대칭 인증서 기반 암호 기법의 강력한 집합을 결합한 것이다.
• 무정부 상태의 분권화된 글로벌 인터넷 환경에서도 매우 안전한 동시에 매우 유연하고 관리하기 쉽게 만들어준다.
  1) HTTPS 개요
• 2) HTTPS 스킴
• 3) 보안 전송 셋업
  

  

  
  4) SSL 핸드셰이크
• 5) 서버 인증서
•  

6) 사이트 인증서 검사

• 사이트 인증서를 검사하는 과정은 날짜 검사, 서명자 신뢰도 검사, 서명 검사, 사이트 신원 검사를 포함한다.
  7) 가상 호스팅과 인증서
• 하나의 서버에 여러 호스트(가상 호스트)로 운영되면 까다로울 수 있다.

14.8 진짜 HTTPS 클라이언트

• SSL은 복잡한 바이너리 프로토콜이라 사용하는데 어려울 수 있다. 오픈 소스 라이브러리를 활용하는 것이 좋다.
  1) OpenSSL
• 2) 간단한 HTTPS 클라이언트
• 3) 단순한 OpenSSL 클라이언트 실행하기
•  

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

• SSL은 바이너리 프로토콜이다. 프락시는 암호화된 메시지를 받고 어리둥절할 것이다. 프락시는 메시지의 헤더에서 메시지가 어디로 전송되어야 하는지
  알아야 하는데 암호화된 메시지는 읽어낼수가 없다.이 때 HTTPS SSL 터널링 프로토콜을 사용한다.
• HTTP는 CONNECT라는 확장 메서드를 사용하여 어디로 갈지 명시 한다

CONNECT home.netscape.com:443 HTTP/1.0

• User-agent: Mozilla/1.1N
• 프락시는 이 CONNECT 메서드를 받으면 직접 대상으로 연결시켜주는 터널을 만들어 준다.