목차
HTTP와 HTTPS
HTTP
"http:// ~ "
HTTP란 서버/클라이언트 간에 데이터를 주고받기 위한 프로토콜이다. (80 포트 사용)
HTTP가 진화하면서 하이퍼텍스트 문서(HTML) 뿐만 아니라 이미지, 비디오 등과 같은 데이터도 주고받을 수 있게 되었다.
그러나 HTTP는 문제가 있다.
1) 보안 취약성
HTTP는 암호화를 하지 않고 평문으로 전송한다.
이는 중간에 제 3자가 네트워크 상에서 데이터를 엿볼 수 있기 때문에 보안에 매우 안좋다.
2) 무결성 문제
무결성을 보장하지 않는다. 전송 중에 데이터가 변경되거나 조작될 수 있으며 이로인해 정보의 정확성은 보장할 수 없다.
3) 신원 보증의 부재
서버의 신원을 확인하는 기능이 없다. 따라서 중간에 제 3자가 서버를 위장하여 클라이언트와 통신할 수 있다.
이러한 HTTP의 주요한 문제들을 해결하기 위해 HTTPS가 나오게 되었다.
HTTPS
"https:// ~ "
HTTP에 데이터 암호화가 추가된 프로토콜이다. ( 443 포트 사용)
1) 보안 취약성 해결
HTTP는 SSL/TLS 프로토콜을 사용하여 데이터의 암호화를 제공한다.
암호화 방식은 대칭키, 비대칭키 방식 모두 사용하고 있으며, 비대칭키(공개키)로 암호화한 대칭키를 이용하여 통신을 하고 있다.
2) 무결성 보장
HTTPS는 데이터의 무결성을 보장하기 위해 메시지 다이제스트를 사용한다.
-> 데이터를 전송하기 전에, 데이터를 바탕으로 다이제스트 값을 생성하고 함께 보낸다.
-> 데이터를 받는 서버/클라이언트는 받은 데이터로 다이제스트 값을 계산한다.
-> 계산한 다이제스트 값과 전송된 다이제스트 값이 같다면 데이터가 변하지 않았다는 뜻이다.
3) 신원 보증
HTTPS는 인증 기관(Certificate Authority)에 의해 발급된 서버 인증서를 사용하여 서버의 신원을 확인한다.
-> 인증기관에서 해당 웹 사이트가 어떤 사이트인지, 누구의 소유인지 등 정보를 인증해준다.
-> 이를 더 자세히 설명하면, 서버는 CA에서 인증서를 발급받고
-> 이를 클라이언트에 전송한뒤 클라이언트는 CA의 공개키를 이용하여 복호화한 뒤 신원을 확인할 수 있다.
🤔 메시지 다이제스트란?
데이터를 수학적으로 압축해서 만든 짧고 고유한 값이다.
예를 들어, "Hello World!" 라는 데이터를 입력하면 12345와 같은 고유한 다이제스트 값이 생성된다.
만약 데이터가 조금이라도 변하면 (예: "HellO World!") 다이제스트 값은 완전히 달라진다. ( 예: 67890 )
🤔 SSL/TLS 란?
SSL과 TLS는 네트워크 통신에서 데이터의 보안 및 기밀성을 제공하기 위한 프로토콜이다.
SSL은 초기 버전이며, TLS는 SSL의 후속버전으로 "SSL/TLS" 라는 용어로 함께 언급되거나 특별하게 구분하지 않고 SSL이라고 말하기도 한다. ( SSL이라는 용어 자체가 보안 프로토콜을 대표하기 때문 )
HTTPS의 동작 과정
정리하면, https 의 동작과정은 대칭키, 비대칭키 방식을 사용하고 있으며, 인증기관에서 인증서를 발급받아 신원 또한 인증해야한다.
그렇다면 https 통신 전에, 인증서를 먼저 발급받아야 한다.
HTTPS의 인증서 발급 과정
서버(A기업)은 자체적으로 공개키, 개인키 생성
1) 인증기관(CA)에게 공개키와 A기업 정보를 보내면서 인증서를 만들어달라 요청
2) CA는 공개키를 확인한 후, 인증서 생성 후 서버(기업A)에 전달 ( 인증서는 CA의 개인키로 암호화 )
3) 인증기관(CA)의 공개키를 클라이언트에게 전달
🤔 공개키 어떤 걸 확인하고 인증서를 발급해주나?
1) 도메인 소유권 확인 : 서버가 해당 도메인의 합법적인 소유자인지 확인
ex) www.example.com의 인증서를 요청할 경우, CA는 그 도메인이 실제로 해당 서버에 속하는지 검증
2) 공개키의 유효성 : 공개키가 실제로 유효하고 안전한지 확인
3) 요청자 신원 검증 ( 선택적) : 요청의 신원 검증
🤔 CA의 개인키로 왜 암호화하나?
CA는 공인된 인증기관으로, 인증서를 발급할 때 해당 인증서가 CA가 발급한 것임을 보장하기 위해 (신뢰성 보장)
동작 과정
HTTPS는 대칭키 암호화와 비대칭키 암호화를 모두 사용한다.
[ 서버: 공개키 전달 ]
1) 클라이언트가 서버로 최초 연결을 시도함
2) 서버는 공개키를 포함한 암호화된 인증서를 클라이언트에게 보냄
[ 클라이언트: 대칭키 전달 ]
3) 클라이언트는 대칭키 생성
4) CA의 공개키를 이용해 인증서를 복호화하여 서버의 공개키를 얻음.
5) 서버의 공개키를 사용해 대칭키를 암호화한 뒤, 서버로 보냄
[ 서버: 복호화 ]
6) 서버는 자신의 개인키를 사용하여 암호화된 대칭키를 복호화함
결론
HTTP는 암호화가 추가되지 않아,보안에 취약하다.
HTTPS는 보안이 추가되어 안전하게 데이터를 주고받을 수 있다.
그러나 HTTPS를 사용하게 되면 암호화/복호화 과정이 필요하기 때문에 HTTP보다 속도가 느리다 ( 거의 차이를 못느낄 정도임 )
또한 HTTPS는 인증서 발급, 유지하기 위해 추가비용이 발생한다.