HTTPS에서 HTTP 요청 블락 에러 해결하기

ㅁ 들어가며

  개발 환경에서나 B2B의 특별한 상황에서 HTTP와 HTTPS를 혼용해서 사용하는 경우가 있다.

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

HTTPS에서 HTTP 요청시 블럭이 발생한다고 개발 문의를 받게 되었다. 해결방법을 찾아가면서 설명했던 내용과 해결책을 정리하였다.

 

다소 설명이 길어졌는데, 한번 참고 보면 보안성 및 네트워크에 대해서 도움이 될 것이다.

HTTP와 HTTPS + SSL에 대해서 간략히 개념 정리를 하였다.

 

출처: https://www.cloudflare.com/ko-kr/learning/ssl/why-is-http-not-secure/

ㅁ HTTP vs HTTPS

HTTP/1.1 200 OK
Date: Wed, 30 Jan 2019 12:14:39 GMT
Server: Apache
Last-Modified: Mon, 28 Jan 2019 11:17:01 GMT
Accept-Ranges: bytes
Content-Length: 12
Vary: Accept-Encoding
Content-Type: text/plain

Hello World!

  HTTP는 복잡한 형식의 데이터를 주고 받는 것이 아닌, 텍스트를 주고 받는 평문 통신이다. 그렇기 때문에 통신을 가로챈다면 데이터를 그대로 볼 수 있어서 보안에 취약하다.

 

# HTTP
GET /hello.txt HTTP/1.1
User-Agent: curl/7.63.0 libcurl/7.63.0 OpenSSL/1.1.l zlib/1.2.11
Host: www.example.com
Accept-Language: en

# HTTPS로 변환하면 공격자들은 이렇게 보인다.
t8Fw6T8UV81pQfyhDkhebbz7+oiwldr1j2gHBB3L3RFTRsQCpaSnSBZ78Vme+DpDVJPvZdZUZHpzbbcqmSW1+3xXGsERHg9YDmpYk0VVDiRvw1H5miNieJeJ/FNUjgH0BmVRWII6+T4MnDwmCMZUI/orxP3HGwYCSIvyzS3MpmmSe4iaWKCOHQ==

  HTTPS는 HTTP의 보안성을 극복하기 위해  Secure Socket가 추가되었다. 기존의 HTTP 통신에 SSL 혹은 TLS 프로토콜를 조합하여 세션 데이터를 암호화한다.

 

ㅁ HTTPS의 공개키 암호화 방식

  HTTPS는 기본적으로 공개키 암호화 방식을 사용한다. 공개키로 암호화 하면 개인키로 복호화가 가능하다. 그래서 클라이언트는 HTTPS 통신을 위해 서버의 공개키를 가져와서 공개키 알고리즘과 공개키를 통해 전송하려는 평문을 암호화하여 보낸다. 이를 받은 서버는 개인키로 클라이언트의 데이터를 복호화 한다. 

 

출처: https://www.cloudflare.com/ko-kr/learning/ssl/what-happens-in-a-tls-handshake/

 

ㅇ SSL통신은 무엇인가요?

  위에서 이야기한 공개키 암호화 방식이 그대로 SSL통신에 적용된다. 클라이언트는 서버에서 서버인증서(CA)를 받아온다.
클라이언트는 서버인증서 신뢰 여부 체크 후, 공개키를 추출하게 된다. 여기서 추가적으로 알아야할 점은 대칭키이다. 이것을 SSL 핸드셰이

크라 부른다. 

 

ㅇ SSL 핸드셰이크란?

  클라이언트와 서버가 통신 할 때에 대칭키를 임의로 만들어 해당 대칭키를 공개키로 암호화 후 전송 한다. 서버는 개인키로 클라이언트가 보낸 메시지를 복호화하여 대칭키를 추출하고, 해당 대칭키를 이용하여 클라이언트와 통신한다. 이렇게 SSL 통신을 하면, 처음 한번 보안체크를 하고 서로는 통신하는 대상이 누구인지 식별하게 되어 정보의 정확성과 안정성을 높일 수 있다.

 

 정리하면, SSL 목적은 암호화 통신이고 핸드셰이크의 두가지 목표는 다음과 같다. 

• 서버와 클라이언트가 주고받을 데이터의 암호화 알고리즘을 결정
• 서버와 클라이언트가 주고받을 데이터의 암호화를 위한 동일한 대칭키 

 더 자세히 알고 싶으면 cloudflare - TLS 핸드셰이크의 원리는 무엇일까요?  | SSL 핸드셰이크를 참조.
   ㄴ 설명이 잘 되어 있어서 참조하였음.

HTTP은 80포트를 사용하여 TCP와 직접 통신하는 방식이었다면,
HTTPS는 443포트를 사용하여 HTTP -> SSL -> TCP의 순서로 통신하게 된다.

 

HTTPS가 보안성을 가진다는 것은 누구와 통신하는지 증명할 수 있고, 지속적인 연결을 전재하고 있다.

보안성을 가진 다는 말은, 다시 연결할 때에 누구인지 식별할 수 있는 정보를 유지하다고 말할 수 있다.

 

ㅁ HTTP의 특징

HTTP는 심플하여, 연결이 끝나면 끊긴다. 이를 보안하기 위해 HTTPS가 만들어졌다.

특징은 다음 두가지로 설명할 수 있다.

- Connectionless(비연결지향)

  ㄴ클라이언트가 서버에 요청하고 응답받으면 Connection은 끊긴다.

  ㄴ TCP 통신의 핸드셰이크의 특징이기도 하다.
  ㄴ HTTP Header에 keep-alive 옵션을 주면 Connection은 일부 유지될 수는 있지만, 기본적으로 비연결성을 지향한다.

- Stateless(무상태)

  ㄴ 연결의 상태 정보를 유지하지 않는다.

  ㄴ 세션정보나 쿠키 정보를 내포하고 있지 않다.

 

ㅁ HTTPS에서 HTTP 요청 블락

  보안성의 문제로 HTTPS가 적용된 사이트에서 HTTP로 요청을 전송하게 되면, 브라우저단에서 Block을 시켜버린다. 이미 보안이 낮은 사이트로는 연결해줄 수 없다는 것이다. 하지만... 상황은 늘 HTTPS를 적용할 수가 없다. 

 - 개발 로컬환경에 HTTPS를 적용하기는 쉽지 않는다.

 - B2B 환경

  ㄴ가장 확실한 보안은 HTTPS가 아니다. 전용선이다.

  ㄴ 네트워크를 공용이 아니라, 전용선으로 직접 연결한다면, HTTPS가 필요하지 않다.

  ㄴ 금융권에서는 법적으로 전용선을 이용하도록 규제되고 있다.

  ㄴ 예전에 고객 전용선과 관련된 작업은 [AWS] AWS Direct Connect 리소스 모니터링에서 언급하였다.

 

블락을 해결해보자!

 

ㅁ 해결방법 

ㅇ 보낼 때 HTTPS로 변경

  제일 간단하게 해결할 방법은 보내는 쪽에서 HTTPS로 보내면 된다. 음... 그럴 수 없는 것을 잘 알고 있다.

 

ㅇ url에 http, https를 빼라

한가지 트릭이 있다. URL 적용 시 http, https를 빼면 된다.

아래의 링크는 이렇게 적용해 두었다.

//velog.io/@shin6949/HTTPS에서-HTTP-요청-블락-에러-해결하기

 참조: HTTPS에서 HTTP 요청 블락 에러 해결하기

클릭하면 잘 이동한다. HTTP와 HTTPS를 자동으로 찾아간다. 개발와 운영에 유연성을 가질 수 있다.

 

ㅇ http-equiv Head 정보 추가

  외부 사이트가 HTTPS를 지원하지 않는 경우 HTML의 Head 부분에 아래 내용을 추가해주면 됩니다.

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

HTTP 컨텐츠를 자동으로 업그레이드 해주는 정책을 활성화한다.

 

ㅇ 웹서버를 사용하는 경우 Head 추가

 nginx를 사용한다면, 해당 URL에 다음을 추가할 수 있다.

add_header	Content-Security-Policy "upgrade-insecure-requests";

 자세한 설명은 Web App을 만들지 않은 서버 관리자의 경우를 참조

 

ㅁ 함께 보면 좋은 사이트

ㅇ HTTP가 안전하지 않은 이유는? | HTTP와 HTTPS의 비교

ㅇ SSL이란 무엇인가요?

ㅇ TLS 핸드셰이크의 원리는 무엇일까요?

ㅇ 공개 키 암호화는 어떻게 작동할까요?