HTTP와 HTTPS의 차이점(HTTPS의 동작과정)

HTTP란?

HTTP는 HyperText Transfer Protocol의 약자로 HTML을 전송하는 프로토콜로 시작하였으나 현재는 모든 것을 HTTP

메시지를 통해 전송합니다.

 

즉, 웹 상에서 클라이언트와 서버가 서로 정보를 주고받을 수 있도록 하는 규약입니다.

 

다음 그림은 HTTP 메시지의 예시입니다.

https://rhammer.tistory.com/242

Message Header와 Message Body로 이루어져 있습니다.

 

Message Header는 HTTP통신에 사용되는 여러 조건 또는 속성 등을 포함됩니다.

Message Body는 실제 요청하거나 요청받는 내용이 포함됩니다.

 

 

조금 더 디테일하게 보고 싶다면 다음 글을 참고하시면 좋을 것 같습니다.

 

https://junuuu.tistory.com/36?category=974977 

HTTP 기본

 

HTTPS란?

HTTPS는 HyperText Transfer Protocol에 Secure가 추가되었습니다.

즉, HTTP 프로토콜의 보안 버전입니다.

 

HTTPS의 등장배경

내 컴퓨터와 구글 서버는 서로 직접 연결되어 있지 않습니다.

따라서 구글 서버에 접속하기 위해서는 수많은 인터넷망을 거쳐 가야 합니다.

 

HTTP 메시지를 담은 패킷이 내 컴퓨터에서 출발하여 많은 인터넷 노드들을 거쳐서 구글 서버에 가는데 해커가 소중한 개인정보가 담겨있는 패킷을 보고 악용할 수 있습니다.

 

따라서 데이터를 주고받는 과정에서 '보안'요소가 추가되었습니다.

HTTPS를 사용하면 서버와 클라이언트 사이의 모든 통신 내용이 암호화됩니다.

 

다음은 HTTP와 HTTPS에서 해커가 내 패킷을 봤을 때 상황입니다.

https://rachel-kwak.github.io/2021/03/08/HTTPS.html

HTTP를 사용했을 때는 비밀번호를 그대로 볼 수 있는 반면에 HTTPS를 사용하게 되면 패킷을 보더라도 비밀번호는 암호화되어 있습니다.

 

HTTPS는 어떻게 패킷을 암호화할까요?

대칭키 방식

https://blog.naver.com/PostView.nhn?blogId=chodahi&logNo=221406287669&parentCategoryNo=&categoryNo=13&viewDate=&isShowPopularPosts=true&from=search

이름에서도 알 수 있듯이, 어떤 정보를 동일한 키로 암호화, 복호화할 수 있습니다.

따라서 암호화된 정보를 전달하고 확인하기 위해서는 송, 수신자 둘 다 동일한 키를 가지고 있어야 합니다.

이러한 키를 안전하게 교환하는 것이 대칭키 암호화 방식의 가장 중요한 부분이라 할 수 있습니다.

 

그러면 클라이언트와 서버가 응답, 요청을 하기 위해서는 결국 키를 한번 주고받아야 합니다.

이때 만약 해커가 이 키를 본다면? 암호화하는 의미가 없어질 수 있습니다.

공개키(비대칭키) 암호화

 

이름에서도 알 수 있듯이, 어떠한 정보를 다른 키로 암호화, 복호화합니다.

대칭키와 다르게 비대칭키를 활용한 암호화에는 개인키와 공개키 두 가지가 사용됩니다.

 

비대칭키를 활용하는 암호화는 두 가지 방식으로 나뉘게 됩니다.

 

1) 공개키로 암호화하는 방식

https://www.crocus.co.kr/1236

공개키는 누구나 알 수 있도록 공개된 키이므로, 어떤 정보를 특정 사용자에게 보낼 때 해당 사용자의 공개키를 통해 정보를 암호화하여 전송합니다.

 

이때 비대칭키 암호화 방식을 사용하기 때문에 공개키를 누군가 알더라도 해당 공개키로 암호화된 정보를 누군가 확인할 수 없습니다.

 

해당 공개키로 암호화된 정보를 복호화하기 위해서는 특정 개인키로만 열어볼 수 있습니다.

 

2) 개인키로 암호화하는 방식

 

개인키는 자신만이 가지고 있는 키로 어떤 정보를 특정 사용자에게 보낼 때 자기 자신의 개인키를 통해 정보를 암호화하여 전송합니다.

 

개인키로 암호화했기 때문에 공개키를 알아야 복호화할 수 있는데 공개키는 누구나 알 수 있습니다.

 

이 방법은 누군가 중간에 패킷을 공개키로 복호화한다면 HTTP 메시지 내용을 알 수 있지만 '내용이 어떤 것이냐'보다는 '누가 이 메시지를 보냈냐'애 초점을 둔 방식입니다.

 

A의 개인키로 암호화 한 메시지는 A의 공개키로만 열어볼 수 있습니다.

즉, 어떤 메시지가 A의 공개키로 열린다면 이는 A가 보낸 것입니다.

 

 

그러면 대칭키 방식은 위험하기 때문에 무조건 공개키(비대칭키) 방식을 사용해야겠네요?

실제 HTTPS 통신에서 실제 전송되는 데이터의 암호화에는 대칭키 암호화 방식을 사용하고, 키 교환에는 공개키(비대칭키) 암호화를 사용하여 공개키의 처리 속도가 느린 문제를 해결하고 있습니다.

 

 

HTTPS의 동작 과정

HTTPS는 HTTP의 하부에 SSL과 같은 보안 계층을 제공함으로써 동작합니다.

https://dailyscat.gitbook.io/twis/network/https

SSL 디지털 인증서

클라이언트와 서버 간의 통신을 공인된 제삼자 업체(CA)가 보증해주는 전자화된 문서

 

SSL과 TLS

SSL(Secure Socket Layer)와 TLS(Transport Layer Security)는 근본적으로는 다르나 동일한 의미로 사용됩니다.

SSL은 TCP/IP 암호화 통신에 사용되는 규약으로써 넷스케이프에서 만들었으며 SSL 3.0 버전부터 TLS 1.0로 업그레이드되었습니다.

 

SSL 방식을 적용하려면 인증서를 발급받아 서버에 적용시켜야 합니다.

인증서는 사용자가 접속한 서버가 우리가 의도한 서버가 맞는지를 보장하는 역할을 합니다.

 

인증서를 발급해주는 기관을 CA(Certificate Authority)라고 부릅니다.

공인인증기관의 경우 웹 브라우저는 미리 CA리스트와 함께 각 CA의 공개키를 알고 있습니다.

 

CA란?

CA는 Certificate Authority의 약자로 영어 그대로 인증기관이라는 뜻을 가집니다.

클라이언트와 서버가 HTTPS로 통신을 할 수 있도록 도와줍니다.

 

인증서 발급부터 어떤 식으로 사이트가 안전하게 사용자와 통신하는지 전체적으로 알아보겠습니다.

서버 = 사이트, 클라이언트 = 사용자입니다.

https://rachel-kwak.github.io/2021/03/08/HTTPS.html

1. 인터넷 사이트(서버)는 공개키와 개인키를 만들고, 신뢰할 수 있는 인증 기관(CA)에 자신의 정보와 공개키를 관리해달라고 계약하고(경우에 따라) 돈을 지불합니다.

 

2. 이때, 계약을 완료한 인증 기관은 기관만의 공개키와 개인키가 있습니다. 인증기관은 사이트가 제출한 데이터를 검증하고, 인증 기관의 개인키로 사이트에서 제출한 정보를 암호화하여 인증서로 만들어 제공합니다.

 

3. 사이트는 인증서를 가지게 되었습니다.

 

4. 인증기관은 웹 브라우저에게 자신의 공개키를 제공합니다.

https://rachel-kwak.github.io/2021/03/08/HTTPS.html

1. 사용자가 사이트에 접속합니다.

 

2. 서버는 자신의 인증서를 웹 브라우저(클라이언트)에게 보냅니다.

예를 들어, 웹 브라우저가 index.html 파일을 요청하면, 서버의 정보를 인증 기관의 개인키로 암호화한 인증서를 받게 됩니다.

 

3.  웹 브라우저는 미리 알고 있던 CA(인증기관)의 리스트 중 알맞은 공개키로 인증서를 해독하여 검증합니다.

인증서는 CA의 비밀키로 암호화되어 있기 때문에 CA의 공개키로 복호화할 수 있습니다.

복호화가 안전하게 되었다면 사용하는 서버가 인증된 서버임을 알 수 있습니다.

만약 복호화되지 않거나 인증되지 않았다면 이는 인증되지 않은 서버입니다.

 

1~3번 과정 속에서 주고 받는 데이터를 통해 대칭키를 생성합니다.(해당 대칭키가 "pre master secret" 이라는 키라고 불립니다.)

이 과정속에서 SSL에 의해 인증된 서버임을 알 수 있고 서버의 공개키 또한 알 수 있습니다.

 

4. 이렇게 얻은 서버의 공개키로 대칭키를 암호화하여 다시 사이트로 보냅니다.

 

5. 사이트는 개인키로 암호문을 해독하여 대칭키를 얻게 되고, 이제 대칭키로 데이터를 구조받을 수 있게 됩니다.

 

1~5번과 같은 과정을 SSL handshake라고 합니다.

https://rachel-kwak.github.io/2021/03/08/HTTPS.html

 

이해를 돕고자 다른 그림 하나도 첨부해보겠습니다.

https://wayhome25.github.io/cs/2018/03/11/ssl-https/

 

HTTPS를 사용하면 무조건 안전한가요?

• HTTPS를 지원한다고 해서 무조건 안전한 것은 아니다. 신뢰할 수 있는 CA 기업이 아니라 자체적으로 인증서를 발급할 수도 있고, 신뢰할 수 없는 CA 기업을 통해서 인증서를 발급받을 수도 있기 때문이다.

무조건 안전하다고 할 순 없지만 최소한의 필수요건, 안전장치라고 할 수 있습니다.

 

 

출처

https://rachel-kwak.github.io/2021/03/08/HTTPS.html(HTTPS란? 동작방식, 장단점)

https://universitytomorrow.com/22(무조건 이해 시켜드립니다. 대칭키와 비대칭키)

https://www.youtube.com/watch?v=H6lpFRpyl14 (HTTPS가 뭐고 왜 쓰나요? 대칭키 비대칭키)

https://dailyscat.gitbook.io/twis/network/https(HTTPS가 동작하는 방식)

https://www.youtube.com/watch?v=XOfMj-JwckQ(SSL인증서를 이용하여 안전한 사이트 인증하기)