현재 거의 모든 웹 사이트들에서는 HTTPS를 지원하는데요. HTTP와 HTTPS의 차이점이 뭘까요?
저는 솔직히 HTTPS는 HTTP에서 보안이 추가되었다는것 밖에 몰랐습니다. 뭐 그게 대부분이긴 합니다..
자 그럼 HTTP의 약점을 먼저 알아보면서 시작하겠습니다.
HTTP의 약점
이 약점은 HTTP만이 아닌, 다른 암호화하지 않은 프로토콜에도 공통되는 문제입니다.
1. 평문이기 때문에 도청 가능
HTTP를 사용한 리퀘스트나 리스폰스 통신 내용은 HTTP 자신을 암호화 하는 기능은 없기 때문에 통신 전체가 암호화 되지는 않습니다.
도청이 가능하다?
도청이 가능하다는게 무슨소리냐?하면 TCP/IP는 구조상 전부 통신 경로를 엿볼 수 있습니다. 인터넷은 전 셰게와 이어져 있기 때문에, 통신 경로 상에 있는 라우터들이 자신 개인의 케이블이나 컴퓨터 등일 수가 없죠.
통신 내용을 엿본다는 것은 암호화도니 통신에서도 암호화되지 않은 통신도 같습니다. 음.. 암호화된 통신을 엿본다는 것은 메시지속의 의미는 볼 수 없지만 암호화된 상태의 메시지는 볼 수 있다는것이죠.
같은 세그먼트의 통신을 도청하는 것은 그렇게 어려운일이 아니라고 합니다. 네트워크 상을 흐르고 있는 패킷을 수집하는 것 만으로도 도청할 수 있습니다. 패킷을 수집하려면 패킷 캡쳐나 패킷 스니퍼라는 툴을 사용해야합니다.
패킷 캡쳐
패킷 스니퍼
1-1. 도청 피하기
도청을 피할 수는 없습니다. 하지만 도청을 해도 내용을 볼 수 없게는 할 수 있습니다. 바로 암호화 방식입니다.
통신 암호화
첫번째 방법은 암호화 방식입니다. HTTP에는 암호화 구조는 없지만 SSL이나 TLS라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화할 수 있습니다.
SSL 등을 이용해 안전한 통신로를 만들어 놓고 그 통신로로 통신을 하는 방법입니다. 마치 터널과 비슷한 방식인 것 같습니다.
이렇게 SSL 등을 이용해 안전한 통신로를 확립하고 나서 그 통신로를 사용해 HTTP 통신을 합니다. HTTP 프로토콜에 SSL을 조합한 방식을 흔히들 알고있는 HTTPS(HTTP + SSL)이라고 부릅니다.
콘텐츠 암호화
다른 한 가지는 통신하고 있는 콘텐츠의 내용 자체를 암호화해 버리는 방법입니다.
HTTP에 암호화 기능은 없기 때문에 HTTP를 사용해서 운반하는 내용을 암호화 하는 것입니다. 즉, HTTP 메시지에 포함되는 콘텐츠만 암호화 하는 것입니다.
이 경우, 클라이언트에서 HTTP 메시지를 암호화해서 출력하는 처리가 필요하게 됩니다.
물론, 콘텐츠의 암호화를 유효하게 하려면 클라이언트와 서버가 암호화된 콘텐츠를 복호화하는 기능을 가지고 있어야하는데, 평상시에 유저가 사용하는 브라우저나 웹 서버가 이런 이런 기능을 가지고 있기는 어렵습니다.
2. 통신 상대를 모르기 때문에 위장 가능
HTTP는 통신 상대를 모르고 통신한다는 것을 알고 계셨나요?
HTTP를 사용한 리퀘스트나 리스폰스에서는 통신 상대를 확인하지 않습니다. 리퀘스트를 보낸 서버가 정말로 URI에서 지정된 호스트인지 아닌지, 리스폰스를 반환한 클라이언트가 정말 리퀘스트를 출력한 클라이언트인지 아닌지 모른다는 것입니다.
누구나 리퀘스트 할 수 있다.
HTTP에 의한 통신에는 상대가 누구인지 확인하는 처리가 없기 떄문에 누구든지 르퀘스트를 보낼 수 있습니다. 또한 서버는 리퀘스트가 오면 상대가 누구든지 무언가의 리스폰스를 반환합니다.
이것은 매우 간단한 구조이기에 장점이라면 장점일 수는 있겠지만, 통신하는 상대를 모른다는 약점이 있습니다.
이 약점들도 여러가지인데 아래와 같습니다.
- 위장한 웹 서버일 우려가 있다. - 리퀘스트를 보낸 곳의 웹 서버가 원래 의도한 리스폰스를 보내야 하는 웹 서버인지 아닌지를 확인할 수 없다
- 위장한 클라이언트일 우려가 있다. - 리스폰스를 반환한 곳의 클라이언트가 원래 의도한 리퀘스트를 보낸 클라이언트인지 아닌지를 확인할 수 없다.
- 통신하고 있는 상대가 접근이 허가된 상대인지 아닌지를 확인할 수 없다.
- 어디의 누가 리퀘스트를 했는지 알 수 없다.
- D-Dos 공격을 방지할 수 없다. - 의미없는 리퀘스트라도 수신하게 된다.
SSL을 더 자세히
SSL을 쉽게 말하자면 상대를 확인하는 증명서라고 보면 편합니다. 사람으로 따지면 주민등록증..? 네.. 그런겁니다.
HTTP에서는 상대를 알 방법이 없기 때문에 SSL이라는 것으로 상대를 확인합니다.
증명서는 신뢰할 수 있는 제 3자 기관에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명합니다. 또 그 증명서를 위조하는 것은 기술적으로 불가능한 것은 아닌데, 상당히 어렵습니다.
이렇게 상대의 서버나 클라이언트가 가진 증명서를 확인함으로써 통신 상대가 내가 통신하고자 하는 상대인지 아닌지를 판단할 수 있습니다.
3. 완전성을 증명할 수 없기 때문에 변조 가능
완전성이란? 정보의 정확성
그것을 증명할 수 없다는 것은 정보가 정확한지 아닌지를 확인할 수 없음을 의미합니다.
클라이언트에게서 받은 리퀘스트의 내용이 다를지도 모른다.
HTTP가 완전성을 증명할 수 없다는 것은 클라이언트가 서버에게 또는 서버가 클라이언트에게 전달한 리퀘스트나 리스폰스가 상대가 수신할 때까지의 사이에 변조되었을지 안되었을지 모른다는 이야기입니다.
변조되었다고 하더라도 이 사실을 알 수는 없죠.
이렇게 공격자가 리퀘스트나 리스폰스를 뺐어서 내용을 변조하는 공격을 Man-in-the-Middle 공격이라고 합니다.
따라서 HTTPS는?
HTTPS = (HTTP + 암호화 + 인증 + 완전성 보호)라고 볼 수 있겠네요.
자 오늘은 HTTP의 약점을 알아보고 SSL 방식으로 이 약점들을 보완하는 방식에 대해서 알아보았습니다.
감사합니다! 이거 보고 구글 합격했습니다.