본문 바로가기

IT

HTTP와 HTTPS의 차이는 뭘까?

드디어 알아보게 된 HTTP와 HTTPS의 차이를 알아보려고 합니다. 이 개념을 저는 정보처리기능사에서

"HTTPS가 HTTP에 비해서 더 보안성이 좋다. "라고 알고 있습니다. 하지만 왜 어떤 점에서 보안성이 더 

좋은 것인지 모르고 있어서 이번 블로그를 통해서 알아볼까 합니다. 

HTTP가 뭘까?

HTTP(Hyper Text Transfer Protocol)의 약어로, 인터넷에서 데이터를 주고받을 수 있는 프로토콜입니다.
(하이퍼텍스트 전송 프로토콜)

 

프로토콜이란?
데이터를 주고 받기 위한 규칙이며, TCP/IP 위에서 동작하며 80번 포트를 사용하여 통신을 한다는 특징이 있다.

 

팀 버너스 리

⭐️ HTTP의 역사 ⭐️

1989년 팀 버너스 리(Tim Berners Lee)에 의해 처음 설계되었으며, WWW(World-Wide-Web) 기반에서 세계적인 정보를 공유하는데 큰 역할을 하였다.

HTTP의 특징은 뭘까?

⭐️ 비-연결 지형

클라이언트가 서버에게 리소스를 요청하고 응답을 받으려면 바로 끊어버리는 개념이다.
연결을 계속 유지를 하게 된다면 서버에서 많은 부담을 줄 수 있기 때문에 클라이언트에게 요청을 받는
웹 서버의 경우 응답을 받는 즉시 바로 연결을 차단하는 특징을 지니고 있다.

⭐️ 무상태성


각각의 요청이 독립적으로 여겨지는 개념으로, 서버는 클라이언트의 상태를 유지하지 않는다.
즉, 클라이언트에 맞게 리소스를 응답하는 것이 불가능하기 때문에 각 클라이언트에서 요청하는
유저를 특정할 수 없다.

HTTP는 아래와 같은 구조로 이뤄져 있다.

http는 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동한다는 것을 알고 있을 것이다.
http는 상태를 가지고 있지 않는 무상태성이라고 위에서 설명을 했다. 그런 Stateless 프로토콜이며

Method, Path, Version, Headers, Body로 구성이 되어 있다.

 

하지만 http는 암호화가 되지 않는 평문 데이터를 전송하는 프로토콜이기에 http로 아이디나, 비밀번호 등을

주고받으면서 제 3자에게 정보를 유출당할 수 있었다. 

 

이걸 해결하기 위해서 무엇이 나왔다?? 바로 HTTPS가 나왔다!! 🔥

 

 

HTTPS는 HTTP에 데이터 암호화가 추가된 포로토콜이다. HTTP는 기존 80번 포트를 사용하였지만
HTTPS는 443번 
포트를 사용하며, 네트워크 상에서 중간에 제 3자가 정보를 볼 수 없도록 암호화를 하고 있다.

이러한 HTTP의 보안은 HTTPS가 하고 있다? ➡️ false


그러면 HTTPS의 보안을 어디서 하고 있는 걸까?

HTTP의 보안은 HTTPS가 아닌 다른 곳에서 담당을 하고 있는데 그곳은 바로 SSL(Secure Sockets Layer)

 

⭐️ SSL이 뭘까?

SSL은 클라이언트와 서버가 서로 데이터를 암호화해 통신할 수 있도록 돕는 보안 계층이다.
HTTPS를 사용하면 HTTP 메시지에 포함되는 콘텐츠 정보에 보안 요소가 추가가 된다.
그리하여서 데이터가 안전하게 주고받을 수 있는 것이다.

 

 

SSL의 짝꿍이라고 불리는 TLS이라는 프로토콜도 있는데, "SSL과 차이가 있으니까 약자가 다르지 않을까?"

라는 생각이 들었다. 그러면 어떤 차이가 있는 걸까? 


사실 이 SSL과 TLS는 같은 보안 프로토콜에서 시작이 되었습니다. 근데 왜 SSL과 TLS는 왜 이름이 다를까??

 

이유는 SSL이 막 등장하기 시작한 90년대 후반에 2.0 버전에 취약점이 많이 발견이 되었습니다. 
이를 해결하기 위해서 처음부터 구조를 다시 설계하여 3.0 버전을 만들었습니다. 사람들은 그러한
3.0 버전과 2.0 버전의 차이를 두고 이름을 불러야 하기에 SSL은 2.0 TLS은 3.0이 된 것입니다.

하지만 처음 나온 SSL이 많은 사람들에게 익숙하기에 많은 프로토콜이 TLS로 교체되어 SSL을 사용을
하지는 않지만 사람들이 부르기로는 SSL이라고 하는 것이죠!! 이해가 되셨나요??


대칭키와 공개키로 확실하게 이해하기 🔐

암호화를 하기 위해서 비밀번호와 같은 역할인 키(key)가 존재합니다.
이러한 키가 있어야지만 암호화를 하고, 반대로 암호를 푸는 복호화도 할 수 있다. 
SSL은 두 가지의 핵심 개념이 존재하는데 그 핵심은 대칭키과 공개키이다.


대칭키 기법

먼저 대칭키 기법입니다.

대칭키 기법은 중요한 핵심 단어인 "한 개"라는 것!! 하나의 키로 암호화와 복호화를 둘 다 할 수 있는

그런 암호화 기법 중에 하나입니다. 위에 예를 들어서 설명을 해보겠습니다. 출처(brunch - naver)

위에 보물 상자가 있는데, 하나의 열쇠의 구멍이 있고, 거기에 맞는 열쇠 하나로 보물 상자를 열고,
닫을 수 있습니다. 또 다른 예시로 쉽게 설명하면 웹 통신으로는 클라이언트와 서버가 각각 "이태랑"
이라는 키를 가지고 있다가 데이터를 응답받았을 때 이 "이태랑"이라는 키로 복호화를 하고, 다시 
요청을 보낼 때는 "이태랑" 키를 가지고 암호화를 하여 전송하는 방식인 거죠.

 

대칭키는 하나의 키를 사용하기 때문에 제 3자가 키를 탈취하면 보안성이 취약해진다는 단점이 있습니다.

⭐️ 이를 해결하기 위해서 나온 기법이 무엇이다?? ➡️ 공개키

 

공개키 기법

이러한 공개키는 대칭키를 보완하기 위해서 탄생하게 되었습니다.

 

위에 보물 상자가 아까 대칭키와 같이 존재하고 있습니다. 하지만 대칭키는 암호화, 복호화를 같은 키로
사용한다는 특징을 가지고 있습니다. But 공개키는 다른 형태인 열쇠가 "두 개"가 한 쌍으로 존재합니다.
"이태랑"이라는 키를 가지고 상자를 암호화시키면 "이승제"라는 키를 가지고 복호화를 시켜야 합니다.

 

이렇게 된다면 제 3자가 "이태랑"이라는 키를 알아도 "이승제"라는 키를 모르니까 보안성이 튼튼하겠죠??

서버가 개인키를 가지고, 클라이언트에서 공개키를 전달해 서로 데이터를 주고받고 있는 상태에서 중간에

공개키를 가로챘다고 해서 개인키를 모르기 때문에 데이터를 복호화할 수 없는 것입니다.

 

공개키는 대칭키보다 더 보안성이 높다는 장점이 있지만, 암호화 과정이 복잡하여 시간이 걸립니다.

SSL은 이러한 대칭키와 공개키의 기법을 함께 통합하여 각각의 장점을 살려 사용합니다.

 

SSL의 동작 과정은 어떻게 될까?

 

1단계 : 클라이언트에서 인사를 하여 서로 현재 지원할 수 있는 암호화 방식을 서버에게 전달한다.
즉, "우리 연결 시도할 거예요"라는 의미에서 보내는 것이다.
2단계 : 클라이언트에게 "오키 연결 완료"라고 하며 응답을 보내고 세 가지 내용을 보내게 되는데
랜덤 데이터, 현재 지원 가능한 암호화 방식, 인증서를 전달합니다. 여기서 인증서는? 서버가 공식으로
인증된 기관인 CA(Certificate Authority)에서 발급받은 문서로 신뢰성을 제공한다.
3단계 : CA로 발급된 인증서를 확인하여 서버에서 전달하여 유효한 인증서를 확인합니다.
확인을 했다면 재확인을 하고 인증서를 복호화하여 자신의 비밀키로 암호화 성공을 나타냅니다.
신뢰 🙆🏼‍♀️
4단계 : 대칭키를 임시로 만들어서 사용을 합니다. 이제 진짜 통신을 하기 위해 키를 만듭니다.
임시로 만든 이 키는 절대 제 3자에게 노출이 되어서는 안 됩니다. 그리하여 공개키로 암호화하여서
이 키를 서버에 전달합니다.
5단계 : 키를 받은 서버는 본인의 비밀키로 암호를 해독해서 임시키를 전달받게 됩니다.
이건 뭐다??? 둘 다 키를 같은 것을 가지게 되고 사용이 가능하다.
6단계 : 결국 이러한 과정을 거친 클라이언트와 서버는 임시키가 세션 키로 바뀌고 이러한 세션키를 
가지고 본격적으로 통신이 가능해진다.

 

⭐️ 여기서 세션키란? ⭐️

세션키를 이용하여 대칭키의 기법으로 데이터를 암호화해서 통신을 하고, 동작이 끝나면 세션을
종료하여 통신을 마칩니다. 그럼 이때 사용한 세션키도 자동으로 삭제가 되는 것이죠.

이러한 과정으로 HTTPS로 안전하게 데이터를 주고받는 것입니다.


느낀 점

아직 SSL에 대한 이해도가 너무 적어서 더 알아봐야 할 것 같다. 내가 오늘 작성한 블로그도 솔직하게

이해가 잘 안 되는 부분도 정말 많았다. 또 추가적으로 세션 부분, 3 Way-Handshake 등등 이러한

개념도 조금 더 공부를 하고 다음 블로그에서 작성하는 것이 좋을 것 같다.