HTTP 와 HTTPS 의 차이점은 보안이 좀 더 강화되었다는 것이다.
현재 Lets encrypt 같은 무료 HTTPS 인증서부터 다양한 HTTPS 인증서 발급 방법이 있는데 그렇다면 그들의 차이점이 있을까? 이번 시간에는 HTTPS 등급에 대해서 알아보고자 한다.
사이트 HTTPS 인증서 확인
예시로 가져온 사이트는 애플이다.크롬 브라우저에서 https 가 인증되었다는 표시인 저 < 자물쇠 > 를 클릭하면 현재 도메인에서 사용되는 인증서의 종류에 대해서 확인할 수 있다.
인증서 뿐만아니라 js 허용 여부, 사용 쿠키에 대해서도 확인할 수 있다.
보는 바와 같이 발급자, 유효기간, 발급 대상 등의 인증서 정보를 확인할 수 있다.
인증서 등급 확인
그렇다면, 인증서에 등급을 매길 수 있을까?
https://www.ssllabs.com/ssltest/
이 사이트에 서 host anme 을 입력하면, 암호화 테스팅 후의 그레이드를 알려준다. ( 여기서 다루진 않겠지만, 이 외에도 다양한 ssl 테스트 사이트가 존재한다. ) 이 글을 보기로 마음먹었다면 자기 도메인 등급 검사 한번씩 꼭 하고 가자!
평가 항목은 Certificate,Protocol Support, Key Exchange, Cipher Strength 으로 나뉘는데 B 이상만 받아도 좋은 평가를 받았다라고 생각하면 될 듯하다. ( 구글, 네이버 등도 이 사이트에서 B 를 받았다. 검사 사이트는 A+ 이라고 하는데.. 최대 등급이 A+ 인데, 그 중에 B 정도면 양호하다고 해야하지 않을까. (TLS 1.2 를 지원하지 않는다는 이유로 B 를 받는 경우가 허다하다.)
하단에는 그레이딩에 대한 평가 이유에 대해서 간단하게 설명해준다.
https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide 를 참고 함.
인증서 평가 기준
유효한 인증서인지
신뢰성 없는 인증서( 잘 알려지지 않은 인증기관에서 서명하지 않은 인증서 )는 MITM (man in the middle) 공격을 방지하지 못하고, SSL 을 효과적✨으로 쓸모 없게 만든다.
혹은, 만료된 인증서 같은 다른 방식으로 잘못된 인증서는 신뢰성을 약화시키고, 장기적으로 인터넷 전체의 보안을 위협한다.
내 인증서가 0점이라구요?
다음 이유의 인증서들은 즉시 0점으로 이어진다. 내 도메인이 0점이라면 한 번씩은 다시 내 도메인 인증이 잘 되어있는지를 꼼꼼히 살펴보자.
- 도메인 이름 불일치
- 아직 유효하지 않은 인증서
- 인증서 만료
- 자체 서명 된 인증서 사용
- 신뢰할 수없는 인증서 사용 (알 수없는 CA 또는 기타 유효성 검사 오류)
- 해지 된 인증서 사용
- 안전하지 않은 인증서 서명 (MD2 또는 MD5)
- 안전하지 않은 키
프로토콜을 지원하는지
먼저 SSL 서버에서 지원하는 프로토콜을 살펴 본다. 예를 들어 SSL 2.0과 SSL 3.0에는 모두 알려진 약점이 있다. 서버는 여러 프로토콜을 지원할 수 있으므로 최종 점수에 도달하기 위해 다음 알고리즘을 사용한다.
각 버전 별 취약점은 https://dokydoky.tistory.com/464 에서 잘 다룬 것 같다.
(최고의 프로토콜 점수+최악의 프로토콜 점수)/2| 실험 계획안 | 점수 |
| SSL 2.0 | 0 % |
| SSL 3.0 | 80 % |
| TLS 1.0 | 90 % |
| TLS 1.1 | 95 % |
| TLS 1.2 | 100 % |
SSL 2.0 취약점
( 출처: https://dokydoky.tistory.com/464 )
메시지 인증에서 사용되는 key과 암호화에 사용되는 key가 동일하다
→ shared secret에서 각 key를 유도(derivation)해서 사용해야 한다.
메시지 인증에 사용되는 MAC이 "MD5(secret prefix + data)" 형태로 생성되어, length extension attack에 취약하다
SSL 3.0 취약점
안전하지 않은 key 유도 과정. master key의 반쪽은 MD5 해쉬함수에 의존하여, 해쉬 충돌(collision)에 안전하지 않다
키 교환을 지원하는지
키 교환은
- 인증을 수행해 한 당사자가 다른 당사자 신원 확인
- 세션 동안 사용할 사용할 비밀 키의 안전한 생성 및 교환 보장
이라는 두 가지 기능을 제공한다.
키 교환단계의 약점은 두 가지 방식으로 세션에 영향을 미칠 수 있다는 것이다.
| 키 교환단계의 약점 |
| 인증 없이 키 교환을 하면 활성 공격자가 MITM (맨인더 미들) 공격을 수행해 전체 통신 채널에 액세스할 수 있다. |
| 대부분의 서버는 키 교환을 위해 공개 암호화에 의존한다. 그러므로 서버의 개인 키가 강할수록 키 교환 단계를 중단하기 어려워진다. 약한 키 또는 키의 일부만을 사용하는 교환절차(소위 내보내기 가능한 키 교환)는 세션 별 비밀 키를 쉽게 손상시킬 수 있는 약한 키 교환 단계를 초래할 수 있다. 일부 서버는 개인 키에 의존하지 않는 키 교환 매커니즘을 이용한다. (키는 인증에 사용된다. ) (임시 Diffie-Hellman 키 교환 (DHE)과 Elliptic Crypto 변형 ECDHE 등) |
| 키 교환 측면 | 점수 |
| 약한 키 (데비안 OpenSSL 결함) | 0 % |
| 익명 키 교환 (인증 없음) | 0 % |
| 키 또는 DH 매개 변수 강도 <512 비트 | 20 % |
| 내보낼 수있는 키 교환 (512 비트로 제한) | 40 % |
| 키 또는 DH 매개 변수 강도 <1024 비트 (예 : 512) | 40 % |
| 키 또는 DH 매개 변수 강도 <2048 비트 (예 : 1024) | 80 % |
| 키 또는 DH 매개 변수 강도 <4096 비트 (예 : 2048) | 90 % |
| 키 또는 DH 매개 변수 강도> = 4096 비트 (예 : 4096) | 100 % |
암호를 지원하는지
통신 세션을 중간하기 위해 공격자는 대량의 통신에 사용되는 대칭 암호를 중단하려 시도할 수 있다. 더 강력한 암호는 해독하는데 필요한 비용이 증가한다.
(가장 강력한 암호 점수 + 가장 약한 암호 점수)/2| 암호 강도 | 점수 |
| 0 비트 (암호화 없음) | 0 % |
| 128 비트 미만 (예 : 40, 56) | 20 % |
| <256 비트 (예 : 128, 168) | 80 % |
| > = 256 비트 (예 : 256) | 100 % |
소견
축하한다. 보안문제가 터졌다는 것은 어느정도 알려지고 사용자가 많은 기업이 되었다는 상징이기도 하다.
보안 문제는 터지기 전까지는 아무일 없다가 어느 날 갑자기 치명적으로 다가온다. 지속적이고 꾸준한 보안에 대한 예민함이 안전한 서비스를 만들 수 있다고 본다.
또한, SSL 만으로 충분하지 않다. SSL은 보안의 한 측면만을 다루며 웹 사이트와 사용자 간의 통신 채널 보안일 뿐이다. SSL 구축 기반 뿐만 아니라 수많은 공격들에 대해 대비가 필요하다.
참고 문헌
https://blog.dalso.org/it-security/3926
https://www.ssllabs.com/ssltest/
https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide
https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide
https://blog.qualys.com/product-tech/2018/02/02/forward-secrecy-authenticated-encryption-and-robot-grading-update?_ga=2.16930169.1355191712.1620524607-1583582496.1620524607
https://herrymorison.tistory.com/entry/SSL-30의-취약점-POODLE이란
https://www.itworld.co.kr/news/113007 ( SSL/TLS의 이해와 TLS 1.3으로 업그레이드해야 하는 이유)
https://dokydoky.tistory.com/464 ( SSL 버전 별 취약점 잘 설명 )