2020.08.14

SSL 및 TLS 인증서를 관리하고 추적하는 4가지 모범 사례

Susan Bradley | CSO
대다수 사람은 보안 소켓 계층(Secured Sockets Layer, SSL)과 전송 계층 보안(Transport Layer Security, TLS)을 당연하게 생각한다. 그러나 시간이 지남에 따라 SSL과 TLS 인증서의 이용은 극적으로 변화해왔다. 과거에는 보안 트랜잭션을 취급하는 웹사이트만이 SSL 인증서에 의한 보호를 제공했다. 현재 검색 엔진들은 모든 것이 인증서로 보호되도록 요구한다. 
 
ⓒ Getty Images Bank

해커는 SSL의 약점을 이용해 인증 정보에 액세스했다. 따라서 불안전한 SSL 프로토콜은 폐기되고 좀 더 안전한 프로토콜에 자리를 내주었다. 대다수 사람은 푸들(Padding Oracle On Downgraded Legacy Encryption, POODLE) 취약점이 처음 공개됐을 때 SSL에 약점이 있음을 알게 됐을 것이다. 푸들은 SSL 3.0이 ‘블록 암호 모드 패딩’을 취급하는 방식에 결함이 있음을 드러냈다. CISA(Certified Information Systems Auditor) 공지는 이를 다음과 같이 지적했다. 

SSL 3.0은 낡은 암호화 표준이고, 대개 TLS에 의해 대체됐지만, 대다수 SSL/TLS 구현은 원활한 사용자 경험을 위해 SSL 3.0과의 하위 호환성을 유지하며 구형 시스템과 연동한다. 클라이언트와 서버 측이 모두 한가지 TLS 버전을 지원하더라도, SSL/TLS 프로토콜 스위트는 프로토콜 버전 협상을 허용한다(이는 ‘다운그레이드 댄스’라고도 불린다). 푸들 공격은 보안 접속 시도가 실패할 때 서버가 SSL 3.0 등 구식 프로토콜로 회귀한다는 사실을 악용한다. 접속 실패를 유발할 수 있는 해커라면 SSL 3.0의 이용을 강제하며 새로운 공격을 시도할 수 있다.

푸들 이전에는 비스트(BEAST)가 있었다. 이는 SSL 공격의 일종이고, 한 HTTPS 세션 상에서 ‘블록 단위 선택 경계 공격(Block wise Chosen Boundary Attack, BCBA)'을 통해 평문 HTTP 헤더를 입수하는 ‘중간자 공격(Man-In-the-Middle Attack, MITM)'을 가능케 한다. 이 두 SSL 공격의 경우, 권장되는 해법은 보다 안전한 암호 스위트로 이동하는 것이었다. 이 외에도 SSL 공격에는 드라운(DROWN), 하트블리드(HeartBleed) 등이 있다. 

여기서는 SSL 및 TLS 인증서에 결부된 위험을 최소화할 수 있는 몇 가지 팁을 소개한다.

 
SSL 프로토콜 검토 

일부 툴은 내부 및 외부 사용자에게 노출된 SSL을 검토할 수 있게 해준다. 다만 가장 쉬운 것은 SSL 서버 테스트다. 테스트하고 싶은 웹사이트 주소를 입력하면 약점을 지적하는 점수 카드가 반환된다. 
 
‘A’ 점수를 목표로 하라. ‘A’를 받았다 하더라도 보안 프로토콜 지원을 향상시키기 위해 앞으로 취해야 할 조치들을 검토해야 한다. 
 


SSL 설정 검토

IIS크립토(IIS Crypto)는 모범 사례를 위해 웹사이트를 검토하는 데 사용할 수 있는 우수한 툴이다. 사용자는 인증서 설정을 검토하고 수정해 설정을 좀 더 안전하게 만들 수 있다. 예를 들어 SSL 2.0, 3.0, MD5, 3DES 같은 불안전한 프로토콜을 자동으로 중지시키는 식이다. 또한 PCI 컴플라이언스나 보편적 모범 사례에 대한 리뷰도 제공한다. 당장 시간을 할애해 회사 전반의 인증서 지원을 검토하고, 아울러 SSL 인증서 갱신 프로세스도 검토한다.

 
SSL 인증 갱신 프로세스 검토 

과거에는 웹사이트와 여타 구현에서 여러 해 동안 쓰인 인증서를 갱신할 수 있었다. 지금은 398일이 넘는 인증서를 입수할 수 없다. 기간이 짧아진 이유는 무엇일까? 애플이 365일에다가 갱신 유예 기간을 더한 기간보다 오래된 SSL 인증서를 사파리 브라우저에서 신뢰하기 않기로 결정했기 때문이다.
 
따라서 SSL 인증서 만료일을 관리하고 추적하는 프로세스 또는 절차가 마련되어 있어야 한다. ‘스태거드 갱신 프로세스(staggered renewal process)'를 채택할 수도 있고, 아니라면 인증서를 갱신하고 키를 교체하도록 설정된 자동 프로세스를 이용할 수도 있다. 무료 SSL 인증 사업자인 렛스 인크립트(Let’s Encrypt)는 단 90일 기간의 인증서를 제공한다. 지나치게 짧아 보이지만, 인증서를 자동으로 갱신할 수 있는 프로세스가 마련되어 있다. 


윈도우 및 애플리케이션을 위한 인증서를 잊지 말라 

애플리케이션들 역시 SSL 및 TLS 인증서를 빈번하게 이용한다. 아직도 TLS 1.0 및 1.1을 사용 중이라면 코로나19 팬데믹은 이들 두 프로토콜을 폐기하려는 계획에 영향을 줬다. 오피스 365의 경우 마이크로소프트는 TLS 1.0 및 1.1을 2020년 초에 단계적으로 배제할 계획이었다. 그러나 이는 2020년 10월까지로 연장되었다. 

구형 플랫폼이라면 보다 최근의 TLS 프로토콜을 지원하는 패치를 찾아야 한다. 예를 들어 아직도 윈도우 7을 사용한다면 RDP, WinHTTP, .NET 상에서 TLS 2.0을 지원하는 일부 패치가 나와 있다. 따라서 이보다 취약한 프로토콜을 중지시킬 수 있다. 구형 셰어포인트 플랫폼이라면 TLS 1.2를 지원하기 위한 패칭과 조정이 필요하다. 구식 플랫폼들이 TLS 1.2를 지원할 수 있는지 미리 파악해야 한다. 그 후 프로토콜을 중지시킨다면 비즈니스 니즈에 영향을 주지 않을 수 있다. 

예를 들어 ‘비즈니스 서버 2015를 위한 스카이프 내 TLS 1.0/1.1 중지시키기(Disable TLS 1.0/1.1 in Skype for Business Server 2015)’ 설명서 페이지에는 TLS 1.0/1.1을 중지시키면 작동하지 않을 애플리케이션의 목록이 있다. 

2017년 마이크로소프트는 ‘TLS 1.0 문제 해결하기(Solving the TLS 1.0 Problem)’라는 백서를 제작했고, 백서는 TLS 1.0 폐기 계획을 다음과 같이 소개했다.
 
  • 코드 분석을 수행해 하드코드 방식의 TLS 1.0 인스턴스를 검색/교정(또는 이보다 오래된 TLS/SSL 버전의 인스턴스)
  • 네트워크 엔드포인트를 스캔하고 트래픽을 분석해 TLS 1.0이나 이보다 오래된 프로토콜을 이용하는 운영체제를 식별 
  • TLS 1.0이 꺼진 상태에서 전체 애플리케이션 스택에 걸쳐 종합 회귀 테스팅을 시행
  • 구형 운영체제 및 개발 라이브러리/프레임워크를 TLS 1.2와의 협상 기능을 갖춘 버전으로 마이그레이션 
  • 업무에 쓰이는 운영체제 전반에 걸쳐 호환성 테스팅을 수행해 TLS 1.2 지원 문제를 식별 
  • 사업 파트너 및 고객과 공조하며 이들에게 TLS 1.0 폐기 조치를 고지 
  • TLS 1.0을 중지시켰을 때 상호운용성을 상실하는 클라이언트를 이해 

백서에서 지적했듯이 다음의 프로토콜은 다양한 운영체제에서 지원한다.



각 운영체제에서, SSL 버전은 최하위의 지원 및 작동 프로토콜과 연결된다. 기본값으로 TLS 1.2와 연결하려면 하위 프로토콜을 중지시켜야 한다. 클라이언트 구현은 퀄리스(Qualys) 사이트에서 테스트할 수 있다. 네트워크가 FIPS 모드를 요구하지만 TLS 1.0/1.1 또한 폐기하고 싶다면 다음의 단계를 이행한다. 
 
  • 원치 않는 TLS 버전에 대해 ‘켜기’를 ‘0’으로 설정함으로써 레지스트리를 통해 TLS 버전을 구성한다. 
  • 그룹 정책이나 파워셸을 통해 커브 25519를 중지시킨다(서버 2016으로 한정).
  • 연관 FIPS 간행물에 의해 허용되지 않는 알고리즘을 이용하는 암호화 스위트를 모두 중지시킨다. 서버 2016의 경우 이는 RC4, PSK, NULL 암호를 중지시키는 수단이다(기본 설정이 유효한 경우에 한함).  
  • 네트워크와 컴퓨터 자산이 앞으로의 변화와 TLS 1.3 시행에 의해 어떻게 영향을 받을 것인지 검토한다. editor@itworld.co.kr 


2020.08.14

SSL 및 TLS 인증서를 관리하고 추적하는 4가지 모범 사례

Susan Bradley | CSO
대다수 사람은 보안 소켓 계층(Secured Sockets Layer, SSL)과 전송 계층 보안(Transport Layer Security, TLS)을 당연하게 생각한다. 그러나 시간이 지남에 따라 SSL과 TLS 인증서의 이용은 극적으로 변화해왔다. 과거에는 보안 트랜잭션을 취급하는 웹사이트만이 SSL 인증서에 의한 보호를 제공했다. 현재 검색 엔진들은 모든 것이 인증서로 보호되도록 요구한다. 
 
ⓒ Getty Images Bank

해커는 SSL의 약점을 이용해 인증 정보에 액세스했다. 따라서 불안전한 SSL 프로토콜은 폐기되고 좀 더 안전한 프로토콜에 자리를 내주었다. 대다수 사람은 푸들(Padding Oracle On Downgraded Legacy Encryption, POODLE) 취약점이 처음 공개됐을 때 SSL에 약점이 있음을 알게 됐을 것이다. 푸들은 SSL 3.0이 ‘블록 암호 모드 패딩’을 취급하는 방식에 결함이 있음을 드러냈다. CISA(Certified Information Systems Auditor) 공지는 이를 다음과 같이 지적했다. 

SSL 3.0은 낡은 암호화 표준이고, 대개 TLS에 의해 대체됐지만, 대다수 SSL/TLS 구현은 원활한 사용자 경험을 위해 SSL 3.0과의 하위 호환성을 유지하며 구형 시스템과 연동한다. 클라이언트와 서버 측이 모두 한가지 TLS 버전을 지원하더라도, SSL/TLS 프로토콜 스위트는 프로토콜 버전 협상을 허용한다(이는 ‘다운그레이드 댄스’라고도 불린다). 푸들 공격은 보안 접속 시도가 실패할 때 서버가 SSL 3.0 등 구식 프로토콜로 회귀한다는 사실을 악용한다. 접속 실패를 유발할 수 있는 해커라면 SSL 3.0의 이용을 강제하며 새로운 공격을 시도할 수 있다.

푸들 이전에는 비스트(BEAST)가 있었다. 이는 SSL 공격의 일종이고, 한 HTTPS 세션 상에서 ‘블록 단위 선택 경계 공격(Block wise Chosen Boundary Attack, BCBA)'을 통해 평문 HTTP 헤더를 입수하는 ‘중간자 공격(Man-In-the-Middle Attack, MITM)'을 가능케 한다. 이 두 SSL 공격의 경우, 권장되는 해법은 보다 안전한 암호 스위트로 이동하는 것이었다. 이 외에도 SSL 공격에는 드라운(DROWN), 하트블리드(HeartBleed) 등이 있다. 

여기서는 SSL 및 TLS 인증서에 결부된 위험을 최소화할 수 있는 몇 가지 팁을 소개한다.

 
SSL 프로토콜 검토 

일부 툴은 내부 및 외부 사용자에게 노출된 SSL을 검토할 수 있게 해준다. 다만 가장 쉬운 것은 SSL 서버 테스트다. 테스트하고 싶은 웹사이트 주소를 입력하면 약점을 지적하는 점수 카드가 반환된다. 
 
‘A’ 점수를 목표로 하라. ‘A’를 받았다 하더라도 보안 프로토콜 지원을 향상시키기 위해 앞으로 취해야 할 조치들을 검토해야 한다. 
 


SSL 설정 검토

IIS크립토(IIS Crypto)는 모범 사례를 위해 웹사이트를 검토하는 데 사용할 수 있는 우수한 툴이다. 사용자는 인증서 설정을 검토하고 수정해 설정을 좀 더 안전하게 만들 수 있다. 예를 들어 SSL 2.0, 3.0, MD5, 3DES 같은 불안전한 프로토콜을 자동으로 중지시키는 식이다. 또한 PCI 컴플라이언스나 보편적 모범 사례에 대한 리뷰도 제공한다. 당장 시간을 할애해 회사 전반의 인증서 지원을 검토하고, 아울러 SSL 인증서 갱신 프로세스도 검토한다.

 
SSL 인증 갱신 프로세스 검토 

과거에는 웹사이트와 여타 구현에서 여러 해 동안 쓰인 인증서를 갱신할 수 있었다. 지금은 398일이 넘는 인증서를 입수할 수 없다. 기간이 짧아진 이유는 무엇일까? 애플이 365일에다가 갱신 유예 기간을 더한 기간보다 오래된 SSL 인증서를 사파리 브라우저에서 신뢰하기 않기로 결정했기 때문이다.
 
따라서 SSL 인증서 만료일을 관리하고 추적하는 프로세스 또는 절차가 마련되어 있어야 한다. ‘스태거드 갱신 프로세스(staggered renewal process)'를 채택할 수도 있고, 아니라면 인증서를 갱신하고 키를 교체하도록 설정된 자동 프로세스를 이용할 수도 있다. 무료 SSL 인증 사업자인 렛스 인크립트(Let’s Encrypt)는 단 90일 기간의 인증서를 제공한다. 지나치게 짧아 보이지만, 인증서를 자동으로 갱신할 수 있는 프로세스가 마련되어 있다. 


윈도우 및 애플리케이션을 위한 인증서를 잊지 말라 

애플리케이션들 역시 SSL 및 TLS 인증서를 빈번하게 이용한다. 아직도 TLS 1.0 및 1.1을 사용 중이라면 코로나19 팬데믹은 이들 두 프로토콜을 폐기하려는 계획에 영향을 줬다. 오피스 365의 경우 마이크로소프트는 TLS 1.0 및 1.1을 2020년 초에 단계적으로 배제할 계획이었다. 그러나 이는 2020년 10월까지로 연장되었다. 

구형 플랫폼이라면 보다 최근의 TLS 프로토콜을 지원하는 패치를 찾아야 한다. 예를 들어 아직도 윈도우 7을 사용한다면 RDP, WinHTTP, .NET 상에서 TLS 2.0을 지원하는 일부 패치가 나와 있다. 따라서 이보다 취약한 프로토콜을 중지시킬 수 있다. 구형 셰어포인트 플랫폼이라면 TLS 1.2를 지원하기 위한 패칭과 조정이 필요하다. 구식 플랫폼들이 TLS 1.2를 지원할 수 있는지 미리 파악해야 한다. 그 후 프로토콜을 중지시킨다면 비즈니스 니즈에 영향을 주지 않을 수 있다. 

예를 들어 ‘비즈니스 서버 2015를 위한 스카이프 내 TLS 1.0/1.1 중지시키기(Disable TLS 1.0/1.1 in Skype for Business Server 2015)’ 설명서 페이지에는 TLS 1.0/1.1을 중지시키면 작동하지 않을 애플리케이션의 목록이 있다. 

2017년 마이크로소프트는 ‘TLS 1.0 문제 해결하기(Solving the TLS 1.0 Problem)’라는 백서를 제작했고, 백서는 TLS 1.0 폐기 계획을 다음과 같이 소개했다.
 
  • 코드 분석을 수행해 하드코드 방식의 TLS 1.0 인스턴스를 검색/교정(또는 이보다 오래된 TLS/SSL 버전의 인스턴스)
  • 네트워크 엔드포인트를 스캔하고 트래픽을 분석해 TLS 1.0이나 이보다 오래된 프로토콜을 이용하는 운영체제를 식별 
  • TLS 1.0이 꺼진 상태에서 전체 애플리케이션 스택에 걸쳐 종합 회귀 테스팅을 시행
  • 구형 운영체제 및 개발 라이브러리/프레임워크를 TLS 1.2와의 협상 기능을 갖춘 버전으로 마이그레이션 
  • 업무에 쓰이는 운영체제 전반에 걸쳐 호환성 테스팅을 수행해 TLS 1.2 지원 문제를 식별 
  • 사업 파트너 및 고객과 공조하며 이들에게 TLS 1.0 폐기 조치를 고지 
  • TLS 1.0을 중지시켰을 때 상호운용성을 상실하는 클라이언트를 이해 

백서에서 지적했듯이 다음의 프로토콜은 다양한 운영체제에서 지원한다.



각 운영체제에서, SSL 버전은 최하위의 지원 및 작동 프로토콜과 연결된다. 기본값으로 TLS 1.2와 연결하려면 하위 프로토콜을 중지시켜야 한다. 클라이언트 구현은 퀄리스(Qualys) 사이트에서 테스트할 수 있다. 네트워크가 FIPS 모드를 요구하지만 TLS 1.0/1.1 또한 폐기하고 싶다면 다음의 단계를 이행한다. 
 
  • 원치 않는 TLS 버전에 대해 ‘켜기’를 ‘0’으로 설정함으로써 레지스트리를 통해 TLS 버전을 구성한다. 
  • 그룹 정책이나 파워셸을 통해 커브 25519를 중지시킨다(서버 2016으로 한정).
  • 연관 FIPS 간행물에 의해 허용되지 않는 알고리즘을 이용하는 암호화 스위트를 모두 중지시킨다. 서버 2016의 경우 이는 RC4, PSK, NULL 암호를 중지시키는 수단이다(기본 설정이 유효한 경우에 한함).  
  • 네트워크와 컴퓨터 자산이 앞으로의 변화와 TLS 1.3 시행에 의해 어떻게 영향을 받을 것인지 검토한다. editor@itworld.co.kr 


X