Http&Network Basic : 웹을 안전하게 지켜주는 HTTPS (7장)

🌐 웹을 안전하게 지켜주는 HTTPS

7.1 HTTP의 약점

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

• HTTP는 암호화하는 기능이 없다.
• TCP/IP는 통신 경로 상 모든 기기를 소유할 수 없기 때문에 도청이 가능하다.
• 패킷을 수집함으로 도청을 할 수 있다. 이때, 패킷 캡처나 스니퍼라는 툴을 사용한다.
• 암호화를 통해서 도청을 방지한다.
  • 통신 암호화 : SSL, TLS이라는 다른 프로토콜을 조합해 안전한 통신로를 확보하고 통신한다.
  • 콘텐츠 암호화 : 콘텐츠 자체를 암호화한다. 주로 웹 서비스에서 이용되는 방법이다.

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

• HTTP 통신은 상대를 확인하지 않는다.
• 누구나 요청할 수 있기 때문에 서버는 모두 응답한다.
• SSL은 암호화도 지원하지만 상대를 확인하는 수단으로 증명서를 제공한다.

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

• 요청이나 응답을 중간에 변조되어도 모른다는 의미이다.
• 이와 같이 중간에 뺏어서 변조하는 공격을 중간자 공격이라고 부른다.
• 디지털 서명(SHA-1 등)으로 방지할 수 있으나 완벽한 방법은 아니다.

---

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

• HTTPS는 HTTP Secure을 의미한다.
• 새로운 프로토콜이 아니고 소켓 통신 부분이 SSL이나 TLS로 대체된 것이다.
• 특히 SSL이 대표적인데, 공개키 암호화 방식을 사용한다.

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

• 공통키는 암호화, 복호화 모두 같은 키를 사용하는 방식이다.
• 키를 보내면 뺏길 수 있고, 안보내면 복호화할 수 없다는 문제가 있다.
• 공개키는 암호화는 공개키를, 복호화에는 비밀키를 사용하는 방식이다.
• 키를 보내지 않고도 복호화를 할 수 있지만 공통키에 비해서 처리가 느리다.
• HTTPS는 공통키와 공개키를 적절하게 조합해서 사용한다.

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

• 공개키도 문제가 존재한다. 바로 진짜 키임을 알 수 없다는 점이다.
• 이 문제를 해결하고자 인증 기관(CA)에서 발급하는 공개키 증명서를 이용한다.
• 증명서를 통해서 서버가 올바른 통신 상대임을 증명할 수 있다.
• EV SSL 증명서, 클라이언트 증명서 등 다양한 증명서가 존재한다.

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

• 통신 흐름
  1. 클라이언트가 Hello 메시지를 보낸다. 서버가 응답할 수 있으면 Hello 메시지로 응답한다.
  2. 서버가 증명서를 포함하는 Certificate 메시지를 보낸다.
  3. 서버가 Hello Done을 보냄으로 최초의 SSL negotiation이 끝남을 알린다.
  4. 클라이언트가 증명서에서 꺼낸 공개키로 암호화한 Key Exchange 메시지를 보낸다. (Pre-master-secret 포함)
  5. 클라이언트가 Change Cipher Spec 메시지를 보낸다. (이후 통신은 암호키로 진행)
  6. 클라이언트가 Finished 메시지를 보낸다. 복호화가 성공하면 서버가 Change Cipher Spec 메시지를 보낸다.
  7. 서버가 Finished 메시지를 보내고 SSL에 의해서 접속을 시작한다.
• MAC(Message Authentication Code)를 붙여주면 변조를 감지할 수 있다.
• SSL은 추가적인 통신으로 생긴 네트워크 부하와 암호화, 복호화를 위해 다량으로 사용하는 리소스(CPU 등) 때문에 느리다.
• 이런 문제는 SSL 엑셀레이터로 해결하기도 한다.

---

😋 지극히 개인적인 블로그지만 댓글과 조언은 제 성장에 도움이 됩니다 😋