.jpg)
.jpg)
HTTPS 보안 품질 테스트 결과, 총 31개 기업 중 68%에서 매우 취약한 HTTPS 사용
[보안뉴스=박형근 시큐리티플러스 대표] 지난 기고에서 웹 데이터의 무결성, 보안성, 그리고 미래 인터넷의 준비를 위해 HTTPS를 필수로 사용하자(지난 글 다시 보기)고 했다. 그러면 과연 HTTPS에 대한 투자, 즉 HTTPS를 적용만 한다면 원하는 목표를 달성할 수 있을까?
시큐리티플러스에서는 이러한 의문에 대한 해답을 찾기 위해 국내 기업들 가운데서 HTTPS를 사용하고 있는 웹 서비스에 대한 보안 테스트를 수행했다. 아쉽게도 아직까지 국내 기업들 중에는 서비스 전반에 걸쳐 혹은 HTTPS만으로 서비스하고 있는 기업을 쉽게 찾을 수 없었다.
HTTPS 보안 품질 테스트 결과, 대상으로 선정된 은행, 포털, 병원, 카드, 증권, 보험사 등 총 31개 기업 중 68%에 해당 되는 21개 기업에서 잘못된 설정으로 인해 매우 취약한 HTTPS를 사용하고 있었다.
HTTPS의 잘못된 설정 중 가장 많은 취약점은 RC4 암호화를 사용하는 것이며, 다음은 TLS1.2 프로토콜을 사용하지 않는 것과 취약한 SSL v3 혹은 SSL v2 프로토콜을 사용하는 것이었다. 반면에 국민은행, 우리은행, SC은행, 더케이저축은행, 국민카드, 롯데카드, 삼성카드, 신한카드 등의 기업에서는 취약하지 않은 HTTPS 프로토콜 운영을 하고 있어 모범적이었다.
RC4는 1987년 RSA시큐리티의 로널드 라이베스트(Ron Rivest)에 의해 개발된 스트림 암호로 1995년부터 SSL의 표준 암호화 프로토콜이다. RC4 알고리즘에 대해서는 많은 다양한 취약점이 보고되고 알려졌다. RC4 암호를 깨기 위해서는 단지 226 개의 세션이나 13X230개의 암호가 요구되어 현재로써는 SSL 세션을 위한 충분한 수준의 보안을 제공한다고 볼 수 없다. 결국 RFC 7465 에서는 모든 버전의 SSL/TLS 암호화 통신에서 RC4 암호의 사용을 금지했다.
다음으로 TLS 1.2는 SSL 버전 3로부터 업그레이드된 TLS 버전 1.0, 그로부터 다시 업그레이드된 TLS 버전 1.1에서 2008년도에 다시 TLS 버전 1.2로 업그레이드된 프로토콜이다. 이전과 달라진 부분은 MD5-SHA1 서명 알고리즘에서 SHA-256으로 바뀌었고, AES(Advanced Encryption Standard) 암호가 추가되었다. 현재로써는 가장 권장되는 암호화 통신 프로토콜이며, TLS 버전 1.3이 개발 중에 있다.
마지막으로 취약한 SSL 버전 3 혹은 SSL 버전 2 프로토콜을 사용하는 것이다. TLS 이전의 암호화 통신 프로토콜로 넷스케이프 사에서 개발되어 SSL 버전 2는 1995년에, SSL 버전 3는 1996년에 발표되었다. 그러나 SSL 버전 3는 2014년 SSL의 모든 블록 암호에 영향을 주는 푸들(POODLE) 공격의 취약한 것으로 밝혀졌으며, 앞서 지적한 RC4 암호의 사용으로 인해 쉽게 암호가 깨질 수 있어 2011년에 RFC 6176에 의해 SSL 버전 2가, 그리고 2015년에는 RFC 7568에 의해 SSL 버전 3가 사용 금지되었다.
각 웹 서버의 SSL/TLS 구성 방법에 따라 다르겠으나, 하나의 예로써 아파치 웹 서버를 예를 들면, 취약한 SSL 버전 3 혹은 SSL 버전 2 프로토콜의 사용을 금지하고, 권장되는 TLS 프로토콜, 특히 TLS 1.2 프로토콜 사용을 위해서는 SSL 설정 파일(참조 /etc/httpd/conf.d/ssl.conf)에서 아래와 같이 설정한다.
또한, 취약한 RC4 블록 암호나, 취약한 MD5 혹은 SHA1 서명 알고리즘의 사용을 금지하고, 권장되는 블록 암호 및 서명 알고리즘의 사용을 정의하기 위해서는 마찬가지로 SSL 설정 파일에서 아래와 같이 설정한다.
추가적으로 아파치 웹 서버가 강도 높은 암호화 연결 시도를 먼저 하도록 아래 옵션을 사용할 것을 권장한다.
다양한 웹 서버에서 유사한 설정을 지원하고 있으니, 웹 서버의 공급회사에 문의해 강도 높은 HTTPS 설정을 할 수 있다.
이렇게 설정된 HTTPS의 강도를 테스트하기 위해서 다양한 무료 공개 웹 서비스들과 유틸리티 서비스를 사용할 수 있다. 필자는 간편하게 사용할 수 있는 Qualys SSL Labs의 SSL Server Test (https://www.ssllabs.com/ssltest/analyze.html)를 사용해 볼 것을 추천한다. 이와 함께 다양한 SSL 및 TLS의 알려진 공격과 취약점에 대해서 정리된 RFC 7457 (https://tools.ietf.org/html/rfc7457) 표준 문서도 한 번 읽어 보길 권한다.
어렵게 보안 투자를 하고도 원하는 목표를 달성할 수 없다면 이처럼 안타까운 일이 없을 것이다. 모든 투자에 있어 반드시 달성해야 할 목표가 있고, 그 목표를 달성하기 위해 변화 관리와 품질 관리가 필요하다. 이제 보안에 있어서도 단순히 기술 도입뿐만 아니라 운영과 보안 품질에 있어서도 지속적으로 관심을 갖고 관리해야 할 시점이다.
[글_ 박형근 시큐리티플러스 대표(securityplus@securityplus.or.kr)]
[보안뉴스=박형근 시큐리티플러스 대표] 지난 기고에서 웹 데이터의 무결성, 보안성, 그리고 미래 인터넷의 준비를 위해 HTTPS를 필수로 사용하자(지난 글 다시 보기)고 했다. 그러면 과연 HTTPS에 대한 투자, 즉 HTTPS를 적용만 한다면 원하는 목표를 달성할 수 있을까?
시큐리티플러스에서는 이러한 의문에 대한 해답을 찾기 위해 국내 기업들 가운데서 HTTPS를 사용하고 있는 웹 서비스에 대한 보안 테스트를 수행했다. 아쉽게도 아직까지 국내 기업들 중에는 서비스 전반에 걸쳐 혹은 HTTPS만으로 서비스하고 있는 기업을 쉽게 찾을 수 없었다.
HTTPS 보안 품질 테스트 결과, 대상으로 선정된 은행, 포털, 병원, 카드, 증권, 보험사 등 총 31개 기업 중 68%에 해당 되는 21개 기업에서 잘못된 설정으로 인해 매우 취약한 HTTPS를 사용하고 있었다.
HTTPS의 잘못된 설정 중 가장 많은 취약점은 RC4 암호화를 사용하는 것이며, 다음은 TLS1.2 프로토콜을 사용하지 않는 것과 취약한 SSL v3 혹은 SSL v2 프로토콜을 사용하는 것이었다. 반면에 국민은행, 우리은행, SC은행, 더케이저축은행, 국민카드, 롯데카드, 삼성카드, 신한카드 등의 기업에서는 취약하지 않은 HTTPS 프로토콜 운영을 하고 있어 모범적이었다.
RC4는 1987년 RSA시큐리티의 로널드 라이베스트(Ron Rivest)에 의해 개발된 스트림 암호로 1995년부터 SSL의 표준 암호화 프로토콜이다. RC4 알고리즘에 대해서는 많은 다양한 취약점이 보고되고 알려졌다. RC4 암호를 깨기 위해서는 단지 226 개의 세션이나 13X230개의 암호가 요구되어 현재로써는 SSL 세션을 위한 충분한 수준의 보안을 제공한다고 볼 수 없다. 결국 RFC 7465 에서는 모든 버전의 SSL/TLS 암호화 통신에서 RC4 암호의 사용을 금지했다.
다음으로 TLS 1.2는 SSL 버전 3로부터 업그레이드된 TLS 버전 1.0, 그로부터 다시 업그레이드된 TLS 버전 1.1에서 2008년도에 다시 TLS 버전 1.2로 업그레이드된 프로토콜이다. 이전과 달라진 부분은 MD5-SHA1 서명 알고리즘에서 SHA-256으로 바뀌었고, AES(Advanced Encryption Standard) 암호가 추가되었다. 현재로써는 가장 권장되는 암호화 통신 프로토콜이며, TLS 버전 1.3이 개발 중에 있다.
마지막으로 취약한 SSL 버전 3 혹은 SSL 버전 2 프로토콜을 사용하는 것이다. TLS 이전의 암호화 통신 프로토콜로 넷스케이프 사에서 개발되어 SSL 버전 2는 1995년에, SSL 버전 3는 1996년에 발표되었다. 그러나 SSL 버전 3는 2014년 SSL의 모든 블록 암호에 영향을 주는 푸들(POODLE) 공격의 취약한 것으로 밝혀졌으며, 앞서 지적한 RC4 암호의 사용으로 인해 쉽게 암호가 깨질 수 있어 2011년에 RFC 6176에 의해 SSL 버전 2가, 그리고 2015년에는 RFC 7568에 의해 SSL 버전 3가 사용 금지되었다.
각 웹 서버의 SSL/TLS 구성 방법에 따라 다르겠으나, 하나의 예로써 아파치 웹 서버를 예를 들면, 취약한 SSL 버전 3 혹은 SSL 버전 2 프로토콜의 사용을 금지하고, 권장되는 TLS 프로토콜, 특히 TLS 1.2 프로토콜 사용을 위해서는 SSL 설정 파일(참조 /etc/httpd/conf.d/ssl.conf)에서 아래와 같이 설정한다.
또한, 취약한 RC4 블록 암호나, 취약한 MD5 혹은 SHA1 서명 알고리즘의 사용을 금지하고, 권장되는 블록 암호 및 서명 알고리즘의 사용을 정의하기 위해서는 마찬가지로 SSL 설정 파일에서 아래와 같이 설정한다.
추가적으로 아파치 웹 서버가 강도 높은 암호화 연결 시도를 먼저 하도록 아래 옵션을 사용할 것을 권장한다.
다양한 웹 서버에서 유사한 설정을 지원하고 있으니, 웹 서버의 공급회사에 문의해 강도 높은 HTTPS 설정을 할 수 있다.
이렇게 설정된 HTTPS의 강도를 테스트하기 위해서 다양한 무료 공개 웹 서비스들과 유틸리티 서비스를 사용할 수 있다. 필자는 간편하게 사용할 수 있는 Qualys SSL Labs의 SSL Server Test (https://www.ssllabs.com/ssltest/analyze.html)를 사용해 볼 것을 추천한다. 이와 함께 다양한 SSL 및 TLS의 알려진 공격과 취약점에 대해서 정리된 RFC 7457 (https://tools.ietf.org/html/rfc7457) 표준 문서도 한 번 읽어 보길 권한다.
어렵게 보안 투자를 하고도 원하는 목표를 달성할 수 없다면 이처럼 안타까운 일이 없을 것이다. 모든 투자에 있어 반드시 달성해야 할 목표가 있고, 그 목표를 달성하기 위해 변화 관리와 품질 관리가 필요하다. 이제 보안에 있어서도 단순히 기술 도입뿐만 아니라 운영과 보안 품질에 있어서도 지속적으로 관심을 갖고 관리해야 할 시점이다.
[글_ 박형근 시큐리티플러스 대표(securityplus@securityplus.or.kr)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
민세아기자 기사보기
[2024-11-22] 
.jpg)
.jpg)
.jpg)
.jpg)
