SSL/TLS 에서는 암호화 통신의 기반이 되는 인증서 관리가 매우 중요합니다. 인증서는 만료기간 (Expire date) 이 있으며 인증서의 생성, 폐지, 갱신 등이 이루어져 무결성이 항상 유지되어야 합니다. 이러한 무결성을 유지하기 위해 CRL, OCSP, OCSP Stapling 같은 기술이 만들어졌습니다. 그러면 이러한 기술은 왜 만들어졌으며 어떻게 동작하게 되는지 알아보도록 하겠습니다. 

 

1. CRL (Certificate Revocation List)

기존에는 CRL (Cerficate Revocation List) 를 이용하여 인증서의 무결성 (Validation) 여부를 확인하였습니다. CRL이란 인증서 폐기 목록 입니다. 다시말해 현재 사용중인 인증서가 만료된건지 정상인지를 판단 할 수 있는 신뢰 할 수 있는 인증서 폐기목록이라는 말이지요.

HTTPS로 접속을 시도한 후 클라이언트는 인증서에 기록된 CRL주소에서 CRL List를 다운로드 받아 인증서의 폐기여부를 확인하게 됩니다. 만약 인증서가 폐기되지 않았다면 인증서의 만료와 관련된 무결성이 확인이 되는 것이죠. 

하지만 CRL은 클라이언트에서 매우 큰 CRL (인증서 폐기목록) 을 모두 다운로드 받아 확인해야 하는 단점을 가지고 있습니다. 그렇기 때문에 처리시간이 매우 느리며 CA기관에서 상기 항목을 계속해서 갱신하고 클라이언트 또한 계속 갱신하여 확인해야 합니다. 

CRT의 동작방식은 아래와 같습니다.

  • HTTP 또는 LDAP을 이용, 인증서를 통해 교부받은 URL을 통하여 CRL을 요청합니다. 
  • CA는 요청을 받은 이후 CRL List (인증서 만료목록) 를 응답합니다. 
  • 브라우저는 CRL정보를 파싱하고 현재 접속하려는 사이트의 인증서가 CRL에 포함되어 있는지 점검합니다. (CRL에는 만료인증서에 대한 시리얼 정보가 포함되고 있으며, 체크하려는 인증서의 시리얼이 CRL에 포함되어 있는지 점검합니다.)

간단하게 말해 CRL은 인증서 폐지내역을 블랙리스트로 관리한다고 보시면 되겠습니다.

 

2. OCSP (Online Certificate Status Protocol)

OCSP는 RFC2560에서 소개되었으며 목적은 인증서의 상태를 실시간으로 체크하기 위한 프로토콜이라고 보시면 되겠습니다. OCSP는 인증서의 시리얼을 통하여 실시간으로 인증서의 만료여부를 CA 인증서 DB에 직접 요청합니다. 이렇게 OCSP는 실시간으로 인증서의 만료여부를 확인 할 수 있으며 CRL과 같이 불필요한 목록을 모두 받아 볼 필요가 없어 그 속도가 빠릅니다.

간단하게 말해 OCSP는 인증서 폐지내역을 화이트리스트로 관린한다고 보시면 되겠습니다. OCSP프로토콜은 인증서의 시리얼을 포함하여 CA기관에 인증서 만료여부를 요청하게 되며

OCSP서버는 요청을 받아 확인 후, 좋음 (good), 만료 (revoked), 알수 없음 (unknown) 의 세가지 값으로 응답하여 줍니다. 만약 인증서가 유효하지 못한 경우에는 error code를 응답해 주게 되고요.

인증서 상의 OCSP목록은 아래 항목에서 확인 할 수 있습니다.

 

3. OCSP Stapling (Online Certificate Status Protocol Stapling)

위에서 살펴본 바와 같이 OCSP는 CRL의 단점을 매우 많이 개선하였습니다. 하지만 OCSP도 단점이 있는데, OCSP는 모든 클라이언트들의 인증서의 만료여부 확인 요청을 모두 처리해 주어야 한다는 것이지요.

만약 웹서버로 수많은 HTTPS 요청이 발생할 경우, 각 클라이언트에서 OCSP 서버로의 요청도 HTTPS 요청만큼 발생하게 되는 것이죠. 이는 보안상 취약점과 함께 웹사이트가 느려지는 문제가 발생하게 되며, 만약 OCSP가 과부하되어 응답을 하지 못할 경우 false warning 메시지와 함께 유저가 강제로 접속하거나 접속을 끊도록 선택해야 하는 상황이 발생하여 Secure Connection을 보장 해 줄 수 없는 상태가 되는것이죠.

하여 이와 같은 문제를 개선하기 위해서 OCSP Stapling 이라는 기술이 만들어졌습니다.

위의 화면과 같이 클라이언트가 직접 OCSP를 통하여 인증서 만료여부를 확인하는 것이 아니라 서비스를 제공하는 웹서버에서 중간에게 OCSP를 통한 인증서 만료여부를 중계하는 것이죠. 실제 인증서 만료여부는 중간자인 웹서버가 OCSP서버와 확인하도록 되어 있고, 클라이언트는 웹서버 접속시 웹서버를 통하여 인증서 만료여부까지 확인 하는 것이죠.

따라서 OCSP 서버 (OCSP Responder) 는 쿼리수가 현저하게 적어질 것이며 자원을 보호 할 수 있는 것이죠.

 

4. OCSP Stapling (Online Certificate Status Protocol Stapling) 설정법

Nginx 서버의 경우 옵션 두개만 켜주면 됩니다. 

server
{
    listen 443 ssl;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    ssl_certificate /etc/ssl/bundle.crt;
    ssl_certificate_key /etc/ssl/your_domain_name.key;

    ssl_stapling on;
    ssl_stapling_verify on;
}

적용 후 재시작 하여 줍니다.

 

5. OCSP Stapling (Online Certificate Status Protocol Stapling) 적용여부 확인

수동으로 확인하는 방법과 SSL점검 툴을 이용하는 방법이 있습니다. CLI에서 수동으로 확인하는 방법은 아래와 같으며 웹서버에서  OCSP Response Status : successful (0x0) 으로 응답받으면 됩니다.

root@rsec:/rsec# openssl s_client -connect rsec.kr:443 -tls1 -tlsextdebug -status
CONNECTED(00000003)
TLS server extension "renegotiation info" (id=65281), len=1
0001 - <SPACES/NULS>
TLS server extension "EC point formats" (id=11), len=4
0000 - 03 00 01 02                                       ....
TLS server extension "session ticket" (id=35), len=0
TLS server extension "status request" (id=5), len=0
TLS server extension "heartbeat" (id=15), len=1
0000 - 01                                                .
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = rsec.kr
verify return:1
OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
    Produced At: Jul 27 08:17:00 2017 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
      Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
      Serial Number: 039F0CD3B93EA257049618EFE1BE63D62EDF
    Cert Status: good
    This Update: Jul 27 08:00:00 2017 GMT
    Next Update: Aug  3 08:00:00 2017 GMT

    Signature Algorithm: sha256WithRSAEncryption
         66:cd:24:ca:0a:5a:8c:69:b9:cc:20:1d:1b:bf:38:37:fe:81:
         11:3b:cd:2e:19:ae:f6:5f:46:c7:78:39:e6:21:1d:b1:ac:84:
         e7:fd:50:56:4a:52:ed:bf:9a:3b:86:f5:ce:c7:5b:88:26:42:
         28:49:2e:1f:b7:e6:ab:1b:ba:b6:4b:cb:bc:1e:d8:d6:62:cc:
         66:7c:e4:79:e6:83:e8:f6:0a:80:3a:be:32:22:70:85:3a:f7:
         87:a5:fb:19:cb:94:0f:d6:1a:80:68:84:1d:e6:b6:23:22:fe:
         19:10:1e:01:2a:34:89:30:86:c6:d4:fc:81:12:0a:c9:76:43:
         f5:cf:58:c0:cb:dc:a8:f9:d2:4f:f6:0f:32:31:38:da:2e:28:
         f3:56:2b:9b:86:59:57:22:cd:f4:32:48:2d:07:ca:9c:6e:df:
         41:c2:3b:ef:b2:9d:24:68:06:85:58:da:4c:a0:39:ea:0d:7e:
         df:39:e0:bd:b5:3e:0b:45:e6:2c:0f:78:bb:8f:4b:18:93:c2:
         07:24:8b:b3:df:d0:07:3b:d7:39:5b:5d:e2:66:8e:5a:f0:af:
         9f:88:a4:a5:0a:bd:9f:a0:89:57:01:e7:e5:68:2b:b9:55:c0:
         c5:88:68:c5:d3:8b:41:0e:6c:2d:3f:69:c6:12:11:80:c0:5a:
         df:3b:d7:d4
======================================

https://www.htbridge.com/ssl/ 와 같은 SSL점검툴을 이용하여 OCSP Stapling 이 적용상태인지 확인 합니다. 

 

6. 결론

인증서를 통하여 SSL암호화 통신을 할 때, 암호화 통신의 근거가 되는 인증서의 무결성 여부는 SSL/TLS 통신의 신뢰여부를 결정짓는 매우 중요한 부분입니다. 따라서 CRL, OCSP 등을 통하여 인증서의 만료 무결성을 검증 할 수 있도록 설계되었으며, 설계상 문제점들을 해결하기 위해 어떻게 발전해 왔는지 알아보기 위해 이렇게 포스팅 하였습니다.

그런데 설정은 딱 두줄이니까 좀 허무하네요. 하지만 트러블 슈팅은 항상 원리를 이해하고 있어야 쉽고 빠르게 문제를 파악하고 해결해 나갈 수 있는 것임으로 SSL/TLS의 인증서 만료무결성 확인을 상세하게 알아보았습니다.

읽어주셔서 감사합니다~~

There are currently no comments.