HTTPS

HTTP의 약점

  • 암호화되지 않은 통신이기 때문에 도청가능
  • 통신 상대를 확인 하지 않음
  • 완전함 증명이 불가능 하기 때문에 변조가능

1. 암호화 되지 않는 통신

암호화된 통신, 암호화되지 않은 통신 등 모든 통신의 내용을 엿볼 수 있다. Packet sniffer tool을 통해서 패킷을 가로채는 것이 가능하다. 이러한 문제를 해결하기 위해 암호화를 사용한다.

해결책

1) 통신 암호화

HTTP에는 암호화 구조는 없지만 SSL(Secure Socket Layer)TLS(Transport Layer Security) 라는 다른 protocol을 통해 HTTP통신 내용을 암호화 할 수 있다. SSL을 이용해 안전한 통신로를 가지고 있는 상태에서 HTTP통신을 한다.

2) 콘텐츠 암호화

content 자체를 암호화 하는 것이다. 이 방법은 맹점은 content만 암호화 될뿐 헤더 내용은 암호화 되지 않는다.

2. 통신 상태를 확인하지 않기 때문에 위장이 가능하다.

HTTP를 사용한 request나 response에서는 통신상태를 확인하지 않는다. 누구나 request가 가능한 것이다.

  • request를 보낸 곳의 웹서버가 정상의 response를 보낸는 곳인지 아닌지 확인하기 어렵다.
  • 클라이언트도 확인 불가능
  • 통신 상대가 접근이 허가된 상대인지 아닌지 확인 할 수 없다.
  • 누가 어디에서 request 보냈는지 확인 할 수 없다.
  • 의미 없는 request를 보낼 수 있다. 대량의 DDOS공격이 가능하다.

해결책

1) 상대를 확인하는 증명서

  • SSL은 암호화 뿐만아니라 상대를 확인하는 수단으로 증명서를 가지고 있다. 증명서를 발행하는 기관은 인증된 제 3의 기관에서 발행한다. 증명서를 이용함으로써, 통신 상대가 내가 통신하고자 하는 서버임을 나타낸다. 개인 정보 누설위험을 줄인다.

3. 완전성을 증명할 수 없기 때문에 변조 가능하다.

완전성은 정보의 정확성을 가리킨다. 서버와 클라이언트가 통신중에 정보가 변조될 가능성이 농후하다.

  • 중간자 (Man-in-the-Middle)공격: 공격자는 request와 response를 통신 사이에서 변조하는 공격

해결책

1) MD5, SHA-1등 해시값을 확인 하는 방법

파일 다운로드를 제공하고 있는 서비스 에서는 PGP(Pretty Good Privacy)에 의한 서명과 MD5 해시 값을 제공한다. 하지만 이런 값들 조차 교묘히 변조된다면 클라이언트는 원하지 않는 content를 받을수 있다.

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

1. HTTPS는 SSL을 사용한 HTTP

기존 HTTP에서 사용한 Layer에 SSL 또는 TLS layer를 추가한 것 뿐이다. 하지만 SSL의 기능은 대단했다. SSL을 사용하면서 암호화, 인증, 완전성 보호를 한번에 할 수 있게 되었다.

2. SSL의 원리

Public key 방식을 사용한다. 암호화 복호화 시 Public key를 사용한다.

1) Symmetric key(공통키)의 문제

암호화, 복호화에 하나의 키를 사용하는 방식이다. 이 방식은 해커들이 공통키를 가지고 있다면 쉽게 암호화, 복호화가 가능하다는 것으로도 해석할 수 있다.

공통키 암호화 방식은 상대방에게 키를 넘겨주어야만 한다. 이것을 안전하게 보내야 하는 문제점이 있었는데 이러한 문제점을 해결하기 위해 두개의 키를 사용하는 Public key 방식을 사용한다.

해결책

1) 두 개의 키를 사용하는 공개키 암호

Public key, Private key pair를 사용한다. 암호를 보내는 측이 상대의 공개키를 사용해 암호화를 한다. 그리고 암호화된 내용을 받아들인 상대는 자신의 비밀키를 통해서 복호화한다.

2) 공통키 + 공개키 = HTTPS

공개키 암호는 공통키 암호 방식보다 속도가 느리다는 단점이 있다. 암호화 복호화 시에 많은 시간이 소요된다. 그렇기 때문에 HTTPS는 키를 교환할때는 공개키 방식을 사용하고 그 후 통신에서는 공통키를 사용하는 방식을 같이 사용한다.

하지만 도중에 공개키를 바꿔치기 할 가능성이 있기 때문에 CA(인증기관)을 통해 해당 공개키에 대한 증명서를 발급 받는 방식이 이용되고 있다.

먼저 서버운영자가 CA에 공개키를 제출한다. 해당 공개키의 인증을 CA에서 해주며 디지털 서명으로 인증한다.

SSL과 TLS

HTTPS에서는 SSL과 TLS라는 두개의 프로토콜을 사용한다. SSL을 사용하는 HTTPS는 느리다는 단점이 있다. 통신 속도가 지연되고 복호화 암호화에 CPU나 메모리 등의 리소스를 많이 사용함으로써 처리가 느려진다. 통신할 때마다 암호화 통신을 한다면 리소스를 많이 소비하기 때문에 민감한 정보를 다루지 않는다면, http만 사용해도 된다.

참조

  • 그림으로 배우는 네트워크