7.1 HTTP의 약점
7.1.1 평문이기 때문에 도청 가능
•
TCP/IP는 도청 가능한 네트워크
◦
암호화되지 않은 통신이기에 패킷 캡처나 스니퍼라는 툴을 통해 도청이 가능합니다.
•
암호화로 도청을 피하다.
◦
통신 암호화
▪
SSL이나 TLS라는 다른 프로토콜과 조합하여 암호화
▪
SSL을 조합한 HTTP를 HTTPS나 HTTP over SSL이라 부릅니다.
◦
콘텐츠 암호화
▪
메시지의 콘텐츠 구조를 암호화 할 수 있는데 서버와 클라이언트가 둘 다 암호화 복호화 기능을 가지고 있어야 하기 때문에 평소에 이용하기 어렵습니다.
7.1.2 통신 상대를 확인하지 않기 때문에 위장 가능
누구나 리퀘스트를 서버에 할 수 있기 때문에 Ddos나 다른 공격을 받을 수 있습니다.
대표적인 Ddos공격으로 미라이 봇넷 사건이 있습니다.
•
상대를 확인하는 증명서
◦
통신 상대를 확인할 수 없지만, SSL로 상대를 확인할 수 있습니다.
◦
통신 상대의 서버나 클라이언트가 가진 증명서를 확인함으로써 판단 가능합니다.
7.1.3 완전성을 증명할 수 없기 때문에 변조 가능
•
수신한 내용이 다를지도 모른다.
◦
데이터를 클라이언트가 수신받을 때 변조되었더라도 이를 알 수 없습니다.
•
변조를 방지하려면?
◦
파일의 디지털 서명을 확인하는 방법등이 존재하지만 확실하면서 편리한 방법은 존재하지 않습니다.
7.2 HTTP+암호화+인증+완전성 보호 = HTTPS
7.2.1 HTTP에 암호화와 인증과 완전성 보호를 더한 HTTPS
HTTP에 인증 구조를 더한 것을 HTTPS라고 부릅니다.
7.2.2 HTTPS는 SSL의 껍질을 덮어쓴 HTTP
HTTP 통신을 하는 소켓 부분을 SSL이나 TLS파는 프로토콜로 대체하고 있을 뿐입니다.
크롬은 14년부터 HTTPS사이트에 SEO적으로 높은 검색순위를 부여했고, 18년도부터 “안전하지 않음”이란 사이트로 표시하기 시작했습니다.
대칭키 방식
public key : 암호화
private key : 복호화
각 end point가 public과 private을 서로 가지고 있고, 각자에게 public을 보내서 암호화한다.
이는 관리해야하는 키들이 많아져 관리가 어렵고, 키의 탈취 문제가 생길 수 있다.
7.2.3 상호간에 키를 교환하는 공개키 암호화 방식
•
공통키 암호의 딜레마
◦
상대방에게 키를 넘겨야하지만, 해당키를 안전하게 배송할 방법이 필요합니다.
•
두 개의 키를 사용하는 공개키 암호
◦
이를 해결하려한 것이 공개키 암호
공개키 암호화 방식
공개키는 모든 사람이 접근 가능한 키이고, 개인키는 각 사용자만이 가지고 있는 키입니다.
A는 B의 공개키로 암호화한 데이터를 보내고 B는 본인의 캐인키로 해당 암호화된 데이터를 복호화해서 암호화된 데이터는 B의 공개키에 대응되는 개인키를 갖고있는 B만이 볼 수 있게됩니다. 하지만 느립니다.
•
HTTPS는 하이브리드 암호 시스템
◦
공개키 암호는 공통키 암호에 비해 처리속도가 느리기 때문에 각각의 방식을 조합해서 통신합니다.
7.2.4 공개키가 정확한지 아닌지를 증명하는 증명서
공개키의 문제점은 공개키가 진짜인지 증명할 수 없다는 것입니다. 이를 위한 문제를 해결하기 위해 CA(Certificate authority)라 불리는 인증기관들(Versign, Comodo, GoDaddy, GlobalSign 등)이 존재합니다.
1.
서버의 운영자가 인증 기관에 공개키 제출
2.
인증 기관은 공개키에 디지털 서명 후 서명이 끝난 공개키 제작
3.
서버의 공개키 증명서를 입수하고, 디지털 서명을 징은 기관의 공개키로 검증
•
조직의 실제성을 증명하는 EV SSL 증명서
◦
실제로 존재하는 기업인지 확인하는 역할을 하며, 주소창 옆에 초록색으로 표시가 됩니다.
•
클라이언트를 확인하는 클라이언트 증명서
◦
인터넷 뱅킹 등에 사용되지만 비용이 많이 듭니다.
•
인증 기관은 신용이 제일
•
자기 인증 기관 발생 증명서는 ‘나야 나’ 증명서
◦
OpenSSL등을 사용하면 누구나 인증 기관을 구축할 수 있지만, 이는 브라우저에서 인정받지는 못합니다.
7.2.5 안전한 통신을 하는 HTTPS의 구조
1.
클라이언트가 메시지를 송신하며 SSL 통신 시작
2.
통신 가능할 경우 응답 - SSL버전과 암호 스위트 포함
3.
서버가 Ceritificate 메시지 송신 - 공개키 증명서 포함
4.
Server Hello Done을 송신하여 최초의 SSL 네고시에이션이 끝났음을 통지
5.
SSL의 최초 네고시에이션이 종료되면 클라이언트가 Client Key Exchange로 응답 - 통신을 암호화하는 Pre-Master secret 포함 → 해당 메시지는 공개키로 암호화 되어 있음
6.
클라이언트는 Change Cipher Spec 메시지 송신→ 이 메시지 이후의 통신은 암호키를 사용해서 진행한다는 것을 의미
7.
클라이언트는 Finished 송신→ 네고시에이션이 성공했는지는 서버가 메시지를 올바르게 복호화 가능한지가 결정
8.
서버에서도 Change Cipher Spec 메시지를 송신
9.
서버에서도 Finished 메시지를 송신
10.
Finished 메시지 교환이 완료되면, SSL에 의해서 접속은 확립 → 이제부터 애플리케이션 계츠으이 프로토콜에 의해 통신
11.
클라이언트가 접속을 끊으며 close_notify 메시지를 송신
•
SSL과 TLS
◦
두개의 프로토콜이 사용되는데 TLS도 통상적으로 SSL로 부름
•
SSL은 느리다?
◦
통신속도가 떨어지고, 리소스를 다량으로 소비해 느립니다.