HTTP 약점
- 평문(암호화 하지 않은) 통신이기 때문에 도청 가능
- 통신 상대를 확인하지 않기 때문에 위장 가능
- 완전성을 증명할 수 없기 때문에 변조 가능
1. 평문이기 때문에 도청 가능
- TCP/IP는 도청 가능한 네트워크
- 암호화로 도청 피할 수 있다
- 통신을 암호화 : HTTP + SSL/TLS 조합
- SSL(Secure Socket Layer)
- TLS(Transport Layer Security)
- SSL 등을 이용해 안전한 통신로를 확립 후, 그 통신로를 사용해 HTTP 통신
- SSL을 조합한 HTTP => HTTPS(HTTP Secure) / HTTP over SSL
- 콘텐츠 암호화: 콘텐츠 내용 자체를 암호화(HTTP메시지에 포함되는 콘텐츠만 암호화)
- 메시지 헤더는 암호화되어 있지 않음
- 메시지 바디에 들어가는 콘텐츠를 암호화(통신자체는 암호화되어 있지 않음)
- 주로 웹 서비스에서 이용되는 방법
- 통신을 암호화 : HTTP + SSL/TLS 조합
2. 통신 상대를 확인하지 않기 때문에 위장 가능
HTTP를 사용한 리퀘스트나 리스폰스 에서는 통신 상대를 확인하지 않음
- 누구나 리퀘스트 할 수 있음
- 위장한 웹 서버일 우려
- 위장한 클라이언트일 우려
- 통신하고 있는 상대가 접근 허가된 상대인지 아닌지 확인할 수 없음
- 어디의 누가 리퀘스트 했는지 확인할 수 없음
- 의미없는 리퀘스트라도 수신하게 됨(DoS 공격 방지 불가능)
- 상대를 확인하는 증명서
- SSL로 상대 확인 가능
- SSL은 암호화 뿐 아니라, 상대를 확인하는 수단으로 증명서를 제공함
- 클라이언트는 통신을 개시할 때 서버의 증명서를 확인함
- 증명서를 가짐으로써 본인 확인 및 웹 사이트 인증에 이용 가능
3. 완전성을 증명할 수 없기 떄문에 변조 가능
완전성: 정보의 정확성
완전성을 증명할 수 없다: 정보가 정확한 지 아닌지 확인할 수 없다
- 수신한 내용이 다를지도 모른다
- 리퀘스트/리스폰스가 발신된 후 상대가 수신할 때까지의 사이에, 변조되었다 하더라도 이 사실을 알 수 없음
- 중간자 공격(Man-in-the-Middle 공격): 공격자가 도중에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격
- 변조를 방지하려면?
- MD5/SHA-1 등 해시값 확인
- 파일의 디지털 서명을 확인
HTTP+암호화+인증+완전성 보호 = HTTPS
1. HTTPS(HTTP Secure): HTTP에 암호화나 인증 등의 구조를 더한 것
- 증명서는 서버 혹은 클라이언트의 신원을 증명
- https://
2. HTTPS는 SSL의 껍질을 덮어쓴 HTTP
- HTTP 통신을 하는 소켓부분을 SSL이나 TLS라고 하는 프로토콜로 대체할 뿐, HTTPS는 새로운 프로토콜이 아니다
애플리케이션(HTTP) |
TCP |
IP |
HTTP
애플리케이션(HTTP) |
SSL |
TCP |
IP |
HTTPS
HTTP는, 직접 TCP와 통신
HTTPS는, SSL을 사용한 경우, HTTP와 SSL이 통신하고, SSL이 TCP와 통신
3. 상호간에 키를 교환하는 공개키 암호화 방식
SSL은 실제 데이터를 암호화 할 때 대칭키 암호화를 사용(암호화 알고리즘 공개하고, 키를 비밀에 부침)
- 대칭키(공통키) 암호의 딜레마: 키 배송 문제
- 암호화할때도 복호화할 때도 같은 키를 사용
- 키를 손에 넣으면 누구라도 암호를 해독할 수 있음
- 키를 보내면 도청 될 가능성이 있고, 키를 보내지 않으면 복호화 할 수 없음
- 애초에 키를 안전하게 보낼 수 있다면, 틀림없이 데이터도 안전하게 보낼 수 있음
- 어떻게 하면 안전하게 키를 보낼 수 있을까?
4. 두개의 키를 사용하는 공개키(비대칭키) 암호
- 서로 다른 두 개의 키 쌍을 사용(비밀키-공개키)
- 암호를 보내는 쪽이 상대의 공개키를 사용해서 암호화 함
- 암호화된 정보를 받은 상대는 자신의 비밀키를 사용해 복호화 함
- 공개키는 누구에게나 넘겨줘도 괜찮음
- 대칭키 암호의 딜레마였던 키 배송 문제 해결
HTTPS는 하이브라드 암호시스템
- 키를 교환하는 곳에서는 공개키 암호 사용
- 그 후, 통신에서 메시지를 교환하는 곳에서는 대칭키(공통키)암호 사용
4. 공개키가 정확한지 아닌 지를 증명하는 증명서
인증기관(CA: Certificate Authority)
- 서버의 운영자가 인증기관에 공개키 제출
- 인증기관은 제출된 공개키에 디지털 서명을 하고, 서명이 끝난 공개키를 생성 후 공개키 인증서에 서명이 끝난 공개키를 담는다
- 서버는 이 인증기관에 의해 작성된 공개키 인증서를 클라이언트에 전송하고, 공개키 암호로 통신
- 증명서를 받은 클라이언트는 증명기관의 공개키를 사용해서 서브의 공개키를 인증한 것이 진짜 인지, 서버의 공개키를 신뢰할 수 있는지 알수 있음
- 조직의 실제성을 증명하는 EV SSL 증명서
- 증명서 역할: 서버가 올바른 통신 상대임을 증명하는 것.
- EV SSL 증명서: 상대방이 실제 있는 기업인지 확인하는 역할을 가진 증명서. 운영하는 조직의 실재성 확인
- 클라이언트 증명서
HTTPS에서는 SSL과 TLS 라는 두 개의 프로토콜 사용
HTTPS 문제점
- SSL 사용하면 처리가 늦어짐
- HTTPS는 서버, 클라이언트 모두 암호화와 복호화 처리가 필요. CPU나 메모리 등의 하드웨어 리소스를 소비
- HTTP통신에 비해 SSL 통신만큼 네트워크 리소스를 더 소비, SSL 통신만큼 통신 처리에 시간이 걸림
- HTTPS는 HTTP에 비해서 속도가 2~100배 느리다
'컴퓨터과학 🖥️ > 네트워크' 카테고리의 다른 글
[Network] HTTP의 병목현상과 WebSocket (0) | 2024.08.16 |
---|---|
[Network] 인증(Authorization) (0) | 2024.08.15 |
[Network] HTTP 헤더 (0) | 2024.07.25 |
[Network] HTTP와 연계하는 웹 서버 (0) | 2024.07.09 |
[Network] HTTP 상태코드 (0) | 2024.07.02 |