티스토리 뷰
보안을 하기 전에는 http를 https로 설정을 하기만 하면 해커들로부터의 침입을 차단하여 안전한 줄로만 알았다. 아마도 대부분의 사람들은 그렇게 생각을 할 수도 있을 것 같다. 그런데, 보안을 하면서 보니 https로 변경했다고 해서 해커들로부터 안전하다라고 볼수는 없다는 것을 알았다. 그리고, 웹에서 보안 기술은 오래되어 관련 자료도 상당히 많이 있고, 이에 대한 용어 설명 그리고, 실제로 적용하려면 어떻게 해야 되는지에 대한 예제를 보여주는 사이트도 상당히 많이 있었다.
그래서, 이번 블로그에서는 잊어버리기 전에 웹에 대한 보안 용어들을 다시 한번 더 정리해 보는 시간을 가져봤다.
SSL
SSL(Secure Socket Layer) 프로토콜은 처음에 Netscape사에서 웹서버와 브라우저 사이의 보안을 위해 만들어졌다. SSL은 Certificate Authority(CA)라 불리는 서드 파티로부터 서버와 클라이언트의 인증을 하는데 사용된다. 아래는 SSL이 어떻게 작동하는지에 대한 간단한 과정을 설명한 것이다.
1. [웹브라우저] SSL로 암호화된 페이지를 요청하게 된다. (일반적으로 https://가 사용된다)
2. [웹서버] Public Key를 인증서와 함께 전송한다.
3. [웹브라우저] 인증서가 자신이 신용있다고 판단한 CA(일반적으로 trusted root CA라고 불림)로부터 서명된 것인지 확인한다. 또한 날짜가 유효한지, 그리고 인증서가 접속하려는 사이트와 관련되어 있는지 확인후 암호화키를 비롯한 url 및 http 데이터를 암호화해서 전송한다.
4. [웹서버,웹브라우저] 웹브라우저와 웹서버는 Private Key를 사용해서 세션을 복호화하고 암호화된 세션을 통해 통신을 한다.
SSL이 무엇을 말하는지 의미를 한번 살펴보았다. 이전에는 SSL 프로토콜 하나만 존재하는 줄 알았는데 그게 아니였다. 우리가 알고 있는 SSL은 TLS 1.2 혹은 1.3을 의미하는 것이며, 보안에서는 SSL 버전2와 버전3이 존재를 하고 이를 사용하지 말라고 대부분의 보안 가이드에 권장을 하고 있다. 그러면, 왜 사용을 못하게 하는것일까? 분명히 그 이유가 있을 것이다. 그래서, 해당 이유를 찾아보았다.
SSLv2을 권장하지 않는 이유
SSLv2는 1995년 2월에 출시된 프로토콜로 상당히 노후된 프로토콜이다. 그래서 많은 취약점들이 나타났고 이제는 어떠한 웹 환경에서도 활용이 적합하지 않다. 그 중 하나가 DROWN(Decrypting RSA with Obsolete and Weakened eNcryption)이라는 해커의 공격이다.
DROWN 해커는 중간자(man-in-the-middle, MITM) 위치에서, 목표 서버에 다수의 SSLv2 연결을 만든다. 이때 해커가 다수의 SSLv2 연결을 이루어낼 경우, 서버를 공격하여 세션 키 값을 알아낼 수 있다. 이 키 값을 이용해, 어떤 통신 내용이든 복호화 할 수 있다.
그래서 다음 2가지 요건 중 1가지라도 충족된다면, 서버는 DROWN 공격에 노출되게 된다.
1. SSLv2 요청을 지원하는 경우
2. 개별 키가 SSLv2 연결을 허용하는 서버에서 사용될 경우 (최신버전 SSL/TLS 프로토콜 포함)
DROWN을 입증한 연구진은 HTTPS 서버에서 SSLv2 연결을 허용할 경우 중간자 공격이 가능해지고, 해커는 SSLv2 연결을 활용하여 서버에 침투를 한다. 그리고, 세션 키를 찾아내어, TLS 트래픽마저 복호화를 할 수 있다. DROWN은 인터넷 보안을 위한 필수 암호화 프로토콜인 SSL 및 TLS에 의존하는 HTTPS 및 기타 서비스에 영향을 미치는 심각한 취약점이다. 이 프로토콜을 사용하면 인터넷을 사용하는 모든 사람이 웹을 탐색하고, 전자 메일을 사용하고, 온라인 쇼핑을하고, 제 3자가 통신을 읽을 수 없는 인스턴트 메시지를 보낼 수 있다.
또한 DROWN은 공격자가 암호, 신용 카드 번호, 영업 비밀 또는 재무 데이터를 포함하여 암호화를 해제하고 민감한 통신을 읽거나 훔칠 수 있도록 한다. 2016 년 3 월 공개 당시, 모든 HTTPS 서버의 33 %가 공격에 취약한 것으로 나타났다. 다행히도이 취약점은 현재 훨씬 덜 널리 퍼져 있으며, 2019 년 현재 SSL Labs는 HTTPS 서버의 1.2 %가 취약하다고 한다.
SSLv3을 권장하지 않는 이유
SSLv3.0은 설계된지 15년 가까이가 되었고 그동안 많은 종류의 취약점이 발견되어 더이상 안전하지않다. 그 중 가장 대표적인 이유가 바로 POODLE(Padding Oracle On Downgraded Legacy Encryption)이다.
Google의 보안 전문가들(Bodo Moller 외 2명)은 SSL 3.0의 설계상의 취약점과 이를 활용한 공격법 "POODLE (Padding Oracle On Downgraded Legacy Encryption)"에 대한 상세 보고서를 공개('14,10.14)했다. "POODLE"은 CBC모드 블록암호문에 대한 패딩 오라클 공격을 활용한 공격기법으로 TLS 연결 설정과정에서 하위버전인 SSL3.0으로 연결 수립을 유도한 뒤, 패딩 오라클 공격을 통해 암호화된 통신내용을 복호화하는 공격기법이다. "POODLE"에 대한 특별한 대응방안이 존재하지 않아서 SSL v3.0을 사용하지않는 것이 현재로써는 최선책이다.
※ SSL/TLS : 통신 과정에서 보안과 데이터 무결성을 제공하는 보안 프로토콜. 넷스케이프사에서 SSL을 개발 하여 업계표준으로 사용되다가 수정을 거쳐 TLS로 명칭을 변경하고 국제표준으로 채택됨
※ 패딩 오라클 공격 : 알고리즘 자체 취약성이 아니라 컴퓨터 동작 시간, 온도, 소리, 전자적 노이즈, 전력사용량 등 부가적인 현상을 공격 도구로 활용하는 사이드 채널 공격의 일종
TLS
TLS (Transport Layer Security)는 클라이언트와 서버간의 통신을 보호하고 암호화하기 위해 사용되는 암호화 프로토콜이다. 넷스케이프 커뮤니케이션스사가 개발한 SSL(Secure Sockets Layer)에 기반한 기술로, 국제 인터넷 표준화 기구에서 표준으로 인정받은 프로토콜로, 표준에 명시 된 정식 명칭은 TLS지만 SSL이라는 용어로 많이 사용되고 있다.
TLS 1.0은 1999년에 나온 프로토콜이며 TLS 1.1의 경우 2006년 공개 되었다. 물론 공개된지 오래 된 만큼 취약점이 많이 나온 상황이며, 2008년에 공개 된 TLS 1.2 에 비해 보안 알고리즘이 취약하여 Google, MS, Apple등은 좀 더 나은 보안을 위해 지원을 중단했다.
( TLS는 현재 1.0, 1.1, 1.2, 1.3(최신)으로 총4개의 버전이 있다. )
※ TLS1.0, TLS1.1은 POODLE 및 BEAST와 같은 다양한 공격에 취약!
► POODLE(Padding Oracle On Downgraded Legacy Encryption) 취약점
: 구식 암호화 기법을 악용할 수 있게 하는 프로토콜 다운그레이드 취약점
► BEAST(Browser Exploit Against SSL/TLS) 취약점
: 앤드 유저 브라우저에서 HTTPS의 쿠키들을 해독하고 효과적인 타킷의 세션을 하이제킹할 수 있는 취약점
TLS 1.2 and TLS 1.3
TLS 1.0 과 1.1 을 보안해 나온것이 바로 TLS 1.2 버전이다. 최근 대부분의 웹사이트에서는 TLS1.2 버전 이상을 사용하도록 권고하며, 대부분이 TLS 1.2가 설정되어 사용이 되고 있다. 그런데, 이 역시 2006도에 나온 프로토콜이기 때문에 점점 기존 취약점들에 약해지기 시작했다. 그래서, 최근 2017년에 나온 TLS 1.3를 사용하기 시작했고, 많은 브라우저들과 웹서버들이 이를 지원을 하기 시작했다. 따라서, 앞으로 웹서버에서 보안을 적용할 계획을 가지고 있다면 TLS 1.3을 사용해야 할 것이다. 또한, TLS 1.2는 300ms가 걸리는 반면 TLS 1.3은 200ms면 사용이 가능하므로 속도도 그만큼 빨라졌다고 볼 수 있다.
참조 링크
https://www.krcert.or.kr/data/trendView.do?bulletin_writing_sequence=22128
https://dokydoky.tistory.com/463
이렇게해서, 웹서비스에서 보안 관련 용어들을 살펴보았다. 물론 그럼에도 보안은 여전히 어려운듯 하다. 그러나, 많은 사람들이 보안 관련 글을 공유하고 실제로 어떻게 적용을 하면 되는지, 적용을 했다면 어떻게 검증하는지에 대한 글들은 검색을 통해서 쉽게 확인할 수 있다. 따라서, 마음만 먹으면 얼마든지 관련 자료들을 검색하고 알아갈 수 있다고 생각한다.
'OpenStack' 카테고리의 다른 글
보안 그리고 암호화 알고리즘 (3) | 2019.10.04 |
---|---|
How to operate containerized OpenStack (1) | 2019.10.02 |
OpenStack Container (1) | 2019.06.07 |
How to design OpenStack for Security (0) | 2019.05.28 |
Octavia Amphora Instance (0) | 2019.05.10 |
- Total
- Today
- Yesterday
- Redhat
- cpu
- neutron
- Network
- 세미나
- NOVA
- 클라우드
- 컨테이너
- 네트워크
- 설치
- 하둡
- 레드햇
- 오픈스택
- 우분투
- Java
- Swift
- 김미경
- 쿠버네티스
- sdn
- 후기
- Python
- 뉴트론
- install
- openstack
- 파이썬
- command
- 명령어
- OVN
- 오픈쉬프트
- ubuntu
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |