그림으로 배우는 Http & Network Basic - 7장

7장 웹을 안전하게 지켜주는 HTTPS

HTTP는 약점이 있다.

• 평문 통신이기 때문에 도청 가능
• 통신 상대를 확인하지 않기 때문에 위장 가능
• 완전성을 증명할 수 없기 때문에 변조 가능

7.1.1 평문이기 때문에 도청 가능

HTTP는 암호화 기능이 없기 때문에 평문으로 메시지를 보낸다. 따라서 통신 경로의 도중에 패킷을 수집하여 도청할 수 있다.

암호화로 도청을 피하는 방법

1. 통신 암호화
   1. SSL(Secure Socket Layer)이나 TLS(Transport Layer Security)라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화할 수 있다. SSL을 조합한 HTTP를 HTTPS라고 부른다.
2. 콘텐츠 암호화
   1. 콘텐츠의 내용 자체를 암호화해 버리는 방법이다.

7.1.2 통신 상대를 확인하지 않기 떄문에 위장 가능

누구든지 리퀘스트를 보낼 수 있고 서버도 상대가 누구든지 리스폰스를 반환한다.

HTTP에서는 통신 상대를 확인할 수 없지만 SSL로 상대를 확인할 수 있다.

증명서를 통해서 서버나 클라이언트가 실재한다는 사실을 증명한다.

7.1.3 완전성을 증명할 수 없기 때문에 변조 가능

변조를 방지하려면, MD5나 SHA-1등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 있다.

7.2 HTTP + 암호화 + 인증 + 완전성 보호 = HTTPS

7.2.1 HTTP에 암호화와 인증과 완전성 보호를 더한 HTTPS

HTTPS를 사용하는 통신은 https://를 사용한다.

7.2.2 HTTPS는 SSL의 껍질을 덮어쓴 HTTP

HTTP 통신을 하는 소켓 부분을 SSL이나 TLS 프로토콜로 대체하는 것이다.

보통 HTTP는 직접 TCP와 통신하지만 SSL을 사용한 경우에는 HTTP는 SSL과 통신하고 SSL이 TCP와 통신한다.

7.2.3 상호간에 키를 교환하는 공개키 암호화 방식

SSL에서는 공개키 암호화 방식을 채용하고 있다.

암호화와 복호화에 하나의 키를 같이 사용하는 방식을 공통키 암호화라고 부른다.

공통키 암호화는 키를 뺏기는 순간 암호화의 의미가 없어지고 키를 전달하는 것 자체도 안전하게 해야한다.

공통키의 문제를 해결하려고 한 것이 공개키 암호화 방식이다.

서로 다른 두 개의 키 페어를 사용한다. 한쪽은 비밀키, 한쪽은 공개키

공개키로 암호화를 하고 암호화된 정보를 받은 상대는 자신의 비밀키로 복호화를 한다.

HTTPS는 공통키 암호와 공개키 암호의 양쪽 성질을 가진 하이브리드 암호 시스템이다.

키를 교환하는 곳에서는 공개키 암호를 사용하고 그 후의 통신에서 메시지를 교환하는 곳에서는 공통키 암호를 사용한다.

7.2.4 공개키가 정확한지 아닌지를 증명하는 증명서

공개키를 증명하기 위해서 인증 기관(CA)과 그 기관이 발행하는 공개키 증명서가 이용된다.

1. 서버는 공개키를 인증 기관에 등록한다.
2. 인증 기관의 비밀키로 서버의 공개키에 디지털 서명으로 공개키 증명서를 작성한다.
3. 서버는 인증 기관에 의해 작성된 공개키 인증서를 클라이언트에 보낸다.
4. 클라이언트는 증명 기관의 공개키를 사용해서 서브의 공개키를 인증한 것이 진짜 인증 기관이라는 것을 확인한다.

조직의 실제성을 증명하는 EV SSL 증명서가 있다.

클라이언트를 확인하는 클라이언트 증명서도 있다.

• 직접 사용자가 증명서를 설치해야 한다.

7.2.5 안전한 통신을 하는 HTTPS의 구조

1. 클라이언트가 Client Hello 메시지를 보내면서 SSL 통신 시작, 메시지에는 SSL의 버전 지정, 암호 스위트로 불리는 리스트등이 포함되어 있다.
2. 서버가 SSL 통신이 가능한 경우에는 Server Hello 메시지로 응답한다. SSL 버전과 암호 스위트를 포함한다.
3. 서버가 Certificate 메시지를 보낸다. 메시지에는 공개키 증명서가 포함되어 있다.
4. 서버가 Server Hello Done 메시지를 보내고 최초의 SSL 네고시에이션 부분이 끝났음을 알린다.
5. SSL의 최초 네고시에이션이 종료되면 클라이언트가 Client Key Exchange 메시지로 응답한다. 메시지에는 통신을 암호화하는데 사용하는 Pre-Master secret이 포함되어 있다.이 메시지는 3번의 공개키 증명서에서 꺼낸 공개키로 암호화되어 있다.
6. 클라이언트는 Change Cipher Spec 메시지를 보낸다. 이 메시지 이후의 통신은 암호키를 사용해서 진행한다는 것을 나타낸다.
7. 클라이언트는 Finished 메시지를 보낸다.
8. 서버에서도 Chagne Cipher Spec 메시지를 보낸다.
9. 서버에서도 Finished 메시지를 보낸다.
10. 서버와 클라이언트의 Finished 메시지 교환이 완료되면 SSL에 의해서 접속이 확립된다. 이제부터는 애플리케이션 계층의 프로토콜에 의해 통신을 한다.
11. …
12. 마지막에 클라이언트가 접속을 끊는다. 접속을 끊는 경우에는 close_notify 메시지를 송신한다.

SSL은 느리다는 단점이 있다.

통신 속도가 떨어지는 것과 CPU나 메모리 등의 리소스를 다량으로 소비하기 때문이다.