HTTP, HTTPS

HTTP는 https://cyk0825.tistory.com/3 를 참고

HTTP의 약점

HTTP는 주로 다음과 같은 약점을 가지고 있습니다.

 

평문(암호화 하지 않은) 통신이기 때문에 도청이 가능하다.

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

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

 

이 약점은 다른 암호화 하지 않는 프로토콜에도 공통되는 문제입니다.

HTTPS는 Hypertext Transfer Protocol over Secure Socket Layer의 약자로 즉 SSL(Secure Socket Layer)을 이용한 Http 통신 방식을 의미합니다.

 

SSL은 전자상거래에서의 데이터 보안을 위해서 개발한 통신 레이어다. SSL은 표현계층의 프로토콜로 응용 계층 아래에 있기 때문에, 어떤 응용 계층의 데이터라도 암호화해서 보낼 수 있다.

 

HTTP의 치명적인 단점. 보안

HTTP는 웹을 지탱하는 심플한 기술이지만 치명적인 단점이 있습니다. 브라우저와 웹서버가 통신함에 있어서 주고 받는 데이터가 암호화 되지 않고 생 날것 그대로 전송 되어진다는 점 입니다.

 

HTTP는 인터넷이라는 바다를 지나 웹서버와 브라우저가 통신하므로 그 중간 어딘가에서 해커가 중간 통로를 도청하게 된다면 날 것 그대로의 중요한 정보들을 탈취할 수 있습니다. 만약 이러한 데이터가 로그인 기능에서 사용하는 아이디 비밀번호 등의 데이터라면 치명적일 수 있습니다. 뿐만 아니라 정상적인 데이터를 중간에서 악의적으로 변조시킬 수도 있습니다.

 

HTTP는 기본적으로 평문 데이터 전송을 원칙으로 하기 때문에 개인의 프라이버시가 오가는 서비스들(전자상거래, 전자메일, 사내문서)에 사용하기 힘들다.

 

HTTPS는 SSL 레이어위에 HTTP를 통과 시키는 방식이다. 즉 평문의 HTTP 문서는 SSL 레이어를 통과하면서 암호화 돼서 목적지에 도착하고, 목적지에서는 SSL 레이어를 통과하면서 복호화 돼서 웹 브라우저에 전달된다.

간혹 HTTPS를 하나의 프로토콜로 인식하기도 하는데, HTTP와 SSL은 전혀 다른 계층의 프로토콜콜의 조합이다. HTTPS over SSL로 보는게 좀더 정확한 시각이다. 거의 모든 웹 서버와 웹 브라우저와 HTTP 기반의 툴들 - wget, curl, ab 기타등등 - 이 SSL을 지원한다.

 

 

SSL, 인증서, 인증기관(CA)

SSL(Secure Sockets Layer)은 암호화 통신과 그 암호화 통신에 사용되는 키를 공유할 수 있도록 하는 기술입니다. 이 때 등장하는것이 인증기관입니다. 인증기관은 CA(Certificate Authority)라고 하는데, 인증기관은 암호화시 사용되는 키를 담은 인증서를 발급하고 관리합니다.

 

따라서 인증기관은 보안상 매우 중요한 역할을 하기 때문에 전 세계적으로 신뢰받는 기관이 운영합니다. 실례로 모 인증기관 중 하나에서 보안 사고가 발생하여 인증기관 목록에서 제외된 사건이 있습니다. 신뢰를 잃었기 때문이죠.

 

웹 서버를 운영하는 웹사이트(네이버, 구글, 티스토리..)는 암호화키를 생성하여 자신이 하나는 보관하고 하나는 인증기관에게 넘겨 인증서를 발급 받습니다. 인증기관은 인증서를 발급 및 관리해주는 대신 돈을 받죠. 발급된 인증서는 인증기관 본인이 보관합니다. 

 

HTTPS 통신 과정

인증기관에 인증서를 의뢰할 때 통신시 사용할 암호화 키와 자신의 웹사이트 주소를 넘겨주었고 이를 바탕으로 인증기관은 인증서를 만들어 보관했습니다.

 

여기서 한가지 알아야 할 사실이 있는데, 브라우저는 이미 인증기관 목록을 가지고 있다는 사실입니다. 브라우저를 개발하는 기업에서 브라우저를 개발할 때 인증기관 목록을 넣어두기 때문입니다. 즉 인터넷 익스플로러와 구글의 크롬 등에는 인증기관 목록이 담겨있는 것이지요.

 

따라서 브라우저는 웹서버와 통신하기 이전에 인증기관 리스트를 확인하여 인증기관에 현재 자신이 통신하려는 웹서버의 인증서가 있는지 확인하고 있으면 인증서를 받습니다.

인증서에는 웹서버가 인증서를 발급할때 첨부했던 암호화키가 들어있으므로 이것을 가지고 데이터를 암호화하여 웹서버와 통신합니다. 웹서버는 최초 인증서를 발급할 때 사용했던 자신의 암호화키로 복호화 하면 됩니다.

 

제 3자인 인증기관이 암호화 키를 인증서에 담아 관리하는 SSL을 이용하기 때문에 암호화 키를 분배하는 과정에서 탈취 당하지 않을 수 있으며, 분배된 암호화 키를 통해 암호화 통신을 할 수 있는 것입니다.

 

HTTPS는 하이브리드 암호 시스템

하이브리드 암호 시스템?
HTTPS는 공통키 암호와 공개키 암호의 양쪽 성질을 가진 하이브리드 암호 시스템입니다.
두가지 방식을 조합해서 장점을 살립니다.
키를 교환하는 곳에서는 공개키 암호를 사용하고 그 후의 통신에서 메시지를 교환하는 곳에서는 공통키 암호를 사용합니다.
그렇다면 공통키 암호와 공개키 암호는 무었일까요? 아래 간단히게 정리해보았습니다.

공통키 암호

상호간에 키를 교환하는 암호화 방식을 공개키 암호화 방식이라고 합니다.
SSL에서는 공개키 암호화 방식을 채용하고 있습니다.
암호화, 복호화에 하나의 키를 같이 사용하는 방식입니다.

하지만 키를 누군가 손에 넣으면 누구라도 암호를 해독할 수 있는 문제가 있습니다.

공개키 암호

공개키 암호는 공통키 암호의 문제를 해결하기 위해 등장한 방식입니다.
공개키 암호에서는 서로 다른 두 개의 키 페어(쌍)를 사용합니다.
비밀키(private key)와 공개키(public key)가 그것입니다.
비밀키는 알려지면 안되는 키이며, 공개키는 누구에게나 알려져도 괜찮은 키입니다.

 

1. 암호를 보내는 측(클라이언트)이 상대의 공개키를 사용해 암호화를 합니다.

2. 암호화된 정보를 받아들인 상대(서버)는 자신의 비밀키를 사용해 복호화를 실시합니다.

 

이 방식은 암호를 푸는 비밀키를 통신으로 보낼 필요가 없으며 도청에 의해서 키를 빼앗길 걱정이 없습니다.

하지만 공개키가 진짜인지 아닌지를 서버에서 증명할 수가 없습니다.
이 문제를 해결하는 데는 인증기관(CA : Certificate Authority)과 그 기관이 발행하는 공개키 증명서가 이용되고 있습니다.
인증 기관이란 클라이언트와 서버 모두 신뢰하는 제 3자 기관입니다.
공개키를 인증 기관에 제출하면 인증 기관은 제출된 공개키에 디지털 서명을 하고 서명이 끝난 공개키를 만듭니다.
그리고 공개키 인증서에 서명이 끝난 공개키를 담습니다.

이런 인증 기관의 공개키는 안전하게 클라이언트에 전달되어야 합니다.
하지만 어떤 방법을 사용하더라도 100% 안전이 보장되지 않기 때문에 많은 브라우저가 인증기관의 공개키를 사전에 내장한 상태로 제품을 내놓고 있습니다.

단점

HTTPS를 사용 시 증명서를 구입하여아 합니다. 증명서의 구입 비용이 부담되는 서비스나 개인 웹사이트의 경우 HTTP만 선택하기도 합니다.
그리고 HTTPS를 사용할 경우 처리가 늦어지게 되는 단점이 있습니다. 그 이유는 아래와 같습니다.

 

1. 클라이언트 요청 시, SSL에 필요한 통신이 추가됩니다

2. 암호화 복호화 계산을 하기 때문에 서버나 클라이언트의 리소스를 추가적으로 소비합니다.

 

위와 같은 이유로 항상 HTTPS를 사용하지 않습니다.

 

cf)HTTP 2.0 이 발전되면서 HTTPS 가 HTTP 보다 빠르다는 사실이 나왔는데요, 다음 링크를 통해 보다 자세한 내용을 확인하실 수 있습니다. 관련 링크 : HTTPS 가 HTTP 보다 빠르다.


출처: https://blog.sonim1.com/99 [Kendrick's Blog]
출처: https://dololak.tistory.com/541 [코끼리를 냉장고에 넣는 방법]

출처: github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/Network