HTTP 프로토콜의 보안적인 문제를 보완하는 HTTPS
HTTP의 약점
평문이기 때문에 도청 가능
- 암호화되지 않은 메시지(평문)으로 HTTP 메시지를 보낸다!
- TCP/IP 구조는 통신 경로 도중에 통신 내용을 엿볼 수 있기 때문에, 패킷을 수집하는 것만으로 도청할 수 있다.
- 암호화로 도청 피하기
: 통신 암호화 - SSL 프로토콜을 조합, 안전한 통신로 확립 후 HTTP 통신
(= HTTPS = HTTP over SSL)
: 콘텐츠 암호화 - HTTP 메시지에 포함되는 콘텐츠만 암호화. 주로 웹 서버에서 이용
통신 상대를 확인하지 않기 때문에 위장 가능
- HTTP에 상대가 누구인지 확인하는 처리가 없기 때문에 누구나 리퀘스트 가능
- 리퀘스트가 오면 상대가 누구든지 리스폰스 반환!
- SSL이 상대를 확인하는 증명서 제공
: 내가 통신하고자 하는 서버임을 증명 & 클라이언트의 본인 확인과 웹 사이트 인증에 활용 가능
완전성을 증명할 수 없기 때문에 변조 가능
- 정보가 정확한지 아닌지 확인할 수 없다
: 발신된 리퀘스트나 리스폰스와 수신한 리퀘스트나 리스폰스가 같은지 아닌지 확인 불가능 - 중간자 공격 가능 (Man-in-the-Middle)
: 공격자가 중간에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격 - 변조 방지 방법
: MD5나 SHA-1의 해시 값을 확인하는 방법
: 파일의 디지털 서명을 확인하는 방법
: 확실히 방지하기 위해선 SSL을 사용하기 (HTTPS)
HTTP + 암호화 + 인증 + 완전성 보호 = HTTPS
HTTP에 암호화와 인증과 완전성 보호를 더한 HTTPS
- HTTPS (HTTP Secure)
: 위에 기술된 HTTP의 보안 문제를 해결하기 위해 암호화와 인증 구조를 더한 것
HTTPS는 SSL의 껍질을 덮어쓴 HTTP
- HTTPS는 새로운 프로토콜이 아니다!
: HTTP 통신을 하는 소켓 부분을 SSL이나 TLS 프로토콜로 대체한 것 뿐 - SSL은 HTTP와 독립적인 프로토콜
: SMTP나 Telnet등에서도 사용되는 네트워크 보안 기술
상호간에 키를 교환하는 공개키 암호화 방식
암호화와 복호화에 하나의 키를 사용하는 공통키 암호의 보안 이슈를 보완하는 공개키 암호화 방식
-
공개키 암호화 방식
: 서로 다른 두 개의 키 페어(비밀키 + 공개키)를 이용
: 상대의 공개키를 이용해 암호화 -> 암호화된 정보 받은 상대가 자신의 비밀키를 이용해 복호화
: 암호를 푸는 비밀키를 통신에 보내지 않기에 도청 위험 X -
하이브리드 암호 시스템
: 키를 교환할 때는 공개키 암호 사용
: 그 후의 통신에서 메시지를 교환할 때는 공통키 암호 사용
공개키가 정확한지 아닌지를 증명하는 증명서
공개키의 문제 : 공개키가 진짜인지 증명할 수 없다
-> 증명서를 사용, 서버가 올바른 통신 상대임을 증명
-
CA(인증기관)과 CA가 발행하는 공개키 증명서로 공개키 이슈 해결
: 서버 운영자가 인증 기관에 공개키 제출
-> 인증 기관이 공개키에 디지털 서명 후 서명이 끝난 공개키 생성
-> 공개키 인증서에 서명된 공개키 담는다
-> 서버는 공개키 인증서를 클라이언트에 보내고, 공개키 암호로 통신인증 기관의 공개키는 클라이언트에게 안전하게 전달되어야 한다!
: 브라우저는 주요 인증 기관의 공개키를 사전에 내장한다 -
상대가 실제로 있는 기업인지 확인하는 증명서, EV SSL
: 운영 조직의 실재성을 확인하여 웹 사이트의 신뢰성을 높인다 -
클라이언트 증명서
: 서버가 통신 중인 상대가 의도한 클라이언트인 것을 증명하는 클라이언트 인증 방식
: 단, 많은 문제와 비용 이슈가 있어 비용을 들일 필요가 있는 곳(EX.은행)에서만 사용
안전한 통신을 하는 HTTPS의 구조
-
SSL의 통신 지연
: SSL 통신만큼 통신 속도 떨어진다
: SSL 통신만큼 네트워크 리소스를 더 소비해서 처리가 느러진다 -
SSL 엑셀레이터 하드웨어 (appliance 서버)
: SSL를 처리하기 위한 전용 하드웨어
: 소프트웨어로 SSL 처리하는 것보다 훨씬 빠르고 부하의 분산이 가능하다
