HTTP와 HTTPS 그리고 Mixed Content

이 글은 'HTTP와 HTTPS Mixed Content'에 대해 적은 글입니다. 이 포스팅을 포함해 게시된 모든 포스팅의 큰 주제는 순차적인 흐름을 지키지 않습니다. 혼란에 주의해 주세요!

** '망나니개발자'님, '정아마추어'님 동의를 얻고 블로그에서 발췌한 글이 있습니다. 참고 부탁드립니다.

---

예전에 취업을 준비하면서 HTTP와 HTTPS의 개념에 대해 공부한 적이 있었다. 당시엔 이 둘의 차이는 보안에 취약하거나 혹은 보안에 이점이 있다는 사실에만 집중하고 말았지만, 최근 실무를 하면서 이 둘에 관련된 이슈가 발생했던 경험이 있다. 이 경험은 그동안 내가 얼마나 잘못된 방식으로 공부를 하고 있었는지, 또 어떤 부분을 채워 넣어야 할지 반성을 하고 다시 마음가짐을 재정비하는 계기가 되었다. 오늘 포스팅이 바로 그 재정비의 첫걸음이겠다.

 

이미지 출처: www.google.com

HTTP와 HTTPS의 정의?

Hyper Text Transfer Protocol

HTTP는 웹 브라우저(Client)와 서버(Server) 간의 웹 페이지의 자원을 주고받을 때 사용하는 통신 규약이다. 더 쉽게 정리하면, 클라이언트와 서버가 양쪽에서 통신할 수 있도록 구현해 주는 것이 바로 HTTP라고 생각하면 된다.

 

Hyper Text Transfer Protocol Secure

HTTP와 HTTPS의 차이점은 바로 'S' 한 글자 차이지만, 그 의미는 크다. 좀 더 정확하게 말하면 S는 Secure Socket Layer(SSL)를 의미하는 것으로 주고받는 정보가 암호화되어 있음을 뜻한다. 그렇다면 이 HTTPS는 왜 등장한 것일까?

 

HTTP는 단어에서도 유추할 수 있듯이 'HyperText Tranfer', 텍스트 교환이다. HTML 페이지 역시 'HyperText', 텍스트다. 즉, HTTP는 텍스트로 구성된 정보들을 네트워크상에서 주고받는 것이다. 의외로 직관적이고 단순 명료한 개념이어서 놀랍다. 하지만, 우리가 로그인 비밀번호가 단순하게 '1234'로 하면 위험하듯이 HTTP를 사용하다 네트워크 침입을 허용하게 되면, 중간에 정보가 노출되는 위험이 존재했다. 특히 HTTP는 단순 텍스트만을 주고받기 때문에 정보의 모든 내용들이 그대로 노출되었다. 이런 명확한 단점을 보완하고자 등장하게 된 것이 HTTPS다.

 

HTTPS의 특징

보안성이 강한 HTTPS

HTTP와 HTTPS의 가장 큰 차이점은 SSL 인증서다. SSL 인증서는 사용자가 웹 페이지에 제공하는 데이터를 암호화해준다. 이렇게 암호화된 데이터는 중간에 누군가가 침입을 하여도 암호화된 정보를 해독할 수 없다. 그 외에도 HTTPS는 TLS(전송 계층 보안) 프로토콜을 통해 보안을 유지한다. 이 TLS는 데이터의 무결성을 제공하는데, 데이터 전송 중에 수정, 손상을 방지해주며 사용자와 웹 페이지간에 올바르게 통신 중인지 서로를 인증해주는 기능도 제공하고 있다.

 

HTTPS의 동작 과정

HTTPS는 공개키와 개인키를 통해 데이터를 암호화한다.

 

- 암호화, 복호화를 할 때 서로 다른 키가 존재한다.

공개키: 모두에게 공개 가능한 키
개인키: 개인만 알 수 있는 키

- 이 두 개의 키는 서로 간에 일종의 상호작용하는 관계를 가진다. 예를 들어 공개키를 사용하여 데이터를 암호화했다면, 그 정보는 개인키로만 복호화가 가능하다. 반대로 개인키로 데이터 암호화를 했다면, 공개키로만 복호화가 가능하다.

공개키로 암호화, 개인키로 복호화 -> 개인키는 개인만 가지고 있으므로 나만이 볼 수 있는 데이터
개인키로 암호화, 공개키로 복호화 -> 공개키는 모두에게 공개가 가능하며, 암호화 과정이 개인키로 진행되었으므로 자신이 인증한 데이터임을 알려 신뢰성을 보장할 수 있다.

 

앞선 내용과 HTTPS 특징에서 언급한 SSL 인증서 등을 기반으로 데이터를 암호화한다는 사실을 알았다. 이렇게 개념을 알았지만, 도대체 인증서를 어떻게 처리하고 키들은 언제 발급받고 요청하는지 여전히 모르는 상태다. 지금부터 알아보자.

 

- 클라이언트가 요청을 보내면, 서버 측에선 암호화를 위한 공개키를 생성해야 한다. 이때 인증된 기관(Certificate Authority)에 공개키를 전송하여 인증서를 발급받을 수 있다.

1. A기업이 있다. A는 HTTP 기반의 애플리케이션에 HTTPS를 적용하기 위해 공개키, 개인키를 발급받는다.

2. A기업은 CA기업에 비용을 지불하고, 공개키를 저장하는 인증서 발급을 요청한다.

3. CA기업은 CA기업의 이름과 서버의 공개키, 서버의 데이터 등을 기반으로 인증서를 생성하고 CA기업의 개인키로 암호화하여 A기업에게 제공해준다.

4. A는 클라이언트에게 암호화된 인증서를 제공한다.

5. 브라우저에선 CA기업의 공개키를 미리 다운로드한 상태이며, 암호화된 인증서를 복호화한다.

6. 복호화를 통해 얻은 A기업의 공개키로 데이터를 암호화하여 요청을 전송한다.

- HTTPS는 이러한 공개키, 개인키 기반의 데이터 암호화를 통해 안전성을 확보한다.

 

그래서 내가 만난 이슈는?

Mixed Content

이미지 출처: www.google.com

빌드업(?)이 굉장히 길었다. 지금부터는 내가 만난 이슈의 내용과 해결 과정을 다루려고 한다. 실무를 하던 어느 날, 나와 같이(필자 본인은 왕초보 프론트엔드...) 주니어 백엔드 개발자분께서 API BASE URL을 수정하신다고 했었다. 당시 내가 적용하던 URL 주소는 HTTPS 기반이었는데, HTTP로 바꾸신다고 하셨다. HTTP와 HTTPS의 차이를 알고 있었지만 그때 '글자 하나 바뀐다고 무슨 일이 벌어질까?'라고 대수롭지 않게 여겼던 나를 생각하면 한대 쥐어박아주고 싶다. 나는 결국 HTTP로 주소를 바꾸고 배포를 하고 테스트를 진행하고 나서야 문제가 일어났음을 알 수 있었다. 당시 내가 마주한 에러 문구는 이렇다.

 

This request has been blocked; the content must be served over HTTPS.

 

브라우저에서 요청을 거부한 것. 이때부터 구글링을 해보니 원인은 바로 HTTPS에서 HTTP로 변경하여 데이터를 출력하려고 할 때 발생하는 이슈라고 한다. 대체 왜 브라우저에서 이러한 요청을 막는 것일까? 제대로 된 원인과 해결의 실마리는 HTTP와 HTTPS의 차이에서 알 수 있었다.

 

HTTPS는 사용자와 웹 서버 간을 암호화와 복호화를 통해 안전한 데이터만을 주고받는다고 정리하였다. 바로 이 HTTPS를 HTTP로 바꾸게 된다는 것은 단순히 말해 '비공개'모드에서 '공개'모드로 바꾸기 위해 시도했다는 것. 따라서 브라우저 입장에선 말도 안 되는 요청을 받아들였지만, 일종의 경고를 계속 보내주는 것이었다.

 

브라우저: 요청한 내용 보여주긴 할 게. 근데 그 뒤의 책임 감당할 수 있겠어?

 

이슈를 해결하기 위해 백엔드 개발자분에게 현 상황을 공유하고 해결방법을 찾기 위해 구글링을 하던 중, 서버에서 해결할 수 있는 방법을 찾았다. 바로 데이터를 암호화해주는 SSL 인증서에 기본적으로 HTTP로 접근하던 방식을 HTTPS로 redirect 시켜주는 방법이 있었다. 먼저 SSL 적용 URL을 찾아 HTTP를 변환시켜 redirect 시키고, 그 이후부터 HTTPS로 접근할 수 있도록 해주었다. 추가로 로컬 환경에선 HTTP든 HTTPS든 언제든지 테스트가 가능하도록 코드를 수정해 주었더니, 오류가 해결되었고 보안성도 지킬 수 있게 되었다.

 

마치며

하마터면 초보 개발자 둘이서 대형사고를 칠 뻔했다. 해결해서 다행이긴 하지만, 머리말에서 말했듯이 내가 얼마나 형식적으로 공부하고 실없는 행동들을 해왔는지에 대한 뼈저린 반성을 하게 되는 계기가 되었다...... 좀 정신 좀 차리고 다니자!!!

 

 

💯 참고 자료 출처

'망나니개발자'님 블로그

mangkyu.tistory.com/98#comment16869539

[Web] HTTP와 HTTPS 및 차이점

'정아마추어'님 블로그

jeong-pro.tistory.com/89

Http와 Https 이해와 차이점 그리고 오해(?)